搞PIM-DM排障最头疼的往往不是协议本身而是共享网段上那台以太网交换机后面藏着的多个路由器同时转发同一路组播一会儿重复包刷屏一会儿某个接收者莫名断流。这两个故障背后正是PIM-DM的断言机制和剪枝否决机制在起作用也经常是大家学的时候一脸懵、排障时反复踩坑的地方。这篇文章不写泛泛的概念直接从触发条件、选举规则、报文时序和排障命令讲起把PIM-DM在共享链路上的这两套冲突解决机制彻底说透。适合正在备考数通认证的兄弟也适合运维现场处理组播故障的老兵。1. 为什么PIM-DM在共享网段上总是“打起来”1.1 多路访问链路给组播协议出的难题以太网本质是共享/多路访问链路。只要在同一个二层域一个PIM路由器往网段上发出的组播报文物理上会被所有连在这个网段的PIM路由器收到。PIM-DM又是数据驱动协议源S发第一组包时路由器先把(S,G)流泛洪到所有下游PIM接口让数据“冲”到每个角落再由没有接收者的分支逐跳剪枝。这个设计在点对点链路上很干净一个上游、一个下游消息不会产生歧义。但一上以太网问题就来了。举个常见的例子。R1和R2都通过不同上游路径学到了通往源S的路由又都连接着同一个接入网段。R1收到源数据后会把这个网段作为出接口转发R2同样会转发。结果在接入网段上同一份组播流从两个方向同时抵达造成接收端重复报文。这就是断言机制要解决的问题在多个转发者之间敲定唯一的“话事人”其他人闭嘴。再看剪枝方向。接入网段上挂着R3和R4两个下游PIM路由器R3没有接收者向R1发了PruneR4下面还有一个正在收组播的终端。如果R1一收到Prune就把这个网段从出接口列表里摘掉R4的接收者当场断流。这时候就需要剪枝否决机制R4听到R3的Prune之后立即发一个Override来否决这次剪枝。1.2 两个机制的互补关系学PIM-DM时很多人把断言和剪枝否决当两个独立知识点背考完就忘。我建议反过来记它们其实是一对“入向”和“出向”的钳制机制。断言管的是数据进入共享网段之前谁有资格往这个网段转发剪枝否决管的是这个网段上的下游需求被汇总之后上游能不能真的剪枝。两个机制都只在多路访问链路上才完整生效都通过224.0.0.13这个所有PIM路由器组播地址通信都涉及组播路由状态机迁移。理解了这个大前提后续的报文格式和定时器细节就顺理成章了。2. 断言机制把重复转发者“打”到只剩一个2.1 触发条件逐条拆解断言不是随时触发的。按PIM协议定义路由器在接口I上收到一个(S,G)组的组播数据包同时满足下面几个条件时才进入Assert流程接口I在(S,G)表的出接口列表中接口I不是当前(S,G)的RPF上游接口换言之这个接口按正常逻辑只该出不该进路由器已经通过RPF接口收到了同一份(S,G)数据。换句话说路由器在自己的下游接口上收到了本该只由自己发出去的数据说明这份数据同时也从另外一条路径被送到了这个共享网段网段上出现了两个有转发权的路由器。实际排障里最常见的触发场景有两种。第一种是源所在网络存在等价多路径上游路由器分别接入同一台二层交换机数据被伪广播到所有端口第二种是运维把两个接入交换机起了一个互联路由导致R1/R2都有去源的路径。无论哪种表现都一样共享网段上的接收者收到两份一模一样的数据包。这里有个细节值得注意PIM-DM中的Assert并不要求预先了解网段里还有谁在竞争。任何一台进入该状态的PIM路由器都会直接往224.0.0.13发Assert报文报文会被所有PIM路由器收到竞争是即时自动完成的。2.2 选举规则三个判据一次敲定Assert报文PIM Type 5里最关键的两个字段是到源的metric preference和metric。前者表示路由协议的管理距离/优先级后者是该协议的度量。选举顺序很简单metric preference越小越优先相同时metric越小越优先再相同物理接口IPv4地址越大越优先。举例说明。源S挂在OSPF区域R1去S的路由是OSPFmetric preference110cost40R2去S的是静态路由metric preference1metric0。那么R2无论后面的判据如何直接当选。反过来如果R2走的是RIPmetric preference120metric2跳虽然OSPF cost是40这种数值表面上比2大但先比较的是preference110小于120R1胜出。第二轮比较metric的场景也很好理解。两台路由器都用OSPF学到去源的路由管理距离都是110其中一个是cost 30另一个是cost 50则cost小的那个成为Assert Winner。如果两边连cost都一样就比接口IP大的胜出。设计这么一套规则的目的是让所有路由器拿同一套客观标准做本地判决不需要来回协商。2.3 Winner和Loser各自的状态行为断言结束后Winner继续在共享网段上转发(S,G)流量并且会周期性重发Assert报文——在很多厂商实现里大约每1秒一次连续几秒之后进入稳态后续只在状态变化时再发。这其实是一个“占位信标”让Loser知道Winner还活着。Loser收到Assert且发现自己输掉之后会立刻把该接口从(S,G)出接口列表里删掉放弃转发权。但它在状态机上记了一笔自己是Loser同时准备一个较短的Assert计时器。这个计时器很关键。假如Winner掉电、接口down或者它到源的路由被撤销Winner就不会再周期重发AssertLoser的Assert计时器超时后如果仍满足转发条件就会重新开始转发并再次发起Assert竞选。所以断言机制自带了故障收敛能力不需要人工干预。2.4 一个最小拓扑看完整过程为了直观我用文字描述拓扑R1和R2通过不同上游路径都能到达组播源10.10.10.1同时连接一个多路访问网段网段下挂着接收者。时间线如下T0源发出首包R1、R2各自从RPF接口收到数据并都从共享网段接口往外转发。T1R1在其共享网段接口上收到了R2转过来的(S,G)包发现该接口在出接口列表于是触发AssertR2也做相同判断。T2R1、R2各自发出Assert报文到224.0.0.13。报文里的选举参数来自各自单播路由表。T3假设R1的metric preference更小R1收到R2的Assert后发现对方判据不如自己R1胜出继续转发R2收到R1的Assert后转入Loser状态删除出接口停止转发。T3之后接收者侧只会再从R1收到流量重复包消失。如果T2时R1先发、R2后发R2同样会用收到的R1报文完成判决过程依然收敛。2.5 别把断言和DR选举混为一谈这是面试高频坑也是排障时常见的概念混淆。PIM-DM中某些共享网段确实会选DR但那主要是为了和IGMP v1等场景配合解决谁是查询器之类的问题断言机制解决的是(S,G)数据通道上重复转发的问题。两者的报文类型、触发条件、作用对象完全不同。我在现场见过有人因为在共享网段看不到DR而怀疑断言没生效纠了半天才发现是概念错了PIM-DM没有RP和注册流程它的DR跟组播数据转发基本不沾边。3. 剪枝否决机制一个Prune不能代表所有接收者3.1 剪枝的标准流程回顾PIM-DM的正常剪枝流程很简单下游路由器发现自己既没有直连组成员也没有下游路由器还需要(S,G)就沿着RPF方向向上游发送Prune报文。上游收到后把对应接口从(S,G)出接口列表中剪掉不再往这个方向转数据。点对点链路上这么干没有任何问题因为上游只服务一个下游收到Prune就说明“这个方向没人要了”。剪枝干净利落。3.2 共享网段上的误伤是怎么发生的剪枝一旦发生在共享网段事情就变了。还是用那个例子R3和R4都通过同一个多路访问网段作为下游接口R3没有接收者R4下面有接收者。R3判断自己“没有下游需求”向R1发Prune。这条Prune不是私聊是以组播方式发出R4也会收到。如果R1那边收到Prune就立刻剪掉出接口R4就再也收不到(S,G)的包——因为R4在同一个网段上没有所谓的“上游其他路径”它的数据本来就要靠R1往这个网段转发。这就是典型的剪枝误伤一个下游没需求不代表所有下游都没需求。3.3 Override的完整工作过程为了解决误伤协议设计了Prune Override机制很多人叫它剪枝否决也有人叫剪枝覆盖。工作过程是这样的R3发出Prune后R4在共享网段上也收到了这条Prune。R4检查自己的(S,G)状态接口还需要这路流于是立即构造一条Join消息实际上是Join/Prune报文里携带Join动作同样发往224.0.0.13这条Join就是Override——它对R3的Prune做了否决。R1收到R3的Prune时不会立刻执行剪枝而是先把该接口置为“剪枝待定Prune Pending”状态并启动一个计时器这个计时器多数厂商默认3秒。R1会在这段时间内监听共享网段是否出现针对同一(S,G)的Override/Join。如果R4的Override在计时器到期前到达R1取消剪枝接口继续留在出接口列表数据照常转发。如果3秒内没有任何Override说明整个共享网段确实没有接收者了R1执行剪枝。这里有个步骤容易让新手迷糊R4发送Override之前它自己可能也已经发过Prune。如果R4先前也没接收者、已经发过Prune后来下面新增了接收者它要发的是Graft去恢复被剪枝状态而不是Override。Override场景针对的是“听到别人剪枝但自己还想要”的局面和Graft是完全不同的两条路径。3.4 Override报文不是独立类型排障抓包时很多兄弟习惯在Wireshark的PIM类型列表里找一个叫“Override”的类型找半天找不到。这很正常。Prune Override不是一个独立的PIM报文类型它承载在Type 3的Join/Prune报文中具体表现就是收到Prune的一方回发一个包含相同(S,G)组播组信息但语义为Join的报文。之所以不发明新报文是因为协议希望复用完整的Join/Prune语义也让所有PIM实现天然理解这个动作对上游来说收到Join就是对Pending剪枝的撤销对目击者来说二者状态切换也很自然。我建议排障时不要按“Override”报文来过滤直接过滤PIM Type 3然后看Join/Prune报文的组条目有没有对应的Join动作。3.5 什么情况下不会出现Override关键点在于只有当其他下游PIM路由器还需要这路组播流时Override才会出现。如果共享网段上所有下游都一致认为“不需要了”那它们都会发Prune没有人发Override上游的Prune Pending超时后自然完成剪枝。另外点对点链路上永远不会有Override。道理前面说过上游只有一个下游下游发Prune就是唯一结论不需要再等3秒评估。所以如果你在点对点链路配置里调Prune Override计时器其实没有实际意义。4. 两个机制合流共享网段上从泛洪到稳态的完整时间线4.1 一个包含双重冲突的复杂场景真实生产网络里一个共享网段往往同时出现“多个上游竞争转发”和“多个下游剪枝需求不一致”的情况。这里我把两种冲突放到同一个拓扑里完整推演一遍。拓扑描述源S的流量可以通过两条路径到达R1和R2R1和R2同时连接共享网段NN下挂着三个下游PIM路由器R3、R4、R5。R5连接一个真实接收者R3没有接收者R4暂时不需要当前组(S,G)。完整时间线如下表阶段时间事件涉及机制泛洪T0源S发出首个组播包R1、R2从各自RPF接口收到并开始向N网段转发泛洪重复T1R1从N网段收到R2转发的同源同组数据R2也收到R1的数据触发AssertAssert触发竞选T2R1和R2向N网段的224.0.0.13发送Assert报文比较metric preference后R1胜出Assert竞选收敛T3R2删除N网段出接口停止转发R1继续向N网段转发(S,G)流量Assert收敛剪枝T4R3因为没有接收者向R1发送Prune剪枝发起否决T5R5因为下面还有接收者在共享网段上听到R3的Prune立即发送JoinOverride剪枝否决确认T6R1在Prune Pending计时器超时前收到R5的Override取消对该接口的剪枝继续往N网段转发剪枝否决收敛稳定T7R3确认自己没有需求完成本地剪枝状态R5继续保持接收R1/R2维持Assert状态稳定运行T1到T3解决的是数据重复问题T4到T6解决的是误剪枝问题。两条线彼此独立又都在同一个网段上工作。4.2 两个机制并行时谁先谁后很多人问如果Assert还没结束下游就发Prune上游该听谁的我的思路是协议把两个机制做成独立状态机分别跑不必严格串行。对于上游收到Prune的接口Prune Pending计时器只关心“这个方向上还有没有其他需要者”不关心当前谁是Assert Winner。断言改变的是谁往网段转发数据不改的是“网段上是否有接收者”这一需求总和。但如果那一路数据其实应该由另一个竞争者转发而某个下游路由器恰好又在剪枝请求上选择了错误的上游在实际网络中现象可能表现为请求发给了LoserLoser不转发数据从Winner继续过来下游也收得到只是路径选择错位。所以排障时如果发现剪枝反复失败先确认当前谁是Assert Winner再谈Override有没有发对方向。4.3 结合State Refresh理解剪枝的长期性还有个容易忽略的点PIM-DM会通过State Refresh消息周期性地刷新剪枝状态防止被剪枝的接口因为定时器超时又被泛洪。在共享网段上State Refresh同样会携带剪枝信息。这里不展开State Refresh的细节但排障时记住一条共享网段上即使看到剪枝被Override了也不要以为永远不会再剪枝。如果后续接收者消失下游还会再发Prune机制再走一遍这是PIM-DM数据驱动设计的正常表现。5. 排障实战如何确认断言和剪枝否决在正常工作5.1 用show命令定位断言状态以Cisco IOS为例配置PIM-DM后查看组播路由表show ip mroute 239.1.1.1 10.10.10.1输出里重点关注接口状态标志。如果断言发生过并产生了Winner表项里会额外显示类似“Assert Winner: 10.0.0.2”的信息或者接口状态变为“Assert”。不同版本输出有差异但核心是看出接口列表里是否存在“Assert”状态以及哪台邻居被标记为Assert Winner。如果接口被标记为Assert说明该网段曾经或正在发生多路转发冲突并且协议已经收敛。如果你在接口上看到持续反复的Assert状态抖动那多半是两条上游路径的metric比较非常接近比如等价ECMP或者单播路由在两条路径间频繁切换。5.2 debug ip pim输出解读调试命令一般用debug ip pim group 239.1.1.1在共享网段上触发一次剪枝时输出大约长这样厂商实现细节略有差异看类型即可PIM: Received v2 Prune on GigabitEthernet0/1 from 10.0.0.2 for (10.10.10.1, 239.1.1.1) PIM: Prune pending timer set for (10.10.10.1, 239.1.1.1), delay 3s PIM: Received v2 Join on GigabitEthernet0/1 from 10.0.0.3 for (10.10.10.1, 239.1.1.1) PIM: Prune overridden on GigabitEthernet0/1 for (10.10.10.1, 239.1.1.1)“Prune pending timer set”上游收到了Prune计3秒等待Override。“Received v2 Join ... for (S,G)”收到了Override。“Prune overridden”Prune被否决接口不剪枝。如果没有收到Override则输出应该看到定时器超时后Prune生效类似PIM: Prune pending timer expired for (10.10.10.1, 239.1.1.1)Assert的debug输出则会出现“Send Assert”字样以及选举结果相关的提示。看到“loser”或“winner”等关键词时配合show ip mroute确认最终状态。5.3 抓包时怎么识别关键报文Wireshark过滤PIM协议的包后Type 5Assert报文。展开后能看到Multicast Group、Source Address、Metric Preference、Metric等字段。这些字段直接决定竞选结果。Type 3Join/Prune报文。展开后看“Join”列表里有没有对应(S,G)组。共享网段上如果它是对Prune的响应就是Override。抓包时注意目的地址所有PIM控制报文目的地址都是224.0.0.13。如果你的交换机配置了组播流量过滤策略别忘了放行这个组否则PIM邻居和Assert/Override报文都会被丢掉这也是一个常见故障点。5.4 常见现象的快速判断表现象可能原因排查方向接收端不断收到重复组播包共享网段断言未收敛或Assert周期复现检查两条上游路径的单播路由比较show ip mroute看Assert Winner组播流量从某台路由器闪断后恢复Prune误伤下游Override没生效抓包看Prune后是否有JoinOverride检查Prune Pending定时器组播流量完全不经过某台正常路由器该路由器在Assert中为Loser已删除出接口show ip mroute确认Loser状态调整上游单播路由让需要的路径胜出剪枝立时生效无视OverridePrune Override计时器被置0或接口被配置为强制剪枝检查接口PIM配置恢复默认计时器PIM邻居一直在抖动又伴随重复包224.0.0.13控制报文被交换机过滤检查二层ACL、组播过滤策略6. 六个容易被忽略的细节附我的经验笔记6.1 Override不是报文类型别被概念带偏这一点我在现场帮人排障时至少纠正过三次。很多教材把Prune Override写得像是一个独立报文导致大家在Wireshark里找“Override”找不到。实际上它是Join/Prune报文里的一种动作本质是一条Join。理解这个比背名词重要你去抓包时看到共享网段上出现携带(S,G) Join的报文就要考虑它是不是Override。6.2 点对点链路上没有Override如果两台路由器之间是串行链路或隧道不存在第三个PIM路由器监听Prune上游收到Prune后立刻剪枝没有任何等待。所以Prune Override计时器只在多路访问接口上有意义。有朋友曾把接入环网口全改成点对点后再调override timer完全是在浪费精力。6.3 Assert结果最终由单播路由决定Assert报文里的metric preference和metric直接由路由器到源的单播最优路由决定。这意味着单播路由一有风吹草动断言选举结果就可能改变。实战里如果你希望某台路由器成为组播业务的固定转发者与其去PIM层面折腾不如先看看单播路径调整OSPF cost、接口metric或者策略路由往往比硬调PIM参数更干净。6.4 RPF检查是断言和剪枝的共同前提PIM-DM里所有(S,G)表项都围绕RPF接口工作。断言判断的是“有没有非RPF接口也收到了数据”剪枝判断的是“出接口方向的需求”。排障时如果RPF接口因为路由切换不对后面的断言、剪枝全都会乱。建议先确认show ip mroute里的Incoming interface和RPF nbr正确再去看Assert和Override否则就是定位错方向。6.5 PIM-SM同样有这两个机制别把知识割裂很多教材把PIM-DM的Assert和Prune Override放在密集模式章节学完就忘。实际上PIM-SM在共享网段上也有一套几乎相同的Assert机制Prune Override在PIM-SM的剪枝过程中同样存在。区别主要在于切入场景PIM-DM因为数据泛洪Assert触发更频繁PIM-SM因为建立的是显式Join树在共享边界的Assert也会发生但触发更受控。理解这一点以后学PIM-SM时能省一半力气。6.6 默认等待时间别乱改Prune Pending计时器默认3秒左右这是为共享网段上其他下游路由器发出Override留出的必要时间。有些老哥为了加快组播收敛把Override计时器调得很小甚至直接关掉结果共享网段上经常出现“本来还有接收者却被剪枝”的隐蔽故障。除非你能100%确认链路上所有PIM路由器都不需要Override否则不要动这个参数。真要优化收敛速度优先考虑限制泛洪范围、调整Assert周期。写到这我自己在维护组播网络时最大的体会是断言和剪枝否决这种机制光靠文档看永远隔着一层。真正上手抓一次包、看一次debug输出、亲眼看到重复包消失或者Prune被Override拦下来才算真正理解PIM-DM在共享网段上到底在做什么。后面如果再遇到组播故障记得先把224.0.0.13放行、把RPF接口确认对再看这两个机制的状态问题基本就跑不出这个圈了。