Configuring RIPv2

Case Study: A Basic RIPv2 Configuration

By default, a RIP process configured on a Cisco router sends only RIPv1 messages but listens to both RIPv1 and RIPv2. This default is changed with the version command, as in the following example:

router rip
 version 2
 network 172.25.0.0
 network 192.168.50.0

In this mode, the router sends and receives only RIPv2 messages. Likewise, the router can be configured to send and receive only RIPv1 messages:

router rip
 version 1
 network 172.25.0.0
 network 192.168.50.0

The default behavior can be restored by entering the c ommand no version in config-router mode.

Case Study: Compatibility with RIPv1

The interface-level "compatibility switches" recommended by RFC 1723 are implemented in Cisco IOS with the commands ip rip send version and ip rip receive version.

The internetwork in Figure 7.10 contains routers speaking both RIPv1 and RIPv2. Additionally, Pojoaque is a Linux host running routed, which understands only RIPv1. The configuration of Taos is:

interface Ethernet0 
 ip address 192.168.50.129 255.255.255.192 
 ip rip send version 1 
 ip rip receive version 1 
! 
interface Ethernet1 
 ip address 172.25.150.193 255.255.255.240 
 ip rip send version 1 2 
! 
interface Ethernet2 
 ip address 172.25.150.225 255.255.255.240 
! 
router rip 
 version 2 
 network 172.25.0.0 
 network 192.168.50.0

Because router Laguna is a RIPv1 speaker, E0 of Taos is configured to send and receive RIPv1 updates. E1 is configured to send both version 1 and 2 updates, to accommodate the RIPv1 at Pojoaque and the RIPv2 at Sandia. E2 has no special configuration; it sends and receives version 2 by default.

In Figure 7.11, debug ip rip is used to observe the messages sent and received by Taos. There are several points of interest here. First, notice the difference between the traps for RIPv1 and RIPv2 messages. The address mask and the Next Hop and Route Tag fields (both set to all zeros, in this case) of the RIPv2 updates can be observed. Second, it can be observed that interface E1 is broadcasting RIPv1 updates and multicasting RIPv2 updates. Third, because Taos has not been configured to receive RIPv1, the updates from Pojoaque (172.25.150.206) are being ignored. (Pojoaque has been misconfigured and is broadcasting its routing table.) ^[9]

^[9] Intentionally misconfigured for this example actually, with the routed -s option.

Perhaps the most important observation to be made from Figure 7.11 concerns the update being broadcast to Pojoaque: It does not include subnet 172.25.150.32. Taos knows this subnet, having learned it via multicast RIPv2 updates from Sandia. But Pojoaque cannot receive those multicasts because it speaks only RIPv1. Moreover, although Taos knows the subnet, the split horizon rule prevents Taos from advertising it out the same interface on which it was learned.

So, Pojoaque does not know about subnet 172.25.150.32. Two remedies are available: First, Sandia could be configured to send both RIP versions. Second, split horizon can be turned off at Taos's E1 interface with the following c onfiguration:

interface Ethernet1 
 ip address 172.25.150.193 255.255.255.240 
 ip rip send version 1 2 
 no ip split-horizon 

Figure 7.12 shows the results. Taos is now including subnet 172.25.150.32 in its updates. Some forethought must be given to the possible consequences of disabling split horizon; Taos is now not only advertising 172.25.150.32 to Pojoaque but also advertising it back to Sandia.

Case Study: Using VLSM

Referring again to Figure 7.10, the subnet 172.25.150.0/24 has been assigned to the internet shown. That subnet has been further subnetted to fit the various data links by expanding the mask to 28 bits; the available sub-subnets, in binary and dotted decimal, are shown in Figure 7.13. Each of the subnets^[10] will have, according to the 2ⁿ – 2 formula, 14 host addresses. Out of these, 172.25.150.32, 172.25.150.192, and 172.25.150.224 have been used.

^[10] Now that the concept should be firmly in place, from here on the single term subnet will be used for a subnet, a sub-subnet, a sub-sub-subnet, or whatever.

In Figure 7.14, a token ring has been added to Taos, with 60 hosts. A subnet with at least six host bits is required to accommodate this data link. A classful routing protocol would require that five of the subnets from Figure 7.13 be assigned to the token ring [5 x (2⁴ – 2) = 70], using secondary addresses. With classless protocols and VLSM, four of the subnets from Figure 7.13 can be combined into a single subnet with a 26-bit mask. This step will provide six host bits (62 host addresses), and no secondary addressing is necessary. Four subnets, 172.25.150.64/28 to 172.25.150.112/28, are combined under one 26-bit mask: 172.25.150.64/26. Notice that the four subnets are not selected at random; the first 26 masked bits are identical and are unique within the group of 16 subnets. ^[11]

^[11] The technique used here to combine several addresses into one address serves as an introduction to address aggregation, covered in Chapter 8.

Also, in Figure 7.14, four serial links and four routers have been added to the internetwork. Without VLSM, four of the subnets from Figure 7.13 would have to be used for the four serial links. With VLSM, a single subnet from Figure 7.13 can be used for all four serial links. 172.25.150.240 is selected, and a 30-bit mask is used to create the subnets in Figure 7.15. Each of the resulting four subnets contains two host addresses.

The fundamental objective of subnetting is always the same: A router must be able to identify every data link with a unique address, distinct from any other address in the internetwork. That is the common goal in the preceding two examples. In the first example, multiple addresses were combined into a single address by reducing the size of the mask until only the bits common to all of the addresses remain. Note that this result also happens when subnets are summarized by the major network address. In the second example, multiple subnets were created from a single subnet by expanding the subnet mask.

Case Study: Discontiguous Subnets and Classless Routing

Figure 7.16 shows that two Ethernets are connected to each of the four new routers. At each site, one Ethernet is a member of subnet 172.25.150.0/24 and will have no more than 12 hosts. This is easy enough. Four unused subnets are chosen from Figure 7.13 and assigned.

The other Ethernet at each site is a member of network 192.168.50.0 and will have no more than 25 hosts. Subnets 192.168.50.64/26 and 192.168.50.128/26 are being used, which leaves 192.168.50.0/26 and 192.168.50.192/26. By increasing the mask to 27 bits, these two subnets can be divided into four, each with five host bits—enough for 30 host addresses per subnet. Figure 7.17 shows the four subnets in binary.

Having assigned all subnet addresses, the next concern is the fact that the subnets of 192.168.50.0 are discontiguous. Chapter 5 presents a case study on discontiguous subnets and demonstrates how to use secondary interfaces to connect them . Classless routing protocols have no such difficulties with discontiguous subnets. Because each route update includes a mask, subnets of one major network can be advertised into another major network.

The default behavior of RIPv2, however, is to summarize at network boundaries the same as RIPv1. To turn off summarization and allow subnets to be advertised across network boundaries, use the command no auto-summary with the RIP process. The configuration for Cochiti is:

interface Ethernet0
 ip address 192.168.50.1 255.255.255.224 
! 
interface Ethernet1 
 ip address 172.25.150.1 255.255.255.240 
! 
interface Serial0 
 ip address 172.25.150.242 255.255.255.252 
! 
router rip 
 version 2 
 network 172.25.0.0 
 network 192.168.50.0 
 no auto-summary 

Isleta, Jemez, and Tesuque will have similar configurations. Summarization must also be turned off at Taos and at Acoma. Recall from Figure 7.10 that Laguna was running RIPv1. For this configuration to work, it must be changed to version 2.

Careful consideration should be given to what effect the variable masks will have on Pojoaque, where RIPv1 continues to run. The debug messages in Figure 7.18 show the version 1 and version 2 updates sent from Taos onto subnet 172.25.150.192/28. The version 1 updates will include only those subnets whose masks are 28 bits, the same as the subnet on which the updates are being broadcast. Although Pojoaque will not receive advertisements for 172.25.150.64/26 or any of the serial link subnets, an analysis of those subnet addresses shows that Pojoaque will, in this case, correctly interpret the addresses as being different from its own subnet. Packets destined for these subnets will be sent to Taos for routing.

Case Study: Authentication

Cisco's implementation of RIPv2 message authentication includes the choice of simple password or MD5 authentication, and the option of defining multiple keys, or passwords, on a "key chain." The router may then be configured to use different keys at different times.

The steps for setting up RIPv2 authentication follow.

In the following example, a key chain named Tewa is configured at Taos. Key 1, the only key on the chain, has a password of Kachina; interface E0 then uses the key, with MD5 authentication, to validate updates from Laguna.

Taos(config)#key chain Tewa
Taos(config-keychain)#key 1 
Taos(config-keychain-key)#key-string Kachina 
Taos(config-keychain-key)#interface ethernet 0 
Taos(config-if)#ip rip authentication key-chain Tewa 
Taos(config-if)#ip rip authentication mode md5
				

A key chain must be configured, even if there is only one key on it. Although any routers that will exchange authenticated updates must have the same password, the name of the key chain has significance only on the local router. Laguna, for instance, might have a key chain named Keres, but the key string must be Kachina to speak to Taos.

If the command ip rip authentication mode md5 is not added, the interface will use the default clear text authentication. Although clear text authentication may be necessary to communicate with some RIPv2 implementations, it is almost always wise to use the far more secure MD5 authentication whenever possible.

Key management is used to migrate from one authentication key to another. In the following example, Laguna is configured to begin using the first key at 4:30 p.m. on November 28, 1997, for 12 hours (43200 seconds). The second key becomes valid at 4:00 a.m. on November 29, 1997, and will be used until 1:00 p.m. on April 15, 1998. The third key becomes valid at 12:30 p.m. on April 15, 1998, and will remain valid permanently after that.

key chain Keres 
 key 1 
  key-string Kachina 
  accept-lifetime 16:30:00 Nov 28 1997 duration 43200 
  send-lifetime 16:30:00 Nov 28 1997 duration 43200 
 key 2 
  key-string Kiva 
  accept-lifetime 04:00:00 Nov 29 1997 13:00:00 Apr 15 1998 
  send-lifetime 04:00:00 Nov 29 1997 13:00:00 Apr 15 1998 
 key 3 
  key-string Koshare 
  accept-lifetime 12:30:00 Apr 15 1998 infinite 
  send-lifetime 12:30:00 Apr 15 1998 infinite 
!
interface Ethernet0 
 ip address 198.168.50.130 255.255.255.192 
 ip rip authentication key-chain Keres 
 ip rip authentication mode md5 

As the configuration shows, the password that is accepted from other routers and the password that is used with transmitted messages are managed separately. Both the accept-lifetime and the send-lifetime commands must have a specified start time and may have either a specified duration or end time or the keyword infinite. The key numbers are examined from the lowest to the highest, and the first valid key is used.

Although this configuration uses a 30-minute overlap to compensate for differences in system times, it is highly recommended that a time synchronization protocol such as Network Time Protocol (NTP) be used with key management. ^[12]

^[12] NTP is outside the scope of this book. Refer to the Cisco Configuration Guide for more information.