32-bit ASes at routeviews

Mon Dec 17 14:41:51 UTC 2012

On Mon, Dec 17, 2012 at 6:14 AM, Claudio Jeker <cjeker at 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 at inconcepts.biz>
Sr Network Operator  /  Innovative Network Concepts