|
Posted by bspdan on March 28, 2007, 8:08 am
If you were Registered and logged in, you could reply and use other advanced thread options
>
> > 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?
>
> 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
| 
Yahoo! 
Google 
Windows Live 
del.icio.us 
digg 
Netscape 
XML site map