Category: IP 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.

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:

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 Small Site Multi-homing article (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.