6.1　IP 多播路由的配置

在配置某特定IP多播路由协议之前，必须将路由器设置为通用、协议中立的多播路由选择方式。

注意：　虽然术语“协议无关（protocol-independent）”比“协议中立（protocol-neutral）更好，但是在PIM中可能会引起混淆。

例6-1所示配置中包含了一些可能要用到的命令，这些命令中只有ip multicast-routing是必需的。就像由默认命令（因而被隐藏了）ip routing启用单播路由一样，该命令的功能也是启用IP多播路由功能。

例6-1中接口E1的配置中包含了命令ip cgmp,该命令会向路由器所连接的Catalyst交换机发送CGMP（Cisco Group Management Protocol, Cisco组管理协议）消息。另一个选项是ip cgmp proxy,当子网中存在其他不支持CGMP的路由器时就可以使用该命令，该命令的作用是让路由器在其 CGMP消息中宣告这些非CGMP路由器。如果要将某台Cisco路由器配置为CGMP proxy（代理服务器），就必须确保将该路由器选举为IGMP查询路由器。

例6-1：命令ip multicast-routing是启用多播路由的必需命令，本基本配置中的其他命令可能会用于某些特殊实现。

有意思的是，本例中没有使用命令来启用IGMP。这是因为在路由器上启用IP多播路由之后，就自动在LAN接口上启用了IGMPv2，本例使用的惟一一个IGMP命令就是在接口 E0上应用的ip igmp version，将默认版本值更改为IGMPvl。表6-1列出了所有更改某接口默认值的IGMP命令，其他IGMP命令则在本章后续内容中进行介绍。

例6-1中的另一条有意义的命令是在接口SO上应用的no ip mroute-cache，该命令的作用是禁止IP多播包的快速交换，与no ip route-cache禁止IP单播包进行快速交换一样。禁用多播包快速交换的理由与禁用单播包快速交换一样，如希望实施按数据包在多条并行路径上进行负载分担，而不是按目的地进行负载分担。

接口TO0的配置中包含了命令ip multicast use-functional，而TO1的配置中则没有使用该命令，因而TO0将多播IP包映射到令牌环功能地址0xC000. 0004. 0000，而T01则将多播 IP地址映射到广播地址0xFFFF.FFFF.FFFF。

6.1.1　案例研究：配置 PIM-DM

在Cisco路由器上启用IP多播路由之后，通过命令ip pim dense-mode即可在路由器的所有接口上启用PIM-DM。图6-1给出了一个简单的PIM-DM拓扑结构，例6-2则给出了路由器Porkpie的配置文件，其他路由器的配置与Porkpie类似。

图6-1　用来示范PIM-DM基本功能的拓扑结构

例6-2：利用命令ip pim dense-mode在接口上启用PIM-DM.

通过分析例6-2可以看出，在配置PIM-DM时要着重考虑两个因素。第一个也是最明显的考虑因素就是必须运行单播路由协议（即本例中的OSPF），否则PIM将无法确定RPF（Reverse Path Forwarding，反向路径转发）接口。通过对比例6-2中的配置文件与图6-1中的拓扑结构，可以看出第二个考虑因素，即配置PIM的时候，必须在每个接口上都启用该协议，否则可能会出现RPF故障。

例6-3显示了多播源10.1.1.88开始传送多播流量，组成员10.1.2.113已经加入多播组之后，路由器Porkpie关于多播组228.13.20.216的多播路由表项。为了清楚起见，本例中仅显示了第5章PIM-DM部分的（S,G）多播路由表项，实际上，除了（S,G）之外还会创建（,G）表项，不过（,G）表项不是PIM-DM规范的一部分，也不用于转发多播包，Cisco IOS软件创建该表项的目的是作为（S,G）数据结构的“父类”。所有连接PIM邻居的接口以及所有直连了组成员的接口都被加入到（*,G）表项的出站接口列表中，如果仅运行了PIM-DM，那么该表项的入站接口列表将始终为空。（S,G）表项中的入站和出站接口均取自于该列表。

注意：　在开始写作本章内容的时候，Cisco已经发布了IOS Software Release 12. 1，并在示范路由器上安装了该软件版本，因而与前面的章节相比，本章中的某些命令在字段格式上存在一些差异，如show ip mroute和show ip route.

例6-3：Porkpie关于多播组228.13.20.216的多播路由表项。

如例6-3所示，E0、S1.609和S1.605都在（*,G）的出站接口列表中，之后S1. 605进入（S, G）表项作为RPF接口，多播包从接口E0被转发出去。虽然S1. 609也位于出站接口列表中，但被剪除了。

如第5章所述，PIM（以及其他使用RPF检查的多播路由协议）可以仅有一个入站接口。例6-4显示了Porkpie的单播路由表，去往多播源子网10.1.1.0/24存在两条等价路径，而PIM会选择IP地址较大的去往邻居的接口作为RPF接口，对例6-4来说，就是接口S1. 605上的地址10.2.4.2。回过头来看一下例6-3，可以看到接口S1.605的确位于入站接口列表中。

例6- 4: Porkpie的单播路由表。

图6-2在互联网络中增加了其他路由器。该路由器Bowler连接在以太网交换机上，与路由器Porkpie共享同一条多路接入链路，因而第5章讨论过的IGMP查询路由器、PIM指派路由器以及PIM转发路由器都将出现。

•　IP地址最小的路由器将成为IGMPv2查询路由器。

•　IP地址最大的路由器将成为PIM指派路由器，仅当子网中运行IGMPvl时才能显出 DR的重要性。

•　拥有去往多播源、管理性距离最小的路由的路由器将成为PIM转发路由器。如果管理性距离相等；那么拥有去往多播源、度量值最小的路由的路由器将成为PIM转发路由器，如果管理性距离和度量值均相等，那么IP地址最大的路由器将成为PIM转发路由器。

图6-2　在图6-1所示的互联网络中增加了路由器Bowler,Bowler、Porkpie以及组成员都通过Catalyst交换机连接在同一个多路接入网络中

例6-5显示了IGMPv2查询路由器和PIM指派路由器规则的应用情况。Porkpie（10.1.2.1）在子网中的IP地址较小，因而成为IGMPv2查询路由器，而 Bowler（10.2.1.25）的IP地址较大，因而成为PIM指派路由器。由于Porkpie和Bowler运行的都是IGMPv2，因而此处的DR没什么意义。

例6-5：Porkpie（10.1.2.1）是IGMPv2查询路由器，Bowler（10.2.1.25）是PIM指派路由器。

例6-6显示了Porkpie和Bowler中去往多播源子网10. 1. 1. 0/24的单播路由。已知图6-2中的互联网络仅运行了OSPF，因而这两条路由的管理性距离均为110，而且可以看出这两条路由的OSPF代价（cost）均为138，因而子网10. 1. 1. 0/24上关于（10. 1. 1. 88, 228. 13. 20. 216）的PIM转发路由器将是IP地址最大的路由器Bowler，例6-7的显示结果证实了该结论。与例6-3中Porkpie的（S,G）表项相比，可以看出接口E0已经被剪除，Bowler的接口E0处于转发模式，表示其正负责将多播流量转发到本子网上。

例6-6：Porkpie和Bowler中去往多播源子网10.1.1.0/24的单播路由拥有相同的管理性距离和度量值，因而IP地址最大的路由器将成为子网10.1.1.0/24的PIM转发路由器。

例6-7：对比（10.1.1.88,228.13.20.216）的多播路由可以看出，Bowler目前是子网 10.1.1.0/24上该多播组的转发路由器。

有意思的是，Porkpie正在该子网上查询组成员，而Bowler正在转发多播组228. 13. 20. 216的多播包，回顾第5章有关IGMP的操作规则可以知道，这种情形是毫无冲突的。Porkpie向组地址发出的组成员查询操作会让子网中的组成员回应IGMP Membership Report（成员关系报告）消息，而Bowler接收到Membership Report消息之后就开始转发多播流量。如果组成员希望离开该多播组，则向All Multicast Routers（所有多播路由器）地址224.0.0.2发出IGMP Leave（离开）消息，该 Bowler也会接收到消息，如例6-8所示。

例6-8：虽然Porkpie（10.1.2.1）是IGMP查询路由器，但Bowler仍然能够从其所连接的组成员接收IGMP Leave（离开）消息。作为该多播组的转发路由器，Bowler从其出站接口列表中删除了该多播组的接口。

重新回到例6-5，命令show ip igmp interface显示Bowler的接口EO正在使用默认的60秒IGMP查询间隔和120秒IGMP查询路由器超时间隔，而且Porkpie也使用着相同的默认时间。例6-9中带有时间戳的调试消息显示这些定时器正处于工作状态，前3条消息显示Porkpie正每隔60秒发送一次IGMP查询消息，但之后发生了某些事情而导致停止查询操作。第4~5两条消息显示120秒之后Bowler接管了查询路由器的角色，并立即发送了自己的查询消息，随后就以60秒为间隔周期性地发送查询消息。最后2条消息显示Porkpie重新称为查询路由器并再次发送查询消息，这是因为Porkpie的IP地址较小，因而Bowler知道Porkpie是查询路由器，从而不再发送查询消息。

例6-9：利用debug命令来显示IGMP查询路由器失效并重新生效所发生的事件。

第5章中曾经提到，PIM默认每隔50秒向其邻居发送一条Hello消息，而保持时间为Hello间隔的3.5倍，如果在保持时间内没有收到来自其邻居的Hello消息，那么将认定该邻居失效。在下面的例6-10中，Bowler和Porkpie最初均处于在线状态，且Bowler正将多播组228.13.30.216的多播包转发到以太网上，例6-10显示了Bowler失效后所发生的事件情况。

例6-10：由于在预设的保持时间内Porkpie都没有收到来自Bowler的Hello消息，因而将接管为多播组228.13.30.216的PIM转发路由器。

由于Porkpie在保持时间内都没有收到来自Bowler的Hello消息，因而知道必须承担PIM转发路由器的职责，其接管了DR的角色并向其邻居发送PIM Graft（嫁接）消息。对比例6-11中Porkpie关于（10.1.1.88,228.13.20.216）的路由表项与例6-7中最上面的内容可以知道，Porkpie现在正将多播包转发到以太网上，但是在成为转发路由器之前Porkpie已剪除了该接口。此外需要注意的是，例6-11中该多播路由表项中已经没有了例6-7中该表项的剪除标记。

例6-11：Bowler失效后，Porkpie开始将多播流量转发到以太网上。

6.1.2　配置 PIM-SM

在学习了如何在接口上启用PI-DM的配置操作之后，读者肯定希望了解如何在接口上启用 PIM-SM，这非常简单，使用命令ip pim sparse-mode即可。有关PIM-SM的多数配置都没有什么新意，也不需要完全独立的示例，惟一的要求（也是比较有意思的配置工作）就是RP（Rendezvous Point，聚合点）的标识。第5章是曾经提到，既可以静态配置RP，也可以利用Cisco的Auto-AP协议或开放的引导协议自动发现RP，以下案例研究将逐一示范这3种配置方法。

1．案例研究：静态配置RP

图6-3所示的互联网络与本章前面的拓扑结构一样，只是现在的路由器运行的都是 PIM-SM，路由器Stetson被选为RP，网络中的其他路由器都被静态配置了该信息。Stetson的RP地址为10.224.1.1，只要通过单播路由协议宣告该地址，该地址就可以存在于所有接口上，因而其他路由器都知道如何到达该地址。不过在实际应用中，应该使用环回接口，这样做的次要原因是可以更容易地管理RP地址，主要原因是不用将RP地址链接到任何可能会失效的物理接口，这也是建议IBGP对等端点使用环回接口的原因。

例6-12显示了Bowler的配置文件，原先配置为密集模式的接口都已被配置为稀疏模式。

例6-12：图6-3中Bowler的配置。

图6-3　互连网络中运行的是PIM-SM，RP位于10.224.1.1

例6-12中的另一个需要注意的是命令ip pim rp-address 10.224.1.1，其作用是告诉路由器如何发现RP。当静态配置RP之后，所有连接了多播组或组成员的路由器都得有一个这样的配置语句，以便让它们知道RP在什么地方。需要注意的是，Stetson的环回接口本身并不需要运行PIM（如例 6-13所示），除了提供RP地址之外，无需环回接口提供任何PIM功能，该RP地址将通过OSPF被宣告给本互联网络。虽然Stetson没有连接多播源或组成员，但其配置文件中也出现了语句ip pim rp-address 10.224.1.1，这样做的原因是让该路由器知道其就是RP。在实际应用中，为互联网络中的所有路由器都静态配置RP地址是非常明智的，这样做的好处是不必担心是否在不需要的地方配置了该语句，从而可以避免在需要配置该语句的地方遗漏了该语句。

例6-13：图6-3中Stetson和RP的配置。

前面的PIM-DM案例研究中对比了Porkpie和Bowler中关于多播组228.13.20.216的多播路由表项。这些路由表项之所以重要，就在于这些路由器与组成员共享同一个以太网子网，因而产生了IGMP查询和PIM转发等问题。例6-14又重新对比了Porkpie和Bowler关于多播组228.13.20.216的多播路由表项，但此时的路由表项看起来比例6-7中密集模式表项要更模糊一些。例如，Porkpie的（,G）表项显示E0位于出站接口列表并处于转发状态，而其（S, G）表项的出站接口列表为空。但Bowler的接口E0位于（,G）表项的入站接口列表中，且该表项的出站接口列表为空，此外，E0位于（S,G）表项的出站接口列表中且处于转发状态。那么，究竟是哪台路由器在转发多播包呢？

例6-14：对比Porkpie和Bowler中关于多播组228.13.20.216的多播路由表项。

只要仔细研究第5章中的PIM-SM操作过程即可明白哪台路由器正在转发多播包。首先知道Bowler是DR（因为其IP地址在子网10.1.2.0/24中较大），也可以通过命令show ip pim interface来验证DR（如例6-15所示）。

例6-15：子网10.1.2.0/24上的PIM指派路由器是Bowler（10.1.2.25）。

当主机首次请求加入某多播组时，DR将加入共享RPT（RP Tree, RP树）。查看例6-16中Bowler的单播路由表可以知道，从Bowler到RP需要经过Porkpie（通过子网10.1.2.0/24），这也是Porkpie的接口E0位于（,G）表项的出站接口列表中的原因。该表项表示RPT将Bowler链接到Stetson, Bowler的（,G）表项的出站接口列表为空且带有一个剪除标记（因为其是 RPT树枝的端点）。

例6-16：从Bowler到RP的最短路由是通过其连接的以太网到Porkpie。

其次，接收到第一个多播包之后，在默认情况下连接了组成员的PIM-SM路由器将试图切换到去往多播源的SPT（Shortest Path Tree，最短路径树），而不论该路径是否经由RP。Bowler的单播路由表显示出去往多播源子网10.1.2.0/24的最短路由是经由Fedora（如例6-17所示）。再回过头来看一下例6-14，Bowler的（S,G）表项显示Fedora（位于10.2.5.2）是上游邻居或RPF邻居，E0位于该表项的出站接口列表中且处于转发状态（因为多播包理所当然地要被转发到其组成员）。由于Porkpie没有为该多播组转发多播包，因而其（S,G）表项的出站接口列表为空且带有被剪除标记。

例6-17：Bowler去往多播源子网10.1.2.0/24的最短路由是经由Fedora，出接口为S1.705。

同样，可以利用调试命令来查看多播包的转发过程。例6-18显示了Bowler正在接口 S1.705上经Fedora从多播源10.1.1.88接收多播组228.13.20.216的多播包，并将这些多播包从接口E0向外转发给其所连接的组成员。

例6-18：利用命令debug来捕捉IP多播包（mpacket），可以看到Bowler正在接口S1.705上接收（10.1.1.88, 228.13.20.216）的多播包，并通过接口EO向外转发。

在路由器Porkpie上使用相同的命令也能看到有趣的结果（如例6-19所示），从输出的调试消息中可以看出路由器Porkpie并没有从RP或Fedora接收多播组228.13.20.216的多播包，而是正在接收Bowler转发到以太网子网10.1.2.0/24上的多播包。例6-14中Porkpie的多播路由表项显示该多播包的RPF接口为S1.609，由于这些多播包是在接口E0上被接收到的，因而RPF检查失败，从而丢弃这些多播包。

例6-19：Porkpie没有转发多播组228.13.20.216的任何多播包。

如前所述，本例所基于的一个事实是Cisco路由器在接收到第一个多播包后将切换到该多播组的SPT。第5章中曾经说过，可以利用命令ip pim spt-threshold来更改这种默认操作，其中的阈值以kbit/s为单位。这样一来，只有当该多播组的多播包的到达速率超出该阈值时，路由器才切换到SPT。此外也可以使用关键字infinity，这样就可以让路由器永远也不切换到 SPT。通过观察在图6-3的Bowler的配置文件中增加命令ip pim spt-threshold infinity之后的情况很有启发意义。例6-20显示了重新配置Bowler之后的Porkpie和Bowler的多播路由表项情况，Bowler的RPT以E0为出接口，穿过子网10.1.2.0/24并经由Porkpie，因而Porkpie现在必须转发来自RP的多播包，但Bowler的接口E0也是该多播组的RPF接口，而PIM路由器又无法通过多播组的RPF接口向外转发该多播组的多播包，这只是水平分割规则（不能通过数据包的接收端口向外转发该数据包）的多播版本。因而Bowler的（*,G）表项被加入了被剪除标记，而Porkpie则开始向组成员转发该多播组的多播包。有意思的是，虽然因Bowler必须使用RPT而让Porkpie承担了多播包转发职责，但Porkpie本身却没有这方面的约束，因而将切换到SPT，从而经由Fedora而不是RP。

例6-20：将Bowler被配置为永远不切换到SPT之后，转发多播组228.13.20.216流量的职责就传递给了Porkpie。

有时可能需要为不同的RP分配不同的多播组，这通常发生于多播域中的多播组数量增加较多的场合，从减少对路由器的内存和CPU需求的角度出发，应划分RP的职责。图6-4所示互联网络的拓扑结构与前面相同，只是现在的Fedora也被指定为RP（地址为10.244.1.2）。结合访问列表，就可以配置多个RP并指定哪些多播组使用哪个RP。

图6-4　Stetson和Fedora都是RP，通过访问列表和静态配置RP地址，可以告诉多播域中的所有路由器哪些多播组应该使用哪个RP

例如，考虑例6-21中的配置文件。

例6-21：Bowler的RP过滤配置。

可以看出，access-list5指定多播组允许使用RP10.224.1.2（Fedora）,而access-list 10则指定多播组允许使用RP 10.224.1.1（Stetson）,多播组地址与上述两个访问列表都不匹配的多播组则没有被指定RP，因而无法加入任一个共享树。将例6-21所示配置增加到Bowler的配置文件中之后，例6-22显示了配置结果，可以看出，所列出的多播组（都是该路由器上的活动多播组）都按照access-list 5和access-list 10被映射到某个RP上。

例6-22：命令show ip pim rp可以显示路由器上的活动多播组以及被映射到的RP。

2．案例研究：配置Auto-RP

对一个稳定的PIM域来说，静态配置RP是非常直观的，当在该域中增加新路由器时，都要配置一个或多个RP的位置。但是对以下两种情形来说，静态配置RP将会带来一些问题。

•　需要更改RP地址（如更改现有RP的地址或安装了一个新RP）时，网络管理员必须修改所有PIM路由器上的静态RP配置，从而会对大型多播域造成长时间的网络中断。

•　RP失效时，静态配置的PIM域无法轻易地切换到备用RP上。

因而除了最小型PIM域之外，为了简化管理并提高冗余性，都部署了两种自动RP发现机制中的一种：Auto-RP或Bootstrap协议。本案例研究将说明Auto-RP的配置操作，而下一小节将介绍Bootstrap协议的配置操作。

如第5章所述，Auto-RP是在Bootstrap协议成为PIMv2组成部分之前，由Cisco开发的专有协议，Auto-RP必须用于Cisco IOS Software Release 11.3之前的版本（该版本第一次支持PIMv2）。

配置基本的Auto-RP需要以下两个步骤。

•　第1步：必须配置所有C-RP（Candidate RP，候选RP）。

•　第2步：必须配置所有映射代理。

利用命令ip pim send-rp-announce即可配置C-RP。在使用该命令时需要指定接口（路由器通过该接口取得其RP地址）和TTL值（该值将被加入到宣告消息中）, TTL提供了定界功能，可以确保多播包不会被转发到多播源的边界之外。当路由器被配置为C-RP之后，该路由器将会每隔60秒向保留地址224.0.1.39发送一条RP-Announce（RP通告）消息。

映射代理负责侦听来自C-RP的RP-Announce消息并选出RP，之后通过RP-Discovery（RP发现）消息（每隔60秒将该消息发送到保留地址224.0.1.40）将RP宣告到PIM域中。

图6-5显示了一个示例拓扑结构，其中的路由器Stetson和Fedora都是C-RP，地址分别为10.224.1.1和10.224.1.2，Porkpie是映射代理，其标识地址为10.224.1.3。

图6-5　Stetson和Fedora都是C-RP，Porkpie是映射代理

例6-23显示了Fedora配置中的相关内容。

例6-23：将Fedora配置为C-RP。

Stetson的配置与此类似，RP地址取自于接口LO，关键字scope则用于设置RP-Announce消息的TTL值。

例6-24显示了将Porkpie配置为映射代理的配置情况。

例6-24：将Porkpie配置为映射代理。

上例中的接口LO被用于导出映射代理地址，且TTL被设置为5。需要注意的是，在例 6-24的配置中，必须在环回接口上配置PIM-SM。对映射代理来说必须如此，如果未能首先在环回接口上启用PIM-SM，那么将会得到与例6-25相似的错误消息。

例6-25：未能在映射代理的环回接口上启用PIM-SM而产生的错误消息。

相应的配置语句将与如下语句相似：

ip pim send-rp-discovery scope 5

由于指定的接口未被接受，因而映射代理无法工作。与映射代理不同，PIM无需在C-RP的环回接口上进行配置，当然，无论是映射代理还是C-RP，都必须在所有连接了PIM邻居的物理接口上配置PIM-SM。

当初次为某Cisco路由器配置PIM-SM之后，该路由器将侦听地址224.0.1.40。如果必须变更C-RP或映射代理，那么将由被更改设备自动宣告这些变更，整个域中的路由器都将知晓该变更情况。不过，最重要的功能特性是可以为任何或全部多播组配置多个RP，映射代理将基于RP地址最大的规则为多播组选择RP，如果该RP出现故障，那么映射代理将选择地址次大的RP并宣告该变更情况。

例6-26给出了一个RP发生故障倒换时的例子，使用了命令debug ip pim auto-rp来显示 Auto-AP的全部操作情况。可以看到Porkpie（图6-5中的映射代理）正在接收来自Stetson（10.224.1.1）和Fedora（10.224.1.2）的RP-Announce消息，由于Fedora的IP地址较大，因而被宣告为域中所有多播组（224.0.0.0/24）的RP。当Porkpie从Fedora接收到第一个RP-Announce消息之后，路由器Fedora就出现了故障，当Porkpie在180秒（通告间隔的3倍）内都没有收到来自Fedora的RP-Announce消息之后，将宣称该RP无效，选择Stetson为新的RP，并开始宣告该新RP。为清楚起见，上述事件均以高亮方式在调试消息中加以标识。

例6-26：利用debug命令来观察图6-5中映射代理上发生的RP故障倒换情况。

如例6-27所示，在Bowler上应用了命令show ip pim rp之后，可以显示出该路由器正在接收的多播组以及这些多播组所映射到的RP情况。第一个显示结果取自Fedora失效之前，可以看出所有的多播组均被映射到其RP地址；第二个显示结果取自Fedora失效之后映射代理开始宣告新RP，可以看出此时所有的多播组均被映射到Stetson。

例6-27：在Fedora失效之前，Bowler的全部多播组均被映射到该RP（10.224.1.2）；在Fedora失效之后，Bowler的全部多播组都被重新映射到Stetson（10.224.1.1）（基于映射代理提供的信息）。

要想更改C-RP发送RP-Announce消息的60秒默认间隔，可以在命令ip pim send-rp- announce中加入关键字interval。例如，下述命令将会让Fedora每隔10秒发送一条 RP-Announce消息。

ip pim send-rp-announce LoopbackO scope 5 interval 10

保持时间（是映射代理等待从C-RP接收到RP-Announce消息的时间）始终是宣告间隔的3倍，因而上述命令可以将Fedora的故障倒换时间缩短到30秒，当然要以路由器发出6倍数量的RP-Announce消息为代价。

C-RP在其RP-Announce消息中向多播组宣告其可以充当RP的角色，默认为宣告到224.0.0.0/24（表示全部多播组）。不过与前一个案例研究中所说的静态配置RP一样，有时可能希望将不同的多播组映射到不同的RP。例如，假设希望将224.0.0.0～231.255.255.255的多播组（224.0.0.0/5）全部映射到Stetson，而将232.0.0.0～239.255.255.255的多播组（232.0.0.0/5）映射到Fedora，则这两台路由器的C-RP配置情况将如例6-28所示。

例6-28：将Stetson和Fedora配置为C-RP。

关键字group-list将语句ip pim send-rp-announce与访问列表绑定在一起，该访问列表描述了哪台路由器可以成为多播组的RP。在映射代理Porkpie根据RP-Announce消息中的约束信息宣告了RP之后，Bowler中的group-to-RP映射情况如例6-29所示，239.255.255.254被映射到Fedora，而其他3个多播组（其地址均落于224.0.0.0/5范围之内）则被映射到Stetson。

例6-29：Bowler中的group-to-RP映射情况，显示了在Stetson和Fedora上配置的约束条件。

假设希望将228.13.0.0到228.13.255.255的多播组映射到Fedora，那么Fedora的配置将如例6-30所示。

例6-30：将Fedora配置为多播组228.13.0.0〜228.13.255.255的C-RP。

例6-31显示了Bowler的配置结果，可以看出Stetson的配置没有发生变化，该C-RP正在将多播组224.0.0.0/5宣告为其允许的多播组范围，其中就包含了228.13.0.0/16。此时，映射代理有了两个关于多播组228.13.0.0/16的C-RP，由于Fedora的IP地址较大，因而将其选择为RP。

例6-31：多播组228.13.0.0/16原先被映射到例6-29中的RP 10.224.1.1，现在已被映射到RP 10.224.1.2.

通过命令show ip pim rp的多种应用形式可以观察到group-to-RP映射情况，该命令的基本应用形式（如前面的几个例子）只能显示路由器上的活动多播组以及每个多播组地址所映射的RP情况。如果要观察映射到某个RP的所有多播组，就要使用show ip pim rp mapping（如例6-32所示）。

例6-32：通过接收来自映射代理10.224.1.3的RP-Discovery（RP发现）消息，Bowler将3个多播组地址范围映射到2个不同的RP上。

另一个相似的命令是show ip pim rp mapping in-use（如例6-33所示）。除了例6-32中显示的信息之外，该命令还显示了该路由器上正在使用的多播组地址范围。请注意，例6-32和例6-33的输出结果中都显示了映射代理的源10.224.1.3，在拥有多个映射代理时该信息将非常有用。

例6-33：关键字in-use显示了该路由器上正在使用的多播组地址范围。

有时，当某多播地址在路由器上被激活之前，就可能希望知道该多播地址将要映射到哪个RP。例如，假设希望知道路由器Bowler上多播组235.1.2.3将会被映射到哪个RP，那么首先应使用命令show ip pim rp-hash（如例6-34所示），显示多播组235.1.2.3将被映射到RP 10.224.1.2，该结果与前面在访问列表中配置的约束条件保持一致。

例6-34：命令show ip pim rp-hash可以显示某特定多播组将要被映射到哪个RP。

通过设置RP通告过滤器（announcement filter），可以防止映射代理接受未经授权的路由器（这些路由器可能被有意或无意地配置为C-RP）。例6-35以Porkpie为例给出了配置示范。

例6-35：为Porkpie配置RP通告过滤器。

例6-35中的配置建立了一个RP通告过滤器，要求路由器仅接收access-list 1所指定的 C-RP，并仅接收由这些C-RP宣告的、由access-list 11所指定的多播组。在上述配置中，access-list 1允许Stetson和Fedora，并允许这些路由器成为所有多播组的C-RP。

在整个案例研究中，为了清楚起见，图6-5中的Stetson和Fedora为C-RP，而Porkpie为映射代理。但在实际应用中，配置多个RP（以提高冗余性）和单个映射代理是毫无意义的，因为映射代理失效后，RP将无法被宣告给多播域，PIM-SM也将失效。更为现实的方法是将Stetson和Fedora同时配置为C-RP和映射代理。Auto-AP可以确保这两个映射代理都能导出并宣告相同的RP，当其中的一台路由器失效后，另一台路由器仍能保持服务状态，并将RP宣告给多播域。

3．案例研究：配置稀疏—密集模式

前一个案例研究中的例子有点“使诈”，回顾图6-5可以看出，C-RP被直连到映射代理，而映射代理被直连到Bowler。图6-6中的Homburg现在被配置为Auto-AP映射代理，该拓扑结构将会产生进退两难的有趣局面：Homburg在RP-Discovery（RP发现）消息中将RP宣告给域中的所有路由器（使用保留地址224.0.1.40），所有的PIM-SM路由器都会侦听该地址，但是在稀疏模式应用环境中，多播包必须首先在共享树上进行转发，这就意味着侦听 224.0.1.40的路由器为了接收RP-Discovery消息，就必须向它们的RP通告希望加入该多播组。但是，如果这些路由器连RP-Discovery消息都没有接收到，那么又如何得知谁是RP呢？

图6-6　Homburg现在被配置为映射代理

如果C-RP没有直连到映射代理，也同样会出现这种矛盾情形。映射代理要想选择RP就必须从C-RP接收RP-Announce消息，为此就必须加入多播组224.0.1.39，但是，如果映射代理不知道RP位于何处，就无法加入该多播组，而映射代理只有接收到RP-Announce消息之后才能知道RP位于何处。

为此，创建了PIM稀疏—密集模式以解决上述问题。当某接口被配置为此模式时，如果知道了该多播组的RP，就使用稀疏模式；如果不知道RP，则使用密集模式。对224.0.1.39和224.0.1.40来说，多播组被认为处于密集模式下。例6-36显示了Homburg的稀疏—密集模式配置情况。

例6-36：路由器Homburg的PIM稀疏—密集模式配置。

在所有物理接口上都应用了命令ip pim sparse-dense-mode，并且在图6-6所示拓扑结构的所有路由器的所有物理接口上也做了相似的配置。由于仅需要将环回接口作为映射代理地址，而无需做出稀疏／密集模式决策，因而环回接口仅用于稀疏模式。接口E0/0也可以被用于稀疏模式，这是因为其没有连接任何下游路由器，而且也无需做出稀疏/密集模式决策。但是为了保持一致性，建议在实际应用中将所有接口都置于稀疏—密集模式下。事实上，只要所有的路由器都支持稀疏—密集模式，那么一般都建议在所有的现代PIM域中都使用该模式。

例6-37给出了重新配置之后的Homburg的多播路由表，可以看出（,224.0.1.39）和（，224.0.1.40）的路由表项都带有D标记，表示它们运行于密集模式，其他（*,G）表项则被标记为稀疏模式。

例6-37：Homburg多播路由中与（,224.0.1.39）和（,224.0.1.40）相关的路由表项显示这些多播组都运行于密集模式。

除了这两个Auto-AP多播组之外，有时可能希望某些多播组运行于稀疏模式，而让其他多播组运行于密集模式。通过在C-RP上应用命令ip pim sendrp-announce group-list（如前面的案例研究所述），可以控制将哪些多播组映射到RP，从而让这些多播组运行于稀疏模式，其他没有被映射到RP的多播组则运行于密集模式。

4．案例研究：配置Bootstrap协议

RFC 2117在首次描述PIMv2时，将Bootstrap协议指定为自动RP发现机制，Cisco IOS软件在Release 11.3T之后开始支持PIMv2，并支持Bootstrap协议。

配置Bootstrap协议的两个步骤与配置Auto-AP协议的两个步骤相似。

•　第1步：必须配置所有C-RP。

•　第2步：必须配置所有C-BSR（Candidate Bootstrap Router，候选引导路由器）。

图6-7显示了与前两个案例研究中一样的PIMv拓扑结构，只是此时运行的不再是 Auto-AP协议，而是Bootstrap协议。为了提供更强壮的网络设计，此时的Stetson和Fedora不但是C-RP，而且都是C-BSR，使得RP和BSR都具备故障倒换能力。

例6-38给出了Stetson和Fedora的相关配置。

例6-38：将Stetson和Fedora同时配置为C-RP和C-BSR。

图6-7　Stetson和Fedora同时充当C-RP和C-BSR的角色

首先，需要从所有可用C-BSR中选出一个BSR，这些C-BSR会向整个PIM域发送 Bootstrap消息（目的地址为224.0.0.13），消息中包含了发信路由器的BSR地址和优先级。到目前为止的配置文件中，都没有更改默认优先级O和默认哈希掩码长度O，因而这两台 C-BSR的相应值均相等，从而BSR地址将成为决定因素。由于Fedora的BSR地址（10.224.1.2）大于Stetson的BSR地址（10.224.1.1），因而Fedora成为BSR，例6-39证实了该推论。通过在域中的路由器上使用命令show ip pim bsr-router，不但可以观察到活动BSR，还可以观察到BSR的地址、运行时间、优先级、哈希掩码长度以及保持时间等参数。

例6-39：命令show ip pim bsr-router显示了PIMv2域的BSR。

C-RP接收到Bootstrap消息并确定了BSR的地址之后，将以单播方式向BSR发送 Candidate-RP-Advertisement（候选RP宣告）消息，这些消息中包含了C-RP的地址和优先级。BSR将C-RP集合到一个RP-Set中，而RP-Set又被包含到Bootstrap消息中，这里就是Bootstrap与Auto-AP存在重大区别的地方：与Auto-AP映射代理不同，BSR并不选择RP。PIMv2路由器接收到Bootstrap消息之后将选择RP，用于做出选择决策的算法可以确保所有路由器都会为相同的多播组选择相同的RP。

例6-40显示了Bowler上的group-to-RP映射情况，可以看出RP是Stetson，这是因为其 IP地址较小，因而被选为RP（本例中C-RP的优先级都相同）。

例6-40：Bowler的所有活动多播组都被映射到Stetson，与Auto-RP不同，RP地址最小的C-RP被选为RP。

例6-41显示了被映射到RP的全部多播组地址范围。与例6-33的输出结果相对比可以看出，本例所显示的映射关系可以从Bootstrap消息中推导出来，并且路由器通过RP-Set知道了所有的C-RP。

例6-41：Bowler知道Stetson和Fedora都是C-RP。

可以更改BSR和RP的默认行为。例如在例6-39中，BSR是Fedora（因为其IP地址较大），如果希望Stetson成为BSR，而将Fedora设置为Stetson失效后的备用BSR，可以将Stetson的优先级设置为大于默认值0。为了将Stetson的优先级设置为100，可以参照例6-42来配置Stetson。

例6-42：将Stetson的优先级配置为100，让其成为BSR。

例6-43显示了重新配置后的结果，Bowler的输出结果显示Stetson已成为BSR（优先级为100），当Stetson失效后Fedora将承担该角色。

例6-43：Stetson（10.224.1.1）的优先级为100，因而成为BSR。

与Auto-AP一样，也可以利用访问列表在多个RP之间分配RP职责。例如，假设希望Fedora成为地址位于228.13.0.0/16范围内的多播组的RP，而Stetson成为其他多播组的RP，可以参照例6-44来进行配置。

例6-44：在Fedora和Stetson之间分配RP职责。

例6-45显示了这些配置的输出结果，BSR在其Bootstrap消息中宣告了这些约束条件，Bowler根据这些约束条件将其多播组映射到RP。当然，并不建议在实际互联网络中进行如此配置，因为某个RP出现故障后，其他路由器将无法承担备用角色。更有效的实现方式是利用访问列表将多播组分配到多个C-RP，至少要通过访问列表为每个多播组创建两个C-RP。

例6-45通过访问列表对Stetson和Fedora的RP映射施加了约束条件之后，Bowler将多播组228.13.20.216映射到Fedora，而将其他多播组映射到Stetson。

使用PIMv2 Bootstrap协议时，一种更好的分配RP职责的方法是利用哈希掩码。哈希掩码是一个分配给BSR的32bit数值，其使用方式有点类似于标准的IP地址掩码。BSR在其 Bootstrap消息中宣告该哈希掩码，接收路由器运行哈希算法，将一定数量的连续多播组地址分配给某个C-RP，再将另一组连续的多播组地址分配给另一个C-RP。

举例来说，如果哈希掩码为30bit，那么将屏蔽所有IP多播地址的前30bit，最后2bit描述的是4个多播组地址区间。这4个地址将被分配给RP，因而多播组地址225.1.1.0、225.1.1.1、 225.1.1.2和225.1.1.3属于一个地址区间，将被分配给某个RP；而225.1.1.4、225.1.1.5、225.1.1.6、225.1.1.7则属于另一个地址区间，将被分配给另一个RP。如此反复，会将整个IP多播组地址区间进行”打包”并分配给所有可用C-RP，其结果就是将所有IP多播组地址都均匀分配给了所有C-RP。通过掩码可以灵活地决定将多少个连续的多播组地址打包成单个地址区间，以便让这些相关地址共享同一个RP。如果哈希掩码为26bit，那么每个地址区间将包括64个连续的多播组地址。

可以通过命令ip pim bsr-candidate来指定哈希掩码长度。本案例研究中前面的例子中，默认的掩码长度为0，意味着单个多播组地址区间涵盖了整个IP多播地址空间。例6-46显示了为图6-7中的Stetson和Fedora分配长度为30的哈希掩码的配置情况。

例6-46：为路由器Stetson和Fedora分配长度为30的哈希掩码。

例6-47使用了命令show ip pim rp-hash来验证上述结果。可以看到，从231.1.1.0开始，后面3个连续的多播组地址都被映射到了Fedora，接下来的4个多播组地址则被映射到了 Stetson，因而整个IP多播组地址区间都被平均分配给了两个RP。

例6-47：哈希算法可以将多播组地址平均分配给所有可用C-RP。

6.1.3　案例研究：多播负载均衡

有时可能希望通过多条并行的等价路径均衡多播流量，目的是希望更充分地利用可用带宽或防止单条路径因多播流量过大而出现拥塞。但是RPF检查却阻止直接在多条物理链路上实施多播负载均衡。

图6-8解释了该问题，除了删去了Bowler且Homburg同时是Auto-AP映射代理和RP之外，图6-8中的拓扑结构与前面案例研究中的完全相同。

图6-8　多播源和组成员之间存在两条等价路径

从连接到Homburg的多播源至连接到Porkpie的组成员存在两条等价路径：一条路径穿越Fedora，另一条路径则穿越Stetson。问题是RPF要求只能有一个入站接口进行工作，这就意味着如果Fedora被选为RPF邻居，那么如果多播流量来自Stetson，由于该流量没有到达 RPF接口，这些多播流量将会被丢弃。与此相似，如果Stetson被被选为RPF邻居，那么如果多播流量来自Fedora，那么RPF检查将失败，从而丢弃这些多播流量。RPF要求所有流量都要到达同一个上行接口。

解决该问题的方法是使用隧道机制（如图6-9所示）。也就是在Homburg的Porkpie的环回接口之间建立隧道，让所有自多播源到组成员的多播流量都通过该虚拟隧道接口进行传送（而不是任一条物理链路），之后被封装的多播组将以常规IP包的方式进行转发，此时，被封装的多播组就可以通过两条物理链路实现负载均衡了。如《TCP/IP路由技术（第一卷）》所述，此时既可以基于目的地（per-destination）进行负载均衡，也可以基于数据包（per-packet）进行负载均衡。

注意：　要想实现基于数据包的负载均衡，需要关闭快速交换功能，或者在需要进行负载均衡的接口上应用命令no ip route-cache。

图6-9　为了通过两条等价路径实施负载均衡，需要在Homburg和Porkpie之间创建一条隧道

当数据包到达Porkpie之后，由于其目的地都是隧道的出口，因而根本不关心来自Fedora还是来自Stetson，并在虚拟隧道接口上移除多播包的封装。从Porkpie上的PIM处理过程来看，所有多播包看起来都是通过同一个接口TU0接收到的，而且都接收自同一个上游邻居Homburg。

例6-48显示了Homburg和Porkpie的配置情况。

例6-48：在Homburg和Porkpie间配置一条隧道，以通过等价路径实现负载均衡。

对Homburg和Porkpie来说，隧道接口的源都被配置为该路由器本身的环回接口，而目的地则被配置为另一台路由器的环回接口。使用的隧道机制是GRE（Generic Route Encapsulation，通用路由封装），并被分配了一个IP地址，从而让路由进程将其视为一个物理IP接口，最后，需要在隧道接口上启用PIM协议。请注意，上述配置中并没有在连接Stetson和Fedora的任何子接口上启用PIM，而且这两台路由器也根本没有启用多播路由。例6-49显示了Porkpie已经通过该隧道与Homburg建立了PIM邻接关系。

例6-49：Porkpie与Homburg通过GRE隧道成为邻居。

但是，仍然存在其他RPF问题需要解决，即Porkpie接收到多播源10.1.1.88发出的多播包之后会检查其单播路由表以查看上游邻居。例6-50显示了检查结果。

例6-50：单播路由表仍然显示10.2.3.1或10.2.4.2为到达10.1.1.88的下一跳地址。

Porkpie的OSPF配置文件中将接口TU0设置为被动模式，虽然这可以确保单播流量不会经过该隧道（仅允许多播流量穿越该隧道），但不幸的是，这也意味着OSPF仍然将Stetson（10.2.3.1）或Fedora（10.2.4.2）视为去往10.1.1.88的下一跳，这样一来。来自10.1.1.88的数据包到达隧道接口后，RPF检查将失败，如例6-51所示。

例6-51：由于单播路由表没有将TU0视为去往10.1.1.88的上行接口，因而从10.1.1.88发出的数据包经隧道到达该接口后会出现RPF检查失败。

为了解决这个RPF问题，需要使用静态多播路由。静态多播路由与静态单播路由类似，都会覆盖/忽略任何动态路由表项，两者的区别在于静态多播路由从不被用于转发操作，而只是被用于静态配置某多播源的RPF接口，以覆盖单播路由表中的信息。命令ip mroute与IP地址和掩码一起使用，用以指定单个地址或一个地址区间。就像静态单播路由可以指定出站接口或下一跳邻居一样，静态多播路由也可以指定一个RPF接口或RPF邻居。例6-52给出了Porkpie的静态多播路由配置情况。

例6-52：为Porkpie配置静态多播路由。

例6-53再次利用debug命令来进行配置验证，可以看到多播包已经通过了Porkpie上的RPF检查，并被转发给了组成员。

例6-53：来自多播源10.1.1.88的多播组已通过了RPF检查并被正确转发。

例6-54显示了关于多播组228.13.20.216的多播路由表项，可以看到Homburg正在其接口E0/0上接收来自多播源10.1.1.88的多播流量，并将这些流量转发到隧道上。而Porkpie正在从隧道上接收这些多播流量，并通过其接口E0转发给组成员。

例6-54：（10.1.1.88,228.13.20.216）的多播路由表项显示该多播组的流量正通过GRE隧道进行转发。