All things related to multicast

[Matthew Davy <>]

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.
> >>>
> >>>
> >>
> 
>