IGMPv2详细实验手册（一个实验理解IGMPv2的工作机制） by 红茶三杯_CCNP学习资料_思科认证 - 雏鹰部落

tea 发表于 2013-1-20 15:20:06

IGMPv2详细实验手册（一个实验理解IGMPv2的工作机制） by 红茶三杯

一实验拓扑及需求

1.1 实验环境描述

[*]拓扑环境非常简单，如上图所示，PC及Source都使用路由器模拟。
[*]R1、R2运行OSPF协议，全网可达
[*]用于实验的组播组定224.1.1.1，PC为接收者（Receiver）

1.2. 实验目的

[*]了解IGMPv2的基本配置
[*]了解IGMPv2的各项协议参数
[*]了解IGMPv2的工作机制（成员关系查询、成员关系报告、成员离开）

二实验步骤

1.完成所有设备的基本配置（IP、OSPF路由协议）
就不贴这部分配置了，注意OSPF这块，保证全网可达即可，Source和PC可使用默认路由。

2.在R1、R2上完成PIMv2的配置
R1的配置如下：
ip multicast-routing
int fastEthernet 1/0
ip pim dense-mode
int serial 0/0
ip pim dense-mode
R2的配置如下：
ip multicast-routing
int fastEthernet 1/0
ip pim dense-mode
int serial 0/0
ip pim dense-mode
当我们在接口上激活PIMv2协议，那么同时，IGMPv2也将同时激活。

3.查看IGMPv2的运行情况
由于IGMP主要工作在组播路由器及组成员（接收者）之间，因此我们重点关注R2，
通过show ip igmp interface命令，可以看到IGMP协议在本地接口上的运行情况：
R2#show ip igmp interface
FastEthernet1/0 is up, line protocol is up
Internet address is 10.1.1.254/24
IGMP is enabled on interface //激活PIM后，IGMPv2在接口上自动激活
Current IGMP host version is 2
Current IGMP router version is 2 //version2
IGMP query interval is 60 seconds //查询间隔，每隔60S发送一个General Query
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 1000 ms //最后一个组员离开后，发送的特定组查询时间间隔
Inbound IGMP access group is not set
IGMP activity: 1 joins, 0 leaves
Multicast routing is enabled on interface
Multicast TTL threshold is 0
Multicast designated router (DR) is 10.1.1.254 (this system)
IGMP querying router is 10.1.1.254 (this system) //IGMP查询者，本路由器即为此MA网络的查询者
Multicast groups joined by this system (number of users):
   224.0.1.40(1)
Serial0/0 is up, line protocol is up
Internet address is 10.1.12.2/24
IGMP is enabled on interface
Current IGMP host version is 2
Current IGMP router version is 2
IGMP query interval is 60 seconds
IGMP querier timeout is 120 seconds
IGMP max query response time is 10 seconds
Last member query count is 2
Last member query response interval is 1000 ms
Inbound IGMP access group is not set
IGMP activity: 0 joins, 0 leaves
Multicast routing is enabled on interface
Multicast TTL threshold is 0
IGMP querying router is 0.0.0.0 (this system)
No multicast groups joined by this system

从上面的输出，可以看到IGMPv2在接口上的运行参数。

4.查看IGMPv2常规查询General Query
General Query消息是针对所有组播组的查询消息，IGMP查询者每隔query interval（默认60S）发送一次该消息，对网络中的所有组播组的成员存活情况进行查询。收到该消息的接收者需以membership report报文响应，以告知自己的存活。
使用debug ip igmp可以查看到IGMP的运行情况：
*Mar1 00:58:50.887: IGMP(0): Send v2 general Query on FastEthernet1/0
*Mar1 00:59:50.887: IGMP(0): Send v2 general Query on FastEthernet1/0
我们可以通过ip igmp query-interval这个接口级的命令来修改查询消息的发送周期。
以下是我们抓取到的General Query报文，可以看到该消息发向224.0.0.1（所有主机）组播地址。

并且当一个Query消息为General Query（通用组查询）时，报文中的Multicast Addr字段为0.0.0.0。

5.主机加入
接下去我们让Receiver1加入组播组224.1.1.1，配置如下：
ip multicast-routing
interface fa0/0
ip igmp join-group 224.1.1.1
此时我们分别在R2及Receiver上开启debug ip igmp

Receiver1上的关键输出如下：
*Mar1 03:39:42.847: IGMP(0): WAVL ** group: 224.1.1.1 interface: FastEthernet0/0Successful
*Mar1 03:39:42.851: IGMP(0): Send v2 Report for 224.1.1.1 on FastEthernet0/0
*Mar1 03:39:42.851: IGMP(0): MRT Add/** FastEthernet0/0 for (*,224.1.1.1) by 4
可以看到，R1主动发起一个IGMPv2 membership report，请求加入224.1.1.1组播组

R2上的关键输出如下：
*Mar1 03:39:45.427: IGMP(0): Received v2 Report on FastEthernet1/0 from 10.1.1.1 for 224.1.1.1
*Mar1 03:39:45.427: IGMP(0): Received Group record for group 224.1.1.1, mode 2 from 10.1.1.1 for 0 sources
*Mar1 03:39:45.431: IGMP(0): WAVL ** group: 224.1.1.1 interface: FastEthernet1/0Successful
*Mar1 03:39:45.431: IGMP(0): Switching to EXCLUDE mode for 224.1.1.1 on FastEthernet1/0
*Mar1 03:39:45.431: IGMP(0): Updating EXCLUDE group timer for 224.1.1.1
*Mar1 03:39:45.431: IGMP(0): MRT Add/** FastEthernet1/0 for (*,224.1.1.1) by 0
R2收到了receiver1的成员关系报告，使用如下命令可以查看到这个报告产生的结果：

R2#show ip igmp groups
IGMP Connected Group Membership
Group Address Interface             Uptime Expires Last Reporter Group Accounted
224.1.1.1    FastEthernet1/0       00:03:4100:02:23 10.1.1.1
224.0.1.40    FastEthernet1/0       03:12:5000:02:2210.1.1.254
那么receiver1就正式加入组播组224.1.1.1了，开始等待来自源的组播数据。

接下去R2会仍会周期性发送通用组查询消息：
R2上的debug信息：
*Mar1 03:40:44.111: IGMP(0): Send v2 general Query on FastEthernet1/0
*Mar1 03:40:48.411: IGMP(0): Received v2 Report on FastEthernet1/0 from 10.1.1.1 for 224.1.1.1
*Mar1 03:41:44.111: IGMP(0): Send v2 general Query on FastEthernet1/0
*Mar1 03:41:52.427: IGMP(0): Received v2 Report on FastEthernet1/0 from 10.1.1.1 for 224.1.1.1
而receiver1每次收到R2发送的这个通用组查询后，需使用IGMP成员关系报告报文进行响应
*Mar1 03:47:41.551: IGMP(0): Received v2 Query on FastEthernet0/0 from 10.1.1.254
*Mar1 03:47:41.551: IGMP(0): Set report delay time to 9.2 seconds for 224.1.1.1 on FastEthernet0/0
*Mar1 03:47:50.855: IGMP(0): Send v2 Report for 224.1.1.1 on FastEthernet0/0

注意，R2发送的通用组查询消息中，含有一个Timer：max query response time（默认10S），这是一个在IGMPv2中被引入的计时器，收到该查询包的主机，会在该计时器指定的时间内响应组成员关系报告。
当然，如果我们这么假设，如果该MA网络中，有大量的组播用户，这些主机收到通用组查询包后，一齐发送成员关系报告，那么网络中将充斥着大量的IGMP消息，实际上，对于每个组而言，IGMP查询者（在这里就是R2），只需要知晓有一个存活的组成员即可，因此每个收到通用组查询包的主机，会在一定的延迟（report delay time，随机值，在上面的debug信息中能看到）后才发送成员关系报告，注意这个延迟时间不能超过查询包里的那个timer的值（上面描述的max query response time）。另一方面，当某个组成员收到本地网络中，同一个组的、其他成员发出来的成员关系报告，那么它将不再发送成员关系报告（抑制了，因为没有必要发了）。
要观察IGMP成员报告抑制的现象，我们可以开启receiver2，并使其也加入组播组224.1.1.1。
接下去有意思的现象发生了，224.1.1.1组里，有了两个成员，当R2（IGMP查询者）发送通用组播组查询的时候，receiver1及2都会收到查询消息，查询包中包含一个最大响应时间（默认10S），那么receiver1及2都会在本地启动一个比最大响应时间小的延迟计时器（随机值），当这个计时器倒计时到0，它将发送一个成员关系报告以响应这个查询包，那么后发送的接收者，会收到前者发送的那个成员关系报告，它就知道，网络中还有跟自己一样的同组的组员，既然他发了成员关系报告，我就不发了，于是从debug信息中：
*Mar1 03:59:41.583: IGMP(0): Received v2 Query on FastEthernet0/0 from 10.1.1.254
*Mar1 03:59:41.583: IGMP(0): Set report delay time to 3.8 seconds for 224.1.1.1 on FastEthernet0/0
Receiver1#
*Mar1 03:59:42.855: IGMP(0): Received v2 Report on FastEthernet0/0 from 10.1.1.2 for 224.1.1.1
*Mar1 03:59:42.855: IGMP(0): Received Group record for group 224.1.1.1, mode 2 from 10.1.1.2 for 0 sources
*Mar1 03:59:42.859: IGMP(0): Cancel report for 224.1.1.1 on FastEthernet0/0

6.IGMPv2离开机制
到目前为止，网络维持一定的稳态，R2将不断的发送通用组查询消息，receiver1或2将对这个消息进行响应，在R2上可以看到有关表项：
R2#show ip igmp groups
IGMP Connected Group Membership
Group Address Interface             Uptime Expires Last Reporter Group Accounted
224.1.1.1    FastEthernet1/0       00:04:0200:02:5610.1.1.1
224.0.1.40    FastEthernet1/0       03:44:3200:02:5610.1.1.254
注意，在R2维护的上述表项中，有个Last Report列，这里就是响应我发送的这个查询包的成员，
现在，我们让10.1.1.2也就是receiver2离开组，那么在receiver2上，只有简单的：
*Mar1 04:15:11.802: IGMP(0): IGMP delete group 224.1.1.1 on FastEthernet0/0

注意，receiver2并没有发送IGMP leave消息，因为他知道，自己并不是224.1.1.1组的最后一个成员，
那么现在，我们让receiver1也离开组
*Mar1 04:17:10.146: IGMP(0): IGMP delete group 224.1.1.1 on FastEthernet0/0
*Mar1 04:17:10.150: IGMP(0): Send Leave for 224.1.1.1 on FastEthernet0/0
由于receiver1已经是组224.1.1.1的最后一个成员了，因此它发出了IGMP leave消息，

而当R2收到这个消息后，R2的动作是：
*Mar1 04:17:12.702: IGMP(0): Received Leave from 10.1.1.1 (FastEthernet1/0) for 224.1.1.1
*Mar1 04:17:12.706: IGMP(0): Lower expiration timer to 2000 msec for 224.1.1.1 on FastEthernet1/0
*Mar1 04:17:12.706: IGMP(0): Send v2 Query on FastEthernet1/0 for group 224.1.1.1
*Mar1 04:17:13.710: IGMP(0): Send v2 Query on FastEthernet1/0 for group 224.1.1.1
*Mar1 04:17:14.710: IGMP(0): Switching to INCLUDE mode for 224.1.1.1 on FastEthernet1/0
*Mar1 04:17:14.710: IGMP(0): MRT delete FastEthernet1/0 for (*,224.1.1.1) by 0
我们看到，R2“一口气”发了两个特定组查询消息（Group-Specific Query），视图通过这种方式确认224.1.1.1组中是否真的没有组员了。这里包含了两个参数：1是时间间隔，2是发送包的个数。当IGMP查询器收到某个组最后一个组员的离组消息后，它将间隔Last member query response interval（默认1S），去发送Last member query count（默认2）个特定组查询。

三知识回顾

红茶三杯（朱SIR）
网络工程 | 项目管理 | IT服务管理 | CCIE培训
沉淀提升成长分享
微博：http://weibo.com/vinsoney
博客：http://blog.sina.com.cn/vinsoney
站点：http://ccietea.com

Roye2012 发表于 2013-1-21 08:31:11

沙发~
先顶再看~
耿叔还是一样威武~

王晓强 发表于 2013-1-21 08:53:42

组播是RS方向的一个难点，理解上有一定的难度，耿叔分析得很细致！
给力耿叔！

victor_huang 发表于 2013-1-21 13:26:30

来一点分析二层组播工作原理的。

bookpig 发表于 2013-1-21 13:45:44

耿子，在我每次需要素材的时候你总是及时的出现啊。。--

jkrh9 发表于 2013-1-21 14:49:46

--给力啊，配置都给了，实验还没做过，有时间做个实验自己来验证一下

寂寞如狗屎 发表于 2013-1-22 15:07:42

耿叔的资料值得收藏

页: [1]

雏鹰部落's Archiver

IGMPv2详细实验手册（一个实验理解IGMPv2的工作机制） by 红茶三杯