All things related to multicast

[Ijsbrand Wijnands <>]

Jan, 

> 
> 
> > Since it's obviously most important to fix the problem involving
> > fmbone.serveurs-nationaux.jussieu.fr, I include the rest of the data
> > without further comment, but this is probably something that needs
> > to be looked into further after the crisis is over, since it points
> > to relatively widescale failure of the peer-RPF-flooding algorithm.
> > 
> 
> I don`t think, it is failure of flooding algorithm, as I said before, we had
> several of these cases some months ago, the reason was misinterpretation 
> of this cisco command and bug in the soft:
> 
> ip msdp redistribute (without any filtering criteria) 
> - in the older IOSes (11.1.25/26 CC) this command caused
> redistribution of all SAs the RP new about but originated by
> the "misconfigured" RP this time - in later IOSes only
> redistribution of registered sources is done, as far as I understood - but
> many people still run 11.1.25/26 (Renater case also). We spotted that at 
> some
> our networks after first configurations of MSDP, but now we
> did not do any checks for what people announce for long time - appologies
> for the troubles caused.

I don't believe that's the problem. If they have old versions of IOS and
they use the redistribute command the wrong way, they would only
originate SA's for sources that are in the mroute table! So, only for
groups they have joined, otherwise you don't create state. The SA's would 
be originated every minute and without encapsulated Mpackets.

What I've seen on your router yesterday was lots of SA' stuck in the 
queue, most of them with an encapsulated Mpacket of 1400 bytes! Some
of the sessions (on slower links) did not stay up longer that a few seconds,
which indicates a continuous stream of encapsulated SA's. So I think Bill
is right, there is probebly an RPF issue causes by a bug or misconfiguation
of the default-peer command or mesh-groups.

Ice.