简介：这份名为“计算机网络多播路由技术”的PPT资源，系统梳理了多播路由的核心知识体系，面向计算机网络专业学生、考研人群以及需要快速理解组播原理的网络技术人员。内容覆盖局域网上的多播实现与IGMP、交换式LAN中的多播转发方案、多播转发树、多播路由算法，以及DVMRP、MOSPF、PIM-DM、PIM-SM等主要协议，并延伸到MBone和IPv6多播技术，章节结构完整，便于按需查阅。压缩包内为1个PPT文件，大小2.4MB，适合直接用于课堂演示或自学浏览。目前已有183人学习该资源。对于正在复习计算机网络课程或准备相关认证的读者，这份PPT能够帮助理清多播地址映射、逆向路由选择、基于源的树与共享树的区别等难点，并通过典型协议对比提升对多播路由整体框架的把握，具有较高的参考价值。
1. 多播路由技术：先搞懂它在计算机网络里为什么不“简单”
第一次在公司园区网里开通多播视频会议，我以为和单播差不多：配个IGMP、加条静态路由就完事。结果视频一开，核心交换机CPU直接飙到80%，画面卡成幻灯片。后来才明白，多播路由技术最反直觉的地方在于：路由器不仅要查目的地址，还要查源地址；交换机看到多播MAC地址默认不是丢弃而是洪泛；而组播树的建立方式，直接决定了DVMRP、MOSPF、PIM-DM、PIM-SM这些协议为什么会被设计出来。这篇笔记把多播路由从局域网到域间、从IPv4到IPv6的路径完整拆开，适合做网络运维、搞视频监控大屏接入，或者正在复习计算机网络考试的人照着落地一遍。
2. 局域网内多播落地：IGMP 侦听、GMRP 与交换机三层协作
2.1 先分清LAN内的两种多播形态
多播在局域网里能不能“直接跑起来”，取决于多播源和组成员是不是在同一个以太网段。如果多播源和所有成员都在同一个二层网络里，理论上不需要任何多播路由协议。多播源把IP多播分组封装成以太网帧，目的MAC地址用IANA预留的组播MAC段：01:00:5E:00:00:00到01:00:5E:7F:FF:FF。组里的主机网卡在驱动层就订阅了这个物理地址，帧到了直接上传给IP层；非组成员的主机网卡没订阅，帧在网卡就被丢弃了，CPU根本不感知。
这里有个容易忽略的映射细节：IPv4组播地址的低23位映射到MAC地址的低23位，所以像239.0.0.1和239.128.0.1这两个组竟然会映射到同一个MAC地址。这就要求在规划组播地址时，不能只盯着IP不重，还要对照低23位算一遍。否则后面做IGMP Snooping过滤时，很容易出现“组成员收得到但别的组也能收到”的串扰现象。
另一种情况是多播源不在本地LAN。这时候路由器要先通过IGMP报文探明：这个网段里有没有组成员？有，就向LAN转发多播分组；没有，这跳直接掐掉。IGMP的工作过程是：路由器周期性地发通用查询报文到224.0.0.1，组成员收到后延迟一段随机时间回Report报文；如果组里已有成员，其他成员看到Report会被抑制，不再重复上报，这就是IGMP的“报告抑制”机制，专门用来减少局域网内的组播报文数量。
回到交换式LAN，问题就来了。IGMP是第三层协议，而交换机是二层的，MAC地址转发表里根本没有“多播地址 → 输出接口”这种表项。交换机的默认行为是把未知目的MAC的帧从所有端口洪泛出去，多播帧自然也被当成未知单播处理。一个小型VLAN里有几十台主机可能无感，但一个承载监控视频的千人大VLAN，洪泛的多播流量会让所有接入交换机CPU集体升高，这才是视频卡顿背后真正要解决的问题。
2.2 交换式LAN处理多播的四种方案
解决交换机洪泛多播的问题，经典做法有四条路线，各有适用场景。
| 方案 | 原理 | 适用场景 | 局限 |
|---|---|---|---|
| 手工配置交换机转发表 | 静态把组播MAC绑定到指定端口 | 组和成员都固定的哑终端（摄像头、机顶盒） | 纯人工维护，组一多就崩溃 |
| GMRP | 基于GARP协议，设备之间通过注册帧传播组播地址 | 不支持IGMP Snooping的老交换机 | 需要全链路交换机都支持GMRP，实际部署很少 |
| IGMP Snooping | 交换机监听IGMP报文，动态学习组成员端口并建立二层转发表 | 几乎所有的现网场景，性价比最高 | 依赖组成员主动发Report，对静默设备无效 |
| CGMP | Cisco专有，路由器把IGMP信息通过CDP同步给交换机 | 老Cisco园区网 | 厂商锁定，新环境很少见 |
实际工程里，IGMP Snooping是绝对主流。它的工作过程很直白：主机B想加入239.0.0.11，发一个IGMP Report；交换机在收到这个报文的瞬间，记下“VLAN 10、组239.0.0.11、端口Gi1/0/3”，后续多播数据帧到达时，交换机只往Gi1/0/3发一份，不再洪泛。如果成员下线或超时没有续报，交换机就把对应表项老化掉。
给一套思科风格的最小配置，照着敲就能在一台接入交换机上开启IGMP Snooping：
! 在VLAN 10上开启IGMP Snooping ip igmp snooping vlan 10 ip igmp snooping vlan 10 querier ip igmp snooping vlan 10 mrouter learn-pim ! ! 把Gi1/0/3静态加入组239.0.0.11 interface GigabitEthernet1/0/3 ip igmp snooping static-group 239.0.0.11 vlan 10配置说明：ip igmp snooping vlan 10是总开关，不开这个，后面全是白搭。querier参数是指定这台交换机在VLAN里充当IGMP查询器，适用于网络里没有路由器的纯二层环境；如果上层有路由器在跑PIM并充当查询器，querier可以不开，避免双查询器冲突。mrouter learn-pim让交换机从PIM hello报文中动态识别路由器端口，组播数据只从路由器端口上联，不会从接入侧口子回到路由器造成环路。static-group适合接入的是不会主动发IGMP报文的哑设备，比如老款视频编码器，静态绑定是最稳的后悔药。
有个值得记住的排查习惯：只要VLAN里开了Snooping但视频依然卡，先看交换机的IGMP Snooping组表，别急着怀疑多播协议。很多项目翻车都翻在“以为Snooping开了，实际全局没开”这一层。
2.3 抓包验证IGMP的加入过程
配置完Snooping，最好在接入侧实际抓一次IGMP报文，确认加入过程真的发生了。用Linux主机接到接入交换机上，开tcpdump抓IGMP：
# 抓取eth0上的IGMP报文，-nn关闭端口名解析，看得更清楚 tcpdump -i eth0 -nn igmp # 另一个终端里执行加入操作，让网卡订阅组239.0.0.11 ip maddr add 239.0.0.11 dev eth0抓包输出里能看到两类报文：路由器发来的IGMP QueryIGMPv2 10.0.1.1 -> 224.0.0.1，以及主机回应的IGMPv2 Report 10.0.1.10 -> 239.0.0.11。要是只看到查询看不到报告，说明主机没发出加入请求，问题在主机侧；要是报告发了、数据流到了交换机却不往下走，问题就在交换机的Snooping表项上。这个边界切分，能把故障定位时间至少砍掉一半。
提示：监控摄像头这类设备经常不上报组成员关系，抓包时用
tcpdump -i eth0 -nn host 239.0.0.11直接过滤组地址，能看到数据帧却看不到报告帧，就得去查交换机的静态组播配置，或者考虑用静态组播MAC绑定兜底。
3. 多播转发树与逆向路径：SPT、RPT 和 RPF 校验的差别
3.1 多播路由比单播复杂的本质
单播路由协议表项的核心是“目的网络地址、下一跳、出接口”，路由器收到分组后拿目的IP查表，匹配就按表转发。多播完全不同。多播分组的目的地址是一个组地址，组里的成员分散在不同的网络里，路由器没法只根据目的地址决定把分组送到哪个方向。它必须问自己两个问题：这个分组的源是谁？这个源离我哪个接口最近？
考察一个具体场景：主机E给Group2发分组，路由器R把它送进Net2；主机F也给Group2发分组，R却把这份副本送进Net1。同样是去往Group2，源不同，转发方向完全不同。更麻烦的是，多播允许任意主机向任意组发分组，发信者本身甚至完全不是组成员。这就导致路由器不能按“目的网络建表”，必须按“源+组”的组合建表，也就是二元组(S, G)来维护一棵棵转发树。
动态性也是个大坑。单播路由只有在拓扑变化时才会重算，多播路由不一样：一个成员加入或离开某个组，即使物理拓扑完好无损，转发树也要跟着改。这也是为什么多播路由协议里到处是“加入报文、剪枝报文、嫁接报文”，而单播协议里压根没这些东西。
3.2 RPF逆向路径转发：多播无环的根基
多播协议普遍依赖一个叫逆向路径转发（RPF）的校验机制。概念上很好理解：路由器收到一个(S, G)多播分组，先查自己到源S的单播路由表，找出回程最优路径对应的入接口；如果分组实际到达的接口等于这个回程入接口，说明分组是从“朝向源的那一边”进来的，是正经分组，照单转发；如果分组是从其他接口进来的，说明是绕路来的野包，直接丢弃。
为什么叫“逆向”？因为单播转发是“朝着目的走”，而多播转发是“从源往外走”。路由器判断的不是“这个分组去哪”，而是“这个分组有没有从根的方向过来”。在路由器上查看RPF信息是个很好的体检手段：
Router# show ip rpf 192.168.0.66 RPF information for 192.168.0.66 RPF interface: GigabitEthernet0/0 RPF neighbor: 10.0.1.2字段含义：RPF interface是路由器认为的“朝向源”的入接口，RPF neighbor是该接口上的下一跳路由器。排查时只要发现组播流量入接口和这里的RPF接口对不上，这跳路由器就会把包丢掉，现象就是“成员收不到流，但路由器上看着有流量进来”。这时候去查单播路由有没有做策略路由、有没有非对称路由，基本一查一个准。
3.3 SPT与RPT：两棵树的代价权衡
多播转发树分两大类。基于源的树（SBT，也叫最短路径树SPT）以每个源为根，从根到每个叶片都走最短路径，用二元组(S, G)标识。它的优点是延迟最低，缺点是状态爆炸：N个组M个源，最多要维护N×M棵不同的树。共享树（ST，也叫汇聚点树RPT）则全网只有一个公共根，所有源的分组先发到根节点RP，再由RP沿着树向下转发，用(*, G)标识。状态少得多，但由于分组绕到RP转一圈，转发路径未必最优。
| 维度 | SPT（源树） | RPT（共享树） |
|---|---|---|
| 二元组 | (S, G) | (*, G) |
| 树根 | 每个源各自为根 | 全网共用RP |
| 转发时延 | 最短路径，低 | 可能绕路，高 |
| 状态开销 | 高，N×M棵树 | 低，每组建一棵 |
| 适用协议 | DVMRP、MOSPF、PIM-DM | CBT、PIM-SM |
组播数据从树根出发，逐跳走分支，路由器每到一个分叉点就复制一份分组发往不同下游接口。判断一个路由器是不是分叉点，只要看它的出接口列表（OIL）里有几个活跃成员端口。在路由器上用一条命令就能看清整棵树的当前形态：
Router# show ip mroute 239.0.0.11 IP Multicast Routing Table (192.168.0.66/32, 239.0.0.11) Incoming interface: GigabitEthernet0/0 Outgoing interface list: GigabitEthernet0/1 GigabitEthernet0/2输出里的Incoming interface就是RPF入接口，Outgoing interface list就是OIL。如果看到OIL里只有空括号或者没有成员口，说明树没建起来，问题通常出在成员侧没有发Join报文，而不是源侧没发数据。这两个概念一定要刻在脑子里：SPT的树结构由源决定，RPT的树结构由RP决定。踩坑时先判断当前是哪种树，再决定查哪个方向，效率完全不一样。
4. 多播路由协议选型：DVMRP、MOSPF、CBT、PIM-DM 与 PIM-SM 的适用边界
4.1 两类协议的家族谱系
多播路由协议按转发树类型分两个家族。基于源的树家族里有DVMRP、MOSPF、PIM-DM；共享树家族里有CBT、PIM-SM。选型前先把这五兄弟的脾气摸清。
DVMRP是最老的一代，距离向量算法，和RIP一个路子，靠周期性洪泛整个网络的组播分组，再对没有成员的分支发剪枝。这套机制在MBone时代够用，但每60秒全网络重播一次，规模一大就是灾难。MOSPF则是给OSPF打了补丁，把组成员信息通过组播LSA扩散到整个区域，每个路由器都能算出任意源到所有成员的最短路径树。好处是精确，坏处是组成员一变化就要重算Dijkstra，在大规模动态组里，路由器CPU就是它的瓶颈，而且MOSPF只在OSPF域内有意义，域间多播还得靠外部协议嵌套。
CBT是共享树的代表，整个组围着一棵以核心路由器为根的树转。组成员要加入时，向上游逐跳发Join请求直到核心点。它只维护(*, G)状态，内存占用极小，但核心点的位置直接决定转发效率：核心点选得偏，分组绕路绕得离谱，就会出现“能用但慢”的玄学问题。实际排障最怕这种，协议没报错、树也建起来了，就是延迟忽高忽低。
IPv4多播路由协议横向对比：
| 协议 | 树类型 | 成员信息获取 | 适用规模 | 主要短板 |
|---|---|---|---|---|
| DVMRP | SPT | 洪泛+剪枝 | 小规模实验网 | 周期洪泛，扩展性差 |
| MOSPF | SPT | 组播LSA扩散 | 单OSPF域 | 组成员变化触发全域重算 |
| CBT | RPT | 显式Join | 中小规模共享树 | 核心点位置敏感 |
| PIM-DM | SPT | 洪泛+剪枝 | 组成员密集的园区 | 带宽浪费，不适应稀疏组 |
| PIM-SM | RPT+SPT | 显式Join+注册 | 广域网/互联网 | RP规划和收敛复杂度高 |
4.2 PIM-DM 与 PIM-SM：建立过程不一样，排查思路就不一样
PIM有两个模式，组网习惯完全不同。PIM-DM是密集模式，假设组成员到处都是，所以先分组的洪泛出去，再把没有成员的枝条剪掉。它的工作过程就像广播树加上修剪，适合组成员密集、带宽过剩的园区网。配置上最省事，接口上开dense-mode就行：
! 全局开启组播路由转发 ip multicast-routing ! ! 进入接口配置PIM密集模式 interface GigabitEthernet0/0 ip address 10.0.1.1 255.255.255.0 ip pim dense-mode参数说明：ip multicast-routing是所有多播路由协议的全局总开关，漏掉它哪怕接口配置再全，路由器也不转发组播分组。ip pim dense-mode把接口置为密集模式，路由器在收到组播分组后会向所有PIM邻居洪泛，没有成员的接口会收到剪枝消息，之后一段时间内不再转发。PIM-DM的剪枝是定时器机制，剪枝状态超时后源重新洪泛，再剪一次。所以看抓包时会发现周期性出现洪泛和剪枝，这不是故障，是密集模式的原生行为。
PIM-SM的思路则反过来，它是稀疏模式，假设组成员很稀少，不能靠洪泛探路。它的建立过程拆开看其实就四步。第一步，PIM路由器之间通过Hello发现邻居、选举DR；第二步，接收者方向的DR沿着到RP的路径逐跳发Join报文，建立共享树(*, G)；第三步，源侧的DR发现源开始发数据，把第一个组播分组封装成单播Register报文发给RP，RP解封装后沿共享树往下转；第四步，共享树上的路由器如果发现源离自己更近、流量大到某个阈值，就发起SPT切换，从共享树分支切到以源为根的SPT。配置上需要指定RP：
! 全局开启组播路由 ip multicast-routing ! ! 所有参与PIM的接口都开稀疏模式 interface GigabitEthernet0/0 ip pim sparse-mode interface GigabitEthernet0/1 ip pim sparse-mode ! ! 静态指定RP地址和它负责的组范围 ip pim rp-address 192.168.1.1 239.0.0.0/8关键参数是最后一行：192.168.1.1是RP地址，239.0.0.0/8表示这个RP只负责管理239.0.0.0/8范围内的组。静态RP适合小型网络，规模大了可以换BSR（自举路由器）或Auto-RP动态选举，让路由器自己学习RP是谁，省去逐台配置的麻烦。共享树转SPT的阈值默认是“第一个组播包到达就切换”，也可以手动调：
! 设置SPT切换阈值，infinity表示永远不切换到源树 ip pim spt-threshold infinity我把spt-threshold调成infinity的情况一般是：源的数量极多、组成员很少，切到源树会让路由器维护海量(S, G)表项，不如老老实实走共享树换内存开销。反过来，做实时音视频会议时，最好保留默认的立即切换，因为RPT绕RP多一跳，延迟可能直接多出十几毫秒。这个参数没有绝对对错，只在“状态开销”和“转发延迟”之间做取舍。
4.3 选型判断的现实顺序
实际项目里，我不会根据“协议名称哪个好听”做选择，而是按下面这个顺序过一遍：先看网络里有没有现成的单播协议，PIM的好处是协议无关，不管底下跑OSPF还是静态路由都能用它；再看组成员密度，整个网段里大部分主机都在看同一路视频，用PIM-DM没问题，反之就用SM。绝大部分广域网和跨数据中心场景最终都收敛到PIM-SM，因为互联网上组成员始终是稀疏的。
DVMRP和MOSPF现在主要出现在教科书和古董设备上，新项目不要选。如果你在维护一套老园区网，路由器只支持DVMRP，注意它的邻居发现周期是60秒，排障时看到“组播表项时有时无”大概率是剪枝定时器和洪泛周期在交替，不是故障。
5. 多播排错避坑：五个高频故障的现象、原因与解决
5.1 五个高频故障的处理记录
故障一：开启多播后核心交换机CPU飙升，组播流量洪泛全网。
- 现象：视频组播源一推流，整个VLAN的交换机CPU集体上涨，抓包发现大量目的MAC为
01:00:5E:xx:xx:xx的帧出现在所有端口。 - 原因：交换机没有开IGMP Snooping，或者开了但对应VLAN没启用，多播帧被当成未知单播洪泛。
- 解决：在VLAN上开IGMP Snooping，并确认有IGMP查询器在工作。如果是只有二层交换机的环境，记得配置
ip igmp snooping vlan 10 querier，否则组成员连查询报文都收不到，永远不会发Report，Snooping表项永远建不起来。
故障二：组成员主机上ping 224.0.0.1能通，但视频流死活收不到。
- 现象：IGMP Report正常发出，Snooping表项也有，但路由器上
show ip mroute的(S, G)表项为空。 - 原因：路由器的接口没开PIM，或没开组播路由总开关。很多交换机只开了Snooping，二层通了，但三层没有PIM邻居，组播无法跨网段转发。
- 解决：检查
ip multicast-routing是否全局开启，检查组播源所在路由器和成员所在路由器之间的所有接口是否都配了ip pim sparse-mode，再确认两端PIM邻居能建立。
故障三：PIM邻居起不来，show ip pim neighbor输出为空。
- 现象：两端路由器接口都配了PIM，但就是没有邻居关系，组播分组在边界被丢弃。
- 原因：最常见的是RPF失败。PIM路由器的入接口必须和去往对端路由器的单播最优路径一致。如果中间有人做了策略路由，组播分组从一个接口进来，而单播路由表指向另一个接口，PIM Hello虽然能互达，但组播转发时RPF校验直接丢包。
- 解决：在两端路由器上分别执行
show ip rpf 对端源地址，对比实际回程接口。如果接口不一致，调整PIM接口配置到与单播路径一致，或者修改策略路由让组播流量也走同一路径。
故障四：两个不同的组播IP映射到同一个组播MAC，组播数据串组。
- 现象：主机加入了
239.0.0.11，却同时收到了发往239.128.0.11的流量。 - 原因：IPv4组播地址低23位映射到MAC地址低23位，导致多个组播IP共用同一个MAC。IGMP Snooping按MAC建表，无法区分这两个组。
- 解决：规划阶段就核对所有组播IP的低23位，避免冲突。已经上线的环境，将交换机Snooping表项调整为基于IP的过滤（部分交换机支持用IP建Snooping表项），或者把组播源改成不同的组地址段。
故障五：同一VLAN内，部分主机能收到组播流，部分主机收不到。
- 现象：交换机Snooping已开启，组表里能看到成员端口，但某台主机就是收不到流。
- 原因：主机网卡驱动没有加入正确的组播MAC，或者主机的IGMP版本和交换机/路由器查询器版本不一致。老交换机只支持IGMPv2，新主机默认发IGMPv3报告，查询器会忽略不认识的报告，导致Snooping表项建不出来。
- 解决：把主机侧加入组改为显式方式，执行
ip maddr add 239.0.0.11 dev eth0强制网卡订阅组播MAC。如果这样能收到流，说明问题在IGMP版本协商，将交换机的IGMP版本兼容模式打开，或者把主机的IGMP协议版本改为v2。
5.2 一个能救命的排查命令顺序
组播排障最忌讳想起来查哪条就查哪条。我现在的固定习惯是按下述顺序过一遍，每步先看现象再决定是否深入：
# 1. 先看二层：Snooping组表有没有成员端口 show ip igmp snooping groups # 2. 再看三层：组播路由表有没有(S,G)表项 show ip mroute # 3. 校验逆向路径：入接口对不对 show ip rpf 源地址 # 4. 最后看协议邻居：PIM邻居是否齐全 show ip pim neighbor顺序逻辑是：二层没表项，问题在IGMP和主机侧；二层有表项、三层没(S, G)，问题在PIM邻居和RP；三层有表项但流量不进，查RPF入接口；前三个全没问题但视频还是断，最后才去查策略路由和防火墙策略。这个顺序帮我避开了无数次毫无意义的抓包和分析，至少能省下一半的排障时间。
6. 域间多播与 IPv6 多播：MBone 遗产与 MLD 的落地验证
6.1 域间多播的接力：从MBone到MSDP
域间多播最早是靠MBone跑起来的。那个年代多数路由器不支持多播，于是把多播分组封装进普通单播IP包，通过IP-in-IP隧道在站点之间穿行，每个接入站点跑一个叫mrouted的守护进程，维护DVMRP路由表。隧道是点对点的，配置量巨大，但正是这套实验设施验证了多播在广域网上的可行性。现在MBone已经成了历史名词，域间多播的接力棒交给了MSDP与MBGP的组合：MSDP让各个域的RP之间互相通告源信息，MBGP则在BGP里携带组播路由属性，让组播源可以在域间可达。
6.2 IPv6多播：地址格式与MLD
IPv6多播地址固定以FF开头，完整格式是8位FF+ 4位标志 + 4位范围 + 112位组ID。范围字段最常用：1表示接口本地，2表示链路本地，5是站点本地，8是组织本地，E是全局。ff02::1代表链路上所有节点，ff02::2代表所有路由器，ff02::5和ff02::6分别是OSPFv3和RIPng的路由器组。
IPv6的组成员管理协议叫MLD，MLDv1对应IGMPv2的能力，MLDv2对应IGMPv3，支持源过滤。在Linux上验证IPv6多播很简单，把本机加入一个组，然后抓MLD报文看交互：
# 把eth0加入多播组ff02::114 ip maddr add ff02::114 dev eth0 # 尝试ping链路本地所有节点，看到回包说明组播可达 ping6 -I eth0 ff02::1 # 抓MLD报文观察加入过程 tcpdump -i eth0 -nn mld6.3 验证技巧与收尾
抓包时关注两种报文：主机发出的MLD Report，以及路由器周期性的MLD Query。只要能看到Report，二层链路就是通的。如果抓不到Query，说明链路上没有启用IPv6组播的查询器，主机永远不会主动发Report，这和IPv4里“没有IGMP查询器”是同一个坑。
做组播项目这几年，最大的教训就是：任何组播方案，开工前先拉一张“组播源、组成员、路由器接口、二层设备是否支持Snooping”的清单，然后按二层Snooping → IGMP/MLD → PIM邻居 → RPF → RP的路径逐层确认，最后再做抓包验证。从那以后，每次组播部署基本没翻过车。希望帮到你。
本文还有配套的精品资源，点击获取
