简介：计算机网络多播路由技术PPT课件，系统讲解多播路由一次发送、多点接收的核心原理，适合网络工程、计算机通信等方向的学生和教师用于课程学习、复习或备课。压缩包内共1个文件，为PPT格式，大小约2.4MB，章节划分清晰，从局域网多播的MAC封装与IGMP组管理讲起，逐步深入到交换式LAN上的多播实现、多播转发与逆向路由选择、多播转发树（SPT/RPT）等核心概念，并覆盖DVMRP、MOSPF、CBT、PIM-DM/PIM-SM等主流协议，以及MBone域间多播和IPv6多播技术。已有183人学习/浏览，内容兼具原理阐述与协议对比，可帮助读者理清多播路由的转发机制、算法选型与协议适用场景，快速构建从局域网到域间的组播部署知识脉络。无论是课前预习、期末复习，还是教师制作课件，这份资料都能提供清晰的参考框架。

1. 多播路由技术：不是广播，而是只有“想收的人”才收到流量

计算机网络多播路由技术，听起来像是教科书里才会出现的冷门章节，实际上视频会议、直播拉流、金融行情推送全都在靠它撑场子。做过线上培训的人都知道，用单播给 500 个参会者各发一路视频，源服务器上行带宽会被打爆；用广播发，全网都被无关包拖下水。多播路由的做法是让源只发一份流量，路由器按成员关系把包复制到每个有接收者的分支。下文从多播地址和 IGMP 管理讲起，再到 PIM-SM 协议选型、Linux 上 FRRouting 实验和排错，适合正在组播网里翻车挣扎的运维，也适合刚啃完《计算机网络》想弄清楚网络层真相的学生。

2. 多播地址与组管理：IGMP/MLD 选型前先弄懂地址和 MAC

在做多播路由之前，必须先回答“谁要这个包”和“包往哪送”两个问题。前者由 IGMP/MLD 负责，地址和 MAC 映射决定了包能不能送到；后者由路由协议决定。把地址和组管理放在一起讲，是因为一半的翻车现场都出在二层过滤和 IGMP 版本不匹配上。

2.1 多播 IP 地址范围与 MAC 映射：二层过滤器的盲区

IPv4 多播地址是 224.0.0.0/4 这个连续段，范围从 224.0.0.0 到 239.255.255.255，源地址必须是单播地址。这个段内部不是都可以随便用。224.0.0.0/24 是链路本地地址，例如 224.0.0.1 代表“本网段所有主机”，224.0.0.5 是 OSPF 协议地址，这类地址 TTL 固定为 1，路由器不会转发。232.0.0.0/8 保留给 SSM（指定源组播），239.0.0.0/8 是可以自由规划的本地管理范围，企业内部组播通常在这里划分。

MAC 地址映射是组播最容易翻车的地方。以太网把 IPv4 组播地址映射到 MAC 地址时，固定使用 OUI 01:00:5e，然后把 IP 地址的低 23 位填充到 MAC 的后 23 位。比如 239.1.2.3 会映射成 01:00:5e:01:02:03，224.0.0.1 映射成 01:00:5e:00:00:01。问题是 IP 地址有 28 位组播编号位，MAC 只能装下 23 位，等于有 5 位被丢了，32 个组播组会共用同一个 MAC 地址。因此网卡会收到不属于本组但 MAC 相同的帧，只能靠 IP 层再过滤一次。这个特性还会影响交换机：如果不开启 IGMP snooping，二层交换机会把组播帧当成未知单播泛洪到所有端口；开启 snooping 后，交换机通过监听 IGMP 报文学习端口成员关系，不相关的组播帧就不会进除接收者之外的端口。

在选型时，局域网内优先开启 IGMP snooping，并确认查询器（querier）存在。很多傻瓜交换机默认广播所有组播，这是直播不卡但全网卡的最常见原因。如果你用 Wireshark 抓包看到“IGMP Membership Query”缺位，就需要在三层交换机或路由器上配置查询器，或者在二层设备上打开“IGMP snooping querier”，否则组播成员表项会因为没人定期询问而老化。

2.2 IGMPv2 与 IGMPv3：选错版本会让源过滤策略没法落地

IGMP 是主机和三层设备之间的组成员管理协议，IPv6 对应 MLD。IGMPv1 最老，已经很少用。IGMPv2 增加了离开组报文，让主机能主动告诉路由器“我不看了”，路由器不必等到超时才把端口从组播组里摘掉，适合 IP 电视这类切换频繁的业务。IGMPv3 最大变化是支持源过滤，主机可以指定只接收某个源的组播，这就是 SSM 的基础。

生产环境怎么选？如果业务是单源直播，建议直接上 IGMPv3+SSM，既绕开 RP 的共享树，又天然解决了“任意源都能灌流量”的隐患。如果业务是多源互动会议，IGMPv2 配合 PIM-SM 也能跑，但要在路由器上做 RPF 检查和源过滤。还要注意两端版本一致性：主机发 IGMPv3 报告，路由器接口只支持 IGMPv2 时会把报告忽略，组成员建不出来。所以配置完要查一下show ip igmp interface，确认版本号一致。

查询器选举和定时器参数也值得调。IGMP 查询器默认每 60 秒发一次 Query，响应超时 10 秒，但 snooping 交换机上的表项老化时间通常更短。如果业务是视频直播，突然用户切台，会有一段短暂黑屏。常见做法是把 IGMP query interval 调到 30 秒，或开启“fast-leave”让离开报文立即生效。这里的“fast-leave”不是所有交换机都支持，开启前要确认该端口下只有一台主机，否则会把还在收流量的主机一并踢出去。

2.3 设计组播地址规划：先算 MAC 冲突再分配

企业内部用 239.0.0.0/8 时，不要随手写一个 239.1.2.3 就开始发包。要先把业务需要的组播组列出来，换算 MAC 后检查是否冲突。因为 32 个 IP 对应同一个 MAC，如果两个业务都映射到相同 MAC，二层交换机无法区分，接收端会同时收到两个业务的帧，虽然 IP 层能过滤，但 CPU 和带宽已经浪费了。

我的习惯是先按业务重要性分配组播组，不同业务尽量使用不同的第二字节段，避免后 23 位碰撞。例如视频流用 239.10.x.x，行情流用 239.20.x.x。还要避开 224.0.0.0/24 的链路本地地址，以及被协议占用的 PIM 224.0.0.13、OSPF 224.0.0.5 等。另一个容易被忽略的是，如果三层设备上配置了ip multicast-routing，它默认会接收所有组播，需要在接口上用 ACL 限制某些组，防止无关组播被路由扩散。

从经验看，大多数组播配置问题不是协议不会配，而是地址规划随意。先把组播组地址、对应的 MAC、允许的源、允许的接收者 VLAN 列表做成一张表，配置就只是把表翻译成命令的过程。这张表还能在排错时快速判断某条流量是应该走 IGMPv2 还是 IGMPv3，是 PIM-SM 还是 SSM。

3. 多播路由协议选型：PIM-SM 为什么是生产环境的默认答案

多播路由协议决定了“这份流量从源到接收者走哪条树”。选型和单播路由不同，它不只看终点，还要看沿途谁想收。生产环境里我几乎只推荐 PIM-SM，但这不代表其他模式没有价值，关键是理解状态量和收敛代价。

3.1 密集模式与稀疏模式：用接收者密度决定组播树形态

多播路由协议大致分两类。密集模式协议假设网络里大部分子网都有接收者，所以一开始把组播包向所有接口洪水，没有接收者的分支再发剪枝消息把源剪掉，典型代表是 DVMRP 和 PIM-DM。这种模式在小型局域网里配置简单，但广域网里周期性洪水会浪费带宽，而且剪枝状态要维护很多接口，扩展性很差。稀疏模式协议假设接收者很少，只有下游主动发出批量加入请求，上游才会建立状态，典型代表是 PIM-SM。

选型时主要看组播业务的范围和接收者密度。如果一个办公楼所有楼层都要收同一个视频，接收者分布密集，用 PIM-DM 可能最省事；但跨城、跨数据中心时，流量路径长且中间链路贵，一定要用 PIM-SM。实际生产网络我基本只说 PIM-SM，因为除个别单网小型分支外，其余场景都能用，且 FRR、Cisco、华为等实现都很稳定。PIM-DM 现在更像教材里的历史名词，踩过坑的人都知道它会在组播源多时出现重复路由震荡。

PIM-DM 的转发是 RPF（逆向路径转发）检错：收到组播包的接口必须是通往源的接口，否则丢弃。PIM-SM 的 RPF 检查依然存在，但它用显式加入建立树，源侧的流量先单播到 RP 再转发，这是两者最大的区别。

3.2 PIM-SM 的 RP 与状态机：注册、共享树和 SPT 切换

PIM-SM 的关键是 RP（汇聚点）。每个组播组都有一个 RP，所有加入该组的接收者先向 RP 发送 Join，以 RP 为根的共享树就建起来了。当发送者第一次向组播组发数据时，源侧 DR（指定路由器）把数据封装成注册消息单播给 RP，RP 解封装后沿共享树转发给接收者，同时 RP 会向源侧 DR 发送 Join，让数据也可以沿着源和 RP 之间的最短路径树走。一旦流量超过某个阈值，接收者侧 DR 会直接向源侧 DR 发 Join，切换到最短路径树（SPT），从此不再绕经 RP。

这个机制的代价是路由状态多，特别是组多、源多的时候。所以生产环境要控制 RP 数量和位置。RP 应该放在带宽充足、距离源和接收者都不远的核心节点，最好用 Loopback 接口，避免物理链路 down 导致整个组播树重建。RP 发现有三种常见做法：静态配置、BSR（自举路由器）、Anycast-RP。小网络直接静态 RP，一两条命令；大网络用 Anycast-RP 做冗余，让多个 RP 共享一个虚拟地址，源侧 DR 和接收者侧 DR 各自哈希到一个 RP，即使某个 RP 挂了，另一个 RP 也能接管。

调试 PIM-SM 时重点看几个表：show ip pim neighbor确认邻居；show ip pim rp确认组的 RP；show ip mroute确认 (S,G) 和 (,G) 表项。如果只有 (,G) 没有 (S,G)，说明源数据还没到 RP；如果 (S,G) 有了但表项上没有出接口，说明下游没有接收者。

3.3 双向 PIM 和 SSM：两个绕开共享树缺陷的变体

双向 PIM（Bidir-PIM）用于多对多场景，比如视频会议里所有人都是源。它不像 PIM-SM 那样每个源都建立一棵树，而是直接在 RP 上把所有源和接收者接到同一个双向共享树，数据包在 RP 处从各方向汇聚再分发，省去了大量 (S,G) 状态。代价是 RP 变成绝对中心，RP 故障会导致整个组瘫痪，而且所有组播流量都经过 RP，对带宽和 CPU 要求高。

SSM 是另一个方向。它依赖 IGMPv3/MLDv2，主机加入组时直接指定源地址，路由器根据 (S,G) 建立最短路径树，完全不需要 RP。适合单一可信源的直播推送，也适合对安全性要求高的行情分发，因为接收者只接受指定的源，不需要的源在协议层面就被过滤掉了。

使用时要注意，SSM 必须在接入层和主机层面同时支持 IGMPv3，而且组播组范围要在 232.0.0.0/8 内。如果业务中源地址本来就用 NAT 或动态变化，SSM 会很难受，因为主机必须先知道源地址才能加入。下表是四种模式的粗粒度对比，方便做选型。

4. 在 Linux 上落地多播转发：FRRouting 最小实验与参数调优

理论讲完，该上手了。这里用三台 Ubuntu 虚拟机做最小实验：一台源、一台路由器、一台接收者。路由器上跑 FRRouting 的 PIM-SM，RP 就落在路由器自己身上。

4.1 内核和拓扑准备：先给系统打开多播转发开关

拓扑如下：

• source：192.168.1.2/24，默认网关指向路由器 eth0
• router：eth0 192.168.1.1/24，eth1 192.168.2.1/24
• receiver：192.168.2.2/24，默认网关指向路由器 eth1

所有机器用 Ubuntu 22.04，内核需要打开多播路由支持。先检查内核配置和转发开关：

grep CONFIG_IP_MROUTE /boot/config-$(uname -r) sysctl -w net.ipv4.ip_forward=1 sysctl -w net.ipv4.conf.all.mc_forwarding=1 echo "net.ipv4.conf.all.mc_forwarding=1" >> /etc/sysctl.conf

说明：grep确认内核编译了多播路由，如果显示=m还需要modprobe ipmr，如果显示=y则直接可用。net.ipv4.ip_forward=1是普通单播转发，net.ipv4.conf.all.mc_forwarding=1才是多播路由的总开关。没有后者，PIM 注册消息和内核转发都不会生效，很多人卡在这一步。

注意：mc_forwarding这个开关在老内核里也叫mr_forwarding，如果 sysctl 报 key 不存在，先确认内核 config 里的CONFIG_IP_MROUTE已经打开。

4.2 安装并配置 FRRouting：PIM-SM 最小配置

FRRouting（FRR）是目前最常用的开源路由套件，里面带了 pimd 守护进程。安装时默认不启 PIM，需要自己打开：

apt update && apt install -y frr sed -ri 's/pimd=no/pimd=yes/' /etc/frr/daemons systemctl restart frr

sed是为了把 PIM 守护进程启用，新版 FRR 默认pimd=no。改完后编辑/etc/frr/frr.conf：

hostname mcast-router password zebra enable password zebra ! interface eth0 ip address 192.168.1.1/24 ip pim ip igmp ! interface eth1 ip address 192.168.2.1/24 ip pim ip igmp ! router pim ip multicast-routing ip pim rp 192.168.1.1 239.1.1.1/32 !

接口下ip pim启用 PIM hello，ip igmp启用 IGMP 监听。router pim下面的ip multicast-routing是总开关，ip pim rp 192.168.1.1 239.1.1.1/32把组 239.1.1.1 的 RP 指向路由器自己的 eth0 地址。注意：RP 地址必须全网可达，而且该接口也要启用ip pim，否则 RP 一直处于 down 状态。

改完执行systemctl restart frr，然后用vtysh看邻居：

vtysh -c "show ip pim neighbor" vtysh -c "show ip pim rp"

如果没有显示任何邻居，多半是接口没有起来，或者 eth0/eth1 没配地址。这一步确认后再往下做收发实验。

4.3 收发组播包：Python 脚本比 ping 靠谱一百倍

很多人习惯先 ping239.1.1.1，这是组播里最典型的错误。ICMP 的 reply 是接收者发出的，组播组成员收到后发回给源，但源未必是组的成员，回包也可能被丢弃，而且多个成员同时回包会让源崩溃。正确做法是用 UDP 组播脚本。

发送端脚本：

import socket, time s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_UDP) s.setsockopt(socket.IPPROTO_IP, socket.IP_MULTICAST_TTL, 32) s.setsockopt(socket.IPPROTO_IP, socket.IP_MULTICAST_IF, socket.inet_aton("192.168.1.2")) for i in range(10): s.sendto(b"hello multicast", ("239.1.1.1", 9000)) time.sleep(1)

逻辑说明：IP_MULTICAST_TTL设置组播包的 TTL，路由器上必须大于 1，否则包不跨网段。IP_MULTICAST_IF指定组播报文出接口，如果机器有多个网卡，不设置会走默认路由，可能直接丢弃。这里循环发 10 包，方便接收端观察。

接收端脚本：

import socket s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_UDP) s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) s.bind(("0.0.0.0", 9000)) s.setsockopt(socket.IPPROTO_IP, socket.IP_ADD_MEMBERSHIP, socket.inet_aton("239.1.1.1") + socket.inet_aton("192.168.2.2")) while True: data, addr = s.recvfrom(1024) print(addr, data)

说明：SO_REUSEADDR让多个进程可以绑定同一端口方便测试；bind绑定 9000 端口而不是组播地址；加入组的IP_ADD_MEMBERSHIP参数是“组播地址 4 字节 + 本机接口地址 4 字节”，注意要写接收端自己的 IP，不能写默认路由地址，否则加入行为会失败。脚本用 root 运行，加入成功时路由器上能看到 IGMP report。

当接收端收到数据后，路由器上应该已经生成了组播转发表：

vtysh -c "show ip mroute" cat /proc/net/ip_mr_cache

show ip mroute会显示 (*,G) 和 (S,G) 表，出接口为 eth1。ip_mr_cache是内核转发表，只有实际转发的包会出现在这里。如果内核表为空，说明 PIM 状态有，但包没有进内核转发，多半是mc_forwarding没打开。

4.4 参数调优：把收敛速度和路径选好

实验通了以后，生产环境还要调几个参数。

PIM Hello 默认 30 秒一次，邻居认为丢失要 105 秒，收敛太慢。如果组播业务重要，可以把接口下的 Hello 间隔改小到 10 秒：

interface eth0 ip pim hello-interval 10

DR 的选择默认按 IP 地址大的优先。如果想让某台设备成为 DR，在接口下设置ip pim drpriority，值越大优先级越高。DR 负责向 RP 发送注册和 Join，选错 DR 会导致源流量绕远路。配置后在show ip pim interface里能确认谁是 DR。

RP 如果放在独立环回地址上，还要确认所有路由器都能通过单播路由到该地址。PIM 不产生路由，它依赖单播路由表做 RPF 检查。如果 RP 地址配置成非环回但物理接口坏了，组播树会反复重建。我一般用show ip pim rp看 RP 是否有效，并定期看show ip mroute里条目是否在刷新。

5. 多播路由配置避坑：五个让我半夜翻车的现场

做组播路由，协议本身不复杂，复杂的都是链路层和版本差异。下面五条是我在实验室和生产环境都踩过的坑，按现象、原因、解决写，照着排查能省下大半天。

5.1 接收端加入组但收不到流量，路由器没有任何组播路由表项

现象：接收端用脚本加入了 239.1.1.1，源端发 UDP，接收端一直等不到数据；在路由器上看show ip mroute什么都没有。

原因：路由器接口缺少ip pim配置，或者源接入接口没有启用 PIM。PIM-SM 只有在启用了 PIM 的接口上才接收和转发组播数据，如果入口接口没开，包会在进入时被丢弃。

解决：在路由器所有参与组播的接口上检查配置，确认 eth0 和 eth1 都有ip pim；然后用show ip pim neighbor确认上下游邻居都建立。如果邻居缺失，往下查二层是否禁用了组播帧。

5.2 PIM 邻居可见，但 RP 上始终只有 (*,G) 没有 (S,G)

现象：源侧 DR 的路由器能看见 RP 邻居，但show ip mroute只有 (*,G)，没有 (S,G)，接收端也收不到数据。

原因：数据封装成 register 从源侧 DR 单播发给 RP，如果到 RP 的路由不可达，或者 RP 接口 down，源侧 DR 的 register 一直被丢弃。也可能是源主机发出的包 TTL=1，源侧 DR 根本收不到。

解决：在源侧 DR 上执行show ip pim rp确认 RP 可达，抓包看源侧 DR 是否收到源主机的 UDP 包，再看 register 是否发出。如果没收到源数据，回去查发送端脚本的 TTL 和出接口。如果 register 发出了但 RP 没收到，用traceroute确认到 RP 的单播路径。

5.3 交换机所有端口都在泛洪组播流量，接入层带宽被打满

现象：一台交换机下接了多个 VLAN，只要源一开始发组播，所有接入端口都在转发，网络延迟飙升。

原因：二层交换机没有开 IGMP snooping，或者 snooping 表项过期。IGMP snooping 要监听主机发起的 IGMP 报告，如果交换机没有查询器，表项会自动老化，然后组播帧从所有端口泛洪。

解决：在交换机上开启ip igmp snooping，并确保只有一个查询器。如果是纯二层网络，需要在三层设备上配置 IGMP 查询器。注意查询器选举依赖 VLAN 接口 IP，通常选 IP 最小的，不要让多台设备同时做查询器，否则表项会震荡。

5.4 两个业务组播组的数据在接收端串包

现象：接收端同一个进程收数据，一会儿收到业务 A 的 UDP，一会儿收到业务 B 的 UDP，抓包看到两个组的帧都进了同一个网卡。

原因：多播 IP 映射到 MAC 时，32 个 IP 共享一个 MAC 地址，二层地址无法区分。如果两个业务恰好映射到同一个 MAC，交换机和网卡都会把两个组的帧送到接收端，只能靠 IP 层再丢一次。

解决：重新分配组播组地址，避免后 23 位冲突。这是 IPv4 组播的老限制，只能通过地址规划绕开。如果必须用同一网段，可以在应用层过滤源 IP 或组 ID，但这只是后悔药，不能治本。另外可以改用 SSM，至少让主机按源过滤，但 MAC 层面的混淆依然存在，只是流量来源变为同一个源时才可控。

5.5 SSM 配置正确但 IGMPv3 加入被忽略

现象：客户端用 IGMPv3 加入 (192.168.1.2, 232.1.1.1)，路由器上show ip igmp groups没有该组，PIM 也没有状态。

原因：接入接口的 IGMP 版本仍为 v2，会用 v2 报文格式去解析 v3 的 report，直接丢弃；或者 PIM 配置里没把该组划入 SSM range，PIM 仍然按 PIM-SM 的 RP 模式处理 IGMPv3 的加入。

解决：在路由器接入接口下配置ip igmp version 3，并在router pim里加ip pim ssm range 232.0.0.0/8。如果在接收端用ip maddr add这种工具，它只在内核里加组，不一定是 IGMPv3，建议直接用支持 IGMPv3 的 socket 脚本验证。

6. 验证多播路由是否真正可用：从源到接收端的全链路测试法

6.1 逐跳抓包：看包死在哪一跳

多播路由排错最忌讳在接收端一个点看问题。我会在源端、路由器入接口、路由器出接口、接收端分别抓包：

tcpdump -i eth0 -n udp port 9000 tcpdump -i eth0 -n -v igmp tcpdump -i eth0 -n -v pim

在源侧看IP_MULTICAST_TTL是否生效；路由器入接口看到 UDP 包，但出接口没有，说明 PIM 状态有问题；出接口有包但接收端没收到，问题在二层交换机或网卡。再看 IGMP report 是否出现在接收端接入的接口上，如果出现但路由器没有生成组播路由条目，说明ip igmp或ip pim漏配。

6.2 看内核和 FRR 的状态：用表和计数器判断树建在哪

在路由器上执行：

vtysh -c "show ip pim rp" vtysh -c "show ip pim neighbor" vtysh -c "show ip mroute" cat /proc/net/ip_mr_cache

我习惯先看ip_mr_cache，因为它是内核转发表的真实状态，只有包真正转发时才产生。如果内核表有 (S,G) 条目，但出接口方向不对，检查 RPF 表：PIM 要求收到组播包的接口必须是通向源的接口，否则静默丢弃。如果出现 RPF lookup failed，通常是对端接口配置了对称路由但 PIM 邻居没建立，可以用show ip rpf <源地址>确认。

最后分享一个习惯：配置组播路由前，我会先写一张“源、组、接收者接口”的映射表，再写脚本循环发一定时间，用接收端脚本记录丢包率。一次生产变更前，我因为在 Loopback 上忘了加ip pim，导致 RP 状态一直 down，业务方等我半天。后来每个多播变更都先抓包再改配置，问题基本都在 10 分钟内暴露。希望帮到你。

本文还有配套的精品资源，点击获取