09-03-2009 01:29 PM - edited 03-06-2019 07:35 AM
I have a situation where I have multicast sender and receiver on the same physical switch on the same vlan.
The receiver is not able to join the senders mulitcase group. I do have IGMP snooping enabled and was hoping not to have to disable it. (Not that disabling would work either....)
One thing to note is on the upstream router (I'd call this the multicast router) I've configured sparse-mode and also built a GRE tunnel to get multicast to another location. Receivers at the remote location (On a different subnet) are able to receive all the senders mcast feeds! It seems to be isolated to the sender and receivers on the same subnet off the same switch that can't receive/join groups. Below is part of the config on the router. Nothing special off the switch.
Any help would be appreciated.
Switch: C7000 (inside an HP Blade server chassis)
Router: Cisco 7206
router config:
ip multicast-routing
ip dvmrp interoperability
interface Loopback1
description TUNNEL SOURCE TO XXX FOR MULTICAST
ip address 10.10.254.1 255.255.255.255
ip pim sparse-mode
!
interface Tunnel0
description MULTICAST TUNNEL TO XXX TUNNEL 0
ip address 10.10.253.1 255.255.255.252
ip pim sparse-mode
tunnel source Loopback1
tunnel destination 10.10.254.2
interface GigabitEthernet0/2
no ip address
ip pim sparse-mode
duplex auto
speed auto
media-type rj45
no negotiation auto
!
interface GigabitEthernet0/2.10
description *** LAN, MGMT VLAN ***
encapsulation dot1Q 10
ip address 10.10.0.1 255.255.255.0
ip pim sparse-mode
!
interface GigabitEthernet0/2.12
description *** LAN, SERVERS VLAN ***
encapsulation dot1Q 12
ip address 10.10.2.1 255.255.255.0
ip pim sparse-mode
!
ip pim rp-address 10.10.254.2
ip mroute 192.168.17.0 255.255.255.0 Tunnel0
ip mroute 10.10.254.2 255.255.255.255 Tunnel0
ip mroute 10.10.2.0 255.255.255.0 10.10.0.1
The receiver is 10.10.2.10 & 24 trying to recieve from any of groups 224.1.1.1, .2, or .3
show IP mroute:
(*, 224.1.1.1), 01:19:40/stopped, RP 10.10.254.2, flags: SJCF
Incoming interface: Tunnel0, RPF nbr 10.10.253.2, Mroute
Outgoing interface list:
GigabitEthernet0/2.12, Forward/Sparse, 01:08:26/00:02:20
(10.10.2.20, 224.1.1.1), 01:19:40/00:03:28, flags: FT
Incoming interface: GigabitEthernet0/2.12, RPF nbr 0.0.0.0, Registering (data-header)
Outgoing interface list:
Tunnel0, Forward/Sparse, 01:19:35/00:02:36
(*, 224.1.1.3), 01:19:36/stopped, RP 10.10.254.2, flags: SJCF
Incoming interface: Tunnel0, RPF nbr 10.10.253.2, Mroute
Outgoing interface list:
GigabitEthernet0/2.12, Forward/Sparse, 01:08:27/00:02:20
(10.10.2.20, 224.1.1.3), 01:15:31/00:02:59, flags: PFT
Incoming interface: GigabitEthernet0/2.12, RPF nbr 0.0.0.0, Registering (data-header)
Outgoing interface list: Null
(*, 224.1.1.2), 01:19:41/stopped, RP 10.10.254.2, flags: SJCF
Incoming interface: Tunnel0, RPF nbr 10.10.253.2, Mroute
Outgoing interface list:
GigabitEthernet0/2.12, Forward/Sparse, 01:08:26/00:02:19
(10.10.2.24, 224.1.1.2), 01:16:17/00:02:59, flags: PFT
Incoming interface: GigabitEthernet0/2.12, RPF nbr 0.0.0.0, Registering (data-header)
Outgoing interface list: Null
(*, 224.0.1.40), 01:19:43/00:02:19, RP 10.10.254.2, flags: SJCL
Incoming interface: Tunnel0, RPF nbr 10.10.253.2, Mroute
Outgoing interface list:
Loopback1, Forward/Sparse, 01:19:43/00:02:19
09-06-2009 04:28 PM
Hello Peter,
I was refering to your earlier post bellow:
C7000-1-SW#sh ip igmp snooping groups
Vlan Group Type Version Port List
-----------------------------------------------------------------------
12 224.1.1.1 igmp v2 Gi2/0/5, Gi2/0/11,
Gi2/0/15, Gi2/0/26
12 224.1.1.2 igmp v2 Gi1/0/10, Gi2/0/11,
Gi2/0/26
12 224.1.1.3 igmp v2 Gi2/0/11, Gi2/0/15,
Gi2/0/26
12 230.230.230.230 igmp v2 Gi2/0/11, Gi2/0/26
C7000-1-SW#
Sender: port g2/0/11
Receiver: port g2/0/15
I was also refering to the IGMP Querier and reciever not the multicast sender and reciever.
Based on the describtion of the original poster, do you think he needs layer-3 here? Also do you think troublshooting IGMP would produce useful information if the sender and reciever of the multicast stream are on the same vlan?
HTH
Mohamed
09-06-2009 04:48 PM
Hello Mohamed,
Personally, I do not think that the original poster need a Layer3 multicast routing here. As he indicated himself, the sender and receiver are on the same VLAN so this all should run without any routing support.
Troubleshooting the IGMP in my opinion is important here as the switch is performing IGMP snooping. Until the switch correctly identifies the subscriber ports, the multicast traffic will not be delivered to those ports. What confuses me strongly, however, is that according to that "show ip igmp snooping groups" output, the switch knows both about the sender and receiver port, and yet the multicast traffic is not being delivered. Can you see it, too? I am trying to think of anything that would prevent a switch from replicating multicast traffic although it knows about the particular receivers but right now I don't see any reason why that should not work - and yet it doesn't.
Any idea?
Best regards,
Peter
09-07-2009 03:18 PM
First off, thank you all very much for looking into my issue. I agree, with the sender and receiver both on the same physical switch and vlan (vlan 12) I wouldn't think any layer 3 deivce would be needed.
Tomorrow, (9/7/09)I am going to try some of the things suggested in this thread. (Removing erroneous staic mroute, removing mulicast routing on the layer 3 switch and if all else fails, just for a test, removing IGMP snooping)
I will post my findings tomorrow.
You're assistance is greatly appreciated!
Jesse
09-08-2009 05:45 PM
I wasn't able to work on this today. I would liked to. The person who handles our Linux servers was out.
(Mcast sender/receivers are on the Linux platform)
I will post tomorrow. Thanks
Jesse
09-08-2009 08:41 AM
Hello Mohamed,
>> Also do you think troublshooting IGMP would produce useful information if the sender and reciever of the multicast stream are on the same vlan?
Absolutely yes when sources and receivers are in the same vlan IGMP snooping can be the source of problems.
Here we have a device that is in the middle:
it could be configured as a L2 switch but it has ip multicast routing enabled.
It has ip pim passive on vlan10 no pim configuration in vlan12 (no SVI vlan12 actually exists)
Or it becomes a full L3 multicast router creating pim neighborships on vlan10 and vlan12 or it has to be configured as L2 only for ipv4 multicast.
Being in the middle is not good.
multicast stream Traffic is forwarded to port gi2/0/26 because a multicast router is detected over it.
User port gi2/0/15 is listed among the ports associated to group 224.1.1.3 but it doesn't receive traffic.
Example:
When we tested RGMP for the first time on a C6500 some years ago, it didn't work and then we found a workaround by creating an SVI on the vlan. (in later releases this is not needed).
Hope to help
Giuseppe
09-09-2009 04:23 AM
Hi all,
Correct me if i correctly understand you. Say sender and receiver are belongs to same vlan. No L3 multicast routing (PIM) is enabled on the vlan interface. On Cisco switch IGMP is enabled by default. Since theoretically it should work.
I think i have seen something similar. But it worked. But multicast stream seems to be flooded to all the port on the switch irrespective of receiver port (even igmp globally enabled). Receiver was able receive the stream, But with " sho ip igmp snooping group" did not show anything.
So I am eagerly waiting for the Jesse's testing. Please update your testing. (You may try to connect you PC to one of the port and just listen using ethereal)
Ragu.
09-09-2009 11:27 AM
I was able to do some testing with my Linux group. Here is what I did. (in order)
1.) Verified that multicast was in fact working over my tunnel. (It was)
2.) Removed "sparse-mode" from interface GigabitEthernet0/2.10. (It wasn't needed.)
2a.) Cleared ip mroute * on the router (My lack of knowing if clearing mroute was necessary.)
2b.) Checked to see if mcast was still working over tunnel. (It was.)
2c.) Checked to see if sender and receiver on vlan 12 was working. (Still wasn't working.)
3.) Removed this route from the router: ip mroute 10.10.2.0 255.255.255.0 10.10.0.1
3a.) Cleared ip mroute * on the router (My lack of knowing if clearing mroute was necessary.)
3b.) Checked to see if mcast was still working over my tunnel. (It was.)
3c.) Checked to see if mcast was working on vlan 12. (Still wasn't working.)
4.) I removed this command of the layer 3 switch: ip multicast-routing distributed
4a.) Cleared ip mroute * on the router (My lack of knowing if clearing mroute was necessary.)
4b.) Checked to see if mcast was still working over my tunnel. (It was.)
4c.) Checked to see if mcast was working on vlan 12. (Still wasn't working.)
5.) I asked my Linux group to verify with me the ports that the sender and receiver were on.
6.) To my surprise (my fault for not looking at this more in depth sooner) The sender was on g2/0/11 and the receiver was on g1/0/15.
7.) This switch is in an HP Blade server chassis so I started thinking maybe the sender and receiver are NOT on the same physical switch. (Even though when you look at the switch module in the HP chassis it looks like one module. And when I'm logged into the switch, I can see all ports g1/0/x - g2/0/x within the same session without having to jump to another set of ports/session to another module)
8.) so I had the Linux group pick a sender and receiver on the same port structure. (2
servers off the g2/0/X)
9.) Still, mcast didn't work!
10.) Lastly, I disabled snmp snooping. As expected, that worked. Both sender and receiver were able to see each other AND sender on g2/0/X was able to reach with receiver on G1/0/x
The switch is in a HP Blade enclosure and show ver off the switch is in my next post (please see next post)
Questions:
1.) Why does it take disabling of IGMP snooping to make this work? (Even with sender/receiver on same set of ports? G2/0/X)
2.) We currently don't have a lot of multicast traffic but will be adding more to the network in the future. At what point does having IGMP Snooping disabled, affect network performance?
Any advice on how to get this to work without disabling IGMP Snooping? (I'm sort of hung up on this idea that disabling IGMP Snooping is not the most optimal way to go.)
Thank you so much for all the help.
Jesse
09-09-2009 11:28 AM
Show ver off the switch:
SWITCH SHOW VER:
cisco WS-CBS3120G-S (PowerPC405) processor (revision C0) with 245760K/16376K bytes of memory.
Processor board ID XXX
Last reset from power-on
3 Virtual Ethernet interfaces
1 FastEthernet interface
52 Gigabit Ethernet interfaces
The password-recovery mechanism is enabled.
512K bytes of flash-simulated non-volatile configuration memory.
Base ethernet MAC Address : 00:23:5D:C6:3F:00
Motherboard assembly number : 73-10920-08
Motherboard serial number : XXX
Model revision number : C0
Motherboard revision number : A0
Model number : WS-CBS3120G-S
System serial number : XXX
Top Assembly Part Number : 800-28497-01
Top Assembly Revision Number : F0
Version ID : V01
CLEI Code Number : COUIAN0CAA
Hardware Board Revision Number : 0x00
Switch Ports Model SW Version SW Image
------ ----- ----- ---------- ----------
* 1 26 WS-CBS3120G-S 12.2(46)SE CBS31X0-UNIVERSALK9-M
2 26 WS-CBS3120G-S 12.2(46)SE CBS31X0-UNIVERSALK9-M
Switch 02
---------
Switch Uptime : 16 weeks, 22 hours, 8 minutes
Base ethernet MAC Address : 00:23:AB:FF:A4:00
Motherboard assembly number : 73-10920-08
Motherboard serial number : XXX
Model revision number : C0
Motherboard revision number : A0
Model number : WS-CBS3120G-S
System serial number : XXX
Top assembly part number : 800-28497-01
Top assembly revision number : F0
Version ID : V01
CLEI Code Number : COUIAN0CAA
License Level : XXX
License Type : XXX
Next reboot licensing Level : XXX
Configuration register is 0xF
C7000-1-SW#
09-10-2009 08:16 AM
testing results listed above
09-11-2009 12:52 PM
Hello Jesse,
I think your device is not behaving correctly about IGMP snooping.
I haven't a direct experience with this switch on a blade.
I would suggest you to open a TAC Service Request.
Hope to help
Giuseppe
09-12-2009 03:09 PM
Hi Jesse,
Very strange symptom indeed.
here is the answers for your questions:
1.) Why does it take disabling of IGMP snooping to make this work? (Even with sender/receiver on same set of ports? G2/0/X)
This shouldnt affect your multicast, IGMP snooping allows the switch to build multicast table to include which reciever's ports should recieve particular multicast stream from the IGMP querior (sender), So whether you disable it or not, with the normal behaviour it should work fine.
2.) We currently don't have a lot of multicast traffic but will be adding more to the network in the future. At what point does having IGMP Snooping disabled, affect network performance?
Any advice on how to get this to work without disabling IGMP Snooping? (I'm sort of hung up on this idea that disabling IGMP Snooping is not the most optimal way to go.)
As mentioned, IGMP Snooping provides Optimization method on the network, it allows the switch to identify which ports should recieve particular multicast streams instead of flooding the multicast to all ports on the switch by listining to IGMP Join messages and record the related host ports and identify the correct IGMP querior port.
HTH
Mohamed
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide