Multicast receiver not receiving mcast from sender on same vlan - Page 2

mortonjes · ‎09-03-2009

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

Mohamed Sobair · ‎09-06-2009

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

Peter Paluch · ‎09-06-2009

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

mortonjes · ‎09-07-2009

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

mortonjes · ‎09-08-2009

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

Giuseppe Larosa · ‎09-08-2009

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

ragulan_dms · ‎09-09-2009

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.

mortonjes · ‎09-09-2009

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

mortonjes · ‎09-09-2009

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#

mortonjes · ‎09-10-2009

testing results listed above

Giuseppe Larosa · ‎09-11-2009

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

Mohamed Sobair · ‎09-12-2009

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