After an RSTP topology change, does a device necessarily have to flush both unicast and multicast address tables? I'm running into an issue where my multicast GDAs (which are dynamic) are being flushed, and not being relearned until the next IGMP report comes in, which can be at best several seconds or up to a minute. This is too long. Is there a hard and fast rule that says you *must* flush multicast, or is it only a best practices type suggestion?
Thanks, Dan
The standard doesn't seem to say anything specific to multicast. It does say that you have to flush entries associated with a port in certain scenarios (in certain scenarios you can optionally just transfer the entries to a different port). So, in the case of multicast, perhaps all the entries that have the port as one of the outputs get flushed.
I'm curious though...what's the problem? I assume it must be flooding the traffic for the period of time between flushing and relearning in order to keep things working.
Anoop
Hi Anoop, Thanks for the reply. Our apps run in automation lines where there is a fairly constant stream of small traffic closely spaced together. Think multicast packet every 100 ms containing sensor data. The problem is that the GDAs get flushed, but because multicast source detection is running on the switch, a GDA is immediately created containing the port that received the multicast packet and the port which has been receiving IGMP queries. This causes the switch to ignore the real receiving port (which got flushed with the GDA) until it gets an IGMP report, which can be a second or two, up to the query interval + 10s. This is too long for our environment.
Thanks, Dan
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.