Typo in one part so sending to make it accurate. > The workaround is to implement <CmdBold> bgp maxas-limit X <NoCmdBold> on the > device that after prepending would need to send an update with over 255 AS > hops. Since IOS limits the inbound prepending value to 10 the most that > could be added iss 11 AS hops (10 on ingress, 10 on egress, and 1 for normal > eBGP AS hop addition). Therefore, a conservative value to configure would be > 200 to prevent this condition.
It should be 21 hops (10 in a route-map on ingress, 10 in a route-map on egress, and 1 normal eBGP AS hop addition). Thanks to John Stuppi for pointing it out. Rodney On Thu, Feb 19, 2009 at 03:15:02PM -0500, Rodney Dunn wrote: > We are working on a document for Cisco.com but in the interim > here is the bug that will fix the issue of a Cisco IOS device > sending an incorrectly formatted BGP update when as a result > of prepending it goes over 255 AS hops. > > Note: The Title and Release-note on bug toolkit may be a > bit different as I just updated it to be more accurate. > > Of all the scenarios I've looked at (thanks to those that responded > offline) there wasn't a condition found where this could happen > without AS path prepending being used. > > Please respond offline or let's move the discussion over to > cisco-nsp at this point. > > CSCsx73770 > Invalid BGP formatted update causes peer reset with AS prepending > > <B>Symptom:</B> > > A Cisco IOS device that receives a BGP update message and as a result of AS > prepending needs to send an update downstream that would have over 255 AS hops > will send an invalid formatted update. This update when received by a > downstream BGP speaker triggers a NOTIFICATION back to the sender which > results > in the BGP session being reset. > > <B>Conditions:</B> > > This problem is seen when a Cisco IOS device receives a BGP update and > due to a combination of either inbound, outbound, or both AS prepending it > needs to send an update downstream that has more than 255 AS hops. > > <B>Workaround:</B> > > The workaround is to implement <CmdBold> bgp maxas-limit X <NoCmdBold> on the > device that after prepending would need to send an update with over 255 AS > hops. Since IOS limits the inbound prepending value to 10 the most that > could be added iss 11 AS hops (10 on ingress, 10 on egress, and 1 for normal > eBGP AS hop addition). Therefore, a conservative value to configure would be > 200 to prevent this condition. > > > > Full support of Section 5.1.2 of RFC4271 is being tracked under > CSCsx75937 > Add BGP support of AS paths longer than 255 per Section 5.1.2 of RFC4271 > > Thanks to those that worked offline with us to verify the field results > reported. > > Rodney > > > > > On Tue, Feb 17, 2009 at 05:27:01PM -0500, Rodney Dunn wrote: > > 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. > > > > > > >