5.7 PIM-DM 操作
到本书写作之时,仍然没有相应的RFC来描述PIM-DM,有关描述仅存在于Internet草案之中。除了通用的消息格式之外,读者可能会发现,PIM-DM与DVMRP之间的相似性甚至要多于PIM-DM与PIM-SM之间的相似性。
5.7.1 PIM-DM基础
PIM-DM使用以下5种PIMv2消息。
• Hello;
• Join/Prune(加入/剪除);
• Graft(嫁接);
• Grafl-ACK(嫁接确认);
• Assert(声明)。
PIMv2路由器使用Hello消息来发现邻居,当PIMv2路由器(PIM-SM或PIM-DM)被激活时,会在每个配置了PIM的接口上周期性地发送Hello消息;PIMv1路由器有类似的功能,只是使用的是Query(查询)消息。Hello(或Query)消息包含一个保持时间(holdtime),其指定邻居在宣称发信路由器无效之前需要等待收到下一条消息的最大时间。Cisco IOS Software中默认的PIMv2 Hello间隔和PIMv1 Query间隔均是30秒,可以利用命令ip pim query-interval来按照接口修改该默认间隔,保持时间被自动设置为Hello/Query间隔的3.5倍。
例5-3显示了命令debug捕获的PIM消息,请注意,该路由器同时拥有PIMv1邻居和 PIMv2邻居(如关键字Hello和Router-Query所示)。该路由器正在接口E0上发送Hello消息,但并没有从该接口上接收到任何Hello或Query消息,表明该子网上无PIM邻居。
例5-3:路由器Steel在接口E0、E1和S1.708上查询邻居,从接口E1和S1.708上侦听到邻居。
如例5-4所示,使用了命令debug ip packet detail(链接到访问列表来过滤无关数据包)来进一步查看PIM消息。可以看出,PIMv2消息被发送给224.0.0.13(使用的协议号是103),而PIMv1消息则被发送到224.0.0.2(使用的协议号是2)。
例5-4:命令debug的输出结果显示了PIMv1和PIMv2所使用的多播目的地址和协议号。
如例5-5所示,可以利用命令show ip pim neighbor来观察PIM邻居表的情况。
例5-5:PIM邻居表记录了例5-3中的侦听到邻居。
当多播源开始发送多播包时,PIM-DM利用泛洪/剪除协议来构建多播树。当每个PIM-DM路由器收到一个多播包时,都会在自己的转发表中增加一个表项,最终多播包被泛洪到所有叶子路由器——即没有下游PIM邻居的路由器。如果接收到多播包的叶子路由器未连接任何组成员,那么该路由器就必须将自己从多播树中剪除出去。为此,需要向沿着多播源方向的上游邻居发送Prune(剪除)消息,Prune消息的目的地址是224.0.0.13,上游邻居的地址也被编码在该消息之中。如果该上游邻居没有连接该多播包所属组的组成员,也没有其他下游邻居或从其所有下游邻居都接收到剪除消息,那么该路由器也会向沿着多播源方向的上游邻居发送Prune消息。
回顾本节前面列出的PIMv2消息类型可以看出,没有“Prune消息”,只有“Join/Prune消息”,该消息使用不同的字段分别列出所要加入的多播组和所要剪除的多播组。为了清楚起见,本节仍继续使用“Prune消息”和“Join消息”,但本节所说的Prune消息实际上就是将组地址列于剪除字段的Join/Prune消息。与此类似,Join消息实际上就是将组地址列于加入字段的Join/Prune消息。
例5-6显示了多播组239.70.49.238的转发表项,观察(S,G)表项,可以看出源地址为 172.16.1.1。路由器查询其单播路由表,以发现去往多播源的上行接口(即S1.708)以及去往多播源的上游邻居(即172.16.2.242),这些信息将进入多播转发表,并用于RPF检查。对 DVMRP来说,如果源地址为172.16.1.1、目的地址为239.70.49.238的数据包到达的接口不是S1.708,那么RPF检查将失败,该数据包也将被丢弃。
注意: 例5-6并没有显示转发表中与该多播组相关的全部信息。为了清楚起见,例5-6删除了部分信息,第6章将详细解释该转发表。
例5-6:命令show ip mroute显示的多播转发表。
(S,G)表项有两个定时器,第一个定时器指示该表项在转发表中存在的时间,第二个定时器指示该表项的到期时间。如果在2分59秒之内无任何多播包发送给该(S,G),那么该表项将被删除。
注意: Cisco IOS Software使用的超时定时器的定时时间为2.5分钟,而Internet草案建议的超时定时器的时间为3.5分钟。
例5-6中的(S,G)表项也有两个相关标记,第一个标记(C)表示该路由器的直连子网上有一个组成员,第二个标记(T)表示该路由器是SPT(Shortest Path Tree,最短路径树)(即CBT中的术语“on-tree”)中的一个有效成员。
注意: PIM将有源树最短路径树和共享树称为RPT(Rendezvous Point Tree,聚合点树)。SPT只是一个描述性名字,因为如本节后面内容所述,这些多播树有时会选择较短的路径(与RPT相比)去往多播源。
例5-6中的出站接口列表上出现了两个接口。第一个接口(E1)处于剪除状态和密集模式,因而可以知道该接口上的下游邻居发送了一条Prune消息,定时器显示该接口已启用了 1小时40分23秒,且剪除状态将在39秒后到期。接收到Prune消息之后,路由器会启动一个210秒的超时定时器,在该定时器到期之前,路由器会一直维持剪除状态。待定时器到期之后,该路由器的状态将被转换为“转发”状态,并重新将数据包转发给下游邻居,直至下游路由器向其上游邻居发送Prune消息,上述操作过程与DVMRP完全相似。
第二个接口(E0)处于转发状态,回顾例5-3可以知道,该路由器在接口E0上发送Hello消息,但没有在该接口上接收到任何来自邻居的Hello消息。基于上述信息以及例5-6可以知道,由于该子网上有一个组成员,因而该路由器在接口E0上转发多播包,例5-7证实了该结论。请注意,例5-6中有一个与接口E0相关联的正常运行时间(uptime),但是没有到期时间,这是因为没有邻居状态会到期。相反,当IGMP告诉该路由器子网中不再有组成员或例5-7中显示的超时定时器为0时,该路由器会从转发表中删除接口E0。
例5-7:命令show ip igmp group显示了记录在IGMP成员关系表中所连接的组成员。
例5-8显示了沿上游方向去往多播源的下一台路由器的转发表情况,在接口S1.803上对(172.16.1.1,239.70.49.238)和上游邻居172.16.2.254执行了RPF检查,并且只有一个下行接口。将该表项的标记与例5-6中的标记相比可以看出,该路由器位于最短路径树上,但没有直连的组成员。
例5-8:该表项的标记表明该路由器位于SPT上,但是没有直连的组成员。
注意: 虽然例5-8输出结果的格式与前一个转发表有少许不同(这是因为使用了不同的Cisco IOS软件版本),但可以看出两个转发表中的相关信息是相同的。
再次回到上游路由器,例5-9显示了该多播组的另一个转发表,其中的标记为“已连接”,但是该例中所连接的不是组成员。请注意,入站接口E0/0显示的RPF邻居地址为0.0.0.0,表明所连接的设备是多播组的源。
例5-9:从RPF邻居地址0.0.0.0可以看出,该路由器连接在多播源172.16.1.1上。
例5-9也显示了(172.16.1.1,239.70.49.238)表项的两个出站接口,其中一个处于转发状态,另一个处于剪除状态。与所有的泛洪/剪除协议一样,PIM-DM也必须为所有的接口维护剪除状态,原因是路由器将其从多播树剪除出去之后,还可以在需要的时候重新嫁接回该多播树。
举例来说,例5-10显示了某路由器的(172.16.1.1,239.70.49.238)表项情况,该路由器没有连接任何组成员,也没有下游邻居,因而出站接口列表为空,标记P表示该路由器向其上游邻居172.16.2.246发送了一条Prune消息。如果此时其所连接的某台主机发送了一条 IGMP消息,请求加入该多播组,那么该路由器会向其上游邻居(向着多播源的方向)发送一条PIM Graft(嫁接)消息,但是该路由器知道该多播源的地址的惟一方式就是通过最初的多播包泛洪,因而路由器必须维护例中所示的剪除状态。
例5-10:由于(S,G)表项(172.16.1.1,239.70.49.238)的出站接口列表为空,因而该路由器将自己从该多播树中剪除了出去。
Graft消息以单播方式被发送给多播树上的上游邻居。当上游路由器接收到该Graft消息后,会将接收到该消息的接口增加到其出站接口列表中,从而使该接口进入转发状态,并立即向其新下游邻居发送Graft-ACK(嫁接确认)消息。如果该路由器正在向其他下游邻居转发多播包,那么则无需做进一步操作;但是,如果该路由器也已经将自己从该多播树中剪除出去了,那么就必须也要向其上游邻居发送Graft消息。当路由器发送了Graft消息之后,会等待3秒钟,以等待Graft-ACK消息,但如果3秒内没有收到该确认消息,那么该路由器就需要重传Graft消息。
PIM-DM的这种泛洪/剪除机制与DVMRP非常相似,但两者之间的差别也很明显。在 5.3.2小节中曾经说过,DVMRP利用毒性反转机制向其上游邻居通告路由的相关性,该路由相关性的作用是告诉上游DVMRP路由器,某特定下游路由器需要依赖该路由来转发来自特定多播源的多播包。由于DVMRP有内嵌的路由协议,即便在多播源开始转发多播包之前,这一切也可以正常进行。因此,在某些拓扑结构中,DVMRP可以限制泛洪的范围,而PIM-DM则无此能力(因为PIM-DM无内嵌的路由协议),因而PIM-DM需要在整个PIM域中进行泛洪。该协议的设计者在规范中提出以下申明:
“不依靠特定的拓扑结构发现协议所带来的简单性和灵活性让我们能够接受本协议引入的额外开销。”
5.7.2 剪除覆盖
DVMRP下游相关性机制的另一个优点在剪除进程中是非常明显的。如图5-50所示,某路由器拥有多个下游邻居,上游路由器Mercury正将多播包泛洪到连接了这3台路由器的 LAN上;Copper的出站接口列表为空,因而向Mercury发送了一条剪除消息;但Silver连接了组成员,因而希望接收多播流量。
图5-50 由于Copper关于(172.16.1.1,238.70.49.238)的出站接口列表为空,因而发送了一条该(S,G)表项的Prune消息;Silver连接了一个组成员,因而希望接收多播流量
如果这3台路由器运行的是DVMRP,那么就没有问题。由于Mercury知道关于该多播组的源的下游相关性,也知道仅从Copper接收了Prune消息,因而继续向Silver转发流量。
但是,如果图5-50中的路由器运行的是PIM-DM,那么Mercury可以根据Hello消息知道其有两个邻居,但Hello消息中并没有描述任何路由相关性信息,因而当Copper发送Prune消息时,Mercury不知道是否要剪除该LAN接口。
PIM-DM利用剪除覆盖(prune override)进程解决了该问题。Copper向Mercury发送了 Prune消息,但Mercury的地址也被编码在该消息之中,携带该消息的IP包被寻址到ALL PIM Routers(所有PIM路由器)地址224.0.0.13。当Mercury接收到该Prune消息后,并不立即剪除该接口,而是设置一个3秒定时器。与此同时,Silver也接收到了该Prune消息(因为该消息使用的是多播目的地址),看到消息中所要剪除的多播组是其希望继续接收多播流量的多播组,而且该消息已经被发送给正在转发多播流量的其上游邻居,因而Silver向Mercury发送了一条Join消息(如图5-51所示)。这样一来,Silver就覆盖了由Copper发送的Prune消息,只要Mercury在3秒定时器到期前接收到一条Join消息,就不会中断多播流量。
图5-51 Silver利用Join消息来覆盖Copper发送的Prune消息
例5-11显示了剪除覆盖进程的运行情况。利用调试命令来捕捉图5-50和图5-51中 Mercury的PIM活动情况,第一条消息显示在接口E0上接收到了一条来自Copper(172.16.3.2)针对(S,G)(172.16.1.1,239.70.49.238)的Prune消息(实际上是在剪除字段中列出239.70.49.238的Join/Prune消息)。请注意,第一行显示该消息为“to us”,表明Mercury已经识别出被编码在该消息中的自己的地址。
第2行和第3行显示路由器Mercury已经计划将(S,G)表项从接口E0上剪除出去,也就是说,已启动了3秒定时器。在第4行,Mercury从Silver(172.16.3.3)接收到一条Join消息。在第5、6行,接口E0处于(S,G)表项的转发状态,Copper的Prune消息已被覆盖。
例5-11:图5-51中的路由器Mercury接收到来自Copper(172.16.3.2)的Prune消息,之后,Silver(172.16.3.3)发送的Join消息覆盖了Copper的Prune消息。
5.7.3 单播路由变化
当拓扑结构发生变化时,单播路由表也要随之发生变化;如果单播路由的变化会影响去往多播源的路由,那么PIM-DM路由表也会发生变化。一个明显的例子就是拓扑结构的变化导致去往某多播源的路径上出现不同的前一跳(previous-hop)路由器。
当多播源的RPF路由器发生变化后,PIM-DM会首先向旧RPF路由器发送一条Prune消息,之后再向新RPF路由器发送一条Graft消息,以构建新的多播树。
5.7.4 PIM-DM 指派路由器
PIM-DM会在多路接入网络中选举一台指派路由器。需要注意的是,PIM-DM协议本身并不需要DR,只是由于IGMPv1没有查询进程,为了管理IGMP查询,IGMP需要依赖该路由协议来选举DR,这也就是PIM-DM(及PIM-SM)指派路由器的作用。
DR选举进程非常简单,每台PIM-DM路由器每隔30秒就发送一条PIMv2 Hello消息或一条PIMv1 Query(查询)消息,以进行邻居发现。在多路接入网络上,IP地址最大的PIM-DM路由器将成为DR(如例5-12所示输出结果),其他的路由器则监控DR发出的Hello包。如果在105秒内都没有接收到该Hello包,则认为DR已失效,从而选举一个新的DR。
例5-12:例5-11中的PIMv邻居表显示Silver(其IP地址172.16.3.3最大)是指派路由器。
5.7.5 PIM 转发路由器选举
如图5-52所示,Mercury和Copper都有一条去往多播源172.16.1.1的路由,且都有一个下行接口去往多播组239.70.49.238(该多播组连接在一个公共多路接入网络中)的成员。由于Mercury和Copper都从该多播组接收到相同的多播包拷贝,因而很明显,如果这两台路由器都将该多播包转发到相同的网络上,那么效率将非常低下。
为了防止上述情况的发生,PIM路由器将在共享网络上选择一台转发路由器(forwarder)。前面说过,DVMRP也有类似的功能,DVMRP选举的是指派转发路由器(designated forwarder),DVMRP的指派转发路由器的选举进程是多路接入网络中路由交换的一部分。但是,由于PIM没有自己的路由协议,因而需要利用Assert(声明)消息来选择转发路由器。
图5-52 Copper和Mercury都从多播源172.16.1.1接收到相同的多播包拷贝,但只有一台路由器将该多播包转发到子网172.16.3.0/24上
当路由器在出站多路接入接口上接收到一个多播包时,会向网络发送一条Assert消息,该消息中包含了多播源的地址和多播组的地址、去往多播源的单播路由的度量值以及单播路由协议用来发现该路由的度量优先值(metric preference,即Cisco术语中的“管理性距离”)。制造数据包拷贝的这些路由器会比较这些消息,并根据以下规则来确定转发路由器。
• 所宣告的度量优先值(管理性距离)最低的路由器为转发路由器。如果这些路由器是通过不同的单播路由协议来发现这些去往多播源的路由,那么这些路由器仅宣告不同的度量优先值。
• 如果度量优先值均相等,那么所宣告的度量值最低的路由器为转发路由器。换句话说,如果这些路由器运行了相同的单播路由协议,那么在度量值上最靠近多播源的路由器就成为转发路由器。
• 如果度量优先值和度量值都相等,那么网络中IP地址最大的路由器就是转发路由器。
由转发路由器负责继续将多播流量转发到多路接入网络中,其他的路由器则停止转发该多播组的流量,并从各自的出站接口列表中删除该多路接入接口。
举例来说,当图5-22中的多播源开始向多播组239.70.49.238发送数据包时,Copper和 Mercury都将收到该数据包拷贝,并且都将该数据包转发到子网172.16.3.0/24上(如图5-53(a)所示)。当Copper在其以太网接口上从Mercury接收到(172.16.1.1,239.70.49.238)的多播包时,将看见该以太网接口位于该(S,G)的出站接口列表中,因而会向该子网发送一条 Assert消息。当Mercury在同一个接口上接收到来自Copper的多播包时,会执行相同的操作,如图5-53(b)所示。
图5-53 当Copper和Mercury在其下游多路接入接口上检测到(172.16.1.1,239.70.49.238)的多播包时,会发起Assert消息以确定该多播组的转发路由器
例5-13显示了 Silver的单播路由表和多播转发表。单播路由表显示了去往多播源 172.16.1.1的等价OSPF路径是经Copper(172.16.3.2)或经Mercury(172.16.3.1),由于这两条路由都是OSPF路由,因而管理性距离都是110;而且由于这两条路由的OSPF代价都是 74,因而IP地址最大的路由器将成为转发路由器。
例5-13:Silver的单播路由表显示了两个去往多播源172.16.1.1的下一跳路由器,多播路由表显示IP地址最大的路由器被选举为转发路由器。