Internetworking perspectives by Ivan Pepelnjak
Quick update: A comment by alvarezp to my EIGRP next-hop post sent me back to the lab. I was spreading wrong rumors ... with the no ip next-hop-self eigrp AS command configured, the next-hop field in the EIGRP updates is used and works as expected in NBMA and route redistribution environments. A detailed post will appear sometime next week.
I would also like to apologize for any confusion I might have caused.
A while ago, Cisco IOS did not allow you to run more than 30 routing processes per router, significantly limiting the options of Service Providers who wanted to support OSPF as the PE-CE routing protocol. The architectural reason for the limit is a 32-bit mask that’s used in Cisco IOS to mark individual routing protocols. The routing protocol ID (as displayed by the show ip protocol summary command) is thus limited to values 0 to 31. With value 0 being reserved for connected routes and value 1 for static routes, 30 values are left to number the routing protocols.
Later IOS releases removed the limitation by allowing the same routing protocol ID to be used for different routing protocols in different VRFs. While this solution satisfies the needs of most customers, it also causes interesting side effects.
Read more in the VRF routing process limitations article in the CT3 wiki.
Valeriy sent me a really interesting question:
When you’re using PAT with a NAT address pool, the routers use the lowest IP addresses from the pool as long as possible, using a new address from the pool only when the TCP/UDP ports on the active ones are depleted. This causes problems with services limiting the number of connections from one IP address. Is there any way to make the router use the whole pool for outgoing connections in a round-robin fashion?
Valeriy has already tried rotary pools, but they don’t work with PAT and the ip nat portmap is only useful for VoIP traffic. Any other ideas?
Update @ 2009-06-01: The exact EIGRP behavior in IOS releases 12.3 and later is described in the EIGRP next-hop processing article in the CT3 wiki.
Update @ 2009-05-30: The information in this post is incorrect, the no ip next-hop-self eigrp command changes EIGRP next hop processing.
Yap Chin Hoong sent me a detailed e-mail describing his efforts to use the Next Hop field present in EIGRP routing updates. His conclusions (that I’ve subsequently verified with a few lab tests) were disappointing: although EIGRP updates have a next hop field, it’s not used (unlike OSPF forwarding address).
When doing the tests, I’ve reused an old NBMA topology and thus started to wonder whether I hadn’t already tested the EIGRP behavior. Turns out I had … and summarized the EIGRP behavior as “EIGRP updates contain no provision for changing IP next-hop address” in the Next-hop fixup in partially-meshed NBMA networks article (In the meantime, I’ve fixed the text to reflect the reality).
This article is part of You've asked for it series.
The readers preparing for various certification exams are a constant source of amazing details, including this one:
I have configured ip ssh timeout 60 and exec-timeout 5 on VTY lines. Preferred input connection is ssh. How much time can I be idle?
According to the IOS documentation, the ip ssh timeout detects the problems in SSH negotiation phase (including user authentication) and the exec-timeout detects user inactivity after the user has logged in.
Do not set ip ssh timeout to a very low value or you won’t be able to type your password before the router disconnects the session.
This article is part of You've asked for it series.
Ali sent me a question that should bother every networking engineer:
Could you explain how Cisco [or another vendor] comes up with the throughput parameters in a products datasheet? For example if a vendor says that "if IPSec is turned on the throughput is 20Mpps", exactly what does it mean? What is the packet size he is referring to and what are the implications here, because very seldom do we have fixed packet sizes in a traffic flow.
The answer, as always, is "it depends". If you're reading a serious performance analysis report, it should document the test procedures, including the packet sizes. If you're getting a "marketing" figure with no further explanation, you can be sure it's been cooked as much as possible. For example, a Gigabit Ethernet link sometimes has 2 Gbps performance (in-and-out) and in case of IPSec packet-per-second values, they are most probably measured with optimal (in this case low) packet size.
This article is part of You've asked for it series.
Vijay sent me an interesting EIGRP query:
I know EIGRP hello packets are used to discover and maintain EIGRP neighborship and when an EIGRP router doesn't receive a hello packet from its neighbor within the Hold timer, that router will be declared dead. But when would EIGRP declare a neighbor dead after sending 16 unicast packets?
The primary mechanism to detect EIGRP neighbor loss is the hello protocol. It's a bit unreliable as it does not detect unidirectional communication, but has an interesting advantage that you can use asymmetrical hello/hold timers (each router can specify what hold timer its neighbors should use for its hello packets).
However, the EIGRP neighbor loss might also be detected during the network convergence phase. EIGRP requires reliable routing updates; each neighbor thus has to acknowledge every packet sent to it. If a neighbor does not reply to a multicast packet (or a unicast packet in point-to-point and NBMA networks), the sending router switches to unicast and retries to send the packet up to 16 times. If the retransmissions fail, the EIGRP neighbor is also declared dead.
This behavior helps to avoid weird conditions including unidirectional communication that cannot be detected with HELLO packets. It also ensures that the network convergence completes in a reasonable time frame (EIGRP might use hold times up to 180 seconds on low-speed Frame Relay links).
You can find a lot of EIGRP details you never wanted to know about in the "EIGRP Network Design Solutions" book published by Cisco Press. Unfortunately, it’s only available in the electronic format on Safari.
Every now and then, a really interesting question appears on the cisco-nsp mailing list. A while ago I’ve seen this one:
I've heard that Cisco devices handle ICMP at a low priority. I found one post describing it handled in process-switching and not fast-switching. Does anyone have an article that explains that process and is it configurable?
Most packets sent to the router are handled in process switching (the packet is queued in the input queue of one of the IOS processes), the obvious exceptions being GRE and IPSec packets (unless they're fragmented).
Packets sent to the router can also be rate-limited with a control plane policy.
The IOS processes perform their job between interrupts (packets being CEF- or fast switched). A reply to an ICMP packet is therefore a lower-priority task than regular packet forwarding.
A week ago AS13214 experienced internal problems and started readvertising all BGP routes (the whole Internet) as part of its autonomous system (AS). A similar incident occurred last November. In both cases, the problem did not spread very far, which indicates that the major ISPs have implemented BGP filters and prefix limits.
One can only hope that every ISP in the world would have done the same. If you’re an ISP and you haven’t configured the BGP maximum prefix feature on your customer BGP sessions yet, please do so ASAP. A good starting point would be a configuration example provided by Cisco (it’s also accessible from the Service Provider Security Best Practices).
I’ve got this question from Pete:
Which community will be sent if only "neighbor {ip-address} send-community" is configured?
Quick answer: only the standard BGP communities are propagated.
The neighbor send-community enables the community propagation. Without this option, no BGP communities will be sent to the BGP neighbor, even if they are attached to entries in the local BGP table. After the neighbor send-community has been configured, the router will start propagating the communities attached to BGP entries in its BGP table to the neighbor.
BGP has two community attributes: the standard BGP communities (defined in RFC 1997) and extended BGP communities (defined in RFC 4360). You can control which communities are sent to a BGP neighbor with the (very obvious) standard, extended or both options of the neighbor send-community router configuration command. If you use neighbor send-community with no extra options, only the standard BGP communities are propagated to preserve backward compatibility.
This article is part of You've asked for it series.
In the last few years I wrote several IP Corner articles covering small-site multihoming (a site connected to two ISPs without having its own public address space or running BGP). Now I’ve combined them in a comprehensive Small site multihoming tutorial accessible in the CT3 Wiki.
I know numerous readers have asked me questions about this design solution, but unfortunately I haven’t saved all of them (I know one of them had to do with load sharing and another one with application-specific policy routing). If you were one of them and still remember your question, please resend it; I plan to expand this tutorial in the following weeks.
Here’s a weird requirement that you could get on a really hard CCIE preparation lab (and hopefully never in a live network): redistribute external OSPF routes from selected ASBRs into BGP without using a route-map on the redistribution router.
For example, assuming R1 and R2 insert external routes into OSPF, you want only routes from R1 to be redistributed into BGP on R3, but you cannot use route-maps on R3.
Answer: OSPF external routes with tags greater than 3758096384 are not redistributed into BGP.
Solution: You can set the OSPF route tags on the originating ASBRs with the redistribute … tag value router configuration command and the router performing OSPF-to-BGP redistribution configured with redistribute ospf pid performs automatic filtering.
Sample configurations: The following printouts contain OSPF router configuration on R1 and R2:
R1#show run | section router ospf router ospf 1 log-adjacency-changes redistribute static subnets network 10.0.0.0 0.255.255.255 area 0 R2#show run | section router ospf router ospf 1 log-adjacency-changes redistribute static subnets tag 3758096385 network 0.0.0.0 255.255.255.255 area 0
You can inspect the OSPF external routes on R3 and verify that only one of them gets inserted into BGP even though all OSPF external routes should be redistributed.
R3#show run | section router bgp
router bgp 65000
no synchronization
bgp log-neighbor-changes
redistribute ospf 1 match external 1 external 2
neighbor 10.0.1.1 remote-as 65000
R3#show ip ospf data external | inc Link State|Tag
Type-5 AS External Link States
Link State ID: 10.2.1.0 (External Network Number )
External Route Tag: 3758098606
Link State ID: 10.2.2.0 (External Network Number )
External Route Tag: 0
R3#show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 10.2.2.0/24 10.0.7.10 20 32768 ?By now you’re probably wondering what’s going on? The behavior is the result of section 4.4.6 of RFC 1403 (3758096384 = 14 * 2^28), which is over 16 years old (and that’s the reason this post belongs to “IOS Fossils”)
Update (2009-05-13): As Roland Dobbins pointed out in his comment, the strictly hierarchical approach to IPv6 address allocation is no longer valid. Another reader kindly provided me with a link to the RIPE IPv6 Address Allocation policy.
I have to admit I have no hands-on Service Provider IPv6 experience (but then there are not too many people that can claim they do) and I don’t attend RIPE meetings, so I might have a completely wrong impression, but here it is: Is it just my perception or do we really lack any production-grade means of end-user multihoming in IPv6?
Update (2010-03-12): I've gathered a lot of IPv6-related information in the meantime. You will find an overview of the Service Provider-related IPv6 challenges in my Market trends in Service Provider networks workshop (register for the online webinar). Advanced backbone designs and configurations are explained in the Building IPv6 Service Provider core workshop (register for the online webinar).
A member of the cisco-nsp mailing list asked an interesting question a while ago: he tried to test his EEM applet with the event manager run command and got the “Embedded Event Manager policy not registered with event none Event Detector” message.
An EEM applet (until EEM 3.02.4) can be triggered only by a single condition. If you want to trigger the applet from the command line (with the "event man run" command), it cannot be triggered by anything else. Such an applet must have "event none" pseudo-trigger.
The event none is used to indicate that "no trigger" is actually what you want to do (as opposed to "I forgot to specify the trigger").
This article is part of You've asked for it series.
I’ve decided to keep the stuff I find interesting separate from the IOS Hints blog (which has evolved into a purely network engineering site). If you’re interested in the links I’m publishing, check them on my Facebook page (or follow the Links item in the More to explore section of the right sidebar). Facebook can also show you a list of the links I’ve published.
You don’t have to be a Facebook user to access the page or view the links, but if you’re already using Facebook and become a fan of my page, new links will automatically appear on your wall.
I've found the following "gem" in the Catalyst 3000 LANE module data sheet:
The module "provides legacy LANs with access to ATM-based services in an ATM campus backbone".
The legacy LAN was switched Ethernet (which is still around after 15 years) and ATM campus backbones have joined the dinosaurs.
In case you've never seen a Catalyst 3000: it was a switch that Cisco got through one of its first acquisitions and although it was a good Ethernet switch, it was a nightmare to configure and the later additions (for example, the LANE module) were a disaster. Luckily, it was allowed to die a quiet death a few years later.
Cisco IOS release 12.4(20)T introduced (web) content filtering. The feature is aimed primarily at the ISR routers which can connect to an external service hosted by Trend Micro, turning the mundane administrative task of blacklisting web sites into a subscription service.
You can use the same features without the Trend Micro service whenever you need a quick fix (for example, blocking a few web sites). The Local content filtering is also available on other platforms, not just on ISRs. Not surprisingly, the online IOS documentation on the local part of this feature is a bit sketchy, but you’ll find all the details you need to configure this feature in the Local Content Filtering article.
Read the full article in the CT3 wiki
.The monthly IP Corner articles you’re probably already familiar with cover a wide variety of technology or design issues. These articles are targeted at a pretty wide audience and thus don’t go into too many technical details. They’re also static: incorporating reader’s feedback or follow-up information is way harder than editing a Wiki article.
To enable easy integration of the IP corner articles with additional related information I’ve created numerous stub articles in the CT3 Wiki. The entries in the Wiki describe the topic (technology or design solution) covered by the IP corner article and a link to the original text. Follow-up information will be easily added to the Wiki topic.
The names of the Wiki topics reflects the actual technology covered in the related articles, so you’ll find topics like EIGRP Stub Routers instead of Scaling EIGRP networks with stub routers (which does sound better in a monthly mailing). The topics have also been categorized, giving you an insight into the technologies covered by the IP Corner articles.
Please note that this is an ongoing project; not all IP Corner articles have been covered yet.
If you’re old enough to remember the days when switches were still called bridges and were used to connect multiple sites over WAN links, you’ve probably experienced interesting network meltdowns caused by a single malfunctioning network interface card. Some of you might have had the “privilege” of encountering another somewhat failed attempt at WAN bridging: ATM LAN Emulation (LANE) service (not to mention the “famous” Catalyst 3000 switches with LANE uplink).
It looks like some people decided not to learn from others’ mistakes: years later the bridging-over-WAN idea has resurfaced in the VPLS clothes. While there are legitimate reasons why you’d want to have a bridged connection across the Service Provider network, VPLS should not be used to connect regular remote sites to a central site without on-site routers. You can find several reasons for this claim in the “VPLS: A secure LAN cloud solution for some, not all” I wrote for SearchTelecom.
The zone-based firewall uses security policy-maps to specify how the flows between zones should be handled based on their traffic classes. The obvious actions that you can use in the security policy are pass, drop and inspect, but there’s also the police action and one of the readers sent me an interesting question: “why would you need the police action in the security policy if you already have QoS policing”.
The difference between interface service policy and inter-zone security policy is in the traffic aggregation: the interface service policy works on traffic classes entering or leaving a single interface and the inter-zone policy works on aggregate traffic between zones, including the return traffic if you’ve used the inspect command to configure stateful inspection of the traffic class.
For example, you could limit the amount of HTTP traffic between your internal clients and your DMZ segment to prevent the internal users from overloading your public web servers.
The inter-zone policing algorithm is pretty aggressive. You have to specify high rates and burst sizes, otherwise you can kill all TCP traffic.
This article is part of You've asked for it series.
You might have wondered why no link-state routing protocols support unequal-cost load balancing (UCLB). Petr Lapukhov provides part of the answer in his Understanding Unequal-Cost Load-Balancing article: EIGRP is one of those few protocols that can ensure a neighbor is not using the current router as its next-hop.
However, one has to wonder: with OSPF and IS-IS having the full network topology (or at least the intra-area part of it) in the SPF tree, how hard would it be to detect that sending a packet to someone that is not on the shortest path would not generate a forwarding loop? Is the lack of OSPF or IS-IS UCLB in Cisco IOS the result of lip service to the standards (at least the OSPF one is way too prescriptive) or a shoddy implementation? What are your thoughts?
Posts
All Comments
