1. 组播这件事先得从“为什么要有IGMP”说起组播这个技术做网络的人多少都接触过但真正把IGMP吃透的人不多。很多人一说组播就是“下边挂一堆交换机不知道报文怎么走的”其实IGMP就是组播体系里最基础也最容易被忽视的一环。简单说IGMPInternet Group Management Protocol互联网组管理协议是主机和路由器之间“对话”的协议。主机用IGMP向路由器报告“我要加入哪个组”路由器用IGMP知道“这个网段下边有没有人对某个组感兴趣”。没有IGMP路由器就只能不管三七二十一把组播流量往每个网段都发一遍和广播没区别组播的意义就没了。IGMP到目前为止有三个主要版本——v1、v2、v3。这一章重点聊v2这也是当前企业内部网络里最常见的版本。相比v1IGMPv2最大的改进是引入了“查询器选举机制”和“离开组报文”这两个机制解决了v1时代非常实际的问题谁是老大、以及用户走了之后老大会不会一直傻等。IGMPv2实现了RFC 2236定义的基本能力。它运行在IP层协议号是2报文封装在IP头里目的地址通常用224.0.0.1所有组播主机或224.0.0.2所有组播路由器。这些细节看起来枯燥但排障的时候特别有用。这篇文章适合三类人看一是正在学组播、对IGMP只有模糊概念的网工二是要维护企业组播业务IPTV、视频会议、桌面广播这类需要在路由器或三层交换机上做IGMP配置和排障的工程师三是做网络设计、需要在“组播到底该选v2还是v3”这个问题上做判断的人。我会把IGMPv2的报文结构、工作机制、配置方法、以及最常见的坑都掰开揉碎讲一遍。有些内容是标准文档里不会明说的纯经验比如查询器选举的优先级怎么设才不容易出问题、不同厂商设备在IGMP查询器和成员关系接口上的表现差异这些我会直接讲结论。2. IGMPv2的核心机制拆解查询器选举与组成员管理2.1 查询器选举为什么v2必须解决“谁问”的问题在IGMPv1时代默认所有路由器都会发查询报文没有选举机制。如果一条链路上只挂了一台路由器那没事但现实情况是很多网络里两台三层设备会同时连着同一个广播网段两台设备都会发IGMP通用查询报文。成员主机收到两个查询者的查询它回一个报告报文两台路由器都能收到这看起来没毛病——但问题不小。IGMPv1时代没有选举两台路由器各自维护自己的组成员表状态可能不一致。更糟糕的是如果其中一台路由器回包超时、或者对成员的响应处理出现差异就会引发组播流量的重复接收或丢包。在组播流量大、视频业务多的时候这种不一致带来的影响是灾难性的。所以IGMPv2引入了查询器选举机制。规则用一句话总结同网段下IP地址最小的路由器获胜成为查询器。所有IGMPv2路由器在启动的时候都会向224.0.0.1发送“成员关系查询”报文报文里带有发送者的IP地址。其他路由器收到该报文后会比较自己的IP和收到报文的源IP如果自己的IP更大就放弃查询器的角色进入非查询器状态不再发通用查询报文只响应特定查询。这个比较不是只做一次就完了而是持续的过程。非查询器路由器上有一个“其他查询器存在计时器”Other Query Present Timer默认值是查询间隔的两倍。如果在计时器到期之前非查询器一直能收到查询器发来的通用查询报文它就继续当“小弟”如果这个计时器超时了说明查询器挂了或不可达它马上接管查询器的角色重新开始发通用查询报文。2.2 组成员关系管理机制从加入、保持到离开IGMPv2的组成员关系管理核心是循环往复的查询-响应过程。这个过程有几个关键定时器组成员关系查询间隔默认125秒、组成员关系超时默认260秒、最大响应时间默认10秒、特定查询间隔默认1秒。主机加入组播组会主动发送“成员关系报告”报文Membership Report目的地址直接是组播组地址本身比如239.1.1.1而不是发到224.0.0.1。这一点很多人会搞错。主机发送报告时源IP是它自己的接口IP目的IP是它要加入的那个组的地址这也意味着报告报文会被该组播组的所有成员收到。路由器收到报告报文后就在对应的接口上记录这个网段下边有组成员对239.1.1.1感兴趣于是把组播流量发往该网段。主机那边也不是发一次报告就完事了。IGMPv2规定成员主机在收到查询器发来的通用查询报文后会延迟一段时间由最大响应时间决定再发送报告报文这样做的目的是让同一网段下的所有成员只有一台主机回报告就行——如果有多台主机同时回报告查询器其实也没意见但网络里报文会冗余。等一下这里有个细节主机延迟发送报告是为了“响应抑制”。如果网段下已经有另一台主机先发出了报告后边的主机听到这个报告就会意识到“反正路由器已经知道有人在这个组了”它就不再重复发报告了这叫报告抑制机制。这个机制减少了冗余报告但对排障来说是个干扰项后面我会讲怎么绕过这个问题做测试。离开机制的引入是IGMPv2和v1最大的区别之一。主机要离开组播组时会发送一个“离开组报文”Leave Group Message目的地址是224.0.0.2所有组播路由器。查询器收到之后会针对该组发送“特定组查询报文”Group-Specific Query目的地址就是组播组地址目的IP填的是组成员关系接口的多播地址224.0.0.1。这个特定查询会连续发几次默认两次间隔1秒如果在特定组查询计时器超时之前没有收到报告查询器就认为该网段下已经没有这个组的成员了停止向该网段发送这个组的组播流量。这里有一个关键点要说清楚离开报文只解决“快速清理”的问题不会立刻把流量斩断。路由器必须做完整的确认过程。所以如果你在设备上配置了IGMPv2并且对特定组启用了快速离开Fast Leave那离开组报文的确认过程会简化但一般不建议在共享网段比如多台主机接在同一台交换机上上乱开快速离开。2.3 报文结构几种报文具体长什么样IGMPv2的报文格式定义在RFC 2236里和v1相比较复杂一点因为多了“最大响应时间”这个字段。IGMPv2有四种报文类型成员关系查询Membership Query分为通用查询General Query和特定组查询Group-Specific Query成员关系报告Membership Report离开组Leave Group报文结构上通用查询、特定查询、报告、离开报文共享同一个基础结构8字节头部外加可选数据。头部包含版本/类型1字节、最大响应时间1字节、校验和2字节、组地址4字节。最大响应时间字段在v2中有了具体含义它决定了主机的延迟发送时间。这个字段的计算规则是如果最大值小于0x80直接填单位0.1秒如果大于等于0x80则按一个浮点编码公式计算。多数实现中默认值是100十进制也就是10秒。组地址字段呢通用查询报文里填0.0.0.0特定组查询报文里填具体的组播组地址报告和离开报文分别填写对应的组播组地址。理解这些结构我推荐的做法是抓包。使用Wireshark抓一下IGMPv2报文比如开着播放器加入一个组播组再看离开时的报文序列比死记字段位置有用得多。接在交换机镜像口抓包时注意交换机上可能有IGMP Snooping干扰见不到预期报文这是常见坑点之一。3. IGMPv2在真实设备上的配置与验证3.1 路由器和交换机上的IGMP基本配置配置IGMPv2之前首先要确认你的三层设备支持组播路由功能并且使能了组播路由协议。在绝大多数主流厂商设备上默认是不开启组播路由的需要手动开启。以常见设备为例基本流程如下先启用组播路由类似multicast routing-enable然后在需要接入组播成员的接口上启用IGMP并把版本指定为2。有些设备默认版本是v2比如启用IGMP时自动选择v2如果你用的是v1或v3就要显式指定。还有一个极其容易被忽略的点路由器上跑组播路由协议比如PIM-SM之前必须先建RPRendezvous Point汇聚点而PIM与IGMP是一体化运作的。IGMP接口启用了之后PIM邻居关系建立不起来IGMP组成员关系就不会生效组播流量不会转发。实际配置时一定要先确认PIM邻居是否建立再看IGMP是否有成员关系。做兼容考虑时不同厂商的表现差异很大。比如有些厂商的设备默认IGMP查询器间隔是60秒有些是125秒最大响应时间有的是10秒有的是20秒。如果做了手工配置一定要在两端确认参数一致性。我见过最典型的故障就是一个网段下同时接了A厂商和B厂商的交换机两个设备都启用了IGMP但A的查询间隔比B短一半导致B的查询器永远抢占不到角色一重启就会产生短暂的成员关系超时业务丢包。3.2 查看请求状态show命令怎么看IGMP排障在命令层面主要看三个东西接口IGMP状态、组成员关系表、以及PIM邻居关系。每个厂商都能通过命令查看但信息组织方式有差别。以主流厂商的脚本为例常用的查看逻辑是先看接口状态——IGMP是否使能、版本是多少、查询器是谁、查询间隔是多少。然后看组成员关系表——每个组播组地址对应在哪些接口上有成员关系成员关系是在哪个时间点建立的。最后看PIM邻居确认下游是否有PIM邻居在负责转发。查组成员关系表的时候要特别关注Expires这个字段。它表示这条成员关系还能保持多久如果它一直在倒计时到期但实际主机还在线那说明主机端IGMP报告周期可能有问题被抑制了或者查询器收到的报告报文没来得及刷新。还有个经验大多数设备上如果你改了IGMP版本或者间隔已经建立的成员关系不会立刻重新建需要等成员关系超时或被手动清理。如果测试时间紧可以用类似reset igmp group all的命令把成员关系清掉让它重新通过查询建立。3.3 三层接口、二层交换机和VLAN下的IGMP注意点纯三层接口上配置IGMP不算复杂真正的坑在二层交换机和VLAN环境里。很多网络拓扑里组播源在核心成员主机接在接入交换机上中间是二层链路。这时候三层设备网关或核心的IGMP配置是第一步但接入交换机还需要配置IGMP SnoopingIGMP侦听才能让组播流量按需转发。IGMP Snooping的原理很简单交换机监听主机和路由器之间交换的IGMP报文学习到哪个接口下有哪个组成员然后在转发组播数据时只往有组成员的接口发。没有IGMP Snooping的交换机就会把所有组播流量当广播洪泛出去组播的优势就没了。配置IGMP Snooping时最容易出问题的点是“查询器”概念。交换机自己不是IGMP查询器只是侦听者所以必须保证VLAN内有一个IGMP查询器。如果你把组播流量直接通过VLAN转发却没有在里面放任何IGMP查询器那么交换机上的IGMP Snooping表项就会很快老化组播流量无法到达主机。解决方案要么是三层设备作为查询器与交换机对接要么在交换机上启用“IGMP Snooping querier”由二层交换机模拟查询器。在纯二层环境里模拟查询器几乎是必备配置。还有一个多VLAN场景如果组播发送方在VLAN 10接收方在VLAN 20中间通过三层路由互通那VLAN 10的接口还是要启用IGMP但真正承担组播转发的接口是在组播源侧或成员侧。注意一个原则IGMP是“主机与路由器”之间的协议只要你想让某个三层接口知道“底下有人要看这个组”就必须在这个接口上启用IGMP并确保查询器存在。4. IGMPv2排障实录常见坑点、抓包技巧和绕坑指南4.1 典型故障一有成员但组播流量不生效这个故障经常出现在接入交换机没有查询器、或IGMP Snooping表项为空的情况。症状是主机能收到单播、能Ping通网关但就是拿不到组播流。排查顺序第一步查三层接口上IGMP是否使能第二步看是否为查询器第三步看组成员关系表里有没有这个组。如果表里有往下看二层——查IGMP Snooping表项看对应接口是否属于成员。如果Snooping表项正常但流量仍不到重点查组播路由表。组播路由表和单播路由表是两张表分别由PIM等组播路由协议维护IGMP只负责接口下的组成员信息。组播流量要能转发必须满足两个条件组播路由表有正确的(*, G)或(S, G)表项并且出接口列表里有成员接口。另一类“看似组播没生效但实际是应用层问题”的情况也要警惕。比如接收端软件自己没发IGMP报告或发送端只把UDP组播流发到了某个特定源IP跟IGMP配置没有关系。先抓包确认IGMP报告报文是否真实存在比折腾设备配置更有用。4.2 典型故障二IGMPv2成员快速离开与重复流量问题主机发离开组报文之后查询器发特定组查询但在一台大二层网络里如果查询器的特定查询响应超时设置得太短比如低于1秒而主机端的报告又要经过交换机转发一旦交换机拥塞或CPU处理不及时报告就可能延期查询器误判成员已经离开。这类问题的直接表现是主机离开组之后的几秒内同一组播组的流量还在网段内持续发送导致其他不该收到的主机也收到流量更极端情况是主机的IGMP重报在特定组查询窗口内没到查询器把成员关系清掉了但主机还在等组播数据流量就断了。解决思路是把查询器的特定组查询间隔调到推荐值不同厂商一般建议1秒实际环境可以调到2秒更稳同时适当增加健壮性变量Robustness Variable来增加查询重试次数。在大二层环境里宁可让离开慢一点也不能让成员关系被误清。4.3 抓包技巧如何正确抓到IGMP的完整交互过程IGMP排障离开不了抓包但有三个坑得提前说清楚。第一交换机上IGMP Snooping会过滤掉一些IGMP报文。如果你在交换机镜像口抓包可能根本看不到主机发出的报告报文因为交换机已经截获了。要看到完整报文最好是SPAN口抓或者直接在主机上先把IGMP Snooping关掉再抓。第二抓到IGMP离开报文不代表查询器会回应。有些设备在收到离开报文后如果没有找到对应的组成员关系就直接丢掉报文不回单一查询。这种场景下你会觉得“抓到了离开报文但无响应”其实很正常。第三主机发报告报文时如果网段里已经有人响应过那么新加入的主机可能被抑制后加入的主机不会立刻发报告。这时候你抓包会看到“成员加入时没有报告报文”。要验证主机能不能收组播直接看主机侧是否收到组播流量更靠谱。抓包时的参考基准正常的主机加入流程应该是主机发IGMP报告目的地址为组播组地址查询器回一个通用查询目的地址224.0.0.1如果中间有IGMPv2的详情按顺序追踪即可。4.4 快速排除IGMPv2与IGMPv3混跑时的兼容性现在不少网络里既有IGMPv2的主机也有IGMPv3的主机。IGMPv3完全向后兼容v2所以v2的主机在v3查询器下通常能正常工作。真正出问题的场景是“查询器是v2、而主机是v3”这种情况下v3主机的源过滤功能会失效——v3的报告报文v2查询器看不懂因此v3主机可能拿不到按源过滤后的组播流。遇到这类情况我的建议是优先把查询器升级到v3模型或者在共享网段中统一版本。有些设备支持“IGMP version 3”的接口下同时接受v2报告但行为差异很大配置前一定要做小范围验证。安全方面多说一句IGMP v2/v3都没有内置认证机制任何人只要在同一广播域里发IGMP报告就能“加入”一个组播组。在企业网环境中这会导致非法组成员接收敏感组播流量。如果有这种风险考量考虑在汇聚层开启组播源过滤功能或者配合ACL允许特定源地址的IGMP报文。5. IGMPv2在真实项目中的一次完整落地笔记最后分享一个实际场景某公司要部署一套基于组播的桌面培训视频系统视频源在中心机房通过三层网络推送到各个办公区终端涉及二十多个VLAN覆盖千余台终端。目标很明确视频不卡顿、不广播泛洪、新终端加入视频组后能在5秒内看到画面。我当时的设计是这样核心交换机启用组播路由启用PIM-SM并建立RP每个业务VLAN的三层接口启用IGMPv2查询间隔调成60秒默认125秒对视频业务太慢了健壮性变量设为3防止偶发丢报告接入交换机全部开启IGMP Snooping并配置查询器模拟。所有视频源和终端均在同一个网段内的用ASM模型。实际配置中遇到的最大的一个坑是某批终端系统默认使用了IGMPv3但这些终端的系统版本对v3报告处理不太标准导致核心交换机看成“未知版本报文”直接丢弃了。于是成员的加入请求失败视频一直不出现。排查过程很痛苦最后吊销终端系统日志才发现它发的IGMPv3报告带了奇怪的源过滤字段。解决办法是把该VLAN的IGMP版本调整为v2也就是不强制让终端发v3报告。结果视频马上就通了。这提醒我当终端生态比较杂的时候先统一IGMPv2是最稳的起点后期再逐步迁移v3。部署完成后我在一个VLAN里手动验证了一下终端加入视频组后核心交换机的组成员关系表几乎即时出现该组接入交换机的Snooping表项也同步生成终端离开播放器后成员关系在几秒内清理完毕不再有视频流量发到该VLAN。整网表现非常稳定。所以我个人的总结是IGMPv2是个老协议但把它的机制吃透后能解决很多看似复杂的组播问题——尤其在大二层、多VLAN、多厂商混排的环境里。如果你正在做组播项目先把IGMPv2的查询器、成员关系、离开机制搞明白再去碰PIM-SM、RP这些上层协议会顺很多。