如圖所示，兩臺路由器被兩個以太網連接起來，其中一個以太網包括一個簡單的網橋。該網橋同時還負責處理其他幾條沒有畫出的鏈路流量，所以有時網橋會變得十分擁擠。主機Milne是一臺承擔重要任務的服務器，網絡管理員擔心網橋會延誤Milne的流量，所以在Roo上添加了一條指向Milne的主機路由，該中路指引數據包使用圖上方的以太網以避開該網橋。
這種解決方案看上去是合理的，但是實際並非如此。在添加上面那條靜態路由後，數據包經Roo不但不能被路由到服務器，而且經過Kanga路由器的數據也不能到達服務器，儘管沒有對Kanga作過任何改動。
第一步首先檢查路由表
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的路由表指明目標地址爲172.16.20.75的數據包實際上被轉發到Kanga的接口E1上，這正是我們所期望的。由於目標網絡直接連接到Kanga上，所以不再需要進一步路由。經過快速檢查確實在Kanga和Milne上的兩個以太網接口都工作正常。
從Roo向Milne執行跟蹤命令，發現以下症狀。Kanga應該發向Milne的數據包被髮向Roo的接口E0。Roo又將數據包發給Kanga接口E1，接着Kanga再次將數據包發回給Roo。這看上去像是發生了路由選擇環路，但是爲什麼呢？
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#
此故障的可疑之處在於Kanga不應該對數據包進行路由選擇，但實事恰恰相反。
Kanga應該能夠識別出數據包的目標地址屬於它的直連網絡172.16.20.0，然後使用數據鏈路向主機傳送數據包。因此疑點發生在數據鏈路上。路由器是否具有經過某條邏輯路徑到達目標網絡的正確信息，這一點我們可以通過查看路由表來獲知。同樣的，我們應該檢查ARP高速緩衝區，來確定路由器是否具有經過某條物理路徑到達某臺主機的正確信息。
查看Kanga的ARP高速緩衝
Kanga#show arpProtocol Address Age (min) Hardware Addr Type InterfaceInternet 172.16.21.1 2 00e0.1e58.dc3c ARPA Ethernet1Internet 172.16.20.2 - 00e0.1e58.dcb1 ARPA Ethernet0Internet 172.16.21.2 - 00e0.1e58.dcb4 ARPA Ethernet1Internet 172.16.20.75 2 00e0.1e58.dc39 ARPA Ethernet0
Kanga#
在Kanga的高速緩衝中，Milne的IP地址與MAC標識符00e0.1e58.dc39相對應。但是當檢查Milne的接口時，發現Milne的MAC地址爲0002.6779.0f4c，因此斷定Kanga一字獲取了不正確的信息。
再次查看Kanga的ARP高速緩衝，令人感到疑惑的是與Milne相對就的MAC標識類似於Kanga自己的CISCO接口的MAC標識符。因爲Milne不是CISCO產品，所以MAC標識符的前3個字節應該與Kanga接口的MAC標識符不同。網絡上其他CISCO產品惟有Roo，因此應該檢查一下Roo的ARP高速緩衝。經查Roo接口E0的MAC標識符即爲00e0.1e58.dc39。
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#
所以Kanga錯誤地認爲Roo的接口E0就是Milne的接口。Kanga使用00e0.1e58.dc39作爲發向Milne數據幀的目標標識符，Roo接收到該幀，在讀取封裝數據包目標地址之後，又將數據包路由回Kanga。
但Kanga是如何得到這個錯誤信息的呢？答案是代理ARP。當Kanga首次收到發往Milne的數據包時，它將發送ARP請求，該請求將詢問Milne的MAC，Milne發回了響應，但是Roo也在接口E0收到了此ARP請求。由於在Roo上也有一條通向Milne的路由，這條路由所在的網絡不是Roo收到ARP請求的網絡，所以Roo發送了一個代理ARP應答。Kanga收到Milne的ARP應答後將相關信息輸入到ARP高速緩衝內，由於網橋的時延生成了來自Roo代理ARP的應答隨後到達Kanga，這時Kanga用新信息覆蓋了ARP緩衝內的原始信息。
解決該問題的辦法有兩種，一種是使用以下命令關閉Roo E0接口上的代理ARP功能
Roo(config)#interface e0 Roo(config-if)#no ip proxy-arp
第二種辦法是在Kanga上爲Milne配置靜態ARP表項
Kanga(config)#arp 172.16.20.75 0002.6779.0f4c arpa
該表項不會被任何ARP應答所覆蓋。
兩種方法哪一種最好取決於網絡環境。使用靜態ARP表項意味着如果Milne的網絡接口被更換，那麼需要修改相應的ARP表項來反應新的MAC標識符。另一方面，如果沒有主機使用代理ARP功能，關閉此功能也是一種很好的辦法。
PS. 本案例參照《TCP/IP路由技術卷一》，我曾向大家推薦過這本書，在此，我再次向大家推薦，學網絡不能不讀卷一，學思科不能不讀卷一，學IGP更不能不讀卷一！