Troubleshooting RIPv2

Two configuration problems common to RIPv2 are mismatched versions and misconfigured authentication. Both difficulties are easy to discover with debugging, as Figure 7.19 shows.

Figure 7.19. Debugging reveals mismatched versions and misconfigured authentication.

A more likely source of trouble with RIPv2, or any classless routing protocol, is a misconfigured variable-length subnet mask. VLSM is not difficult, but if a VLSM scheme is not designed and managed carefully it can cause some unusual routing difficulties.

Case Study: Misconfigured VLSM

Host C in Figure 7.20 cannot communicate across the internetwork, and it cannot even ping the other hosts or routers on the local data link. Hosts A and B have no communications problems with each other or with any other host across the internetwork, but they cannot communicate with C. All hosts are configured to use 172.19.35.1 as the default gateway address.

Figure 7.20. Hosts A and B can communicate across the internetwork, but host C cannot.

When an attempt is made to ping host C from host A or B, the first ping is successful and subsequent pings fail (Figure 7.21). The fact that at least one ICMP Echo Request packet reached C and at least one Echo Reply packet was returned indicates that the problem is not related to the hardware or data link.

Figure 7.21. When host B pings host C, the first ping is successful and subsequent pings fail.

The strange ping behavior leads to the hypothesis that after the first successful packet, subsequent packets ”either the Echo Requests from B or the Echo Replies from C ”are somehow being misdirected. Because this behavior is happening on the local data link, the Address Resolution Protocol (ARP) caches should be examined.

Figures 7.22 and 7.23 show the ARP caches for C and B, respectively. The suspicions about ARP are confirmed here. C's cache contains the correct MAC address for B (00a0.2470.febd), but B's cache has a MAC address of 0000.0c0a.2aa9 associated with C. A closer look at both caches shows that 0000.0c0a.2aa9 is the MAC address of San_Felipe's locally attached interface. This information can be deduced from the fact that the same MAC address is mapped to IP address 172.19.35.2 and to the IP addresses reachable via that router.

Figure 7.22. Host C's ARP cache shows the correct MAC address associated with all addresses.

Figure 7.23. Host B's ARP cache shows that C's IP address is mapped to the MAC address of San_Felipe's interface 172.19.35.2.

The ping results begin to make sense. B broadcasts an ARP Request for 172.19.35.72. C sends an ARP Reply, and B sends its first ping correctly. In the meantime, San_Felipe has received the ARP Request and apparently believes that it has a route to 172.19.35.72. It responds with a proxy ARP (later than C because it has to perform a route lookup first), which causes B to overwrite C's MAC address. Subsequent Echo Request packets are sent to San_Felipe, where they are routed off the local data link and lost. A protocol analyzer attached to the Ethernet proves the point (Figure 7.24).

Figure 7.24. A protocol analyzer, filtering for ARP packets, shows B's ARP request to C and replies from both host C (00a0.24a8.a1a5) and router San_Felipe (0000.0c0a.2aa9).

If you know that the trouble is a routing problem, it remains only to find the cause. First, the subnet addresses for each data link should be determined (Figure 7.25). Next, C's IP address should be compared with all the subnets reachable via San_Felipe, in binary, to find any conflicts. Figure 7.26 shows the addresses with the subnet bits of the last octet in bold.

Figure 7.25. When analyzing any addressing scheme, and espeecially a VLSM design, the subnets for every data link should be determined so that conficts and overlaps may be discovered .

Figure 7.26. C's IP addresses with subnet bits of the last octet highlighted.

A comparison shows that the first three bits of 172.19.35.72/25 match subnet 172.19.35.64/27. San Felipe has routes to both 172.19.35.0/25 and to 172.19.35.64/27 (Figure 7.27). When it receives a packet destined for host C, it will be able to match one bit to subnet 172.19.35.0/25 but three bits to 172.19.35.64/27. As a result, the router will choose the more specific subnet and route the packet off the local data link and into oblivion.

Figure 7.27. san_fellipe has routes to both 172.19.35.0/25 and to 172.19.35.64/27;the second route is a better match of host c's address than is the first route.

The solution to this trouble is to readdress either host C or subnet 172.19.35.64. This step sounds easy on paper. In real life, it may involve some difficult decisions, as it did for the client on whose internetwork this case study is based.

Figure 7.28 shows all the subnets of 172.19.35.0, based on a 27-bit mask. The intention was to combine the first four subnets into a single subnet with a 25-bit mask to accommodate up to 85 hosts on the "backbone" Ethernet. This decision is valid because the grouping will use all the subnets whose first bit is zero; no other address can cause a conflict. Next, 172.19.35.192/27 is subnetted with a 30-bit mask to be used on the serial links. Again, this design decision is valid. Subnets 172.19.35.128/27 and 172.19.35.160 are used as is. The error occurred when subnets 172.19.35.64/27 and 172.19.35.96/27 were selected to be used on two "remote" networks. These subnets had already been spoken for.

Figure 7.28. A 27-bit subnet mask is applied to subnet 172.19.35.0.

The difficult decision is in deciding whether to re-address the backbone, giving up some address space there, or to re-address the two remote subnets and give up address space on each of them. The second option was chosen , using a 28-bit mask to divide 172.19.35.224/27 into two subnets for the remote sites.