| The default configuration file for gated lists RIP as the only routing protocol configured by default. This highlights its widespread support and popularity in the UNIX community. This goes against the trend in the networking industry that is moving away from RIP, especially version 1 (the default). RIP is losing favor because version 1 doesn't support variable length subnet masks, multicasting, or authentication, and it is slow to repair failed routes (180 seconds to delete an unreachable route ). In a world where every network is using some form of subnetting and three minutes is a long time; these are serious limitations. When we use it on HP-UX, it's usually version 2 of the protocol that we choose. This needs to be configured explicitly in the gated.conf file. The advantage of RIP is that it is relatively simple to configure. RIP is best suited to small- to medium- sized networks where the network topology is relatively stable. Below is a simple example of a RIPv2 configuration file that I will use in this example:
root@hpeos003[] vi /etc/gated.conf # # This is an initial /etc/gated.conf file. # Note that this file should be modified according # to the routing topology. Refer to the sample # configuration files in the "/usr/examples/gated" directory. # See gated-config(4) for details. # @(#)B.11.11_LR # traceoptions "/var/adm/gated.trc" size 10M files 2 route; interfaces { interface all passive ; }; rip yes { interface all version 2; }; root@hpeos003[] root@hpeos003[] gdc checkconf configuration file /etc/gated.conf checks out okay root@hpeos003[] root@hpeos003[] gdc start gated started, pid 3893 root@hpeos003[]
It is this simplicity that makes RIP so popular. This is a simple configuration for a router. For a client machine, we could use the same configuration with only minor modifications to ensure that a non-router doesn't broadcast on its (only) interface:
root@hpeos002[] vi /etc/gated.conf # # This is an initial /etc/gated.conf file. # Note that this file should be modified according # to the routing topology. Refer to the sample # configuration files in the "/usr/examples/gated" directory. # See gated-config(4) for details. # @(#)B.11.11_LR # traceoptions "/var/adm/gated.trc" size 10M files 2 route; interfaces { interface all passive ; }; rip yes { nobroadcast ; interface all version 2; }; root@hpeos002[] root@hpeos002[] # gdc checkconf configuration file /etc/gated.conf checks out okay root@hpeos002[] # root@hpeos002[] # netstat -rn Routing tables Destination Gateway Flags Refs Interface Pmtu 127.0.0.1 127.0.0.1 UH 0 lo0 4136 192.168.0.34 192.168.0.34 UH 0 lan0 4136 192.168.0.32 192.168.0.34 U 2 lan0 1500 192.168.0.64 192.168.0.35 UG 0 lan0 0 127.0.0.0 127.0.0.1 U 0 lo0 0 root@hpeos002[] # root@hpeos002[] # gdc start gated started, pid 3927 root@hpeos002[] #
The first thing to notice is that clients are no longer supplied with a default route . The gated process on each of our routers is simply broadcasting the routes they have available. The clients will update their routing tables with all newly discovered routes supplied by gated . gated will broadcast its available routes every 30 seconds. Clients (a router is also a client) will receive these broadcasts and add them to their routing table if they are better routes to a particular destination. A better route is one with fewer hops from the current network. The hop count is the primary measure of whether a particular route is selected. A directly connected path has a hop count of 1. As successive routers are crossed the hop count is increased by one each time. The maximum hop count (RIP's infinity metric ) is when the hop count reaches 16. At that point, the network or node is deemed unreachable . The drawback of this model is that there is no weight given to a particular route depending on the speed of its connection. RIP is a typical vector-distance protocol. Now that we have our clients and routers up and running, we can test our configuration. First, we can perform a sanity check to ensure that the basic routing is working:
root@hpeos002[] # traceroute hpeos001 traceroute: Warning: hpeos001 has multiple addresses; using 192.168.0.67 traceroute to hpeos001 (192.168.0.67), 30 hops max, 40 byte packets 1 hpeos004 (192.168.0.35) 2.349 ms 2.403 ms 1.375 ms 2 hpeos001 (192.168.0.67) 2.091 ms 2.879 ms 1.940 ms root@hpeos002[] #
We need to test the resilience of dynamic routing. In this instance, I will remove the cable from the hpeos004 node because it is acting as the router for node hpeos002 . The time to update the routing table is controlled by the kernel parameter ip_ire_gw_probe_interval :
root@hpeos002[] # ndd -get /dev/ip ip_ire_gw_probe_interval 180000 root@hpeos002[] #
This time is specified in milliseconds . The default value of 180000 = 3 minutes. We can use ndd to change this if we like, but we get into a discussion regarding how often the kernel should wake up to perform the probe of potentially dead gateways against the performance impact of having the kernel wake up and execute kernel code; it's a matter of high availability versus performance. If you are going to use RIP, you must tackle that question yourself. After a few heart-stopping minutes, the routing table is updated and communications are restored:
root@hpeos002[] # netstat -rn Routing tables Destination Gateway Flags Refs Interface Pmtu 127.0.0.1 127.0.0.1 UH 0 lo0 4136 192.168.0.34 192.168.0.34 UH 0 lan0 4136 192.168.0.32 192.168.0.34 U 2 lan0 1500 192.168.0.64 192.168.0.33 UG 0 lan0 0 127.0.0.0 127.0.0.1 U 0 lo0 0 root@hpeos002[] # root@hpeos002[] # traceroute hpeos001 traceroute: Warning: hpeos001 has multiple addresses; using 192.168.0.67 traceroute to hpeos001 (192.168.0.67), 30 hops max, 40 byte packets 1 hpeos003 (192.168.0.33) 2.323 ms 2.370 ms 1.340 ms 2 hpeos001 (192.168.0.67) 2.101 ms 2.861 ms 1.915 ms root@hpeos002[] #
We can also test an individual router by using the ripquery command.
root@hpeos002[] # ripquery -r hpeos003 24 bytes from hpeos003(192.168.0.33) version 2: 192.168.0.64/255.255.255.224 router 192.168.0.33 metric 1 tag 0000 root@hpeos002[] #
These are simply the routes that are being broadcast on my network. In this way, I can begin to troubleshoot why a router is not broadcasting a specific route. As more routers join our network, my routing table will begin to grow and grow. If you become concerned about the possibility of lots of routers flooding your machine, you can consider using options such as noripin and trustedgateways to control which interfaces you will listen on for RIP packets and which nodes you will accept RIP updates from. 16.3.1 Conclusions on RIP The Routing Information Protocol is relatively simple to set up initially. It provides a robust infrastructure for managing multiple routers in a small- to medium-sized organization. One of its main limitations is the speed with which it can react to a failed route, although we can tune this via kernel parameters and the ndd command. The algorithm that RIP uses to establish the best route to a network or host is also one of its drawbacks because we can't build in to the algorithm any characteristics of the connection that would allow us to weight the selection of one route over another. Once our network begins to grow, we will probably want to utilize a more sophisticated routing protocol. Such a protocol is OSPF (Open Shortest Path First). | 