If you want to take this offline send it unicast or we could move it to cisco-nsp.
What scenarios are you seeing that appear broken other than when a notification is sent when a > 255 hop update is received? That's the one I'm working on right now. Rodney On Tue, Feb 17, 2009 at 05:31:49PM -0500, German Martinez wrote: > 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. > > >