爱华网1.实验拓扑及需求
拓扑环境非常简单，如上图所示，两台PC与路由器R1、R2连接在同一个LAN中；用于实验的组播组定224.1.1.1，PC为接收者（Receiver），使用Cisco Router模拟。
2.实验目的了解IGMPv2的基本配置了解IGMPv2的各项协议参数了解IGMPv2的工作机制（成员关系查询、成员关系报告、成员离开）
3.实验步骤及配置
1）完成所有设备的接口IP地址配置
2）在R1、R2上完成PIMv2的配置
R1的配置如下：ip multicast-routinginterface fastEthernet 0/0 ip pim dense-mode ip igmp version 2 (默认就是IGMP version2)R2的配置如下：ip multicast-routingint fastEthernet 0/0 ip pim dense-mode
当我们在接口上激活PIM协议，那么同时，IGMP也将被激活，而且默认激活IGMP的版本2
3）查看IGMPv2的运行情况
通过show ip igmp interface命令，可以看到IGMP协议在本地接口上的运行情况：R1#show ip igmp interface fastEthernet 0/0FastEthernet0/0 is up, line protocol is up Internet address is10.1.1.253/24 IGMP is enabled on interface //激活PIM后，IGMPv2在接口上自动激活 Current IGMP host version is 2 Current IGMP router version is 2 IGMP query interval is 60 seconds //查询间隔，每隔60S发送一个GeneralQuery IGMP querier timeout is 120 seconds //查询器超时时间，120S IGMP max query response time is 10 seconds //收到这个查询包的组成员响应该查询的最大时间 Last member query count is 2 //最后一个组员离开后，发送的特定组查询包个数 Last member query response interval is 1000ms //最后一个组员离开后，发送的特定组查询时间间隔 Inbound IGMP access group is not set IGMP activity: 1 joins, 0 leaves Multicast routing is enabled oninterface Multicast TTL threshold is 0 Multicast designated router (DR) is10.1.1.254 IGMP querying router is 10.1.1.253 (thissystem) //IGMP查询者，本路由器即为此MA网络的IGMP查询者 Multicast groups joined by this system(number of users): 224.0.1.40(1)
从上面的输出，可以看到IGMPv2在接口上的运行参数。
4）查看IGMPv2常规查询General Query
General Query消息是针对所有组播组的查询消息，IGMP查询者每隔queryinterval（默认60S）发送一次该消息，对网络中的所有组播组的成员存活情况进行查询。收到该消息的组播组接收者需以membershipreport报文响应，以告知自己的存在。
在R1上使用debug ip igmp可以查看到IGMP的运行情况：*Mar 1 00:49:04.463: IGMP(0): Send v2general Query on FastEthernet0/0*Mar 1 00:50:04.475: IGMP(0): Send v2general Query on FastEthernet0/0*Mar 1 00:51:04.475: IGMP(0): Send v2general Query on FastEthernet0/0我们可以通过ip igmp query-interval这个接口级的命令来修改查询消息的发送周期。以下是我们抓取到的General Query报文，可以看到该消息发向224.0.0.1（所有主机）组播地址。
并且当一个Query消息为General Query（通用组查询）时，报文中的MulticastAddr字段为0.0.0.0。值得注意的是，只有IGMPv2查询器R1才会发送general Query消息。
5）主机加入
接下去我们让Receiver1加入组播组224.1.1.1，配置如下：ip multicast-routinginterface fa0/0 ip igmp join-group 224.1.1.1
此时我们分别在R1及Receiver上开启debug ip igmp
Receiver1上的debug输出如下：*Mar 1 00:51:29.995: IGMP(0): Send v2 Reportfor 224.1.1.1 on FastEthernet0/0
可以看到，Receiver1主动发起一个IGMPv2 membershipreport，请求加入224.1.1.1组播组，这个数据包的目的地址是224.1.1.1。
R1上的debug输出如下：*Mar 1 00:51:32.815:IGMP(0): Received v2 Report on FastEthernet0/0 from 10.1.1.1 for224.1.1.1*Mar 1 00:51:32.819: IGMP(0): Received Grouprecord for group 224.1.1.1, mode 2 from 10.1.1.1 for 0sources*Mar 1 00:51:32.819: IGMP(0): WAVL Insert group: 224.1.1.1 interface: FastEthernet0/0Successful*Mar 1 00:51:32.819: IGMP(0): Switching toEXCLUDE mode for 224.1.1.1 on FastEthernet0/0*Mar 1 00:51:32.823: IGMP(0): UpdatingEXCLUDE group timer for 224.1.1.1*Mar 1 00:51:32.823: IGMP(0): MRT Add/UpdateFastEthernet0/0 for (*,224.1.1.1) by 0R1收到了receiver1的成员关系报告，使用如下命令可以查看到这个报告产生的结果：R1#show ip igmp groupsIGMP Connected Group MembershipGroup Address Interface Uptime Expires Last Reporter GroupAccounted224.1.1.1 FastEthernet0/000:01:18 00:02:2210.1.1.1 224.0.1.40 FastEthernet0/0 00:05:1200:02:2010.1.1.253那么receiver1就正式加入组播组224.1.1.1了，开始等待来自源的组播数据。
6）接收者响应常规组查询消息接下去R1仍会继续周期性发送通用组查询消息：R1上的debug信息：*Mar 1 00:53:04.507: IGMP(0): Send v2general Query on FastEthernet0/0*Mar 1 00:54:04.535: IGMP(0): Send v2general Query on FastEthernet0/0而receiver1每次收到R2发送的这个通用组查询后，需使用IGMP成员关系报告报文进行响应，以下便是receiver1的debug输出：*Mar 1 00:53:01.739: IGMP(0): Received v2Query on FastEthernet0/0 from 10.1.1.253*Mar 1 00:53:01.739: IGMP(0): Set reportdelay time to 8.8 seconds for 224.1.1.1 on FastEthernet0/0*Mar 1 00:53:10.943: IGMP(0): Send v2 Reportfor 224.1.1.1 on FastEthernet0/0注意，R1发送的通用组查询消息中，含有一个Timer：max query responsetime（默认10S），这是一个在IGMPv2中被引入的计时器，收到该查询包的主机，会在该计时器指定的时间内响应组成员关系报告。当然，我们这么假设，如果该MA网络中，有大量的组播用户，这些主机收到通用组查询包后，一齐发送成员关系报告，那么网络中将充斥着大量的IGMP消息，实际上，对于每个组而言，IGMP查询者（在这里就是R1），只需要知晓有一个存活的组成员即可，因此每个收到通用组查询包的主机，会在一定的延迟（reportdelaytime，随机值，在上面的debug信息中能看到）后才发送成员关系报告，注意这个延迟时间不能超过查询包里的那个timer的值（上面描述的maxquery responsetime）。另一方面，当某个组成员收到本地网络中、同一个组的其他成员发出来的成员关系报告，那么它将不再发送成员关系报告（抑制了，因为没有必要发了）。
7）组成员关系报告的抑制
要观察IGMP成员报告抑制的现象，我们可以开启receiver2，并使其也加入组播组224.1.1.1。接下去有意思的现象发生了，224.1.1.1组里，有了两个成员，当R1（IGMP查询者）发送通用组播组查询的时候，receiver1及2都会收到查询消息，查询包中包含一个最大响应时间（默认10S），那么receiver1及2都会在本地启动一个比最大响应时间小的延迟计时器（随机值），当这个计时器倒计时到0，它将发送一个成员关系报告以响应这个查询包，那么后发送的接收者，会收到前者发送的那个成员关系报告，它就知道，网络中还有跟自己一样的同组的组员，既然他发了成员关系报告，我就不发了，于是从接收者2的debug信息中：*Mar 1 00:59:00.459: IGMP(0): Received v2Query on FastEthernet0/0 from 10.1.1.253*Mar 1 00:59:00.463: IGMP(0): Set reportdelay time to 9.0 seconds for 224.1.1.1 on FastEthernet0/0*Mar 1 00:59:02.551: IGMP(0): Received v2Report on FastEthernet0/0 from 10.1.1.1 for 224.1.1.1*Mar 1 00:59:02.551: IGMP(0): Received Grouprecord for group 224.1.1.1, mode 2 from 10.1.1.1 for 0sources*Mar 1 00:59:02.551:IGMP(0): Cancel report for 224.1.1.1 onFastEthernet0/0我们看到，接收者2的report delaytime还没倒计时到0，它就收到了接收者1发出来的成员关系报告，因此它就抑制掉自己的组成员关系报告。
8）IGMPv2离开机制到目前为止，网络维持一定的稳态，R1将不断的发送通用组查询消息，receiver1或2将对这个消息进行响应，在R1上可以看到有关表项：R1#show ip igmp groups 224.1.1.1 detailFlags: L - Local, U - User, SG - Static Group, VG - VirtualGroup, SS - Static Source, VS - Virtual Source, Ac - Group accounted towards access controllimitInterface: FastEthernet0/0Group: 224.1.1.1Flags:Uptime: 00:09:16Group mode: EXCLUDE(Expires: 00:02:16)Last reporter: 10.1.1.1Source list is empty
现在，我们让10.1.1.2也就是receiver2离开组，只要no ip igmp join-group224.1.1.1即可。*Mar 1 01:02:41.203: IGMP(0): IGMP deletegroup 224.1.1.1 on FastEthernet0/0*Mar 1 01:02:41.203: IGMP(0): Send Leave for224.1.1.1 on FastEthernet0/0
再来看看，R1收到这个leave消息的话，会做些什么：*Mar 1 01:02:45.371: IGMP(0): Received Leavefrom 10.1.1.2 (FastEthernet0/0) for 224.1.1.1*Mar 1 01:02:45.375: IGMP(0): Received Grouprecord for group 224.1.1.1, mode 3 from 10.1.1.2 for 0sources*Mar 1 01:02:45.375: IGMP(0): Lowerexpiration timer to 2000 msec for 224.1.1.1 onFastEthernet0/0*Mar 1 01:02:45.375:IGMP(0): Send v2 Query on FastEthernet0/0 for group224.1.1.1*Mar 1 01:02:46.379:IGMP(0): Send v2 Query on FastEthernet0/0 for group224.1.1.1*Mar 1 01:02:46.755: IGMP(0): Received v2Report on FastEthernet0/0 from 10.1.1.1 for 224.1.1.1*Mar 1 01:02:46.755: IGMP(0): Received Grouprecord for group 224.1.1.1, mode 2 from 10.1.1.1 for 0sources*Mar 1 01:02:46.759: IGMP(0): UpdatingEXCLUDE group timer for 224.1.1.1*Mar 1 01:02:46.759: IGMP(0): MRT Add/UpdateFastEthernet0/0 for (*,224.1.1.1) by 0
我们看到，R1收到leave消息后，将组播组224.1.1.1的超时时间设置为2000msec，并且“一口气”发了两个特定组查询消息（Group-SpecificQuery），试图通过这种方式确认224.1.1.1组中是否有其他组员了。这里包含了两个参数：Last member query responseinterval，默认值为1sLast member querycount，默认值为2个上面两个参数的意思是，当IGMP查询器收到leave消息时，查询器将在“Last member query responseinterval”时间内，发送“Last member query count”个特定组查询消息。
Receiver1收到了这个特定组查询，回复了一个成员报告以便通告自己的存在。R1就知道，组224.1.1.1里仍有组成员存在。
现在我们让Receiver1也离开组播组，接收者1会立即发送离组消息，看看R1上会发生什么：*Mar 1 01:06:44.911: IGMP(0): Received Leavefrom 10.1.1.1 (FastEthernet0/0) for 224.1.1.1*Mar 1 01:06:44.911: IGMP(0): Received Grouprecord for group 224.1.1.1, mode 3 from 10.1.1.1 for 0sources*Mar 1 01:06:44.911: IGMP(0): Lowerexpiration timer to 2000 msec for 224.1.1.1 onFastEthernet0/0*Mar 1 01:06:44.911: IGMP(0): Send v2 Queryon FastEthernet0/0 for group 224.1.1.1*Mar 1 01:06:45.915: IGMP(0): Send v2 Queryon FastEthernet0/0 for group 224.1.1.1*Mar 1 01:06:46.915: IGMP(0): Switching toINCLUDE mode for 224.1.1.1 on FastEthernet0/0R1收到leave离组消息后，在1s内发送了两个特定组查询消息。这次就再没有组员发送组成员报告了，因此R1将该组播组删除。
红茶三杯（http://weibo.com/vinsoney/）原创文章，作者版权所有，转载请注明出处
红茶三杯
网络工程 | 项目管理 | 技术培训沉淀 提升 成长 分享微博：http://weibo.com/vinsoney博客：http://blog.sina.com.cn/vinsoney站点：http://ccietea.com
