All things related to multicast

[Brent Sweeny <>]

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?
-- 
Brent Sweeny            

            812 / 855-5391
Indiana University Information Technology/Abilene Network Operations

On Mon, May 13, 2002 at 03:17:25PM -0500, Matthew Davy wrote:
> 
> This is exactly what we're seeing.   I enabled all the MSDP traceoptions on 
> the Indiana Gigapop M20 and found the following errors immediate before 
> each 
> reset...
> 
> May 13 14:06:31 MSDP bad encap data length expected 164 got 178 from 
> 192.12.206.249 group 233.2.171.195 source 169.237.118.3
> May 13 14:07:08 MSDP bad encap data length expected 100 got 114 from 
> 192.12.206.249 group 233.2.171.195 source 169.237.118.2
> May 13 14:10:57 MSDP bad encap data length expected 272 got 286 from 
> 192.12.206.249 group 233.2.171.195 source 169.237.118.1
> May 13 14:25:45 MSDP bad encap data length expected 124 got 138 from 
> 192.12.206.249 group 233.2.171.195 source 169.237.118.2
> May 13 14:32:29 MSDP bad encap data length expected 316 got 330 from 
> 192.12.206.249 group 233.2.171.195 source 169.237.118.1
> May 13 14:40:24 MSDP bad encap data length expected 92 got 106 from 
> 192.12.206.249 group 233.2.171.195 source 169.237.118.2
> May 13 14:50:06 MSDP bad encap data length expected 316 got 330 from 
> 192.12.206.249 group 233.2.171.195 source 169.237.118.1
> May 13 14:59:44 MSDP bad encap data length expected 213 got 227 from 
> 192.12.206.249 group 233.2.171.195 source 169.237.118.3
> 
> 
> I've contacted the source of the SAs so they can try to figure out what's 
> causing this.   In the meantime, I filtered these SAs at the Abilene edge.
> 
> - Matt
> 
>  
> On Mon, May 13, 2002 at 11:15:08AM -0700, Tom Pusateri wrote:
> > One clarification:
> > 
> > The calculated length of the encapsulated data, based on the SA length
> > field, did not match the IP header length of the encapsulated data.
> > 
> > Thanks,
> > Tom
> > 
> > In message 
> > <>
> >  you write:
> > >We did have a problem reported with resets recently and we looked at the
> > >packet traces and determined invalid packets were being sent to us.
> > >
> > >The length in the SA including the encapsulated data did not match
> > >the length of data actually sent. In this case, there is no option
> > >but to tear down the session because it is no longer possible to
> > >determine the beginning of the next TLV.
> > >
> > >I made an argument long ago in IETF that using a TLV mechanism
> > >in a stream protocol like TCP was a bad idea for this very reason
> > >but got overruled...
> > >
> > >Thanks,
> > >Tom
> > >
> > >
> > >In message 
> > ><>
> > > you write:
> > >>
> > >>Brent,
> > >>
> > >>I'm back on earth this week, so let me know if my help today would be 
> > >>more
> > >>than just an annouance.
> > >>
> > >>Greg
> > >>
> > >>On Mon, 13 May 2002, Bill Owens wrote:
> > >>
> > >>> At 16:23 -0500 5/10/02, Brent Sweeny wrote:
> > >>> >folks, for the last several days we (Abilene) are seeing 
> > >>> >frequent--and
> > >>> >even weirder--simultaneous resets of msdp sessions on Abilene, and
> > >>> >can't quite figure out what's going wrong.  here are some data 
> > >>> >points,
> > >>> >and I'll ask some questions at the end.
> > >>>
> > >>> I will sheepishly admit to not having looked at the logs on our
> > >>> Junipers in some time, and just finding that the resets apparently
> > >>> started in Buffalo quite a while ago:
> > >>>
> > >>> Dec 30 04:26:49 buf-m20 rpd[573]: RPD_MSDP_PEER_DOWN: MSDP peer
> > >>> 199.109.2.2 peer-group Abilene-Buf out of Established
> > >>> Dec 30 04:27:36 buf-m20 rpd[573]: RPD_MSDP_PEER_DOWN: MSDP peer
> > >>> 199.109.2.2 peer-group Abilene-Buf out of Established
> > >>> Dec 30 04:53:47 buf-m20 rpd[573]: RPD_MSDP_PEER_DOWN: MSDP peer
> > >>> 199.109.2.2 peer-group Abilene-Buf out of Established
> > >>> Dec 30 04:57:41 buf-m20 last message repeated 2 times
> > >>> Dec 30 05:14:51 buf-m20 rpd[573]: RPD_MSDP_PEER_DOWN: MSDP peer
> > >>> 199.109.2.2 peer-group Abilene-Buf out of Established
> > >>>
> > >>> But they didn't start in NYC until recently:
> > >>>
> > >>> May  3 14:02:04 nyc-m20-0 rpd[587]: RPD_MSDP_PEER_DOWN: MSDP peer
> > >>> 199.109.5.2 peer-group Abilene-NYC out of Established
> > >>> May  3 14:02:40 nyc-m20-0 rpd[587]: RPD_MSDP_PEER_DOWN: MSDP peer
> > >>> 199.109.5.2 peer-group Abilene-NYC out of Established
> > >>> May  3 14:04:19 nyc-m20-0 last message repeated 5 times
> > >>> May  3 14:14:23 nyc-m20-0 last message repeated 28 times
> > >>> May  3 14:19:33 nyc-m20-0 last message repeated 6 times
> > >>>
> > >>> Our other Juniper, roc-m10, does not peer with Abilene and hasn't
> > >>> seen any resets on the MSDP peers within NYSERNet. Those peers
> > >>> include one GSR that had been on 12.0(15)S and jumped directly to
> > >>> 12.0(21)S1 a month or so ago. Our Junipers have progressed through
> > >>> the usual set of releases and are now on 5.2R2.3. If there's any
> > >>> debugging that we can do, just let me know. Watching things after
> > >>> CLEV goes to 12.0(21)S tonight will be a good test. . .
> > >>>
> > >>> Bill.