chanong 也许你听过这样的问题：“他知道什么？他什么时候知道的？” 这些问题也适用于网络调查人员。 解决路由问题时，第一步是检查路由表。 路由器知道什么？ 该信息在路由表中存在了多长时间？ 路由器如何知道如何到达相关的目标网络？ 路由表中的信息准确吗？ 为了成功排除网络故障，有必要了解如何跟踪路由。
案例研究：追踪故障路线
图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是一个接口。
然后，需要检查路由表（参见例3-38）。 目的地址10.1.5.1可以匹配路由表条目10.1.0.0/16。 该表项的下一跳地址是10.4.6.1，是Tgger的接口地址。
从路由表（示例3-40）可以看出，目的网络10.1.0.0是直连网络。 也就是说，数据包已经到达目的地，因为目的地址10.1.5.1是自己的接口地址。 由于到目的地址的路径被验证是正确的，我们可以假设来自 Pooh 的 ICMP echo 数据包可以到达目的网络。
下一步是跟踪 ICMP 回显应答数据包所采取的路径。 为了追踪这条路径，阅读器需要知道回复数据包的源地址 - 该地址将是回复数据包的目标地址。 路由器发送的报文的源地址是发送该报文的接口的地址。 在此示例中，Pooh 最初将响应数据包转发到 192.168.1.34。 如图3-9所示，数据包的源地址为192.168.1.33。 因此，要发送的响应应答报文的目的地址为192.168.1.33。
参考示例3-34中的路由表，您可以发现192.168.1.33将匹配路由表条目192.168.1.024并被转发到另一个接口192.168.1.193。 重新检查例 3-39 中的路由表首先提醒我们还有另一条通往 192.168.1.0 的路由。 然而，根据这一信息准确解释那里实际发生的情况时需要非常小心。
除非你使用扩展的ping工具将源地址设置为另一个地址。
比较 Tgger 路由表中 10.0.0.0 子网和 192.168.1.0 子网的路由表条目。 标题 10.0.0.0 表明其子网大小不同：换句话说，是到子网 10.4.7 的静态路由。 使用24位掩码，到子网10.1.0.0的静态路由使用16位掩码。该路由表记录了正确的
面具。
192.168.1.0 的标题不同。 表示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 更改为 .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执行trace命令，发现以下症状。 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中，有两台路由器通过帧中继链路连接。 路由器配置为 IPv4 和 IPv6，并使用静态路由建立静态路由表。
例3-46和例3-47分别给出了 和 的路由配置。
如图例3-48所示，在两台路由器之间进行Ping和Trace测试，结果表明网络工作正常。 并且两个站点之间的流量正常。
可从其自己的以太网地址（IPv4 和 IPv6）访问的以太网地址。
也可以通过 FEC0:0:0:A:1 到达。
但已被新路由器取代。 将配置导入新路由器后，所有接口均正常工作。 两个站点之间的测试结果表明，IPv4 工作正常，但 IPv6 失败（参见示例 3-49）。
对以太网 IPv6 地址 FEC:8:204:clFF:FES0:F1C0 的 Ping 和跟踪均失败，但对 FEC:A:0:0:0：仍然成功。
让我们看一下例3-50中的路由表。 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连接到接口/0.2 ; go 流向 FEC:0:8:/64 和 FEC0:0:A:/64 的流量将从该接口转发。
替换操作前后的路由完全相同。 那么问题出在哪里呢？ 可能是以太网接口工作不正常。 您可以在例3-51中查看以太网接口的状态。
从例3-51可以看到，接口状态正常，并且配置了IPv6。 根据网络文档和图，更换前可以ping通接口，更换后就不能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，静态路由仍然指向FEC::3:204:CIFF:FE50:F1C0。 如果MAC地址发生变化，则该地址不是同步接口的地址。 例3-52给出了同步接口的新地址。
如果目的地址在FEC0:0:0:/62范围内，则IPv6静态路由会将相关流量指向下一跳地址FECO::3:204:CIFF:FE50:F1C0。 虽然下一跳地址是原始路由器MAC地址，但是使用该路由的流量仍然可以成功路由。
虽然指定的下一跳地址不再合法，但它与新的合法地址（EC0:0:0:-/64）在同一个子网中，我们在路由表中可以看到，这样，这个子网就连接到了接口/0.2。 通过递归查询转发表，虽然指定的下一跳地址不存在，但去往FEC0:0:A:I的流量仍然是从/0.2发出的。
每当更换路由器或接口卡时，请务必修改引用旧路由器 EUI-64 格式 IPv6 地址的路由表条目。
案例研究：跟踪 IPv6 故障路由
图3-3中，在 和 之间增加了一条链路，以便在主链路中断时可以作为备份链路。 修改后的新网络如图3-12所示。 由于使用该网络的IPv6应用对时延不敏感，但对带宽要求较高，网络管理员决定利用新增链路进行负载分担，在各路由器上添加静态路由。
如示例 3-53 所示，为每条现有路由添加第二条路由。
示例3-54和3-55也分别对 和 执行类似的操作。
目前，IPv6 路由间歇性出现故障，有时有效，有时无效。 可以看到路由表中的静态路由和设计的一模一样。 在定向以太网接口上执行 ping 测试。 有时成功，但有时主机无法访问（参见例3-56）。
调试 IPv6 ICMP 数据包。 您可以发现，您可以成功收到一些响应数据包（参见例3-57），但您也会收到一些目的地不可达的ICMP消息。
例3-57的调试结果显示：有时成功，有时失败
调试结果（见例3-58）显示IPv6数据包从S0/0.3和S0/0.2到达。
源地址为 fe.:2:230:949:24:2780 的数据包从接口 S0/0.3 到达（数据包来自通过链路 to）。 对于目标网络fc.:824:4:fe5/:f12/0，出接口为S0/0.2或S003。 这是因为基于报文的负载均衡是在S00.2和S0/0.3之间交替转发报文。 当数据包从 S00.2 出站并从 S00.3 入站时，该数据包将被转发。 但是，如果出站来自 S0/0.3，入站来自 S00.3，则路由器将生成一条 ICMP 错误消息，指示 ping 失败。
如果数据包离开同步接口，然后又进入同一接口，则表明存在路由环路。 由于路由器正在处理交换和基于数据包的负载平衡，因此每个路由器轮流使用两条路由，因此某些数据包从出站接口入站。
微信扫一扫打赏
支付宝扫一扫打赏
