IGMP使用详解.doc

IGMP
一、 Internet 组管理协议
IGMP 是Internet 组管理协议(Internet Group Management Protocol)的缩写。IGMP 在
TCP/IP 协议中的位置:
应用层协议（FTP,HTTP,SMTP）
TCP UDP ICMP IGMP
IP
ARP RARP
MAC
PHY
在了解 IGMP 协议的之前，我们首先看看以太网对报文的处理方法。我们知道，目前使
用的以太网（ethernet）有一个特点，当一个报文在一条线路上传输时，该线路上的所有主
机都能够接收到这个报文。只是当报文到达MAC 层时，主机会检测这个报文是不是发送给
自己的，如果不是该报文就会被丢弃。常用的抓包软件ethereal, sniffer 都可以捕获当前物理
线路上的所有报文，不管该报文的目的地址是不是自己。以太网中有一种特殊的报文广播包
其目的mac 地址全为0xff，所有的主机都必须接收。
说到 IGMP 不能不提“组播”的概念。假如现在一个主机想将一个数据包发给网络上的
若干主机，有什么方法可以做到呢？一个方法是采用广播包发送，这样网络上的所有主机都
能够接收到，另一种方式是将数据包复制若干份分别发给目的主机。这两个方法都存在问题：
方法一，广播的方法导致网络上所有的主机都能接收到，占用了网络上其他主机的资源。方
法二，由于所有目的主机接收的报文都是相同的，采用单播方式显然效率很低。为了解决上
面所述的问题，人们提出了“组播”的概念，控制一个报文发送给对该报文感兴趣的主机，
IGMP 就是组播管理协议。
我们来看一个简单的组播应用场景

PC，如何处理呢？首先STB 要发起一个连接请求，也就是IGMP report 报文，加入到电视直播的组播组中。同样当STB 要断开连接的时候就发送一个IGMP leave 报文。Router 也需要知道当前有哪些STB 加入了组播组，防止有的STB 异常掉线了，却依然占用系统资源。Router 周期性的发送IGMP query 报文查询组播组情况，STB 接到query 报文后发送report消息到router。当然还有一种报文就是IGMP data，用来传输组播数据。这基本上就是IGMP协议的基本流程了。
二、 组播实现
1. IP 组播组与组播MAC
二层组播MAC 定义为：01:00:5e:xx:xx:xx，其中xx 由三层的IP 组播组确定。三层地址：
组播流使用的IP 是D 类IP 地址（二进制1110 开始），从224.0.0.0～239.255.255.255。由于
组播MAC 地址是一个虚拟的地址，并不是真实网卡的MAC 地址，那么网卡在发送报文是
二层MAC 地址怎么确定呢？答案是采用地址映射的方法将三层IP 地址映射到MAC 地址。
映射关系如下。

从上面的映射关系可以看出 IP 地址的五个bit 无法映射到MAC 层，因为MAC 层的这五个
bit 已经确定。也就是说有32 个IP 组播组会被映射为同一个MAC 地址。
（在这里不能不说一个面试常问的问题：一个网卡的 MAC 地址是53:10:10:10:10:10，
问这是一个合法的MAC 地址吗？原因？）
2. 报文格式：

IGMP 报文封装在IP 层上，在IP 层的协议类型码是0x02。IGMPv2 有report, query 和
leave 有三种类型的报文，
IGMP report：type 为0x16(IGMPv2)或0x12(IGMPv1)
IGMP leave：type 为0x17
IGMP query：type 为0x11，query 报文有两种情况，一种是针对特定组播组的查询，例
如router 要查询属于组播组225.225.100.3 的所有成员，另一种是通用查询，查询所有主机
加入组播组的情况，两者的主要区别是在Group Address 上。
IGMP data：与通常的报文相同，主要区别是MAC 地址使用的是组播MAC。
三、 IGMP 协议的应用问题
1. IGMP snooping
首先我们来看这样一种情况，交换机的A 端口(port)有一个组播包需要送到主机D。通
常交换机会将这个报文flood 到每一个端口，确保报文能够送到主机D。但这样处理存在问
题，主机D 挂在port C 上，switch 没有必要将报文发往每一个端口，占用其他端口的网络
资源，同时也占用CPU 的资源。Linux 源码中也没有对组播报文进行特殊处理，
linux-2.4.33\net\bridge\br_input.c 行79 br_handle_frame_finish()
if (dest[0] & 1) {
br_flood_forward(br, skb, !passedup);/*flood 报文到其他端口*/
if (!passedup)
br_pass_frame_up(br, skb);/*向local IP stack 发送数据*/
goto out;
}

针对上面所说的问题，人们提出了IGMP snooping 技术，该技术的主要思想是侦听每一
个端口上的IGMP 报文，通过解析报文获得其组播地址，将组播地址与交换机的端口联系起
来。当关系建立后，就可以通过组播组查到目的port，从而不需要flood 报文到每一个端口
上。
交换机的桥模块维护这样一张表，以组播组为索引，组播组下记录了属于该组播组的所
有端口。当一个组播报文从A 口送到交换机时，交换机从报文中获取组播组地址，然后从
表中找出该组播组，将报文直接发送到下属的C 端口。而E，F，H 端口不会有数据送到。

组播索引表采用这样的管理，桥接收到一个 IGMP report 报文解析report 报文中的组播
组，创建组播索引，将report 报文的端口记录下来。当然当组播组已经存在了就不需要重新
创建组播索引了，只需要检查端口确认是否要添加端口。当桥收到一个IGMP leave 报文时，
根据报文中的组播地址和报文端口从表中找到要离开的端口，删除端口。
是不是经过这样处理就没有问题了呢？答案是否定的。假如交换机的 C 端口连接的不
是主机而是一个HUB，HUB 下挂了两台主机，并且两台主机都加入了同一个组播组，也就
是说C 端口下有两台主机，当其中一台主机发送IGMP leave 后，会导致C 端口被删除，结
果另一台主机也无法接收到组播数据了。
基于端口的组播报文转发是有问题的，一个解决方法是基于MAC 的组播转发，组播组
下面记录的不是port 而是MAC。当组播组有报文时需要处理时，首先查找MAC，然后从
桥中根据MAC 找到port，最后将报文转发到该port。
其实许多支持 IGMP snooping 的交换机中组播组n 的最大值是确定的，一般是256，我
们可以让一台主机加入到256 个组播组中，把所有的组播组资源占尽，后续的其他主机的组
播报文将无法得到处理。这也算是一种攻击吧。
2. IGMP proxy
简单一句话：设备的上行端口担任主机的角色发送report 和leave 报文，下行端口执行
路由器的角色发送query 报文。
3. IGMP report/leave 报文