All things related to multicast

[Mike McBride <>]

Did the source of the SAs ever come back with the cause for the bad data
lengths from the originating RP, that cisco apparently then forwarded to
Juniper who then reset the connection? In IOS, we trust the length in
the MSDP header and forward the SA without resetting the session. Perhaps
the best way to handle such packets is to drop the SA without resetting
the session.

mike

On Wed, 15 May 2002, Brent Sweeny wrote:

> It sounds like Tom Pusateri and Matt Davy hit the nail on the head,
> but what's *supposed* to be happening?
>
> All I can find in the MSDP spec (draft v13, Nov2001) is that it appears
> to me from the message header error subcodes (p.19) that if there is a
> bad message length, the peer "Must Close" the connection.  Elsewhere
> (p15), though, it says:
>                                       "... If an implementation
>    receives a TLV that has length that is longer than expected, the TLV
>    SHOULD be accepted. Any additional data SHOULD be ignored."
> Which I assume means that only the TLV is accepted, so if I understand
> it correctly that's not a contradiction.
>
> was the mandate to close the connection if the message length is bad
> a relatively recent addition?  or did Juniper just recently decide to
> implement something longstanding and Cisco didn't, yet?
>