Category: IP Routing

You've probably already heard the phrase "When the only tool you have is a hammer, everything looks like a nail" (and seen people acting according to it). Likewise, if you have an IOS release with EEM support, a lot of things that would require smart design could be solved in a brute-force way with a few EEM applets. For example, the problem of the BGP default route could be solved “easily” with a few applets that track syslog messages reporting when the BGP neighbors go up/down.

Speaking of Joe Harris … he just wrote a great post about the IP routing table profiling available in Cisco IOS and the ways it can be used to monitor the stability of your network.

The IP-over-IP (usually GRE) tunnels (commonly in combination with IPSec to provide security) are frequently used when you want to transport private IP traffic over public IP network that does not support layer 3 VPNs. If you use the GRE tunnels in combination with default routing (or route summarization), you can get serious routing issues when the tunnel destination disappears, but a default (or summary) route in the IP routing table still covers it. You could work around this issue by deploying a routing protocol over the GRE tunnel (which could lead to hard to diagnose routing loops if you're not careful) or by using GRE keepalives introduced in IOS release 12.2(8)T.

When I started exploring the details of MTU handling in Cisco IOS, I quickly got tired of analyzing various long printouts to extract the MTU sizes, so I wrote a Tcl script that displays hardware, IP, and MPLS MTUs in a tabular format. To install it on your router:

1. Download it and copy it to your router's flash or NVRAM.
2. Define an alias, for example alias exec mtu tclsh flash:displayMTU.tcl.

The script recognizes two parameters: the ip parameter displays only the interfaces that have IP configured and the mpls parameter displays only the MPLS-enabled interfaces.

An IOS device configured for IP+MPLS routing uses three different Maximum Transmission Unit (MTU) values:

• The hardware MTU configured with the mtu interface configuration command
• The IP MTU configured with the ip mtu interface configuration command
• The MPLS MTU configured with the mpls mtu interface configuration command

The hardware MTU specifies the maximum packet length the interface can support … or at least that's the theory behind it. In reality, longer packets can be sent (assuming the hardware interface chipset doesn't complain); therefore you can configure MPLS MTU to be larger than the interface MTU and still have a working network. Oversized packets might not be received correctly if the interface uses fixed-length buffers; platforms with scatter/gather architecture (also called particle buffers) usually survive incoming oversized packets.

The MPLS VPN implementation on Cisco IOS has always allowed you to create VRF static routes that pointed to interfaces belonging to other VRFs. The feature can be used to implement interesting overlapping VPN (or common services VPN) designs, some of which are explained in the MPLS and VPN Architectures books.

However, quite often the ability to create inter-VRF static routes is considered a major security problem, as an operator configuration error could establish undesired inter-VPN connectivity. In these cases, use the no ip route static inter-vrf configuration command to prevent such routes from being installed in the VRF routing table.

The Static routing with Catalyst 3750 post has generated a lot of good, creative ideas. Some of the proposed solutions were better than the others and some were simply not implementable (but nonetheless, had great creative potential :). Here is my list of the favorites:

A routing protocol: as a few of you have rightly pointed out, this is the best choice.

Aggressive Unidirectional Link Detection (UDLD): this is my second favorite, as it's a reliable link-level mechanism that will detect a break in the fiber cable … exactly the right tool for the job.

In a previous post, I've described how the track interface ip routing command reports incorrect interface state if you use IP Event Dampening feature. To track the actual IP routing readiness of an interface, you could use the following workaround:

• Create a static IP route pointing to the interface you want to test. Make sure this route is not redistributed into any routing protocols.
• Track the reachability of the static route

Here's an interesting scenario:

We have two sites, each using a Catalyst 3750 switch, and routing between them using static routes. There's a primary fiber link between them and we're using twisted-pair-to-fiber converters due to port limitations on Cat3750. These converters do not report fiber link down status correctly (the carrier is still present on twisted pair even if fiber is down), so the primary Ethernet interfaces do not go down if the fiber link breaks and the primary static route is not removed, requiring manual action to switch over to the backup link.

The setup is summarized in this diagram:

The track number interface name ip routing command is supposed to track an interface readiness to forward IP packets. In reality, it only tracks the interface line protocol status plus the IPCP status in case of PPP interfaces (as well as the actual presence of an IP address on the interface). If you configure IP Event Dampening (with the dampening) command, the interface might be suppressed (unavailable for IP routing), but the track object will report it as available (tested on IOS release 12.4(6)T). This could result in suboptimal HSRP/GLBP decisions if you use track objects to influence HSRP/GLBP priority or actual loss of data if you use such a track object to control policy-based routing.