雏鹰部落

 找回密码
 立即注册

QQ登录

只需一步,快速开始

搜索
查看: 1943|回复: 6

[讨论/求助] IGMPv2详细实验手册(一个实验理解IGMPv2的工作机制) by 红茶三杯

[复制链接]
发表于 2013-1-20 15:20:06 | 显示全部楼层 |阅读模式
一 实验拓扑及需求

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的运行情况:
*Mar  1 00:58:50.887: IGMP(0): Send v2 general Query on FastEthernet1/0
*Mar  1 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上的关键输出如下:
*Mar  1 03:39:42.847: IGMP(0): WAVL ** group: 224.1.1.1 interface: FastEthernet0/0Successful
*Mar  1 03:39:42.851: IGMP(0): Send v2 Report for 224.1.1.1 on FastEthernet0/0
*Mar  1 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上的关键输出如下:
*Mar  1 03:39:45.427: IGMP(0): Received v2 Report on FastEthernet1/0 from 10.1.1.1 for 224.1.1.1
*Mar  1 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
*Mar  1 03:39:45.431: IGMP(0): WAVL ** group: 224.1.1.1 interface: FastEthernet1/0Successful
*Mar  1 03:39:45.431: IGMP(0): Switching to EXCLUDE mode for 224.1.1.1 on FastEthernet1/0
*Mar  1 03:39:45.431: IGMP(0): Updating EXCLUDE group timer for 224.1.1.1
*Mar  1 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:41  00:02:23   10.1.1.1        
224.0.1.40       FastEthernet1/0          03:12:50  00:02:22  10.1.1.254  
那么receiver1就正式加入组播组224.1.1.1了,开始等待来自源的组播数据。

接下去R2会仍会周期性发送通用组查询消息:
R2上的debug信息:
*Mar  1 03:40:44.111: IGMP(0): Send v2 general Query on FastEthernet1/0
*Mar  1 03:40:48.411: IGMP(0): Received v2 Report on FastEthernet1/0 from 10.1.1.1 for 224.1.1.1
*Mar  1 03:41:44.111: IGMP(0): Send v2 general Query on FastEthernet1/0
*Mar  1 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成员关系报告报文进行响应
*Mar  1 03:47:41.551: IGMP(0): Received v2 Query on FastEthernet0/0 from 10.1.1.254
*Mar  1 03:47:41.551: IGMP(0): Set report delay time to 9.2 seconds for 224.1.1.1 on FastEthernet0/0
*Mar  1 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信息中:
*Mar  1 03:59:41.583: IGMP(0): Received v2 Query on FastEthernet0/0 from 10.1.1.254
*Mar  1 03:59:41.583: IGMP(0): Set report delay time to 3.8 seconds for 224.1.1.1 on FastEthernet0/0
Receiver1#
*Mar  1 03:59:42.855: IGMP(0): Received v2 Report on FastEthernet0/0 from 10.1.1.2 for 224.1.1.1
*Mar  1 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
*Mar  1 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:02  00:02:56  10.1.1.1        
224.0.1.40       FastEthernet1/0          03:44:32  00:02:56  10.1.1.254         
注意,在R2维护的上述表项中,有个Last Report列,这里就是响应我发送的这个查询包的成员,
现在,我们让10.1.1.2也就是receiver2离开组,那么在receiver2上,只有简单的:
*Mar  1 04:15:11.802: IGMP(0): IGMP delete group 224.1.1.1 on FastEthernet0/0

注意,receiver2并没有发送IGMP leave消息,因为他知道,自己并不是224.1.1.1组的最后一个成员,
那么现在,我们让receiver1也离开组
*Mar  1 04:17:10.146: IGMP(0): IGMP delete group 224.1.1.1 on FastEthernet0/0
*Mar  1 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的动作是:
*Mar  1 04:17:12.702: IGMP(0): Received Leave from 10.1.1.1 (FastEthernet1/0) for 224.1.1.1
*Mar  1 04:17:12.706: IGMP(0): Lower expiration timer to 2000 msec for 224.1.1.1 on FastEthernet1/0
*Mar  1 04:17:12.706: IGMP(0): Send v2 Query on FastEthernet1/0 for group 224.1.1.1
*Mar  1 04:17:13.710: IGMP(0): Send v2 Query on FastEthernet1/0 for group 224.1.1.1
*Mar  1 04:17:14.710: IGMP(0): Switching to INCLUDE mode for 224.1.1.1 on FastEthernet1/0
*Mar  1 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


本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有账号?立即注册

x
发表于 2013-1-21 08:31:11 | 显示全部楼层
沙发~
先顶再看~
耿叔还是一样威武~
发表于 2013-1-21 08:53:42 | 显示全部楼层
组播是RS方向的一个难点,理解上有一定的难度,耿叔分析得很细致!
给力耿叔!
发表于 2013-1-21 13:26:30 | 显示全部楼层
来一点分析二层组播工作原理的。
发表于 2013-1-21 13:45:44 | 显示全部楼层
耿子,在我每次需要素材的时候你总是及时的出现啊。。
发表于 2013-1-21 14:49:46 | 显示全部楼层
给力啊,配置都给了,实验还没做过,有时间做个实验自己来验证一下
发表于 2013-1-22 15:07:42 | 显示全部楼层
耿叔的资料值得收藏
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

QQ|熊猫同学技术论坛|小黑屋| 网络工程师论坛 ( 沪ICP备09076391 )

GMT+8, 2024-3-28 17:59 , Processed in 0.086198 second(s), 22 queries , Gzip On.

快速回复 返回顶部 返回列表