In order to ensure complete coverage of traditional IPv4 routing setups, I will show you how to configure and use the RIP protocol within your router. I will illustrate both the UNIX and Cisco viewpoints. While I will assume only that you are going to be running the RIP or RIPv2 protocols, much of what I say will be valid for running other dynamic routing protocols. In Chapter 7 I will cover the link-state, inter-AS, and distance-vector dynamic routing protocols as they work within the framework of a fully policy-routed network.
To this end, recall where I left off at the end of the section "UNIX Configuration Commands." You had a fully functional Linux router running a static routing configuration. This router was capable of routing between the 10.1.1.0/24 and the 192.168.1.0/24 IPv4 networks. It also possessed a default route pointing to a previously known router, 10.1.1.1. It's time to add to that router the ability to participate in a dynamic routed IPv4 network through the use of RIP.
In general, UNIX usage and Linux in particular offer many extra functions through the use of daemons. In the case of dynamic IPv4 routing, this is particularly true. Indeed, the very RFCs that define the original RIP protocol refer to the protocol as the description of the operation of the routed daemon. This is because the routed daemon came along before the RIP protocol was ever formally defined. Thus the very definition of the RIP structure came from the mechanism and workings of the routed daemon functions. So to configure RIP on a Linux system you merely have to run the routed daemon.
The routed daemon may be run from the command line but is usually started in the networking initialization script for the system. In normal operation, routed listens on UDP port 520 for routing information packets from other systems. If the system is considered a router, it also periodically broadcasts copies of its routing tables to all directly connected networks.
When routed is first started it finds all directly connected interfaces configured and running on the system ignoring the loopback interface. If multiple interfaces are found, the system is defined as a router for the purpose of sending out broadcasts. After determining the interface(s) to which it will bind, routed transmits a request packet on each interface and loops listening for request and response packets from other routers.
Upon receiving a request packet routed replies using the information maintained in the system routing table. The response packet generated contains a list of routes marked with a hop count metric. The metric associated with each route provides a rough distance as relative to the originating router.
Response packets received by routed may update the routing tables if any of the following conditions are satisfied:
No routing table entry exists for the destination network or host, and the metric indicates the destination is reachable (hop count < 16).
The source of the packet is the same as the router in the existing routing table entry. That is, updated information is being received from the router through which packets for the destination are being routed.
The existing entry in the routing table has not been updated for some time (standard definition of 90 seconds) and the route is of the same or lesser hop count as the current route.
The new route describes a shorter route to the destination than the one currently stored in the routing tables; the metric of the new route is compared against the one stored in the table to decide this.
In addition to processing incoming response and request packets, routed also periodically checks the routing table entries. If an entry has not been updated for 3 minutes, the hop count is set to 16 and marked for deletion. Before actually deleting the route from the table, routed will wait an extra 60 seconds to ensure that the deleted route will propagate correctly.
routed will periodically broadcast the routing tables every 30 seconds to all directly connected networks. This timeout can be adjusted but since it is part of the standard setup, you will want to leave it alone for most networks.
routed also supports the notion of distant passive and active routers. When routed starts up it looks for the optional configuration file /etc/gateways, and if it exists it reads the file to find routers that may not be located by other means. Routers marked passive in the file do not exchange routing information but may be referred to, while routers marked active will exchange routing information. Routes through passive routers are specified using manual static routes that refer to those routers, but those static routes are not included in any routing information transmitted. Routers marked external are also passive, but are not placed in the kernel routing table or included in routing updates. The function of external entries is to inform routed that another routing process, such as gated, will install a route using that router so routed will not override that route. Such entries are only required when both routers may learn of routes to the same destination. You will see in Chapter 7 that there are many complexities to this when combined with Policy Routing.
Run routed from the command line to illustrate how to turn on RIP routing:
Difficultno? Actually there are several options to routed that you can specify. These include forcing routed to consider the system a router and also allowing routed to only listen for packets but not send any.
Cisco IOS RIP Configuration
Now that you have seen how easy it is to configure and run routed on a Linux system, it's time to set up the same level of functionality on a Cisco router.
Since we are considering RIP you can see that just as in Linux the actual initiation of the protocol is to simply turn it on. In Cisco IOS there is no concept of active interfaces, so you must manually specify all networks for which you want the RIP protocol to be included in the active broadcasts. Thus where Linux routed will listen to and accept RIP information about any network from a connected router, Cisco will passively listen to RIP broadcasts from any router but will only broadcast information about networks it has been told to advertise. Following is a simple example of turning on RIP for our Cisco router.
router rip network 10.1.1.0 network 192.168.1.0
This told the Cisco router to turn on and start using the RIP protocol on all interfaces connected to networks 10.1.1.0/24 and 192.168.1.0/24. The zeros in the network command above refer to full class-based networks.
There are many options in Cisco RIP that you can specify and use. You can specify the type of RIP, as in version 1 or version 2, which is important in that RIPv2 allows for authentication, CIDR, and multivalued netmasks. With routed you must use a version of routed that understands RIPv2, but you would usually in that case use gated or zebra, as you will see in Chapter 7. Also, you can specify changing the various timeouts, apply passive interface rules, and specify active and passive routers as in the /etc/gateways file. See the Cisco IOS documentation for all of the details.
Essentially you now have a fully functioning RIP router participating in the dynamic routing structure of your network.