2 Sets of VSS and Multicast Issue

[mave250500]

We have a multicast problem and would like some help…

We have 4 Cisco 6509 Switches running in 2 sets of 2 VSS as shown in attachement

Each VSS instance is connected by 6x10G links.

The 2 VSS instances are connected with 4x10G (A, B, C, D) links in a Trunked EtherChannel.

We have 4 multicast sources (P-S above), each source outputting 12 multicast groups. 2 sources connect to VSS1 Primary, the other 2 connect to VSS2 Standby.

We have a multicast client (X & Y) plugged into each of the VSS2 switches on the same VLAN as the multicast source. i.e. there is no multicast routing involved.

We are experiencing very odd behaviour and would like some help.

We don’t always see all multicast groups on the VSS2 primary.

We’ve done the following testing with various different combinations of links between the VSS instances, which is even odder:

Test	VSS2 Primary Client	VSS2 Secondary Client
Link A alone (B, C, D disconnected)	All multicast groups received.	All multicast groups received.
Link B alone (A, C, D disconnected)	No multicast groups received. But can ping the IP address of the multicast source!!!	All multicast groups received.
A, B, C & D connected	Only some of the multicast groups received!!	All multicast groups received.

We are using the following OS:

s72033-adventerprise_wan-mz.122-33.SXI2a.bin

My conclusion is that the problem is something internal to the way the cisco’s are handling multicast under VSS. Normal TCP/ICMP seem to work fine.

Please help!!!

Thanks

[Yogesh Ramdoss]

Hello Imran,

I assumed links A,B,C and D are bundled together as a port-channel.

As given, all works fine when B link is shut/disconnected.

Scenario:

All links but B are disconnected. VSS2-Secondary Client receives all streams, but not the

client in VSS2-Primary.

Stream from Source S to Client Y (VSS2-Primary). has to follow the path:

S ==> VSS1-P ==> VSS1-S ==> VSS2-S ==> VSS2-P ==> Client Y

Stream from Source S to Client X (VSS2-Seconday). has to follow the path:

S ==> VSS1-P ==> VSS1-S ==> VSS2-S ==> Client X

As Client X is receiving the traffic, we can safely assume that the packet reached all the way to

VSS2-Sec. Now. the frame has to be replicated across VSS2's VSL link. If you can have another

client (say Y1) to VSS2-Pri and if Y1 receives the traffic, then this may be an issue local to VSS2-P.

If it doesn't then we may need to look into the replication across  VSS2's VSL link.

I hope you have checked IGMP snooping table entries during working and non-working condition.

If all looks OK, then I would recommend you to open a Service Request to look into the hardware

programming for multicast forwarding in hardware.

As you may be aware, Cat6500s uses different forwarding mechanisms (and hardware resources)

for unicast and multicast.

Hope this helps.

- Yogesh

[mave250500]

Yogesh

Thank you for replying to the post, you are right, all the ports are bundled in PortChannel. Tried every possible thing but no joy, we are now looking into getting TAC access sorted and open a case, let's see what comes up.

Thanks for your help mate.

Cheers

[Gerard Daly]

Hi Imran,

Just an uneducated basic suggestion regarding this issue...

I realise there is no Multicast Routing however would PIM not be required for IGMP?

Just a thought.

Thanks

Gerry

[mave250500]

Gerard

It’s all L2 and both the source and the subscribers sit on the same VLAN so no need for PIM.

Thanks for your reply mate.

Cheers

[mave250500]

Hi All

We opened TAC case and after a long troubleshooting  with the TAC engineer, it has been narrowed down to an "issue" with the IOS - we will be updating soon and see where we go from there. Thank you all for your help.

Cheers

[lwilfredoflor]

Hi  mave250500, could you find the issue ? if any bug, etc