anyone else seeing very long AS paths?

Tue Feb 17 20:11:57 UTC 2009

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.
> 