anyone else seeing very long AS paths?
gmartine at ajax.opentransit.net
Tue Feb 17 22:31:49 UTC 2009
On Tue Feb 17, 2009, Rodney Dunn wrote:
It will be great if you can share with us your findings. It seems
like we are hitting different bugs in different platforms.
> It is confusing but from what I have tested you have it correct.
> The confusing part comes from multiple issues.
> a) The documentation about the default maxas limit being 75 appears to be
> incorrect. I'll get that fixed.
> b) Prior to CSCee30718 there was a hard limit of 255. After that fix
> AS sets of more than 255 should work.
> c) CSCeh13489 implemented the maxas command to mark it as invalid and
> not send.
> There does appear to be an issue when you cross the 255 boundary
> and the next hop router sends a notification back.
> I've got it recreated in the lab and we are working to clearly understand
> why that is. I'll post an update once we have more.
> The way to prevent it is the upstream device that crosses the 255 boundary
> on sending needs to use the maxas limit command to keep it less than 255.
> It doesn't work on the device that receives the update with the AS path
> larger than 255.
> On Tue, Feb 17, 2009 at 08:58:48PM +0100, Ivan Pepelnjak wrote:
> > > We were dropping ALL prefixes and the eBGP session was still
> > > resetting.
> > Upstream or downstream?
> > > 1) "bgp maxas-limit 75" had no effect mitigating this problem
> > > on the IOS we were using. That is: it was previously verified
> > > to be working just fine to drop paths longer than 75, but
> > > once we started receiving paths >
> > > 255 then BGP started resetting.
> > I was able to receive BGP paths longer than 255 on IOS release 12.2SRC. The
> > paths were generated by Quagga BGP daemon.
> > 12.2SRC causes the downstream session to break when the installed AS-path
> > length is close to 255 and you use downstream AS-path prepending.
> > In your case, I'm assuming you were hit with an older bug (probably at the
> > 128 AS-path length boundary). It would be very hard to generate just the
> > right AS-path length to unintentionally break your upstream EBGP session (as
> > I said before, it's a nice targeted attack if you know your downstream
> > topology).
> > If your IOS is vulnerable to the older bugs that break inbound processing of
> > AS paths longer than 128, there's nothing you can do on your end. The
> > internal BGP checks reject the inbound update before the inbound filters (or
> > bgp maxas-limit) can touch it and reset the upstream BGP session.
> > Hope this helps
> > Ivan
> > Disclaimer: as I don't have internal access to Cisco, all of the above is a
> > result of lab tests.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: not available
More information about the NANOG