Chesapeake NetCraftsmen

 Designing Default and Dial Backup 

Introduction

This month I'd like to take a look at a couple of topics that at first don't appear to be related to each other. More specifically, default routes, and dial backup, or at least routing for dial backup situations. As we go, we'll see that there's more here than first meets the eye! My intent is to talk about some of the undocumented, unwritten, design rules that can really make a difference.

This is partly stimulated by what I've encountered in a couple of consulting sessions, also in a couple of discussions after class about some network designs. I hope you'll find it useful!

Static Default Routes

ip route 0.0.0.0 0.0.0.0 131.108.1.1

This says that if all else fails, that is if no entry in the routing table matches, then send the packet to 131.108.1.1. Here 131.108.1.1 is perhaps the address of our Internet gateway. There's nothing wrong with that, but we might want more. We could put in two such static default routes...

Let's shift our focus. The above is something we might configure into one router. What if we have 100, 200, or 400 routers? Then static routes start getting to be a bit more maintenance burden. We also have to think about next hop routers, and put the static routes in consistently, with each hop moving the packets closer to the Internet gateway.

Or we can repeat the above configuration command (with next hop 131.108.1.1), even though we're putting it into routers that are further and further from our gateway. If that sounds odd, well, maybe it is.

It's called a recursive route. (Well, some folks call it that). That's because the router first looks up the destination in the packet. Since it doesn't get a match, it uses the recursive route. But to deliver the packet to 131.108.1.1, which is not a directly connected router, it has to look up a route to 131.108.1.1, or maybe 131.108.1.0 (the subnet). If we don't have such a route in our routing table, this whole recursive exercise was a waste of time.

To summarize, in favor of recursive routes we have simplicity: you can put the exact same (recursive) route into many routers, and it does the right thing. It's hard to misconfigure the next hop with this. On the other hand, it may cause the router to have to do some extra work in delivering packets. And when your recursion fails, so to speak, then troubleshooting this is just a bit more complex.

Corporate Default Routes

Let's say your company is using private network 10.0.0.0 internally. Does 10.0.0.0 actually appear as a destination in your routing table? Probably not! Suppose you put in a static route with something like:

ip route 10.0.0.0 255.0.0.0 10.200.200.1

Think about a packet for the corporate network 10.0.0.0, a packet that somehow happens to not match a more specific route in a router's routing table. Then this "corporate default" kicks in and causes the packet to get sent towards 10.200.200.1. If we redistribute this into a dynamic routing protocol on router A, then it causes A to "attract" such packets, only to forward them towards 10.200.200.1. The router with address 10.200.200.1 better be directly connected to A for this to work!

It may be a bit obscure at this point why on earth we'd want to do this. Well, imagine that you normally can deliver packets, say to 10.1.1.1. But when you lose your link to subnet 10.1.1.0, the connected routers stop advertising the subnet. Meanwhile, hosts that were talking to the server 10.1.1.2 continue trying to send packets. So we forward such packets to 10.200.200.1. If this router happens to be a dial backup router that "knows" how to reach 10.1.1.0, we're all set. We'll see below how this might fit into a dial backup strategy.

If you're doing OSPF or another protocol and doing route summarization you have to be a little bit more careful. A summary route may well match 10.1.1.0 or 10.1.0.0, and this longer prefix match takes precedence over matching 10.0.0.0. So your backup strategy needs to take this into account. We'll see one way of dealing with this situation towards the end of this article.

IP Default Gateway

IP Default Network

ip default-network 131.108.0.0

Notice that the address is not an IP host address, not the address of a router interface, but instead is the name of a Class B network (Class A or C also works). This might be some network out in your Internet Service Provider. From experience, pick one that's really there, and make sure it's not a one-link Class C that might go away some evil day ("The Day We Lost Default").

The Cisco routing protocols IGRP and EIGRP will pass around the default-network as a candidate default. Other routers, if they have a route to the specified default network, may choose to use this for packets with destination not matched in the routing table. (If there is no route to the default network, then it's ignored). If there are several choices, the one with the best metric is chosen. If the protocol is not IGRP or EIGRP, then 0.0.0.0 is advertised because of the default-network command. This is a static default route. (Be sure not to put subnet information into the default-network statement's network, because it will then show up as a static route).

I've seen some varied strategies in some of the networks I've "visited". It seems like people use a mix of dynamic routing, static defaults, and the default-network command. My suggestion is that we want to think in terms of "originating default". The idea is to have the "exits" from a network advertise "I am an exit" to the rest of the network. Then, when in doubt, the router just passes packets towards the nearest exit, so to speak.

There are two design reasons I favor this approach: it minimizes router configuration (and makes changes easy). Second, since the dynamic routing protocol is carrying the information, re-routing is automatic in case of outage. It's also hard to misconfigure things with this command. All of these are important as your network grows in size!

There is another way to obtain dynamic distribution of default routing information, namely to redistribute a static or dynamic route into a dynamic routing protocol. This can work very well, but I suggest doing it with an access list and/or route map, to ensure no surprises with more being redistributed than you might have originally intended.

By the way, be careful doing this sort of thing with RIP. As long as you redistribute into RIP you may be OK. But lately I've been seeing more and more networks obtaining misinformation from RIP advertisements, usually from a misconfigured UNIX or NT box. One symptom is the "wandering default", where the next hop for 0.0.0.0 just sort of randomly moves around between various addresses.As PC's start speaking more routing protocols, we'll need to use authentication or access lists more to work around such problems.

By the way, there is a Cisco configuration command for OSPF that you use on an Autonomous System Boundary Router, the ASBR:

default-information originate [always] [metric metricvalue] [metric-type type-value] [route-map map-name]

This tells the router (connected to another Autonomous System, possibly running another routing protocol) that it should advertise a route to 0.0.0.0. The options in square brackets are things we can do to tweak the origination of default. One can do similarly for IS-IS for IP, EGP and BGP.

Floating Static Routes

ip route 0.0.0.0 0.0.0.0 131.108.1.1 200

The administrative distance, 200, tells the router to use this static route only when there is no route with lower administrative distance ("better degree of believability") to destination 0.0.0.0. Usually this is used so that there's a route when dynamic routing information is lost. That way, for example, when a Frame Relay PVC fails (or Frame Relay connectivity in general is lost), the router can be instructed to send packets out the Serial or ISDN BRI interface (which, in turn, perhaps triggers a phone call).

Another way we can use static routes is with interface static routes:

ip route 0.0.0.0 0.0.0.0 bri 0 200

This says that when the dynamic default route is lost, the last resort is to send packets to unknown destinations out the ISDN BRI port. Why? Well, usually we lose dynamic default because our main (Frame Relay?) link to HQ has failed. This floating static default route causes packets to unknown destinations to trigger DDR dialing, bringing up and using the backup link.

Dial Backup Does Need Routing

There is another little issue that needs to be part of your dial backup design, and that's routing.

Many networks are star topologies, so that's what I'm going to concentrate on for the rest of this article. The remote sites in such networks are usually "stubs", a single router with one or two LAN ports and the WAN port. The only routing it may need is a default route back to the hub router, henceforth referred to as HQ. And so it's easy to put in a floating static route that says when the hub or link is down, to shove packets out the Serial or BRI backup interface. It's also fairly reasonable to tell a Cisco router that all or most packets are interesting, so the phone line will get brought up as soon as there's traffic.

The challenge sometimes comes in getting packets back to the branch site. The design question gets even more interesting if we think about minimizing cost, by not leaving the backup line up when there's no traffic. Technically, that's DDR (dial-on-demand routing) rather than dial backup, but the two approaches blur together somewhat.

HQ router(s) do need to have some routing information and some way to bring the backup line up, or else they won't be able to deliver packets to the sites. There's one exception to this: if all traffic originates in stub nets and goes only to HQ, not to other stub sites, then we can perhaps leave all call origination to the stub site routers. If you're willing to leave the backup line up until the primary comes back into service, then the call origination issue goes away, but routing still need to be thought about.

By the way, if you want to nail an ISDN backup link up for sure, one trick I've heard of is to send SNMP traps to a management station at HQ. Activating the ISDN traps causes a trap whenever the backup ISDN call is terminated. Unless the main link is back up, this trap then causes an ISDN call to go through.

Dial Backup and Dynamic Routing Protocols

You do have to watch out for convergence, which can be rather slow with RIP and IGRP, preventing your backup link from being used for minutes (which, depending on your idle-timeout, may cause the router to end the call). You can tweak timers, but you have to be careful about consistency. Recent EIGRP versions are an attractive possibility, providing simplicity and fast convergence.

In IOS 11.2 there's also support for OSPF over demand circuits, which might be useful in backup situations. The biggest concern is that the average OSPF design may then possibly have many areas coming into the ISDN backup router at HQ, which might overload it. Caveat: I haven't shaken this out in the lab yet, so I'm not sure if there are quirks when you try to use it as part of a dial backup/DDR design. If you've tried this, please let me know and I'll be glad to pass your info on! Or send a letter to the Editor describing what you've seen.

The one thing to be really careful of in designing for dial backup with dynamic routing: the backup link usually needs to stay up, so that the routing information doesn't time out. Otherwise, HQ "forgets" that the site(s) are reachable through the dial backup router, and so packets don't get forwarded to that router.

Dial Backup and Static Routes

The HQ backup router can also use floating static routes to route out to sites as needed. This does need to be coupled with dialer map statements. We'd need one static route for each remote LAN subnet, which can be a bit of typing but isn't too hard to do. (And thanks to Dan for mentioning his lab test result: 2000 dialer maps on one 4700 isn't too healthy for the CPU).

That still doesn't quite complete the picture, however. Often the ISDN or dial backup router is separate from the Frame Relay or WAN router(s), so as not to have a single point of failure. The HQ WAN routers all need to know to send unknown packets to the ISDN or other backup router.

And that's where the "corporate default" route may play a role. It can be used to send corporate unknowns to the backup router. A network outage is probably why we'd have packets going to a corporate address that's not in the routing table. So the corporate default works in case of network outages, to forward packets to the ISDN / backup router, which then knows what to do with them. That's exactly what we need!

What we've bought ourselves with this approach: a bit more configuration, but now we can allow the backup line to go down. We're really doing something more like bi-directional DDR now: bring up the phone line in either direction as needed.

If you're doing OSPF or EIGRP with route summarization, then you need to be a bit careful. The summaries may take precedence over the corporate default route. This may prevent this strategy from working, or it may cause an extra WAN backbone hop for some packets.

Dial Backup and Redistribution

This approach can work fairly well at small to medium scale but doesn't match up well with summarization: it basically defeats summarization on the HQ backbone interconnecting the WAN and backup routers. That's still OK as long as you don't mind having a few subnet routes being advertised on your WAN backbone in case of an outage.

If we're running OSPF and don't want to run 11.2 yet, or don't like OSPF for demand circuits, then we might try using a distance vector protocol on backup links. That way the remote site "reports in" to HQ when backup goes active. On the HQ backup router, we then redistribute our dynamic distance vector protocol (RIP or EIGRP probably) into OSPF. This works reasonably well even with summarization schemes, because the redistributed routes are probably not summarized, so the sites that are on backup show up in routing tables as more specific routes (more specific than any summary routes we're using at area boundaries).

The trade-off here is configuration versus traffic. Corporate default plus floating statics on the backup router is a little more work but somewhat reduces routing traffic on the HQ WAN backbone. Redistribution of subnets into OSPF is a fairly clean alternative.

Summary

However, I do hope there's a common theme visible here. The dial backup routing strategy does need to be designed. It needs to be tailored to the topology and routing protocols in your network. It also needs to match your tastes as to leaving backup links up until the primary is restored, and as to level of complexity. And don't forget, any backup scheme needs to be thoroughly tested, both up front and every once in a while as the network changes out from under the original design.
 

New Thinking/Errata

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 .

4/97
Copyright (C)  1997,  Peter J. Welcher