Category:  IP routing

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.

One of my readers recently asked an interesting question: “How do you install a static route when an IP address is not reachable?”

Without going into the design reasons that prompted the question, you can actually track when IP SLA measurement fails with an obscure configuration syntax of the track objects that tracks when another track object fails.

One of my readers asked for a working configuration of the conditional OSPF default route advertisement feature. In my scenario, the OSPF default route would be announced whenever an Internet prefix (172.18.0.0/16) would be present in the IP routing table.

After I've published the Tcl script that displays the interface IP parameters in a formatted table, cos quickly pointed out a bug: I've expected the IP addresses in the address mask format. In the meantime, I've figured out the root cause of the problem (our remote labs are set to display IP masks in decimal format for compatibility reasons) and fixed the Tcl script. It temporarily sets the terminal ip netmask-format to bit-count before executing the show command. The new script recognizes three parameters:

• active: display only interfaces that are up/up;


• configured: display only interfaces with configured IP addresses (unnumbered interfaces using IP address of an interface without one count as configured since IOS reports their IP address as 0.0.0.0).


• address: displays IP address of the unnumbered interface, not the interface that it's borrowing the address from.

You can view the Tcl source or download it from my web site.

Here’s an interesting OSPF-related question I got::

“Which one is better: default-information originate or default-information originate always?”

As always, the answer is it depends. If your OSPF edge routers have external default routes (for example, static default routes toward the Internet, see the next diagram), you'd want them to announce the default route only when they have a default themselves (otherwise, they would attract the traffic and then blackhole it). In this case, you’d use default-information originate.

It makes perfect sense in hindsight, but I was nonetheless pleasantly surprised: when the router acting as a DHCP client (configured with the ip address dhcp interface configuration command) receives the DHCP reply packet containing the default gateway option (option #3), it installs a static default route toward that next-hop.

Even better, the default route is installed with the administrative distance 254 (floating static route), making sure that the default route you’ve configured manually or the default route received via a routing protocol are not overwritten.

Cisco IOS allows you to configure the ip default-gateway, but most often it looks like this setting is ignored. In fact, the default gateway is only used when an IOS device does not perform IP routing (acts like an IP host), for example, when you configure a Catalyst switch for layer-2 switching ... or when you disable IP routing on a router with no ip routing configuration command. In both cases, the show ip route command (or show ip redirects on some Catalyst switches) displays the default gateway and any ICMP redirects received from directly attached routers:

b2#show ip route
Default gateway is 192.168.0.5

Host      Gateway         Last Use    Total Uses  Interface
1.2.3.4   192.168.0.10        0:00            13  FastEthernet0/0

Disabling IP routing on a router makes perfect sense if you use it as a (reverse) terminal server or telnet-to-X.25 gateway.

In his latest Q&A post, Scott Morris mentioned an excellent Cisco article that describes routing tricks needed to implement sinkholes and remote blackholes in great details. Highly recommended reading.

When pinging a directly-attached host (end-station) from a router, it's quite common to lose the first reply, as shown in the following example (the same symptom might occur when pinging a remote host that has been inactive).

a2#ping 10.0.0.10

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.10, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 1/1/4 ms

Actually, it's not the reply that was lost, the request was never sent out. Whenever a router has to send a packet to the next-hop (or directly attached destination) that has no entry in the ARP table, the ARP request is sent out, but the original packet is unconditionally dropped.

In his excellent question, Matt reminded me of (almost prehistoric) days when static routes pointing to a connected interface (not IP next-hop) had administrative distance zero. I also remembered that we've had interesting routing problems as those static routes actually behaved like connected routes (and were redistributed into routing protocols with redistribute connected command).

IOS release 12.3T introduced an interesting concept: static routes that are used only if an object a router is tracking (for example, next-hop router) is available. Named reliable static routing, this feature allows you to constantly ping next-hop router (or any other IP address) and use the static routes only if the tested destination is reachable.

While the reliable static routes are easy to understand and configure, a careless implementation can lead to interesting routing loops or other instability problems. You'll find the needed in-depth design and implementation guidelines in my IP Corner article Small Site Multi-homing (which is one of the prime applications for reliable static routing) in sections Not-so-Very-Static-Routes and End-to-End Connectivity Test.

Unequal load-sharing with static routes is almost impossible as there is no configuration command to assign non-default traffic share count to a static route. For example, if you configure two default routes, one pointing to a low-speed interface and another one pointing to a high-speed interface, there is no mechanism to force majority of the traffic onto the high-speed link (IOS ignores interface bandwidth when calculating load sharing ratios).

You can, howerer, use a workaround: if you configure multiple routes for the same prefix pointing to the same interface, that interface will attract proportionally more outbound traffic.

Have you ever experienced a long wait between the moment you've configured a static route and its appearance in the IP routing table? The reason might be that Cisco IOS by default adjusts static routes every 60 seconds. IOS release 12.0(29)S (integrated in 12.3(10) and 12.4) fixes this problem with the ip route static adjust-time seconds global configuration command.