On Mon, Dec 17, 2012 at 6:14 AM, Claudio Jeker <cjeker@diehard.n-r-g.com> wrote:
This can happen when a old 2-byte only routers are doing prepends with the neighbor address (4-byte). Then the magic in the 4-byte AS RFC to fix up ASPATH has no chance to work and you will see 23456.
After a careful re-read of RFC4893 section 4.2.3 Processing Received Updates, I am fairly sure it is either an implementation issue with the involved 4-octet ASN routers, or else their transit providers are using as-path-*expand* when learning their routes for some reason (customers ask for the strangest things.) The specification for 4-octet AS refers to "old" and "new" BGP speakers, which I'll do here: When NEW speaker receives a route from an OLD speaker, its job is to make AS_PATH and AS4_PATH the same length by using ASNs from from AS_PATH, which cannot have been inserted into AS4_PATH by the OLD speaker(s) that do not support the Attribute. If a NEW speaker implements as-path-prepend incorrectly, and puts 23456 (AS_TRANS) into AS4_PATH instead of his real ASN, then the route passes through some OLD speakers and out to a NEW one again, the second NEW speaker has no opportunity to reconstruct the correct path. On the other hand, if an OLD speaker is configured for as-path-*expand* as it learns routes from a NEW speaker, then it may insert AS_TRANS into the AS_PATH but no entries are being pushed to AS4_PATH. This is a limitation of the specification and cannot be avoided. In effect, the use of as-path-* expand* at a NEW->OLD boundary where the NEW router has a 4-octet ASN and OLD router is performing *expand* means the correct AS_PATH cannot be rebuilt. -- Jeff S Wheeler <jsw@inconcepts.biz> Sr Network Operator / Innovative Network Concepts