anyone else seeing very long AS paths?

[gmartine at ajax.opentransit.net (German Martinez)]

On Tue Feb 17, 2009, Rodney Dunn wrote:

Hello Rodney,
It will be great if you can share with us your findings.  It seems
like we are hitting different bugs in different platforms.

Thanks
German

> Ivan,
> 
> 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.
> 
> Rodney
> 
> 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
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20090217/c64c40f9/attachment.bin>