Routing TCP[s]IP (Vol. 11998)

Because RIPv2 is merely an enhancement of RIPv1 and not a separate protocol, the commands introduced in Chapter 5 for manipulating timers and metrics and for configuring unicast updates or no updates at all are used in exactly the same way. After a brief look at configuring a RIPv2 process, the rest of this section concentrates on configuring the new extensions.

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:

routerrip version2 network172.25.0.0 network192.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:

routerrip version1 network172.25.0.0 network192.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:

interfaceEthernet0 ipaddress192.168.50.129255.255.255.192 ipripsendversion1 ipripreceiveversion1 ! interfaceEthernet1 ipaddress172.25.150.193255.255.255.240 ipripsendversion12 ! interfaceEthernet2 ipaddress172.25.150.225255.255.255.240 ! routerrip version2 network172.25.0.0 network192.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:

interfaceEthernet1 ipaddress172.25.150.193255.255.255.240 ipripsendversion12 noipsplit-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:

interfaceEthernet0 ipaddress192.168.50.1255.255.255.224 ! interfaceEthernet1 ipaddress172.25.150.1255.255.255.240 ! interfaceSerial0 ipaddress172.25.150.242255.255.255.252 ! routerrip version2 network172.25.0.0 network192.168.50.0 noauto-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.

1. Define a key chain with a name .

2. Define the key or keys on the key chain.

3. Enable authentication on an interface and specify the key chain to be used.

4. Specify whether the interface will use clear text or MD5 authentication.

5. Optionally configure key management.

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.

keychainKeres key1 key-stringKachina accept-lifetime16:30:00Nov281997duration43200 send-lifetime16:30:00Nov281997duration43200 key2 key-stringKiva accept-lifetime04:00:00Nov29199713:00:00Apr151998 send-lifetime04:00:00Nov29199713:00:00Apr151998 key3 key-stringKoshare accept-lifetime12:30:00Apr151998infinite send-lifetime12:30:00Apr151998infinite ! interfaceEthernet0 ipaddress198.168.50.130255.255.255.192 ipripauthenticationkey-chainKeres ipripauthenticationmodemd5

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.