All things related to multicast

[Amel Caldwell <>]

Thanks Matt.  I think this got it.  At least it has remained up longer than it
has in the last week and a half.

Amel

On Tue, 14 May 2002, Matthew Davy wrote:

>
>Looks like I was too specific with the SA filter.   We started getting SAs 
>from
>the same sources, but to different groups.   I've now filtered all SAs with
>169.237.118.1, 169.237.118.2, and 169.237.118.3 in the source field.
>
>- Matt
>
>
>On Tue, May 14, 2002 at 06:36:23AM -0700, Amel Caldwell wrote:
>> 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.
>> >> >>>
>> >> >>>
>> >> >>
>> >>
>> >>
>> >
>> >
>>
>>
>