Old and New Routing Techniques http://www.netcraftsmen.net/welcher/papers/admindis.

htm

Old and New Routing Techniques

Peter J. Welcher

Cisco recently released IOS version 11.2, which has all sorts of nifty new features in it. This month's
article talks about a couple of these features, new routing techniques for Cisco routers. It starts,
however, with an old but important topic, Administrative Distance.

Administrative Distance
The Cisco router IOS comes equipped with a routing concept named administrative distance. The idea
behind administrative distance: when a router speaks multiple routing protocols, there is always the
possibility that the protocols will come up with different routes to some destination. When this
happens, the router needs some way to pick one of the alternative routes. Cisco routers use the
administrative distance to do this.

An analogy: if you hear contradictory rumors from friends, don't you decide whom to believe based on
how well-informed they usually are, and other such factors? Think of the administrative distance as
"degree of believability", with low being better (more believable). It can apply to either a routing
protocol or to the source of the routing information, a neighboring router.

The default administrative distances in the Cisco routers are chosen to work well in most networks.
Here is a table showing the defaults:

Type of Route Administrative Distance

Directly connected interface 0

Static route 1
EIGRP summary route 5
External BGP 20
Internal EIGRP 90
IGRP 100
OSPF 110
IS-IS (IP) 115
RIP 120
EGP 140
External EIGRP 170
Internal BGP 200
Unknown 255

1 of 6 1/6/03 3:00 PM
Old and New Routing Techniques http://www.netcraftsmen.net/welcher/papers/admindis.htm

Let's see how this works.

Suppose IGRP tells the router that the way to subnet 131.108.5.0 is via 131.108.7.5. Suppose RIP
says the next hop is 131.10.10.5. Since IGRP has lower administrative distance, the router puts the
IGRP route into the routing table. The RIP route is only used when the IGRP routing information is
not being received (presumably from 131.108.7.5).

Note that because of its low administrative distance, BGP is considered to be an excellent source of
external routes, but not very good for routing within an autonomous system (because our choice of
Interior Gateway Protocol is used for that).

Suppose we configure a router's interface with an IP address and subnet mask. That causes the router
to install a directly connected route in it's routing table (as long as the interface is up). If we were silly
enough to put in a static route saying that the route to that subnet was out another interface, the router
would stick to the directly connected route, because the administrative distance is lower (0 versus 1).
So you can't fool the router that way!

Note that routing metrics don't play any role in this. If IGRP comes up with any route to a destination,
no matter how poor, then that route is used instead of a RIP route.

I know of three advanced uses for administrative distance. They are floating static routes, dual static
routes, and routing protocol migration. . (I'm sure there are others -- if you know of any good ones let
me know! And thanks to Terry for suggesting dual static routes.)

Floating Static Routes

The first example (uses for administrative distance) is "floating static routes." This is where we
configure something like
ip route 131.108.5.0 255.255.255.0 131.108.14.2 200

This says that the way to subnet 131.108.5.0 is via next hop 131.108.14.2, but that the administrative
distance is 200.

I hope you're thinking "that's high, so it must be a fairly unbelievable route." If so, you're right! Now
why on earth would we want to do this?

Suppose 131.108.5.0 is normally connected via a Frame Relay link. Say there are many Frame Relay
PVC's originating from the serial interface on this router. When the interface physically goes down, dial
backup can be activated. When the PVC goes down, we need IOS 10.3 or later and subinterfaces to
use dial backup on a single PVC. And when we do it, even with 10.3 or later, there has been a
limitation that says we need a separate physical interface for each PVC. Backing up 20 PVC's at a hub
router just can't be done this way.

But instead we configure floating static routes such as the above route. Normally, we receive dynamic
routing information (RIP, IGRP, EIGRP, OSPF, or whatever). This has lower administrative distance
than the 200 we put on our static route, so the static route gets ignored. It only becomes active when
we lose the dynamic routing information. If we have also set up Dial-on-Demand Routing (DDR), we

2 of 6 1/6/03 3:00 PM
Old and New Routing Techniques http://www.netcraftsmen.net/welcher/papers/admindis.htm

now can place a call to provide an alternative path for traffic.

This technique also used to be useful for ISDN BRI interfaces: dial backup wasn't able to place an
ISDN call until 10.3.

Dual Static Routes

This is a variant of the above. Perhaps we have a small stub office network and router. The stub is
connected by a serial line, with another low-bandwidth serial link to another site, normally used for
certain traffic only. We might configure something like
ip route 131.108.5.0 255.255.255.0 serial 0

ip route 131.108.5.0 255.255.255.0 serial 1 200

The idea would be that traffic for subnet 131.108.5.0 should use the serial 0 interface unless it is down,
in which case it should use serial 1. Note that such routes are considered like directly connected routes,
and are also redistributed into dynamic routing protocols automatically.

Another possible use of this might be to specify alternative default exit points to a network, where the
routing protocol is perhaps RIP. This would look like
ip route 0.0.0.0 0.0.0.0 150.1.1.1

ip route 0.0.0.0 0.0.0.0 160.1.1.1 200

The intent is to have a default route that goes by our ISP at 150.1.1.1, but if that subnet becomes
unreachable (be careful with this when you've got summary routes!), use the ISP at 160.1.1.1. (This
special kind of static route involves recursion on how to reach the next hop).

I personally prefer use of the ip default-network command instead. It can be used with
IGRP/EIGRP or RIP and is a lot easier to configure (on the exit router only) and maintain (you didn't
configure it into all the other routers).

Routing Protocol Migration

Another use of administrative distance is to migrate from one routing protocol to another. Suppose
we're using RIP in our network, and that we've decided (or been told) to migrate to OSPF. We could
just start configuring OSPF into our network, but then as we added it to more and more routers we'd
get OSPF routes displacing RIP routes due to administrative distance. We'd see all our traffic going
between the OSPF routers whenever possible, even if there were better routes available through a
router speaking only RIP.

The solution? Configure OSPF with a distance command, to set its administrative distance to 150,
say. Here's how the migration might work:

1. Add OSPF to all routers with distance 150.

2. Revisit all routers, remove the OSPF distance command.
3. Revisit all routers, check that all routes are now OSPF-derived. If there are any RIP routes
showing, we missed setting up OSPF on the router(s) connected to that distance.

3 of 6 1/6/03 3:00 PM
Old and New Routing Techniques http://www.netcraftsmen.net/welcher/papers/admindis.htm

4. While reviewing routing, look for any links that aren't being used. We might have missed an
interface and not be speaking OSPF on one or more links. If we did so, they won't be being used
to carry traffic (another way to spot them: very low utilization).
5. Finally, when convinced we're all set with OSPF, turn off RIP.

That's it for migrating!

RIP-2
As mentioned above, Cisco has added RIP-2 support to its RIP implementation. Just add the line
version 2

to your RIP configuration and the router will speak (only) RIP version 2. Other commands allow more
specificity, so the router may transmit or receive either of the two RIP versions (per interface). The
commands to do this:
interface Ethernet 0

...

ip rip send version 1

ip rip send version 2

ip rip send version 1 2

ip rip receive version 1

ip rip receive version 2

ip rip receive version 1 2

Why would you want to run RIP-2? Well, it supports classless routing, hence variable length subnet
masks (VLSM). It also supports router authentication (so you don't have to listen to those NT boxes
that think they're routers).

I've seen the comment that running RIP-2 is like putting drag racing tires on a Volkswagen Beetle. I'm
not going to disagree, but I'll point out that I've seen Beetles in drag (so to speak).

And there's a pretty good use for RIP-2, as I've heard about from folks at two sites. They want to
migrate from RIP to OSPF, and are big enough to be thinking about readdressing to allow better route
summarization. Except that most of their address space is in use. And they don't want to use private
addressing.

Their solution is to use RIP-2 as a migration tool. They'll turn on RIP-2 as the routers get upgraded
(one catch to this plan!).They'll then put in some VLSM on WAN links, to free up chunks of address
space. That in turn lets them start readdressing to get addresses into contiguous blocks. Once they've
done that they'll feel better about cutting over to OSPF. Or perhaps feel comfortable enough about
EIGRP to consider that instead. (As large sites gain experience with the "improvements" that have
been in EIGRP since around June). And it's not as if route summarization hurts with EIGRP either.

I feel comfortable enough with EIGRP that I might try that instead, to shorten the migration. But it's

4 of 6 1/6/03 3:00 PM
Old and New Routing Techniques http://www.netcraftsmen.net/welcher/papers/admindis.htm

their network!

ODR
Another feature new to IOS 11.2 is On Demand Routing. This is a fancy name for "easy configuration
of hub and spoke networks". You certainly don't have to do it this way, but if you don't mind the minor
shortcomings, it's probably a win as far as simplicity and ease of maintenance.

The assumption is that you have a hub and spoke topology, with the branch offices ("stubs") consisting
of a single router each. To use ODR, configure no dynamic routing protocol on the stub routers. The
lack of the dynamic routing tells the IOS that the router is a stub router and should therefore try to do
ODR.

Do configure the stub router interfaces with IP addresses.

And on the central hub router, configure

router odr 1

(The "1" is a process id).

That's all it takes. The stub routers use CDP to advertise the directly connected networks to the hub. It
installs routes (effectively, dynamic static routes) into the routing table. If you redistribute ODR, these
in turn can be passed on to the rest of the network at the central site.

You probably will also want to configure the stub routers with a static default route pointing back to
the hub. Configure the hub with passive interface(s), to avoid wasting bandwidth on unnecessary full
routing updates to the stub offices. If you configure "ip classless ", the stub router will also use the
default route for unknown subnets of the networks configured on it.

ODR does advertise prefixes, so that it can support VLSM. It does not advertise secondary addresses,
so you have to work within one subnet per interface. That's not hard to live with.

Distribute lists can be used (under the " router odr 1" command) to control what network prefixes
are learned via ODR. That's probably a good idea, for some security and control.

Since CDP (Cisco Discovery Protocol) is used to carry ODR information, convergence of ODR
depends on the CDP interval, normally one minute. ODR routes are marked invalid after three minutes
without updates, by default, and are flushed after four minutes. The CDP and ODR times can be
adjusted if desired.

If ODR is used with Dial-on-Demand Routing (DDR), you have to specify that CDP packets are
uninteresting, or the dialup link will probably remain active, resulting in a large phone bill. In this
setting, you'll have to cause an "interesting packet" to be sent, then wait for CDP and ODR to do their
thing before the link will be useable (that should take under a minute, normally).

Dr. Peter J. Welcher (CCIE #1773, CCSI #94014) is a Senior Consultant with Chesapeake
NetCraftsmen. NetCraftsmen is a high-end consulting firm and Cisco Premier Partner dedicated to

5 of 6 1/6/03 3:00 PM
Old and New Routing Techniques http://www.netcraftsmen.net/welcher/papers/admindis.htm

quality consulting and knowledge transfer. NetCraftsmen has nine CCIE's, with expertise including
large network high-availability routing/switching and design, VoIP, QoS, MPLS, network
management, security, IP multicast, and other areas. See http://www.netcraftsmen.net for more
information about NetCraftsmen. Pete's links start at http://www.netcraftsmen.net/welcher . New
articles will be posted under the Articles link. Questions, suggestions for articles, etc. can be sent to
pjw@netcraftsmen.net .

12/96
Copyright 1996, Peter J. Welcher

6 of 6 1/6/03 3:00 PM