6.2　IP 多播路由的故障检测与排除

解决IP多播互联网络问题的主要武器就是彻底理解IP多播路由协议，否则没有任何故障检测与排除工具能够有助于从混乱（有时甚至更复杂）的IP多播行为中找出问题的根源。而且，仅了解一种多播路由协议根本不够，还必须理解PIM、IGMP以及单播路由之间的相互作用及关系。

如果读者已经学习了《TCP/IP路由技术（第一卷）》和本卷每章中的故障检测与排除内容，那么应该较好地掌握了解决路由式互联网络问题的方法和所需的技术知识。因而本节不再给出更多的案例研究来解释故障检测与排除技术，而是解释如何使用为多播互联网络提供的一些专用分析工具。

本章中已经出现了很多show和debug命令，这些命令对观察Cisco路由器上的IP多播路由非常有用。表6-2列出了主要可用show命令，表6-3则列出了主要的多播debug命令。在检测和排除IP单播路由故障时，命令show ip route是主要信息源，与此类似，在检测和排除IP多播路由故障时，命令show ip mroute是主要信息源。

6.2.1　使用 mrinfo

命令mrinfo可以观察路由器的多播连接和这些连接的细节情况。该命令最初是作为 Mbone中用于测试路由器的mrouted工具的一部分，因而该命令对多厂商混合域来说非常有用，下面就以图6-10中的拓扑结构为例加以说明。

如例6-55所示，在路由器Sombrero上应用了命令mrinfo，输出结果的第一行显示了用作查询消息源的地址、路由器上运行的Cisco IOS软件版本以及标记的情况，表6-4列出了各种可能的标记及其含义。接下来的两行输出结果显示了路由器上的多播接口以及该路由器的所有对等体。第二行0.0.0.0表示Sombrero的接口192.168.10.1没有对等体，1/0表示该接口的度量值为1且没有设置TTL阈值，该接口上运行的是PIM，该路由器是所连子网的IGMP查询路由器，且该子网为叶子网络（也就是说，没有多播流量经该子网穿越到其他多播路由器）。第三行显示Sombrero的接口192.168.200.1有一个对等体192.168.200.2（路由器Betet），该接口的度量值为1，没有设置TTL阈值，且运行了PIM。

图6-10　整个故障检测与排除案例中所要使用的拓扑结构

例6-55：图6-10中Sombrero的IP多播连接信息。

但mrinfo的真正用处是利用该命令查询阈值的其他路由器，如例6-56所示，通过在该命令中指定Boater的某个IP地址（本例中为环回地址），Sombrero就可以利用该命令来查询Boater。从显示的标记可以知道，路由器Boater启用了SNMP（而Sombrero则未启用），该路由器有5个启用了多播功能的接口，其中2个接口位于叶子网络上，其余3个接口有PIM对等体。检查一下图6-10即可知道上述信息都是正确的。

例6-56：Sombrero利用mrinfo来查询Boater的多播对等体。

例6-57显示了路由器Derby和Fez的查询情况。这两台路由器共享同一个以太网连接，对比这些查询结果，可以看出Derby（192.168.224.4）是子网上的IGMP查询路由器。

例6-57：通过Sombrero来查询Derby（192.168.224.4）和Fez（192.168.224.5）。

6.2.2　使用 mtrace和 mstat

另一个有用的工具是命令mtrace，该命令可以跟踪从指定目的地到指定源之间的RPF路径。与mrinfo类似，mtrace也是一个基于UNIX的MBone工具，可用于多厂商混合域，也可以从域中的任一台路由器发起该命令，而无需通过RPF路径上的路由器发起该命令。

使用该命令时，需要指定一个源地址和一个目的地址，该命令会向目的地发送一条跟踪请求。该请求使用单播方式跟踪所指定的源，由路径上的第一跳路由器以单播方式将跟踪结果反馈给查询路由器。

例6-58显示了Sombrero利用该命令跟踪从Derby的接口192.168.12.2到Turban的接口192.168.11.1的RPF路径的情况。请记住，由于这是一种反向路径跟踪，因而Turban的接口是源，而Derby的接口为目的地。输出结果首先显示了目的地址，以及到达源所经过的每个中间路由器，还显示了从源开始的跳数（因为在该跳上使用了多播路由协议）。

例6-58：利用mtrace来检查从目的地192.168.12.2到源192.168.11.1的RPF路径。

除了隔离多播路由故障之外，mtrace还有一个重要功能，那就是将实时多播包引导到互联网络之前观察多播的行为。请注意，图6-10中没有标示多播源或多播组成员，假设希望找到连接在Boston上的多播源（地址为192.168.14.35），该多播源将发起多播组235.100.20.18的多播流量，组成员的地址为192.168.12.15、192.168.10.8、192.168.11.102。例6-59给出了相应的结果。

例6-59：mtrace可用于测试多播域中暂时不存在的RPF源、目的地和组地址。

例6-59中的跟踪操作指定了包括源地址和目的地址在内的多播组，虽然正常情况下所有多播组的RPF路径都相同，但指定多播组在多播定界或RP过滤等情况下却非常有用。如果没有指定多播组（如例6-58），则默认使用多播组地址224.2.0.1（MBone音频多播组地址）。

命令mstat是mtrace的改良版本，不仅能提供从多播源到多播组目的地路径的踪迹信息，还能提供该路径的统计信息。例6-60重新发起从源192.168.14.35到目的地192.168.10.8路径上多播组235.100.20.18的跟踪操作。对比例6-60与例6-59中的跟踪操作输出结果，可以看出mstat不仅提供了多播包统计情况，还提供了更为详细的整条路径情况。

例6-60：命令mstat提供了更为详细的从源到目的地的多播流量跟踪信息。

从下往上看，例6-60显示了查询源和响应目的地，对本例来说都是192.168.200.1（Sombrero）。请注意，输出结果中用ASCII码表示了箭头符号，显示Sombrero曾向192.168.10.01（在本例中是其自己的接口），然后跟踪了去往路由器Boater接口（多播组连接在上面）的反向路径，之后向Sombrero发送了该查询的响应消息。在输出结果的最左侧，ASCⅡ箭头还表示了多播流量所选取的从源至目的地的路径。在每一跳显示的信息中，ttl和hop的统计值很容易让人误解，因为ttl显示的实际上是从源点开始的跳数，而hop显示的则是跳与跳之间的时延（以毫秒为单位）。需要注意的是，在响应目的地下面还显示了rtt（Round-Trip Time，往返时间）。之后显示了所有多播流量以及命令中所指定的（S,G）对的统计信息，第一条统计信息对比了已丢弃多播包数量和已发送多播包数量，第二条统计信息显示了整体流量速率（以pps[packet-per-second，包/秒]为单位）。对例6-59来说，由于从源至目的地没有任何多播流量，因而这些统计信息均为0，事实上，源和目的地根本就不存在。

如例6-61所示，已经安装了相应的主机，多播源也正在生产多播流量，且组成员也已经加入了多播组，此时可以观察流量速率（pps）和丢包统计情况。在使用命令mstat时请记住，只有实现了路由器的时间同步之后，路由器之间的时延才有效。

例6-61：源和目的地之间开始有多播流量之后再次使用命令mstat。

例6-62给出了路由器之间未实现时间同步时的显示结果，其中的路径跟踪信息及包速率仍然有效，但各跳之间的时延却毫无意义。从例6-62中还可以看到Turban和Beret的路由跳之间丢失了一个多播包，这可能是一个问题，也可能不是一个问题。此时只能多次迭代运行mstat以观察该多播组丢失情况是否正常，如果不正常，那么就需要使用debug命令进行进一步的研究和分析。

例6-62：如果路由器的时钟没有实现同步，那么输出结果中显示的路由跳之间的时延将毫无意义。

最后，可能会在mstat的输出结果中看见负的丢包数（如-3/85）。“负丢包”实际上表示的是获得的多播包，也就是说收到了额外的多播包，此时表明可能出现了环路，需要做进一步的研究和分析。