简介计算机网络多播路由技术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:03224.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 的基础。生产环境怎么选如果业务是单源直播建议直接上 IGMPv3SSM既绕开 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指定路由器把数据封装成注册消息单播给 RPRP 解封装后沿共享树转发给接收者同时 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确认组的 RPshow ip mroute确认 (S,G) 和 (,G) 表项。如果只有 (,G) 没有 (S,G)说明源数据还没到 RP如果 (S,G) 有了但表项上没有出接口说明下游没有接收者。3.3 双向 PIM 和 SSM两个绕开共享树缺陷的变体双向 PIMBidir-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 会很难受因为主机必须先知道源地址才能加入。下表是四种模式的粗粒度对比方便做选型。模式典型场景状态量是否依赖 RP二层要求PIM-DM局域网密集接收多每源每组否IGMPv2PIM-SM广域网稀疏接收多但有剪枝是IGMPv2/v3Bidir-PIM多对多会议少只有 (*,G)是强中心IGMPv2/v3SSM单源直播/行情少只有 (S,G)否IGMPv34. 在 Linux 上落地多播转发FRRouting 最小实验与参数调优理论讲完该上手了。这里用三台 Ubuntu 虚拟机做最小实验一台源、一台路由器、一台接收者。路由器上跑 FRRouting 的 PIM-SMRP 就落在路由器自己身上。4.1 内核和拓扑准备先给系统打开多播转发开关拓扑如下source192.168.1.2/24默认网关指向路由器 eth0routereth0 192.168.1.1/24eth1 192.168.2.1/24receiver192.168.2.2/24默认网关指向路由器 eth1所有机器用 Ubuntu 22.04内核需要打开多播路由支持。先检查内核配置和转发开关grep CONFIG_IP_MROUTE /boot/config-$(uname -r) sysctl -w net.ipv4.ip_forward1 sysctl -w net.ipv4.conf.all.mc_forwarding1 echo net.ipv4.conf.all.mc_forwarding1 /etc/sysctl.conf说明grep确认内核编译了多播路由如果显示m还需要modprobe ipmr如果显示y则直接可用。net.ipv4.ip_forward1是普通单播转发net.ipv4.conf.all.mc_forwarding1才是多播路由的总开关。没有后者PIM 注册消息和内核转发都不会生效很多人卡在这一步。注意mc_forwarding这个开关在老内核里也叫mr_forwarding如果 sysctl 报 key 不存在先确认内核 config 里的CONFIG_IP_MROUTE已经打开。4.2 安装并配置 FRRoutingPIM-SM 最小配置FRRoutingFRR是目前最常用的开源路由套件里面带了 pimd 守护进程。安装时默认不启 PIM需要自己打开apt update apt install -y frr sed -ri s/pimdno/pimdyes/ /etc/frr/daemons systemctl restart frrsed是为了把 PIM 守护进程启用新版 FRR 默认pimdno。改完后编辑/etc/frr/frr.confhostname 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 helloip 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(bhello 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_cacheshow 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 10DR 的选择默认按 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 一直被丢弃。也可能是源主机发出的包 TTL1源侧 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 rangePIM 仍然按 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 分钟内暴露。希望帮到你。本文还有配套的精品资源点击获取 多播路由技术实战：IGMP、PIM-SM与FRRouting排错指南
简介计算机网络多播路由技术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:03224.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 的基础。生产环境怎么选如果业务是单源直播建议直接上 IGMPv3SSM既绕开 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指定路由器把数据封装成注册消息单播给 RPRP 解封装后沿共享树转发给接收者同时 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确认组的 RPshow ip mroute确认 (S,G) 和 (,G) 表项。如果只有 (,G) 没有 (S,G)说明源数据还没到 RP如果 (S,G) 有了但表项上没有出接口说明下游没有接收者。3.3 双向 PIM 和 SSM两个绕开共享树缺陷的变体双向 PIMBidir-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 会很难受因为主机必须先知道源地址才能加入。下表是四种模式的粗粒度对比方便做选型。模式典型场景状态量是否依赖 RP二层要求PIM-DM局域网密集接收多每源每组否IGMPv2PIM-SM广域网稀疏接收多但有剪枝是IGMPv2/v3Bidir-PIM多对多会议少只有 (*,G)是强中心IGMPv2/v3SSM单源直播/行情少只有 (S,G)否IGMPv34. 在 Linux 上落地多播转发FRRouting 最小实验与参数调优理论讲完该上手了。这里用三台 Ubuntu 虚拟机做最小实验一台源、一台路由器、一台接收者。路由器上跑 FRRouting 的 PIM-SMRP 就落在路由器自己身上。4.1 内核和拓扑准备先给系统打开多播转发开关拓扑如下source192.168.1.2/24默认网关指向路由器 eth0routereth0 192.168.1.1/24eth1 192.168.2.1/24receiver192.168.2.2/24默认网关指向路由器 eth1所有机器用 Ubuntu 22.04内核需要打开多播路由支持。先检查内核配置和转发开关grep CONFIG_IP_MROUTE /boot/config-$(uname -r) sysctl -w net.ipv4.ip_forward1 sysctl -w net.ipv4.conf.all.mc_forwarding1 echo net.ipv4.conf.all.mc_forwarding1 /etc/sysctl.conf说明grep确认内核编译了多播路由如果显示m还需要modprobe ipmr如果显示y则直接可用。net.ipv4.ip_forward1是普通单播转发net.ipv4.conf.all.mc_forwarding1才是多播路由的总开关。没有后者PIM 注册消息和内核转发都不会生效很多人卡在这一步。注意mc_forwarding这个开关在老内核里也叫mr_forwarding如果 sysctl 报 key 不存在先确认内核 config 里的CONFIG_IP_MROUTE已经打开。4.2 安装并配置 FRRoutingPIM-SM 最小配置FRRoutingFRR是目前最常用的开源路由套件里面带了 pimd 守护进程。安装时默认不启 PIM需要自己打开apt update apt install -y frr sed -ri s/pimdno/pimdyes/ /etc/frr/daemons systemctl restart frrsed是为了把 PIM 守护进程启用新版 FRR 默认pimdno。改完后编辑/etc/frr/frr.confhostname 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 helloip 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(bhello 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_cacheshow 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 10DR 的选择默认按 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 一直被丢弃。也可能是源主机发出的包 TTL1源侧 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 rangePIM 仍然按 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 分钟内暴露。希望帮到你。本文还有配套的精品资源点击获取