anyone else seeing very long AS paths?

Steven Saner ssaner at hubris.net
Tue Feb 17 20:05:35 UTC 2009


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Feb 17, 2009, at 1:50 PM, Ivan Pepelnjak wrote:

> 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

What is not yet clear is, what are the definitions of "Old IOS  
release" and "New IOS release"? There has been talk of a bug referred  
to as CSCdr54230. I have seen statements on another list that this was  
fixed in 12.1(4) and 12.0(10)S3, but yet this problem was experienced  
on such releases as 12.2(40). Has there been any definitive word yet  
on what it takes to qualify as a new IOS release?

Steve

- --
- ---------------------------------------------------------------
Steven Saner <ssaner at hubris.net>
Director of Network Operations
Hubris Communications



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iEYEARECAAYFAkmbGI8ACgkQvgCxUpg3pZOfgQCeOCnoDIwX/IMF+wfnM8md2SiM
LSEAoIptOHmO7yPhAGdVZ8+dlhCiOI8k
=WD0q
-----END PGP SIGNATURE-----




More information about the NANOG mailing list