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