All things related to multicast

[Amel Caldwell <>]

Matt--

I am still seeing frequent resets on our MSDP peerings between Abilene and
AS101 in Seattle.  Are you still seeing the GSR --> Juniper MSDP peerings
reset?

Amel

On Mon, 13 May 2002, 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.
>> >>>
>> >>>
>> >>
>>
>>
>
>