multicast-2 IGMP协议
IGMP协议V2
互联网组管理协议
PS:这个不是路由协议，就是一个普通的协议，并不构建路由表
只是运行在末跳路由器和终端（组成员）之间用于管理的协议
主要作用
1 组成员利用IGMP协议向最末跳路由器报告一个组的加入或离开，
2 叶路由器利用IGMP协议维护所有组成员的信息，用于判断需要转发哪些组的数据
3 IGMP一个有三个版本，V1,V2,V3，在路由器上默认开启的是V2
4 IGMP被封装在IP包头后，协议号为2 ，并且IP包头中TTL=1（这也将这个包完完全全的限制在了一个广播域中）
通过一个小实验来更好的理解IGMP协议吧
实例
在leaf router上进行抓包测试，看看下面的设备都发送了哪些请求
IGMP消息
1 HOST发送的
2 路由器发送的
而每种下面又分为两种
Host : report(报告加入) leave（离开）
当R2上开启ip igmp join-group 224.1.1.1 //这里的224.1.1.1只是随手输入的，别当真
R2(config)#inter f0/0 //进入接口下
R2(config-if)#ip igmp join-group 224.1.1.1 //输入想要加入的组， 换句话说，就是我想要接收这个组的数据，
report
通过抓包可以看到，
Source : 192.168.1.2 原是自己没有问题
Destination: 224.1.1.1 想要加入到这个组，肯定发往这个组播地址,只不过就是现在没有人回复，
当然，report 消息产生的原因有两种
第一种就是咱们上面说的，我想要加入到一个组内，会发送report 时间间隔为10s,发送一次/两次,为什么发两次，是为了确保组播路由器可以接收到，此时不考虑suppress 的问题
Suppress 抑制，什么意思？
就是我一个组里有多个成员，当收到路由器发来query 查询时，做为组内成员需要回复，而这时，不是所有的成员都需要回复，只要有一台就可以了。这就叫抑制， 显然这是我成员自发的，路由器要一一辨识，肯定不能被抑制喽~
第二种就是Leaf router 发送出来的query 查询，当我收到之后就会马上回复，
这个时候就要考虑supress了，具体为什么，看上面几行就明白了。
leave
假设现在将R2上的加组取消，会在leaf-router 上看到什么呢？
Source: 192.168.1.2
Destination: 224.0.0.2 ？？ 为什么是这个?
其实很好理解
224.0.0.2 代表着所有广播域内的路由器，为什么不直接发送给192.168.1.1 呢？
那么请问如果此时有两个leaf呢？怎么办？
所以最简单的方法还是这个，使用224.0.0.2
Router:
general(通用查询) : 同期性的检测组成员的存在
specific (指定组查询) :
general query
R1(config)#ip multicast-routing //全局开启组播功能
R1(config-if)#ip pim dense-mode //接口下开启 协议无关组播(这个放在后面讲)
当路由器配置这个命令之后，就意味着开启了组播功能，
此时，路由器就会向外发送通用查询，60S/次
通过wireshark 可以很清楚的看到，两次的query 查询时间间隔
PS:这时你会发现一个问题，由路由器发出的query general 消息发送到的是224.0.0.1,是本广播域内的所有设备，那么这里如果有路由器要不要接收？为什么？
因为要考虑另外一种情况，就是主备leaf设备
Master 和backup 都是leaf router， 如果说Master 宕机，肯定会由backup 来接管，
但做为backup 设备如何知道master设备死了呢？
就是通过query general 消息,如果我120s 没有收到这个查询，那么我就认为你死了，我来当主。
那么又有一个问题
这两个设备是如何决定谁是master呢？
这取决于二者的Ip,谁的小，谁就是master
Mater 也被称为查询者。而二者谁是查询者，就由谁发来送查询消息。
Specific 指定组查询
只有当组内成员离开时才会出发这一消息
退出就退出吧，为什么路由器还要发送这个消息呢？
因为此时做为leaf路由器要检测一下还有没有其它成员需要接收这个组的数据，如果没有，那么将不再转发该组数据，如果有的话，就必须有人回复，
并且这个回复也有时间限制，1S必须回复，如果没有回复，那么就认为该组内没有成员了
路由器还可以通过一条命令来查询现在本地所转发的组
Show ip igmp groups
我的F0/0口下，存在着具体的表项，uptime,存活时间，expries 超时，
这东西如果你发送了query ，下面有回复report消息，那肯定不会超时。
Last reporter 回复者，这个就不一定了，组内谁都可以回复
确保接口开启了组播功能
随后就可以在wireshark 中看到相关的查询消息，
并且可以看到相应的时间,
每次间隔60S
和HOST发出的消息不同，由ROUTER发出来的通用查询，必须是有回复的
可以看到由R1发送出来的query general ，R2收到之后马上给予回复，
通俗点儿讲，就是
路由器问：同志们，有没有谁在某一个组里呀？ （发送到224.0.0.1）
PC2: 我，我，我， im here 我连接着224.1.1.1 (发送到224.1.1.1)
(这里由ROUTER发出的查询，是所有组成员都要回复吗？不是，只要有一台回复就OK 了，)
这里有一个注意，就是发送的224.0.0.1,按理说如果此时出于冗余考虑，存在两台leaf router
那么另外一台路由器是不是也收到了这个查询呢？
是的，没错，
在这里，其意义就是备份的设备等于原有主设备down掉之后自行上位.
修改相应时间等参数
1 修改版本
Ip igmp version
2 修改查询频率
Ip igmp query-interval [seconds]
时间范围是1-1800 单位是S
3 查询者超时时间，（就是backup检测的时间）
Ip igmp querier-timeout [seconds]
时间为60-300 S
4 query 查询的响应时间,默认为10S
修改的时间范围是1-25S
5 specific 的最大响应时间，默认为1S 也就是1000MS
这里的时间MS,
6 specific query的查询次数
默认是1或2次，可以修改的范围是1-7次.
IGMP协议V1
这个基本上不用了，
和V2对比
1：一个是主机发送的report消息
该消息和V2中的完全一样
在这里和v2版本中不同的是，V1没有最大响应时间
2：一个是路由器发送的query general消息
这也就意味着，将没有离组消息和指定组查询消息，
路由器可以是V2,主机可以是V1，
但是如果反过来就不行了~
在V1中Query 消息中没有最大响应时间的
那么做为V1，没有离组消息，如何来确认下方有没有组成员呢？
只能等，3次的query 查询时间 180S时间
另外，在V2中有查询者的概念，（双路由器的情况）
而在V1中不存在查询者的概念， 只是使用DR来进行充当
而DR的选举是地址越大越优~，
正好和V2版本的查询者选举正好相反。
PS: 这个DR本来和IGMP没有毛关系 是PIM协议所产生的，
由于V1中没有查询者，但是如果又路由器又要决定由一个设备来发送查询消息，那么这个时候就用到了PIM的DR来充当 ，就这么个事儿
IGMP协议v3
主要是用在SSM上，指定源组播
只接收指定的源发往哪一个组播地址的流量
而V1和V2中是没有办法做到这一点的，
只能确定我接收哪一个组的流量，
并不知道这个流量真正的源是谁
R3(config-if)#ip igmp version 3
R3(config-if)#ip igmp join-group 239.1.1.1 source 1.1.1.1
有几点需要注意
1 虽然我想要加入的组是239.1.1.1 但是我向外发送的组播目标地址是224.0.0.22
这个地址是VERSION 3 特有的地址，
2 相比V1和V2 发送出来的report消息中，包含了源，
Multicast address:239.1.1.1
Source address:1.1.1.1
只接收来自于239.1.1.1这个组播地址的源1.1.1.1 的数据
路由器改成VERSION 3 之后
先会发送一个到224.0.0.1的通用查询包，要求时间是2.5S
而此时做为成员，就会给予回复，
有查询有回复，
那么就在leaf router上建立了表项
由主机发送离组消息，block source 阻止这个源
随后，leaf router 会发送指定组查询
离组后，条目也会被删除,(因为我发送了两次指定组查询，有没有谁还想要由1.1.1.1发往239.1.1.1的流量？)两次都没有人回复我，那么我就会把这个条目删除掉
上面显示的stopped 是代表倒计时停止，
因为下面的组成员，所以不再倒计时.
IGMP V3消息
1 服务于特殊的模型SSM
2 允许组成只接收指定的组源源到组的流量
3 成员可以在单个消息中添加多个组的请求，
4 对于host 和router 的消息格式做了修改，添加了source
5 取消了report suppress （抑制）每个组成员都独立报告 ,因为加了源
6 igmp v3模拟组成员的命令是 ip igmp join-group x.x.x.x source x.x.x.x
组播地址 源地址
---------------------------------------------------
CCIE成长之路 --- 梅利
