Troubleshooting RIPv2 and RIPng
| Two configuration problems common to RIPv2 are mismatched versions and misconfigured authentication. Both difficulties are easy to discover with debugging, as Example 6-29 shows. Example 6-29. Debugging reveals mismatched versions and misconfigured authentication.Jemez#debug ip rip events RIP event debugging is on Jemez# RIP: ignored v1 packet from 172.25.150.249 (illegal version) RIP: ignored v2 packet from 172.25.150.249 (invalid authentication) Jemez#A more likely source of trouble with RIPv2 or RIPng, 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 VLSMHost C in Figure 6-17 cannot communicate across the network, and it cannot even ping the other hosts or routers on the local data link. Hosts A and B have no communication problems with each other or with any other host across the network, but they cannot communicate with C. All hosts are configured to use 172.19.35.1 as the default gateway address. Figure 6-17. Hosts A and B can communicate across the network, 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 6-18). Because at least one ICMP Echo Request packet reached C, and at least one Echo Reply packet was returned, the problem probably is not related to the hardware or data link. Figure 6-18. 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 packetseither the Echo Requests from B or the Echo Replies from Care somehow being misdirected. Because this behavior is happening on the local data link, the Address Resolution Protocol (ARP) caches should be examined. Example 6-30 and Figure 6-19 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 because the same MAC address is mapped to IPv4 address 172.19.35.2 and to the IPv4 addresses reachable via that router. Figure 6-19. Host B's ARP cache shows that C's IPv4 address is mapped to the MAC address of San_Felipe's interface 172.19.35.2. Example 6-30. Host C's ARP cache shows the correct MAC address associated with all addresses.Linux 1.2.13 (Zuni.pueblo.com) (ttyp0) Zuni login: root Password: Last login: Sat Nov 29 11:21:57 on tty1 Linux 1.2.13. Zuni:~# arp -a Address HW type HW address Flags Mask 172.19.35.112 10Mbps Ethernet 00:00:0C:0A:2A:A9 C * 172.19.35.1 10Mbps Ethernet 00:00:0C:76:5B:7C C * 172.19.35.33 10Mbps Ethernet 00:A0:24:70:FE:BD C * 172.19.35.2 10Mbps Ethernet 00:00:0C:0A:2A:A9 C * 172.19.35.3 10Mbps Ethernet 00:00:0C:0A:2C:51 C * 172.19.35.9 10Mbps Ethernet 00:A0:24:A8:26:28 C * 172.19.35.91 10Mbps Ethernet 00:00:0C:0A:2A:A9 C * Zuni:~# 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 6-20). Figure 6-20. 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 6-21). Next, C's IPv4 address should be compared with all the subnets reachable via San_Felipe, in binary, to find any conflicts. Table 6-5 shows the addresses with the subnet bits of the last octet in bold. Figure 6-21. When analyzing any addressing scheme, and especially a VLSM design, the subnets for every data link should be determined so that conflicts and overlaps may be discovered.
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 (Example 6-31). 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. Example 6-31. San_Felipe 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.San_Felipe#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default, U - per-user static route Gateway of last resort is 172.19.35.1 to network 0.0.0.0 172.19.0.0/16 is variably subnetted, 10 subnets, 3 masks R 172.19.35.128/27 [120/1] via 172.19.35.3, 00:00:07, Ethernet0 R 172.19.35.160/27 [120/1] via 172.19.35.3, 00:00:08, Ethernet0 R 172.19.35.212/30 [120/1] via 172.19.35.3, 00:00:08, Ethernet0 R 172.19.35.208/30 [120/1] via 172.19.35.3, 00:00:08, Ethernet0 C 172.19.35.204/30 is directly connected, Serial0 C 172.19.35.200/30 is directly connected, Serial1 R 172.19.35.196/30 [120/1] via 172.19.35.1, 00:00:17, Ethernet0 C 172.19.35.0/25 is directly connected, Ethernet0 R 172.19.35.64/27 [120/1] via 172.19.35.206, 00:00:11, Serial0 R 172.19.35.96/27 [120/1] via 172.19.35.202, 00:00:23, Serial1 R* 0.0.0.0/0 [120/1] via 172.19.35.1, 00:00:18, Ethernet0 San_Felipe# 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 network this case study is based. Table 6-6 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.
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. |
EAN: 2147483647
Pages: 233