|
静态路由故障诊断 也许你听过这样的问题，“他知道什么?他什么时候知道的?”这些问题对于网络调查员也同样适用。当排除路由故障时，首要的一步就是检查路由表。路由器知道什么?这些信息在路由表中存在多久了?路由器知道怎样如何到达讨论中的目标网络?路由表中的信息准确吗?为了顺利地排除网络的故障，了解如何跟踪路由是十分必要的。 案例研究: 追踪故障路由 图3-9所示的网络在前面已经作过相应的配置，其中包括每台路由器相应的静态路由。 现在发现一个问题，在连接到Pooh 以太网接口的子网192.168.1.0/27 上，设备与子网10.1.0.0/16.上的设备可以正常地通信。然而，当从Pooh向子网10.1.0.0/16 发送ping时，结果出现ping失败(参见示例3-36)。这看上去很奇怪。如果Pooh可以成功地路由数据包到达日标网络，那么为什么从Pooh发的数据包却传送失败呢? 为了解决这个问题，需要跟踪ping所经过的路径。首先，检查Pooh的路由表(参见示例3-37)。(根据路由表)目标地址10.1.5.1 可以匹配到路由表项10.0.0.0/8，该子网经下一跳地址是192.68.1.34, 192.168.1.34 是Eeyore的一个接口。   然后，需要检查Eeyore的路由表(参见示例3-38)。目标地址10.1.5.1 可以匹配到路由表项10.1.0.0/16，该表项的下一跳地址为10.4.6.1,它是Tgger的一个接口地址。  Piglet的路由表(参见示例3-40)显示出目标网络10.1.0.0是一个直连网络。换言之，数据包已经到达目的地了，因为目标地址10.1.5.1就是Piglet自己的接口地址。因为去往目标地址的路径经过验证是正确的，所以我们可以认为来自Pooh的ICMP回应数据包可以到达目标网络。 下一步是跟踪ICMP回应应答数据包所经过的路径。为了跟踪这一路径，读者需要知道回应数据包的源地址一这个地址将是回应应答数据包的目标地址。从路由器发出数据包的源地址就是发送数据包的接口地址。在本例中，最初由Pooh向192.168.1.34 转发回应数据包。在图3-9中，显示出数据包的源地址为192.168.1.33.所以Piglet将要发送的回应应答数据包的目标地址就是192.168.1.33. 参考示例3-34 中Piglet 的路由表，可以发现192.168.1.33 将会匹配到路由表项192.168.1.024并被转发到192.168.1.193,它是Tigger的另一个接口。重新检查示例3-39中Tigger的路由表，首先使我们想起还有一条关于192.168.1.0 的路由。可是，如果根据这些信息准确地解释那里发生的实际情况，那么需要十分小心。 除非用扩展 ping I具将源地址设置为其他地址。  比较一下Tgger路由表中有关10.0.0.0子网和192.168.1.0子网的路由表项。10.0.0.0 的标题表明其子网大小各不相同:换句话说，指向子网10.4.7.0Tigger 的静态路由使用了24位掩码，指向子网10.1.0.0的静态路由使用了16 位掩码。该路由表为每个子网记录了正确的 掩码。 192.168.1.0的标题则不同，它表明Tigger 知道192.168.1.0 有3个子网，且掩码都为255.255.255.224.用这个掩码可以确定目标地址192.168.1.33 所属的目标网络为192. 168.1 32/27.但是路由表中只有关于192.168.1.64/27. 192.168.1.0/27 和192.168.1.192/27 的路由表项，而没有关于192.168.1.32/27 的路由表项，因此路由器不知道该如何到达这个子网。 这样问题就很清楚了, ICMP的回应应答数据包是在Tgger处被丢弃的。一种解决办法是，另外创建一条指向网络192.168.1.32的静态路由，掩码为5.2.525.224指向下一跳的地址为192.168.1.65 或10.4.6.2.还有一种解决办法是,将关于192. 168.1.0的路由表项的掩码由5525.5255.2244改为255255.255.0. 此案例的精髓就是当你跟踪路由时，你必须考虑完整的通信过程。 注意:不仅要验证去往目标网络的路由是正确的，还要验证返回的路径也是正确的。 案例研究: 协议冲突 如图3-10所示，两台路由器被两个以太网连接起来，其中一个以太网包括一个简 单的网桥。该网桥同时还负责处理其他几条没有画出的链路的流量，所以有时网桥会变得十分拥挤。主机Milne是一台承担重要任务的服务器，网络管理员担心网桥会延误Milne的流量，所以在Roo上添加了-条指向Milne的主机路由，该路由指引数据包使用图上方的以太网以避开该网桥。 这种解决方案看上去是合理的，但是实际并非如此。在添加上面那条静态路由后，数据包经Roo不但不能被路由到服务器，而且经Kanga路由的数据包也不能到达服务器，尽管没有对Kanga作过改动。 第一步首先检查路由表。Roo 的路由表(参见示例3-41)指明目标地址为172.16.20.75的数据包实际。上被转发到Kanga的接口EI上，这正是我们所期望的。由于目标网络直接连接到Kanga上，所以不再需要进一步的路由。经过快速检查确定在Kanga和MiIne上的两个以太网接口都工作正常。   在示例3-42中，从Roo向Milne执行跟踪命令,发现以下症状。Kanga 应该发向MiIne的数据包被发向Roo的接口E0. Roo 又将数据包发给Kanga接口EI,接着Kanga再次将数据包发回给Roo.这看上去像是发生了路由选择环路，但是为什么呢? 此故障的可疑之处在于Kanga不应该对数据包进行路由选择，但事实恰恰相反。 Kanga应该能够识别出数据包的目标地址属于它的直连网络172.16.20.0, 然后使用数据链路向主机传送数据包。因此疑点发生在数据链路上。路由器是否具有经过某条逻辑路径到达目标网络的正确信息，这一点我们可以通过查看路由表来获知。同样的，我们应该检查ARP高速缓冲区，来确定路由器是否具有经过某条物理路径到达某台主机的正确信息。  示例3-43给出了Kanga的ARP高速缓冲。在Kanga的高速缓冲中，Mine 的IP地址与MAC标识符00e0. le58.dc39相对应。但是当检查Milne的接口时，发现Milne的MAC标识符为0002.6779.0f4c,因此断定Kanga一定获取了不正确的信息。  再次查看Kanga的ARP高速缓冲，令人感到疑感的是与Milne相对应的MAC标识符类似于Kanga自己Cisco接口的MAC标识符(路由器接口的MAC地址没有相应的存活时间)。因为Milne不是Cisco产品，所以MAC标识符的前3个字节应该与Kanga接口的MAC标识符不同。网络上其他的Cisco产品惟有Roo， 因此应该检查一下Roo的ARP高速缓冲(参见示例3-44)。经查Roo接口E0的MAC标识符即为00e0.le58.dc39.  所以Kanga错误地认为Roo的接口EO就是Milne的接口。Kanga 使用00e0.le58.dc39作为发向Mine数据帧的目标标识符，Roo 接收到该帧，在读取封装数据包的目标地址之后，又将数据包路由回Kanga。 但Kanga是如何得到这个错误信息的呢?答案是代理ARP。当Kanga首次收到发往Milne的数据包时，它将发送ARP请求，该请求将询问Milne的数据链路标识符。Milne 发回了响应，但是Roo也在接口EO收到了此ARP请求。由于在Roo上也有一条通向Mine的路由，这条路由所在的网络不是Roo收到ARP请求的网络，所以Roo发送了一个代理ARP应答。Kanga收到MiIne的ARP应答后将相关信息输入到ARP高速缓冲内。由于网桥的时延造成了来自Roo代理ARP的应答随后到达Kanga,这时Kanga用新信息覆盖了ARP缓冲内的原始信息。 解决该问题的办法有两种。一种是使用以下命令关闭Roo E0接口上的代理ARP功能:  第二种办法是在Kanga上为MiIne配置静态ARP表项:  该表项不会被任何ARP应答所覆盖。示例3-45显示出iE:在输入静态ARP表项以及Kanga上ARP高速缓冲的相应结果。 两种方法哪一种最好取决于网络环境。使用静态ARP表项意味着如果Mine的网络接口被更换，那么需要修改相应的ARP表项来反应新的MAC标识符。另一方面，如果没有主机使用代理ARP功能，关闭此功能也是一种很好的办法。 案例研究: 被取代的路由器 图3-11中有两台路由器Honeypot 和Honeybee通过帧中继链路相连，路由器被配置为IPv4和IPv6,并且使用静态路由建立了静态路由表。 示例3-46和示例3-47分别给出了Honeypot和Honeybee的路由配置。 如示例3-48所示，在两台路由器之间进行ping和trace测试，结果显示网络工作正常。而且两个站点之间的流量也正常。 Honeypot可以从自己的以太网地址到达Honeybee的以太网地址，IPv4 和IPv6都可以。 Honeypot还可以通过Honeybee 到达FEC0:0:0:A:1. 可是Honeybee被-台新的路由器替换了，当把Honeybee的配置导入新路由器时，所有的接口都工作正常。两站点之间的测试结果显示IPv4工作正常,但是IPv6发生故障(参见示例3-49)。 向Honeybee以太网的IPv6地址FEC:8:204:clFF:FES0:F1C0 ping和trace都告失败，但是向FEC:A:0:0:0:ltrace仍然是成功的。 让我们看一下示例3-50中Honeypot的路由表。IPv6 的路由表中有一条路由通过下一跳地址FEC0::3:204:C1FF:FES0:F IC0指向FEC0::/62. 从示例3-50可以知道，通过FEC:3:204:CIFF:FE50:FIC0可以到达FEC:0:0:/62,并且FEC:0:0::/64被连接到接口Serial0/0.2上;去往FEC:0:8:/64和FEC0:0:A:/64的流量都会从该接口转发给Honeybee。 替代操作前后的路由是完全一样的。那么问题出在哪里呢?或许Honeybee 的以太网接口没有正常工作，这可以查看一下示例3-51中Honeybee的以太网接口状态。 从示例3-51中可以看到接口状态正常并且配置了IPv6.根据网络的文档和图表，该接口在替换前可以被ping通，但是替换后就不行了。 如果我们仔细查看以太网接口的输出信息，可以发现全球单播地址的后64位发生了变化。现在地址变为FEC::8:2B0:64FF:FE30:IDE0.因为IPv6地址是EU1-64格式，所以后64位由接口的MAC地址确定。当路由器被替换后, MAC地址也随之改变。路由器上不再有FEC0::8:204:CIFF:FE50:FICO存在。这就是ping不通的原因。 但是根据路由表(参见示例3-50)，对于目标网络FEC0:0:0:8:/62， Honeypot 的静态路由仍然指向FEC::3:204:CIFF:FE50:F1C0.如果MAC地址发生了变化，那么这个地址就不是同步接口的地址了。示例3-52给出了Honeybee同步接口的新地址。 如果目标地址在FEC0:0:0:/62的范围内，Honeypot 的IPv6静态路由将把相关流量指向下一跳地址FECO::3:204:CIFF:FE50:F1C0.虽然下一跳地址是原来路由器的MAC地址，然而使用该路由的流量仍然可以被成功路由。 这里虽然指定的下一跳地址不再是合法的，但是它和新的合法地址在相同的子网中(EC0:0:0:-/64),正像我们在Honeypot的路由表中看到的那样，这个子网被连接到Honeypot的接口Serial0/0.2.上。通过对转发表的递归查询，虽然指定的下一跳地址不存在，但是去往FEC0:0:A:I的流量依然从Seria10/0.2送出。 每当路由器或接口卡被替换时，一定要记得修改参考旧路由器EUI-64 格式IPv6地址的路由表项。 案例研究:追踪IPv6故障路由 在图3-3中,在Honeypot和Honeytree之间添加了一条链路，当主链路万一发生中断时，它可以作为备份链路。改动后的新网络如图3-12 所示。由于使用该网络的IPv6应用对时延不敏感，但是对带宽却要求很高，所以网络管理员决定使用新添加的链路作负载均衡，因此在每台路由器上添加静态路由。 如示例3-53 所示，对应于Honeypot每个已存在的路由，示例中又添加了第二条路由。 示例3-54和示例3-55也分别对Honeytree和Honeybee进行了类似的操作。 现在, IPv6的路由选择间歇性的出现故障，有时工作，有时不工作。可以看出路由表中的静态路由与设计的完全相同。从Honeypot向Honeybee 的以太网接口进行ping测试,有时成功，有时出现主机不可达(参见示例3-56)。 在Honeypot.上调试IPv6的ICMP数据包，你可以发现能成功地收到-些响应数据包(参见示例3-57)，但是还会收到一些来自Honeytree的目标不可达的ICMP消息。 示例3-57在 Honeypot上的调试结果显示:有时成功，有时失败 在Honeytree上调试ICMPv6的结果(参见示例3-58)显示，IPv6 的数据包正在从S0/0.3和S0/0.2到达。 源地址为fe.:2:230:949:24:2780的数据包从接口S0/0.3 到达Honeytree (来自Honeypot的数据包经过Honeypot至Honeytree的链路到达)。对于目标网络fc.:824:4:fe5/:f12/0来说，出站接口是S0/0.2或S003.这是因为Honeytree执行基于数据包的负载均衡，在S00.2和S0/0.3之间交替转发数据包。当数据包从S00.2出站并且从S00.3入站时，数据包将会被转发。但是如果从S0/0.3出站，而又从S00.3入站，则路由器会产生ICMP错误信息，表明ping失败。 如果数据包从同步接口出站后又从相同的接口入站，那么就表明存在路由环路。由于路由器正在处理交换和基于数据包的负载均衡，每台路由器都会轮流使用两条路由，所以一些数据包会从出站的接口又入站。
|
|
|
