anyone else seeing very long AS paths?

Tue Feb 17 19:50:42 UTC 2009

As far as I understand the issues :)

There are two limits: the first one @ 128 AS numbers (where BGP switches to
the 'extended length' of BGP attribute), the other one @ 256 AS numbers
(where BGP has to use two AS_SEQUENCE segments).

Old IOS releases break on the first boundary when processing INBOUND update.
bgp maxas-limit cannot save you, as the router drops UPSTREAM BGP session
before the update is fully processed.

New IOS releases accept all INBOUND updates. Prefixes with AS-path length
above 254 are never valid (the long printout contains maxas-limit status).
bgp maxas-limit works on inbound updates and thus drops whatever you feel is
oversized.

New IOS release fail when sending OUTBOUND updates. If you've configured bgp
maxas-limit, you're safe. If not, your DOWNSTREAM BGP session will be
dropped by your neighbor receiving invalid BGP update.

If your customers are using old IOS, there was nothing they could do to
prevent the BGP session reset (apart from upgrading, obviously :). Who was
the actual culprit depends on the AS-path length ... See above.

Does this make sense? I know it's complex :)
Ivan

> -----Original Message-----
> From: Jack Bates [mailto:jbates at brightok.net] 
> Sent: Tuesday, February 17, 2009 8:31 PM
> To: Ivan Pepelnjak
> Cc: nanog at nanog.org
> Subject: Re: anyone else seeing very long AS paths?
> 
> Ivan Pepelnjak wrote:
> > Classic IOS (I did not test XE, XR or NX) can handle 
> inbound updates 
> > with AS path lengths above 255, but fails miserably when it has to 
> > send an oversized update (producing invalid BGP UPDATE message), 
> > resulting in a flapping BGP session (anyone who wants to test this 
> > behavior and report/fix this bug can get all the files 
> needed to reproduce it).
> 
> Just to reconfirm. The issue arrives with sending an update, 
> not receiving? So if an ISP does not have a limit and their 
> IOS cannot handle this, they will send an invalid BGP UPDATE 
> to the downstream peers causing them to reset regardless of 
> their max as-path settings?
> 
> Just trying to reconfirm, so I can inform my customers if 
> there was anything they could do to prevent it, or if it is 
> actually their provider that instigated the peer reset by 
> sending invalid updates.
> 
> -Jack
> 
> 