All things related to multicast

[Matthew Davy <>]

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