Previous | Table of Contents | Next |
There are four common types of routing protocols you should know aboutmore 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).
Its 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 protocolsthat 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. Its different in that it advertises servers, not routers.The reason for SAP is similar to the reason for RIPit allows all routers to share information via broadcast. As such, its 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 IPXs SAP and RIP.) Similarly, if you have a complex and congested TCP/IP network, youd 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!
Theres not really a lot that goes wrong with routing protocols that arent domino-effect problemsthat is, problems caused ultimately by a bad hub port, cable, or card on the network, or by somebody changing a configuration. Still, its good to be acquainted with the basics so that you can read the configuration from your router and get the basic gist of whats going on.
All modern serverswhether NT, UNIX, or NetWarecan 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, its 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 theyre misconfigured. Ive 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 routers second interface was configured as being on network B, and though it wasnt 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. Heres the lesson: Dont plug a new router into a production network until its time; instead, test on a disconnected network. Test hubs are cheap enoughputting together a couple of test segments shouldnt cost more than $100. Ive 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 couldnt 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 analysisif 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. |
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 youre one step closer to resolving your problem.
Previous | Table of Contents | Next |