Case Study: A Protocol Conflict

Figure 3-10 shows two routers connected by two Ethernet networks, one of which includes a simple bridge. This bridge handles traffic for several other links not shown and occasionally becomes congested. The host Milne is a mission-critical server; the network administrator is worried about traffic to Milne being delayed by the bridge, so a static host route has been added in Roo that will direct packets destined for Milne across the top Ethernet, avoiding the bridge.


Figure 3-10. A host route directs packets from Roo to Milne across the top Ethernet, avoiding the occasionally congested bridge.

wKiom1NrJmuQsBTpAADoir5ws0U909.jpg



This solution seems to be logical, but it isn't working. After the static route was added, packets routed through Roo no longer reach the server. Not only that, but packets routed through Kanga no longer reach the server, although no changes were made to that router.

The first step, as always, is to check the route table. Roo's route table (Example 3-41) indicates that packets with a destination address of 172.16.20.75 will, in fact, be forwarded to Kanga's E1 interface, as desired. Kanga is directly connected to the destination network, so no more routing should be occurring; a quick check verifies that the Ethernet interfaces are functioning at both Kanga and at Milne.

Example 3-41. Roo's route table, showing the static host route to Milne via Kanga's E1 interface.
Roo#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 not set
     172.16.0.0/16 is variably subnetted, 3 subnets, 2 masks
C       172.16.20.0/24 is directly connected, Ethernet0
C       172.16.21.0/24 is directly connected, Ethernet1
S       172.16.20.75/32 [1/0] via 172.16.21.2
Roo#


In Example 3-42, a trace is performed from Roo to Milne, and a symptom is found. Instead of delivering the packets to Milne, Kanga is forwarding them to Roo's E0 interface. Roo forwards the packets to Kanga's E1 interface, and Kanga sends the packets right back to Roo. A routing loop seems to have occurred, but why?

Example 3-42. A trace from Roo to Milne reveals that Kanga is forwarding the packets back to Roo instead of delivering them to the correct destination.
Roo#trace 172.16.20.75
Type escape sequence to abort.
Tracing the route to 172.16.20.75
1 172.16.21.2 0 msec 0 msec 0 msec
2 172.16.20.1 4 msec 0 msec 0 msec
3 172.16.21.2 4 msec 0 msec 0 msec
4 172.16.20.1 0 msec 0 msec 4 msec
5 172.16.21.2 0 msec 0 msec 4 msec
6 172.16.20.1 0 msec 0 msec 4 msec
7 172.16.21.2 0 msec 0 msec 4 msec
8 172.16.20.1 0 msec 0 msec 4 msec
9 172.16.21.2 4 msec 0 msec 4 msec
10 172.16.20.1 4 msec 0 msec 4 msec
11 172.16.21.2 4 msec
Roo#


The suspicious aspect of all of this is that Kanga should not be routing the packet, which appears to be the case.

Kanga should recognize that the destination address of the packet is for its directly connected network 172.16.20.0 and should be using the data link to deliver the packet to the host. Therefore, suspicion should fall on the data link. Just as the route table should be examined to see whether the router has the correct information for reaching a network across a logical path, the ARP cache should be examined to see whether the router has the correct information for reaching a host across a physical path.

Example 3-43 shows the ARP cache for Kanga. The IP address for Milne is in Kanga's cache as expected, with a MAC identifier of 00e0.1e58.dc39. When Milne's interface is checked, though, it shows that it has a MAC identifier of 0002.6779.0f4c; Kanga has somehow acquired incorrect information.

Example 3-43. Kanga's ARP cache has an entry for Milne, but the associated data-link identifier is wrong.
Kanga#show arp
Protocol Address     Age (min)  Hardware Addr   Type  Interface
Internet 172.16.21.1         2  00e0.1e58.dc3c  ARPA  Ethernet1
Internet 172.16.20.2         -  00e0.1e58.dcb1  ARPA  Ethernet0
Internet 172.16.21.2         -  00e0.1e58.dcb4  ARPA  Ethernet1
Internet 172.16.20.75        2  00e0.1e58.dc39  ARPA  Ethernet0
Kanga#


Another look at Kanga's ARP table reveals that the MAC identifier associated with Milne is suspiciously similar to the MAC identifier of Kanga's own Cisco interfaces. (The MAC addresses with no ages associated with them are for the router's interfaces.) Because Milne is not a Cisco product, the first three octets of its MAC identifier should be different from the first three octets of Kanga's MAC identifier. The only other Cisco product in the network is Roo, so its ARP cache is examined (Example 3-44); 00e0.1e58.dc39 is the MAC identifier of Roo's E0 interface.

Example 3-44. Roo's ARP cache shows that the MAC identifier that Kanga has for Milne is actually Roo's E0 interface.
Roo#show arp
Protocol Address     Age (min)  Hardware Addr    Type   Interface
Internet 172.16.21.1        -   00e0.1e58.dc3c   ARPA   Ethernet0
Internet 172.16.20.1        -   00e0.1e58.dc39   ARPA   Ethernet0
Internet 172.16.20.2        7   00e0.1e58.dcb1   ARPA   Ethernet0
Internet 172.16.21.2        7   00e0.1e58.dcb4   ARPA   Ethernet1
Roo#


So Kanga mistakenly believes that the E0 interface of Roo is Milne. It frames packets destined for Milne with a destination identifier of 00e0.1e58.dc39; Roo accepts the frame, reads the destination address of the enclosed packet, and routes the packet back to Kanga.

But how did Kanga get the wrong information? The answer is proxy ARP. When Kanga first receives a packet for Milne, it will use ARP to determine that device's data-link identifier. Milne responds, but Roo also hears the ARP request on its E0 interface. Because Roo has a route to Milne on a different network from the one on which it received the ARP Request, it issues a proxy ARP in reply. Kanga receives Milne's ARP reply and enters it into the ARP cache. The proxy ARP reply from Roo arrives later because of the delay of the bridge. The original ARP cache entry is overwritten by what Kanga thinks is new information.

There are two solutions to the problem. The first is to turn off proxy ARP at Roo's E0 with the following command sequence:

Roo(config)#interface e0
Roo(config-if)#no ip proxy-arp


The second solution is to configure a static ARP entry for Milne at Kanga with the following command:

Kanga(config)#arp 172.16.20.75 0002.6779.0f4c arpa


This entry will not be overwritten by any ARP reply. Example 3-45 shows the static ARP entry being entered and the resulting ARP cache at Kanga. Note that because the entry is static, no age is associated with it.

Example 3-45. A static ARP entry on Kanga corrects the problem caused by proxy ARP.
Kanga(config)#arp 172.16.20.75 0002.6779.0f4c arpa
Kanga(config)#^Z
Kanga#
%SYS-5-CONFIG_I: Configured from console by console
Kanga#show arp
Protocol Address     Age (min)   Hardware Addr    Type   Interface
Internet 172.16.21.1        10   00e0.1e58.dc3c   ARPA   Ethernet1
Internet 172.16.20.2         -   00e0.1e58.dcb1   ARPA   Ethernet0
Internet 172.16.21.2         -   00e0.1e58.dcb4   ARPA   Ethernet1
Internet 172.16.20.75        -   0002.6779.0f4c   ARPA
Kanga#


The circumstances of the network should help determine which of the two solutions is best. A static ARP entry means that if the network interface at Milne is ever replaced, someone must remember to change the ARP entry to reflect the new MAC identifier. On the other hand, turning off proxy ARP is a good solution only if no hosts make use of it.