Resources Archived Articles Old and New Routing Techniques
| Old and New Routing Techniques |
| Sunday, 01 December 1996 14:55 |
|
IntroductionCisco 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 DistanceThe 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 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 RoutesThe first example (uses for administrative distance) is "floating static routes." This is where we configure something likeip route 131.108.5.0 255.255.255.0 131.108.14.2 200This 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 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 RoutesThis 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 likeip route 131.108.5.0 255.255.255.0 serial 0 ip route 131.108.5.0 255.255.255.0 serial 1 200The 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 200The 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 MigrationAnother 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:
RIP-2As mentioned above, Cisco has added RIP-2 support to its RIP implementation. Just add the lineversion 2to 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 2Why 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 their network! ODRAnother 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 quality consulting and knowledge transfer. NetCraftsmen has eleven CCIE's (4 of whom are double-CCIE's, R&S and Security). NetCraftsmen has 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/about-us/bios/staff-articles-and-blogs/pete-welcher.html . New articles will be posted under the Articles link. Questions, suggestions for articles, etc. can be sent to This e-mail address is being protected from spambots. You need JavaScript enabled to view it . 12/96 |
