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.