Previous Table of Contents Next


Route in Peace: Routing Protocols

There are four common types of routing protocols you should know about—more for configuration checking (making sure that routers are configured for the same routing protocols) than anything else. TCP/IP has two common ones, as does IPX/SPX. The oldest routing protocol, for both TCP/IP and IPX/SPX, is called Routing Information Protocol (RIP).


It’s important to realize that different network protocols (TCP/IP versus IPX/SPX) have different routing protocols. Although RIP for TCP/IP works similarly to RIP for IPX/SPX, they are, in fact, different.

RIP

Both the TCP/IP RIP and the IPX/SPX RIP are broadcast protocols—that is, each RIP router announces its routing table to everybody on the network every so often. Also, both RIPs calculate route cost based on number of hops rather than how fast a particular route might be (for cases where multiple routers have a path to the same network). RIP can cause lots of network traffic in complex networks because it talks too much. (TCP/IP RIP will broadcast to the network every 30 seconds.)


IPX/SPX has a companion protocol to RIP called SAP, or Service Advertisement Protocol. This protocol is similar to RIP in that it broadcasts information to the network to anybody who might be listening. It’s different in that it advertises servers, not routers.

The reason for SAP is similar to the reason for RIP—it allows all routers to share information via broadcast. As such, it’s pretty chatty.


OSPF and NLSP

If your network is complex and congested, you might want to stop using IPX RIP and go with NLSP. (NLSP replaces IPX’s SAP and RIP.) Similarly, if you have a complex and congested TCP/IP network, you’d probably want to replace the RIP with OSPF. OSPF (Open Shortest Path First) for TCP/IP and NLSP (NetWare Link State Protocol) for IPX/SPX are the more advanced routing protocols. They take into account how fast a link might be and assign a cost accordingly. Each NLSP or OSPF router identifies itself to other routers on the same network and learns the routes that those other routers know. If something changes, the routers communicate it directly; because they do a quick check on each other fairly often (usually 10 seconds), a dead router is noticed and the routing tables are updated quickly. Good stuff!

There’s not really a lot that goes wrong with routing protocols that aren’t domino-effect problems—that is, problems caused ultimately by a bad hub port, cable, or card on the network, or by somebody changing a configuration. Still, it’s good to be acquainted with the basics so that you can read the configuration from your router and get the basic gist of what’s going on.


All modern servers—whether NT, UNIX, or NetWare—can be configured to be simple and cheap routers. Of course, they need to be multihomed in order to be connected to more than one network.

I use this sometimes to swap out routers. If I suspect that a network problem might be router related, it’s a lot cheaper to temporarily put in a PC with UNIX on it acting as a router than it is to purchase a new $10,000 router just to rule out a router problem.


Router Rumble!

Be careful if you start to experiment with routers. Unlike servers, which are typically self-contained entities, routers that participate in routing protocols on your network can seriously damage your connectivity if they’re misconfigured.

I’ve seen a situation where somebody plugged a router into network A that was configured to connect network A with network B. This was because the new router was intended to replace the router that currently served network B.

Unfortunately, the new router’s second interface was configured as being on network B, and though it wasn’t plugged into network B proper, it started to advertise via routing protocols that it knew the best route to network B. This caused confusion in the routing tables; some packets started to go to this router, only to discover that there was an entrance, but no exit! The legitimate router for network B was doing what it was supposed to do, but it was being usurped by the new router.

Here’s the lesson: Don’t plug a new router into a production network until it’s time; instead, test on a disconnected network. Test hubs are cheap enough—putting together a couple of test segments shouldn’t cost more than $100.

I’ve also seen a situation where a RIP router for network C was accidentally plugged into network A. Because RIP routes are broadcast rather than going address to address, the router was able to tell all the routers on that segment that it knew the best way to network C. Again, all of a sudden, folks couldn’t get to a network segment that until then had been just fine.

These are, of course, human errors that could have been found by change analysis—if the guilty party had ’fessed up! Both errors were found through examination of the routing table, when someone exclaimed, “Hey! Why in the heck is network B going to that IP address?” Fortunately, the networks had been well documented; otherwise, the person looking at the routing table might have assumed that the network B next hop was listed correctly.

Checking Routes

Routing problems can be diagnosed from the router itself, but they can also be diagnosed via a network connected to a router. You can determine whether a router is up just by pinging it (be sure to ping it from a segment that it lives on, because pinging it from a different segment involves different routers). Likewise, you can use the traceroute, tracert, and iptrace commands to see how a packet from the workstation is actually flowing through the network. Check the routing table of multihomed servers with netstat -r to see what they think the routes are. Once you do these things, you can compare the results with how it should flow according to your site documentation, and you’re one step closer to resolving your problem.


Previous Table of Contents Next