Converging Remote Networks into Your Routing Table
Adam Olson As corporate and provider networks grow their RAS (Remote Access Server) pools, a quick and reliable method of converging remote network routes needs to be implemented. Creating such a design ensures connectivity to the remote network and decreases the time before transfers can commence. This is an issue in any network where there is a possibility of a remote network connecting to more than one RAS device. You need to select the routing protocol best suited for this environment and configure all your RAS devices and routers to make sure they know who is connected to which device. More Detail Convergence is obtained when all the routing tables in your network are up to date and synchronized. When your systems and networks are not fully converged, traffic ends up in a black hole, arriving at a router that has no way of forwarding packets to the requested destination. This problem has obvious implications -- the remote user will not have connectivity to other networks, and the user's connection will be completely or partially unusable until full convergence has been achieved. Convergence is not hard when the connections are from users who require only one IP address, whether dynamically or statically assigned. In this environment, static routes can be configured on the devices to point dial-in pools to the appropriate RAS device. When a static IP address is given to a user, most RAS devices will proxy ARP for the one IP address. This means that a router or host can be configured with a static route pointing out their local interface and any RAS device on that local segment will respond to ARP requests for the remote connection. The network gets a little more complex when the remote host initiating the connection is acting as a router for other computers on the remote network. Typically, the remote network will be connecting with ISDN or analog to the RAS server and will use dial-on-demand routing. The link will be brought up when a remote user wants to access resources beyond the RAS gateway, and the link will be terminated after a defined idle period. When the link resumes after an idle period, the new connection may be through a different RAS device in the pool of RAS devices. This sudden change renders routing tables out of date. Routing Protocols and Addressing I will use RIPv2 (Routing Information Protocol version 2) as the routing protocol in these examples, but almost any IGP (Interior Gateway Protocol) will work. I like to use RIPv2 in this type of design because of its ease of configuration, support of VLSM, and quick convergence in this particular environment. I find OSPF and other more robust routing protocols more appropriate for larger networks, where immediate failover and link speed is a factor. RAS devices typically communicate to servers and routers over Ethernet, which works well with RIPv2 being a distance vector routing protocol. Link cost is not an issue and immediate failover is not required because the routes are removed faster than the time it takes for the user to connect again. First, I will define a pretend network so we can start configuring. Figure 1 shows the physical topology of the network. Our service provider network consists of an Ethernet LAN using 206.13.45.0/24 for address space. On the LAN, we have one Cisco 2501 router with two links upstream, as well as ten Cisco AS5200s to which all the users connect. We have set aside the IP range of 216.100.36.0/24 for assigning small networks to users. A routing protocol now must be implemented so our Cisco 2501 router will be aware of which RAS device any subnet of 216.100.36.0/24 is on. Device Configuration First, configure the 2501. RIPv2 support is available in Cisco IOS version 11.1 or greater. If you are not running at least version 11.1, you will need to upgrade your IOS image before continuing with this configuration. Once you are logged into the router and have entered enable mode, type: router# conf t Enter configuation commands, one per line. End with CNTL/Z. router(config)# router rip router(config-router)# version 2 router(config-router)# network 206.13.45.0 router(config-router)# distribute-list 1 in Ethernet0 router(config-router)# no auto-summary router(config-router)# Control-ZThe purpose of each command is:
To create the ACL type: router# conf t Enter configuation commands, one per line. End with CNTL/Z. router# access-list 1 permit 216.100.36.0 0.0.0.255 router# Control-Z:The access-list command above creates an ACL with a reference ID of 1. It is a standard IOS access list because we are not concerned about any application specifics of the traffic, just the address portion. This line permits any RIPv2 updates that fall within the network range of 216.100.36.0/24. Every other RIPv2 update is discarded by the implicit deny at the end of a Cisco ACL. The wildcard bits or netmask portion might look a little funny at first because it is inverted. When the wildcard bits are applied to the address range, a 0 requires the bit to match, and a 1 is an “I don't care” bit. Thus, that command is saying “I care about anything up to 216.100.36 and the last octet can be anything”. Now for the Other Half We have finished configuring our Cisco 2501, so now let's move on to the RAS devices. Almost any RAS device with a somewhat current operating system will support RIPv2. I am going to use a Cisco AS5200 in the example, but the basic principals remain the same. The RAS must be configured to exchange routes using RIPv2 on its local Ethernet interface, configure the other interfaces passive (typically), and permit only outgoing RIPv2 updates via the Ethernet interface. First, login to the AS5200 and enter enable mode: as5200# conf t
Enter configuation commands, one per line. End with CNTL/Z.
as5200(config)# router rip
as5200(config-router)# version 2
as5200(config-router)# redistribute static
as5200(config-router)# passive-interface Async1 (issue command \
for other interfaces)
as5200(config-router)# network 206.13.45.0
as5200(config-router)# distribute-list 1 in
as5200(config-router)# no auto-summary
as5200(config-router)# Control-Z
The new commands here are:
as5200# conf t Enter configuation commands, one per line. End with CNTL/Z. as5200# access-list 1 deny any as5200# Control-Z:This differs from the previous ACL in that here we are denying any incoming RIPv2 updates. In other RAS implementations, this same action is performed by telling the RIPv2 process to only send updates. From the RAS's point of view, all it needs to know about is who is directly connected, and if they are not directly connected, it will forward the packet to the default gateway. If the default gateway is overloaded with handling this sort of traffic, then some IGP must be implemented to allow the RAS devices to update each other directly. With this design, the default gateway will be freed from the burden of inter-network traffic. The syntax above will differ by RAS, of course, but the same steps are followed and need to be addressed regardless of which RAS you are using. Verifying the New Configuration The devices should now be communicating via RIPv2, and the router should be installing the new routes from the RAS. There are a few commands you can use to verify the new operation and to troubleshoot any problem you may experience. Looking at the routing tables of the router and RAS is very informative. On a Cisco, the command is sho ip route and should be similar on most other platforms. If the routing table is not being populated with the remote network routes, verify the operation of RIPv2 by running sho ip proto on the command line. This is also a Cisco command and will be a little bit different on other operating systems. If anything looks incorrect here, verify the existing configuration against the configuration process detailed above. Other helpful commands are ping and traceroute. These two commands can aid you in testing the connectivity between two devices and observing the path taken to get from one end to the other. If the route is in the routing table and a ping is failing, verify that no filtering is taking place on ICMP traffic and that the remote host is configured correctly. Tweaking the Timers Another important step is adjusting the routing protocol timers. If a remote network disconnects and then reconnects in a short amount of time to another RAS, the router must learn the new route immediately. If the timers are not tuned correctly, the old route will linger in the router until a specific time period has passed. The route will then be removed, and the new route will be installed. While this process is taking place, the remotely connected network will not be able to get anywhere. The timers that can be tweaked to streamline the process are the Update timer, the Invalid timer, the Holddown timer, and the Flush timer. The name of each timer pretty much says it all. By decreasing the Update timer, the interval between each update decreases, which enables new routes to be heard more quickly. The downside of this is an increase in traffic on the wire. RIPv2 updates are fairly small, thus making it somewhat trivial. The Invalid, Holddown, and Flush timer all have to do with how long the route should exist in the routing table before it is replaced by an update from another RAS. The lower these timers are set, the faster the routes that have disappeared will be removed from the routing table. This speeds up the time required for full convergence to take place. I suggest you play around with the timers until you have met the proper failover time required in your specific environment. The command to set RIPv2 timers in a Cisco is timers basic update_time invalid_time holddown_time flush_time sleep_time under the router rip configuration mode. When using this, you will want to adjust your wait timers (Invalid, Holddown, and Flush) on the Cisco 2501. The update timer modifications will be made on the RAS devices, because they are the boxes sending the updates. Conclusion Converging remote networks efficiently is an important step toward creating a dynamic and stable network. A streamlined routing protocol implementation keeps everyone happy. If you have any questions on design issues or if you are encountering difficulties tailoring this to your environment, please feel free to email me.
About the AuthorAdam Olson lives in the Bay Area. He has helped build a successful ISP
(http://www.humboldt1.com), designed and configured portions of the
California Power Network while working at MCI WorldCom, and is
currently working for a company targeting the ecommerce and time
management industries (http://www.quaartz.com). Adam enjoys playing
Neil Young on acoustic guitar and snowboarding in Tahoe. He can be contacted at: [email protected] |