anyone else seeing very long AS paths?

Rodney Dunn rodunn at cisco.com
Tue Feb 17 16:27:01 CST 2009


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






More information about the NANOG mailing list