如图所示,两台路由器被两个以太网连接起来,其中一个以太网包括一个简单的网桥。该网桥同时还负责处理其他几条没有画出的链路流量,所以有时网桥会变得十分拥挤。主机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 Ethernet0Kanga#
在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更不能不读卷一![/img]..