No ideal: (
Cry.
Pachimu if the name Juniper counters longer than 23 characters, then the counters are not available by snmp (jnxFWCounter)? Where did the idea for this strange limitation?
Here For example, colocall-in-rate-limit is, and colocall-out-rate-limit - no longer exists. : (
In addition, from cli counters that you can watch without any problems.
MX480, 9.5R2.7
What poliser considers only dropnutye packages, but not dropnutye bytes - uncomfortable, but this has already resigned himself (you have to multiply the number of packets dropnutyh the average packet size). While that's even considered normal s6500 and Packages and bytes.
Saturday, September 26, 2009
Thursday, September 24, 2009
Pokemon Gold Silver Trade Vba
What to do with harmful more specific routes
There's an old problem:
client announces / 23 upstream and the same grid as the two / 24, IX (for example, UA-IX). The result is that traffic comes from the world upstream on / 23, and then the client is already on / 24 (more specific) through IX. As a result, the client receives the external traffic through IX, with no speed limits, accounting, etc.
issue in detail investigated and described Ginsburg here , and give a solution for JunOS (for which many thanks to him). Therefore, I can only tell their own words, lead configuration for Cisco, and to describe other, less accurate and more simple solutions.
Firstly, just want to say that the administration to tackle the problem unpromising. The client can this be done without malice. In the end, nothing illegal, he does not.
first thing that comes to mind for the protection of from this situation - the imposition of IX to a separate router. Customers who have their own inclusion in the IX, made by "external" router, which just announced by IX no. Drawbacks: firstly, the client may want to reserve access to that IX, secondly, the client should switch to another router if it is connected to IX, in the third place, the client may not be included in the IX, but some client of the client - to be in the fourth, different IX may be several (KH-IX, UA-IX, DE-CIX, etc .), and it is unclear as their share of routers. Actually, the traffic from the IX is a "bonus" for the upstream, which is denied, providing the client paid only IPT-traffic апстриму, очевидно, невыгодно. Вместо отдельных роутеров, разумеется, можно использовать разные vrf в пределах одного роутера. Ещё вариант - строить с клиентами two BGP-session "peace" and "Ukraine" (in other words, IPT, and IX). If IX is only one solution to completely work, though, and creates some inconvenience for customers.
second option - To filter traffic on a router, which goes from upstream to IX. More specifically, from the upstream and peering links of the traffic should go only to customers, and all that goes out on the upstream or peering, start dropping. The disadvantage is that the client in this case simply did not work, causing his displeasure. In addition, upstream and peering can be incorporated into different routers, and in this case, the filtering interface receives more difficult.
solution proposed Ginsburg, the most correct, although not always easy to implement. Namely: to have two routing tables, one only clients, and in another - fullview. Traffic from upstream and peering is being routed to the first table of customers - for the second. In this case, traffic from upstream will take on a client, even if from the IX is more specific route. It does not require a lot of memory, because the client routes is relatively small. A small additional modification: make another routing table, which there is only client prefixes and fallback to the complete table, if the route is not found, and the table used for routing traffic from clients. In this case, traffic from one customer goes to another client, even if there are more specific to IX. Disadvantage: in case of multiple routers decision on where the package is being routed, should be taken immediately at the entrance to the package in our network. That is, it is suitable for MPLS-networks and for networks with a single "external" router, but not very suitable for the rest. However, not hopeless: if external links are included in the different routers, then you can either mark traffic, or build internal links so as to always was unambiguously clear whether upstream traffic from the client or vice versa.
Example configuration with different routing tables for JunOS is at Ginsburg. For Cisco is roughly the same, using vrf. Derived from the upstream traffic in zarulivaetsya vrf through PBR (more elegant solutions are not invent). Checked and ISR (3825, 7200) and 6500 (12.2 (33) SXI) - works. In some cases, the NO-LOCAL to add traffic to its own IP, otherwise the behavior of the receiving country. Configuration changes BGP не требуется.
UPD: Возможные грабли. Up to a 1000 prefixes will be imported by default. The prefix-limit argument is used to specify a limit from 1 to 2,147,483,647 prefixes. That is, if the client prefixes may be more than 1000 (including as a result of erroneous stuffing customer something extra) better in line
There's an old problem:
client announces / 23 upstream and the same grid as the two / 24, IX (for example, UA-IX). The result is that traffic comes from the world upstream on / 23, and then the client is already on / 24 (more specific) through IX. As a result, the client receives the external traffic through IX, with no speed limits, accounting, etc.
issue in detail investigated and described Ginsburg here , and give a solution for JunOS (for which many thanks to him). Therefore, I can only tell their own words, lead configuration for Cisco, and to describe other, less accurate and more simple solutions.
Firstly, just want to say that the administration to tackle the problem unpromising. The client can this be done without malice. In the end, nothing illegal, he does not.
first thing that comes to mind for the protection of from this situation - the imposition of IX to a separate router. Customers who have their own inclusion in the IX, made by "external" router, which just announced by IX no. Drawbacks: firstly, the client may want to reserve access to that IX, secondly, the client should switch to another router if it is connected to IX, in the third place, the client may not be included in the IX, but some client of the client - to be in the fourth, different IX may be several (KH-IX, UA-IX, DE-CIX, etc .), and it is unclear as their share of routers. Actually, the traffic from the IX is a "bonus" for the upstream, which is denied, providing the client paid only IPT-traffic апстриму, очевидно, невыгодно. Вместо отдельных роутеров, разумеется, можно использовать разные vrf в пределах одного роутера. Ещё вариант - строить с клиентами two BGP-session "peace" and "Ukraine" (in other words, IPT, and IX). If IX is only one solution to completely work, though, and creates some inconvenience for customers.
second option - To filter traffic on a router, which goes from upstream to IX. More specifically, from the upstream and peering links of the traffic should go only to customers, and all that goes out on the upstream or peering, start dropping. The disadvantage is that the client in this case simply did not work, causing his displeasure. In addition, upstream and peering can be incorporated into different routers, and in this case, the filtering interface receives more difficult.
solution proposed Ginsburg, the most correct, although not always easy to implement. Namely: to have two routing tables, one only clients, and in another - fullview. Traffic from upstream and peering is being routed to the first table of customers - for the second. In this case, traffic from upstream will take on a client, even if from the IX is more specific route. It does not require a lot of memory, because the client routes is relatively small. A small additional modification: make another routing table, which there is only client prefixes and fallback to the complete table, if the route is not found, and the table used for routing traffic from clients. In this case, traffic from one customer goes to another client, even if there are more specific to IX. Disadvantage: in case of multiple routers decision on where the package is being routed, should be taken immediately at the entrance to the package in our network. That is, it is suitable for MPLS-networks and for networks with a single "external" router, but not very suitable for the rest. However, not hopeless: if external links are included in the different routers, then you can either mark traffic, or build internal links so as to always was unambiguously clear whether upstream traffic from the client or vice versa.
Example configuration with different routing tables for JunOS is at Ginsburg. For Cisco is roughly the same, using vrf. Derived from the upstream traffic in zarulivaetsya vrf through PBR (more elegant solutions are not invent). Checked and ISR (3825, 7200) and 6500 (12.2 (33) SXI) - works. In some cases, the NO-LOCAL to add traffic to its own IP, otherwise the behavior of the receiving country. Configuration changes BGP не требуется.
ip vrf upstreams
rd xx:yy
import ipv4 unicast map IMPORT-UPSTREAMS
!
interface GigabitEthernet0/1.100
description Upstream
encapsulation dot1Q 100
ip address 4.1.1.1 255.255.255.252
ip policy route-map FROM-UPSTREAM
!
route-map FROM-UPSTREAM permit 10
match ip address NO-LOCAL
set vrf upstreams
!
route-map IMPORT-UPSTREAMS permit 10
match community CLIENTS
!
route-map IMPORT-UPSTREAMS permit 20
match community FROM-IGP
!
route-map IMPORT-UPSTREAMS deny 30
!
ip access-list extended NO-LOCAL
deny ospf any any
permit ip any any
!
UPD: Возможные грабли. Up to a 1000 prefixes will be imported by default. The prefix-limit argument is used to specify a limit from 1 to 2,147,483,647 prefixes. That is, if the client prefixes may be more than 1000 (including as a result of erroneous stuffing customer something extra) better in line
import ipv4 unicast explicitly known to a sufficient number of imported prefixes. Tuesday, September 22, 2009
Office Sitting Plan Sample
Likbez
I used to think that everyone who configures BGP or MTA, in general outlines know how to do it. Now I see that Rout-faces - this is not the only random errors, and frighteningly mass phenomenon. So I think that the description of the banal and obvious for many things would not be amiss.
1. BGP-interactions are with the upstream, with customers and peering, ie, parity (for more complicated cases are not view). If Submarine little, peering not. If very small customers with BGP also there is only upstream. BGP must be configured so that upstream (and peering) went announcements only from clients but not from other upstream. Filter networks (access-list or prefix-list) does not solve this problem! customer may have an alternative you upstream, and the prefix of your client received not directly from him, and from upstream, will go to another upstream. Today may be all right, but tomorrow your client will be changed. Not only that: a filter for the as-path this problem, too, in general, does not solve: when you're the fifth time change upstream, carefully redraw all the filters you likely to forget. Correct this problem is solved by bgp community: on announcements received from upstream, putting a special community attribute, and announcements with this attribute upstream do not give. Or vice versa: a special attribute bet on announcements from customers and upstream give only them and nothing else. Then the announcements of your client's leave upstream, if you got them directly from the customer, and will not leave if they are received in a different way (from upstream).
2. Community are external and internal. External - the ones that you give to customers and are taking them. Internal - which use only within their own AS. To routing occurred correctly, the client or upstream should not be able to put the community on the basis of which will change the view of the origin of this announcement. For example, wrong to allow a situation where upstream announcement sent to your "client" community, and this announcement went to another upstream. To avoid this, internal community needs to be cleaned at a reception announcements from both customers and from upstream. For example, the internal community can be a two-or three-digit, and the external - Four-and five-digit, and at the reception, you can delete all of its two-and three-digit community. "Ours" - which is part of xxxx: yyyy Part xxxx - your Submarine.
3. Rule good taste: delete all your unwanted community when exporting announcements. That is, even when all its export upstream, and all except the special information, for export customers. Unnecessary clutter up your community memory routers (worldwide!) And increase the convergence time bgp.
4. Do you think that you have a routing All right? Dial the number to your Submarine here and click "show route-leaks". Most likely, you will learn many interesting things. If you suddenly found nothing - do not relax and look over a longer period of time, it was before.
5. Do not use any weight, unless you know exactly why and what you are doing. For separation prefixes on the priorities there local-preference. The difference is that localpref transmitted between your routers, it is enough to put on the outside of bgp.
6. When configuring BGP on Cisco and many other platforms, you must first register number of the Submarine at the other end (remote-as). Immediately thereafter, BGP strives to rise to the prescription of any filters. As a result, upstream collects from you fullview, or do you get fullview from his client. To this was not, bgp should not rise immediately, while it is not configured completely. In a more or less recent versions of IOS specifically for this at the command "neighbor ... remote-as ..." in the end you can say "shutdown". If this is not possible, first zadaunite sabinterfeys, then configure BGP with all filters, and only then say "no shutdown". Fortunately, at Juniper is no such problem: there can be everything first register and then to commit.
7. A that does not keep all configs routers in cvs or svn? And do not track changes difam? And how to live without it? ;-)
On a more complex version appears Rout-faces I'll write next time.
UPD: I forgot to mention about the much-needed for the client and the peer BGP configuration, as a restriction on the number of prefixes. Very helps against Rout-faces and other troubles. For example, for Cisco IOS: "
I used to think that everyone who configures BGP or MTA, in general outlines know how to do it. Now I see that Rout-faces - this is not the only random errors, and frighteningly mass phenomenon. So I think that the description of the banal and obvious for many things would not be amiss.
1. BGP-interactions are with the upstream, with customers and peering, ie, parity (for more complicated cases are not view). If Submarine little, peering not. If very small customers with BGP also there is only upstream. BGP must be configured so that upstream (and peering) went announcements only from clients but not from other upstream. Filter networks (access-list or prefix-list) does not solve this problem! customer may have an alternative you upstream, and the prefix of your client received not directly from him, and from upstream, will go to another upstream. Today may be all right, but tomorrow your client will be changed. Not only that: a filter for the as-path this problem, too, in general, does not solve: when you're the fifth time change upstream, carefully redraw all the filters you likely to forget. Correct this problem is solved by bgp community: on announcements received from upstream, putting a special community attribute, and announcements with this attribute upstream do not give. Or vice versa: a special attribute bet on announcements from customers and upstream give only them and nothing else. Then the announcements of your client's leave upstream, if you got them directly from the customer, and will not leave if they are received in a different way (from upstream).
2. Community are external and internal. External - the ones that you give to customers and are taking them. Internal - which use only within their own AS. To routing occurred correctly, the client or upstream should not be able to put the community on the basis of which will change the view of the origin of this announcement. For example, wrong to allow a situation where upstream announcement sent to your "client" community, and this announcement went to another upstream. To avoid this, internal community needs to be cleaned at a reception announcements from both customers and from upstream. For example, the internal community can be a two-or three-digit, and the external - Four-and five-digit, and at the reception, you can delete all of its two-and three-digit community. "Ours" - which is part of xxxx: yyyy Part xxxx - your Submarine.
3. Rule good taste: delete all your unwanted community when exporting announcements. That is, even when all its export upstream, and all except the special information, for export customers. Unnecessary clutter up your community memory routers (worldwide!) And increase the convergence time bgp.
4. Do you think that you have a routing All right? Dial the number to your Submarine here and click "show route-leaks". Most likely, you will learn many interesting things. If you suddenly found nothing - do not relax and look over a longer period of time, it was before.
5. Do not use any weight, unless you know exactly why and what you are doing. For separation prefixes on the priorities there local-preference. The difference is that localpref transmitted between your routers, it is enough to put on the outside of bgp.
6. When configuring BGP on Cisco and many other platforms, you must first register number of the Submarine at the other end (remote-as). Immediately thereafter, BGP strives to rise to the prescription of any filters. As a result, upstream collects from you fullview, or do you get fullview from his client. To this was not, bgp should not rise immediately, while it is not configured completely. In a more or less recent versions of IOS specifically for this at the command "neighbor ... remote-as ..." in the end you can say "shutdown". If this is not possible, first zadaunite sabinterfeys, then configure BGP with all filters, and only then say "no shutdown". Fortunately, at Juniper is no such problem: there can be everything first register and then to commit.
7. A that does not keep all configs routers in cvs or svn? And do not track changes difam? And how to live without it? ;-)
On a more complex version appears Rout-faces I'll write next time.
UPD: I forgot to mention about the much-needed for the client and the peer BGP configuration, as a restriction on the number of prefixes. Very helps against Rout-faces and other troubles. For example, for Cisco IOS: "
neighbor ... maximum-prefix 100 restart 10 ", for JunOS: " set protocols bgp group CLIENTS family inet unicast prefix-limit maximum 100 teardown idle-timeout 10 ". That is, if a client sends more than hundreds of announcements, BGP with it automatically zadaunitsya for 10 minutes, then automatically rises, and if the client by the time the error is corrected, he will live, and if not - again lie down for 10 minutes, and so on. Of course, this limit can be set individually for different customers. Friday, September 11, 2009
![[info]](https://lh3.googleusercontent.com/blogger_img_proxy/AEn0k_s17NwgKk3g7wDHlnbn9MXVHFNpWvBo0SxsqO5Znww4uWi80vEqBDu1YEq59GiSsOnJwHZYJrkh9uG2ZxPaSMnC9K-SyDbMmvaly4IEJhYBMifz-A=s0-d){kind=small}
Subscribe to:
Posts (Atom)