CASE STUDIES
from the files of
Networking Unlimited, Inc.

WebQuery@NetworkingUnlimited.com
14 Dogwood Lane, Tenafly, NJ 07670
Phone: +1 201 568-7810

Eliminating Router Dependency in an ISDN Backup Application

Copyright © 1999, Networking Unlimited, Inc. All Rights Reserved.

Conventional ISDN dial backup configuration can only dial a single destination number for any single IP address. Networking Unlimited, Inc. developed an ISDN dial backup configuration which allowed any remote to call any core router as if all core routers were just different phone numbers on the same interface on the same router.

Background

The client used a three router core in a hub and spokes configuration to ensure that a spoke would never be disconnected. Each spoke had two frame relay PVCs to two core routers and ISDN dial backup into the remaining core router in case both PVC's were lost. While the configuration looked robust on paper, it turned out to be fairly weak in practice. The weakest link in the chain was the physical 56Kbps link at the spoke into the RBOC frame relay network, so that when one PVC was lost, nine times out of ten so was the second PVC. As a result, router maintenance at the core was severely constrained, as there was no way to predict when a spoke would lose its frame link and require the router down for maintenance restored immediately to answer its ISDN call.

The "by the book" ISDN dial backup configuration supporting IP and IPX dedicated an IP subnetwork and an IPX network to each ISDN PRI interface. While a Cisco dialer interface definition can combine multiple PRI interfaces on a single address range, the dialer interface can not span multiple routers. The challenge was to develop a configuration which would allow a spoke to sequentially call all the core routers until a successful ISDN link was established.

Technical Approach

The key to solving the client's dilemma was to develop a configuration which did not depend upon assigning addresses to the ISDN interfaces. Changing the ISDN configuration to use IP unnumbered while necessary is not sufficient, as the dialer at the spoke end could only be programmed to attempt to reach a single IP address. Solving the problem for IP required having a single address that the ISDN dial up could use that was the same on all three routers. Networking Unlimited, Inc. implemented this single address by defining a loopback address on each core router with the same IP address. The routing advertisements on the inter-core LAN interfaces were then filtered to prevent the core routers from confusing each other. Three IP dialer map statements could then be included on the spoke router providing three different routers names and telephone numbers for the same IP address, which would be called in order when the line needed to be brought up.

IPX dial backup was more difficult to implement. The original configuration used IPX RIP (when the network was originally designed, EIGRP IPX routing was not stable enough for production use). While EIGRP IPX routing would have been desirable to reduce routing traffic, it did not solve the problem of eliminating core router dependency in the spoke ISDN backup. Instead, we "cheated" and let IPX simply respond to the state of the ISDN link, depending upon the IP routing to bring the link up and down as required. IPXWAN was used as the IPX routing protocol, with three dialer maps, one for each core router, each with a different IPX network number to match the IPXWAN assigned network number based on the router IPX address. Since IPX RIP would require several minutes to detect and react to a frame relay problem, the ordering of the IPX dialer maps was immaterial, which turned out to be fortunate, because unlike IP dialer map statements, the IPX dialer maps are reordered when loaded so there would be no way to change ISDN target priorities.

At the same time, the dial backup was modified so that it was driven by dial on demand routing rather than interface backup configuration. That way, when communications were lost but the local frame interface remained up, dial backup would occur regardless. This also had the side effect of greatly simplifying ISDN circuit testing. All that was required to verify that an ISDN interface was functioning correctly was to ping the "magic" target IP address. The link would come up and if the CHAP handshake completed successfully, you could be confident there were no ISDN line problems for that spoke.

Bottom Line Results

The new scheme has been an unqualified success. The network is much more robust, ISDN testing has been automated, and core maintenance is much simpler as it is now possible to down a core router with far less fear that maintenance will be cut short (there are still core functions which are only dual redundant, but all normal spokes can function with only a single core router alive).

As part of the reconfiguration required to ensure that spokes would always call in to the core if needed, the entire routing structure of the network has been revised. Since the only way for a spoke to reach any destination is to send the packet to the core, all routing to the core is done via default routes defined as weighted floating static routes to core addresses redundantly defined by loopback interfaces on each core router and dynamically learned via EIGRP. That way, as the network continues to grow and more spokes are added, the routing tables in the spoke routers remain small and the percentage of WAN bandwidth consumed by routing updates stays constant. Similarly IPX advertisements are filtered so that only shared core servers and services are learned by the spokes.

Home Page | Company Profile | Capabilities | Coming Events | Case Studies | White Papers | Book

Copyright 1999-2000 © Networking Unlimited Inc. All rights reserved.