多播源采用了持续发送的方式-网络通信专区

多播源采用了持续发送的方式

作者：www.net130.com 编辑：王炯 2007-06-24 00:00

最近的一个工程中涉及到了多播路由，现场工程师反映了这样一个情况：
Cisco CAT4000处（多播源接到了这台4000上，4000上没有L3模块）的VLAN上能直接捕获到多播数据包（多播源采用了持续发送的方式），但跨过4000和4000直接相连的7609上的相同VLAN里却收不到这些多播信息，为什么会出现这种情况呢？

现在我们用一个实验环境来说明这个问题。网络拓扑图。

id=ImgSpan href="/Fsmanage/RoUpimages/2004818234542.jpg" target=_blank> 按此在新窗口浏览图片

拓扑说明：
MR（Multicasting Router）为多播路由器，其中位于192.168.168.0/24网段中的192.168.168.40为多播源，所使用的软件为Cisco IP/TV，所用到的多播组有两个——224.2.227.223和224.2.227.224。
MR直接和一台2950T-24交换机相连，交换机上接一台PC机，PC机上安装了IP/TV Viewer，为多播接收者。

MR路由器的多播配置部分如下，为简便起见，使用的多播路由协议为PIM dense-mode：

ip multicast-routing

interface FastEthernet0/0
ip address 192.168.168.155 255.255.255.0
ip pim dense-mode

interface FastEthernet0/1
ip address 10.0.0.1 255.255.255.0
ip pim dense-mode
ip igmp join-group 224.2.227.223
ip igmp join-group 224.2.227.224
ip cgmp …………

在F0/1口上配置了ip igmp join-group语句，强制10.0.0.0/24网段直接加入224.2.227.223(224)两个多播组。

========================================================================

在MR路由器上显示F0/0口上的组成员情况：

MR_2611XM#sh ip igmp group f0/0

IGMP Connected Group Membership
Group Address Interface Uptime Expires Last Reporter
224.0.1.24 FastEthernet0/0 00:47:47 00:02:34 192.168.168.9
224.0.1.40 FastEthernet0/0 00:47:49 00:02:40 192.168.168.155
224.2.227.223 FastEthernet0/0 00:47:48 00:02:33 192.168.168.40
224.2.227.224 FastEthernet0/0 00:47:49 00:02:33 192.168.168.40
239.255.255.250 FastEthernet0/0 00:47:48 00:02:33 192.168.168.14
239.255.255.254 FastEthernet0/0 00:47:47 00:02:37 192.168.168.9

因为IP/TV发出的IGMPv2 membership report信息，路由器知道了F0/0口有224.2.227.223(224)两个多播组的组成员存在，由以下debug ip igmp信息可得到验证：

*Mar 1 10:05:22.286: IGMP(0): Received v2 Report on FastEthernet0/0 from 192.168.168.40 for 224.2.227.224
*Mar 1 10:05:22.286: IGMP(0): Received Group record for group 224.2.227.224, mode 2 from 192.168.168.40 for 0

*Mar 1 10:05:29.730: IGMP(0): Received v2 Report on FastEthernet0/0 from 192.168.168.40 for 224.2.227.223
*Mar 1 10:05:29.730: IGMP(0): Received Group record for group 224.2.227.223, mode 2 from 192.168.168.40 for 0

同样，由于F0/1口上ip igmp join-group语句的原因，F0/1口上也存在224.2.227.223(224)两个多播组的组成员：

MR_2611XM#sh ip igmp group f0/1
IGMP Connected Group Membership
Group Address Interface Uptime Expires Last Reporter
224.2.227.223 FastEthernet0/1 00:38:02 00:02:07 10.0.0.1
224.2.227.224 FastEthernet0/1 00:38:00 00:02:09 10.0.0.1
239.255.255.250 FastEthernet0/1 00:09:47 00:02:14 10.0.0.3

==============================================================================

IGMP信息验证完后，再看多播路由的情况：

MR_2611XM#sh ip mroute 224.2.227.223
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel
       Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 224.2.227.223), 00:43:33/stopped, RP 0.0.0.0, flags: DCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/1, Forward/Dense, 00:11:08/00:00:00
FastEthernet0/0, Forward/Dense, 00:43:33/00:00:00

(192.168.168.40, 224.2.227.223), 00:34:29/00:02:59, flags: LT
Incoming interface: FastEthernet0/0, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/1, Forward/Dense, 00:11:08/00:00:00

可以看到(192.168.168.40, 224.2.227.223)这条(S, G)多播路由信息的情况：
它的Incoming interface为F0/0，说明多播信息由F0/0口入；
RPF nbr显示为0.0.0.0，表示没有上一跳多播路由器，这和我们的实际网络拓扑情况是相符的；
Outgoing interface为F0/1，转发模式为Dense模式，多播数据包已由F0/1口负责转发。


MR_2611XM#sh ip mroute 224.2.227.224
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel
       Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 224.2.227.224), 00:44:55/stopped, RP 0.0.0.0, flags: DCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/1, Forward/Dense, 00:12:24/00:00:00
FastEthernet0/0, Forward/Dense, 00:44:55/00:00:00

(192.168.168.40, 224.2.227.224), 00:35:51/00:02:59, flags: LT
Incoming interface: FastEthernet0/0, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/1, Forward/Dense, 00:12:24/00:00:00

同样(192.168.168.40, 224.2.227.224)的(S, G)多播路由信息也是正常的。

========================================================================

如果把IGMP协议看成是路由器上的多播组成员发现机制，那么IGMP Snooping/CGMP协议就是交换机上的多播组成员发现机制。如果交换机上没有类似IGMP Snooping/CGMP这样的协议，那么交换机上和MR路由器相连端口处于同一个广播域中的所有机器都会接收到多播信息，即使这个广播域中只有一台机器加入了多播组，造成多播数据包泛滥的情况。

路由器和交换机之间必须有一个学习机制，让交换机来知道路由器到底发送了哪些多播组过来，这种学习方式有两种：pim-dvmrp和cgmp。默认情况下为pim-dvmrp方式，交换机侦听IGMP查询、PIM和DVMRP数据包，在这里我们采用了CGMP方式，因为一些老型号的交换机并不支持igmp snooping：

ip igmp snooping vlan 1 mrouter learn cgmp

在交换机上查看组成员的归属情况：

Switch#sh ip igmp snoop group
Vlan Group Version Port List
---------------------------------------------------------
1 224.2.227.223 Fa0/1
1 224.2.227.224 Fa0/1
1 239.255.255.250 Fa0/3

可以看到F0/1口（此口直接和路由器相连）上已正确学习到两个组

而通过查看交换机上的多播路由器连接情况，也可以看到交换机正确学习到F0/1口上的MROUTER：

Switch#sh ip igmp snoop mrouter
Vlan ports
---- -----
   1 Fa0/1(dynamic)

再查看IGMP Snooping的信息：

Switch#sh ip igmp snoop vlan 1
Global IGMP Snooping configuration:
-----------------------------------
IGMP snooping : Enabled
IGMPv3 snooping (minimal) : Enabled
Report suppression : Enabled
TCN solicit query : Disabled
TCN flood query count : 2

Vlan 1:
--------
IGMP snooping : Enabled
Immediate leave : Disabled
Multicast router learning mode : cgmp
Source only learning age timer : 10
CGMP interoperability mode : IGMP_CGMP

在了解清楚IGMP Snooping工作情况后，再查看多播MAC地址和端口的对应情况：

Switch#sh mac address multi
Vlan Mac Address Type Ports
---- ----------- ---- -----
   1 0100.5e02.e3df IGMP Fa0/1
   1 0100.5e02.e3e0 IGMP Fa0/1
   1 0100.5e7f.fffa IGMP Fa0/1, Fa0/3

在这里可以手动将某个端口加入到特定的多播组中，如：

ip igmp snooping vlan 1 static 0100.5e02.e3df interface Fa0/3

这时再看多播MAC地址和端口的对应情况，可以看到F0/3口已经和0100.5e02.e3df多播MAC地址对应起来：

Switch#sh mac address multi
Vlan Mac Address Type Ports
---- ----------- ---- -----
   1 0100.5e02.e3df USER Fa0/1, Fa0/3
   1 0100.5e02.e3e0 IGMP Fa0/1
   1 0100.5e7f.fffa IGMP Fa0/1, Fa0/3

这时尽管F0/3口上的机器没有发出多播请求，但在F0/3口机器上抓包可以看到多播数据包已经在大量“泛滥”。

了解清楚IGMP Snooping的概念后，我们再回头来看开始遇到的那个问题。
之所以会出现这样的问题是因为CAT4000上用的是SEII，而SEII并不支持IGMP Snooping，只支持CGMP，而因为设计及施工上的原因，多播源直接是从CAT4000过来，然后再接到核心的7609上，结果造成CAT4000所接的机器能接收到多播包，而跨到7609上后，因为7609默认支持IGMP Snooping，如果机器不发出IGMP report信息，机器就不会接收到多播信息包，所以造成同一个VLAN在CAT4000上的机器能收到多播数据包而7609的机器上却收不到。

转载地址：http://www.net130.com/CMS/Pub/Tech/tech_instance/234542.htm

关注我们