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. > >
pgpKi14UX012c.pgp
Description: PGP signature
