multicast failure after upgrade

[topendharness]

Gday guys, was wondering if anybody else has had troubles with multicasting on the 5500 series switches since the latest software was released.
I'm using stacks of 5520-24T-PWR switches in a small campus setup (2 cores with IST and 5 edge closets) using FW 6.0.0.10 and SW 6.2.0.008.

Since the upgrade, one of the core stacks (which does the send-querying) dissolves the multicast groups and then send outs massive amounts of IGMP packets to rebuild the table. Of course this is creating havoc on our voice system. It seems to be dissolving the group table at the rate of 4 times the send-query value i.e. send-query rate 20secs, table dissolves at 80secs.

We isolated the other core stack and took it back to an older version and its quite stable.  We need the new version of software to meet the needs of the 400+ groups.

Have sent an issue to Nortel/Avaya.

Breeny

[Michael McNamara]

Thanks for taking the time to share the issue with us.

I'm assuming that you're just using IGMP and not PIM. I'd be very interested in hearing about your discussions with Avaya/Nortel. I've heard rumor that the support folks are now telling customers to re-enable the IGMP proxy/snooping features that were disabled log ago because of all the issues.

[topendharness]

Hi Michael,
Yes we are using just the IGMP protocol as its only being used at the layer 2 level for one VLAN.  Snooping is enabled but we have deliberately disabled the proxy feature as it wasnt working for us in our environment. I'll also be interested in the Nortel/Avaya response (will keep you posted).
In the mean time, i'm thinking of throwing a Cisco router on the VLAN segment and let the router do the querying and multicast functions in lieu of the core stack. This may also have benefits later on if we need to send or recieve further multicast streams from outside of the domain (WAN).
Question though. If i have a router hanging off one core stack, should i configure VRRP anyway as insurance against packets not being able to traverse the IST to another edge switch?

Breeny

[Michael McNamara]

Snooping is enabled but we have deliberately disabled the proxy feature as it wasnt working for us in our environment.

You might want to test again... I've been told that Nortel/Avaya is now recommending that IGMP Snooping and Proxy be enabled for any networks that have any medium to large Multicast applications.

In the mean time, i'm thinking of throwing a Cisco router on the VLAN segment and let the router do the querying and multicast functions in lieu of the core stack. This may also have benefits later on if we need to send or recieve further multicast streams from outside of the domain (WAN).

You could certainly do that... might not hurt if you want PIM functionality as that's not yet supported in an IST (ERS5500/5600) stack configuration. That would allow you to have multicast sources and destinations in different VLANs.

Question though. If i have a router hanging off one core stack, should i configure VRRP anyway as insurance against packets not being able to traverse the IST to another edge switch?

If I understand the question VRRP isn't going to help. If your router supported mutli-port trunking (LACP) you could create a LACP trunk using two ports (one to each core switch), that would prevent any packets destined for the router from needing to traverse the IST and it would also provide you redundancy should one of your core switches fail.

Having packets/frames traverse the IST isn't necessarily a bad thing. You can't dual-home ever device to both core switches so occasionally there might be a device or two that is only connected to a single core switch and occasionally the MAC/FDB table will end up with the frame landing on the 'other' core switch, not a big problem the frame/packet will be switched/bridged to the proper switch and the user never notices anything.

Good Luck!