BGP 4-Byte ASN Migration: AS_TRANS and Interop

IANA has been allocating 4-byte autonomous system numbers from the 65536–4294967295 range since 2009, yet plenty of production networks still run 2-byte ASNs — and because of that, engineers eventually hit the one number that behaves differently from every other ASN in the table: 23456. This article explains how RFC 6793 (which obsoletes RFC 4893) makes old and new BGP speakers interoperate, why AS_TRANS appears in show ip bgp output, and the upgrade order that keeps a live network stable while you migrate.

Why 23456 Exists

A "new" BGP speaker (4-octet capable) talking to an "old" speaker (2-octet only) negotiates a capability during session establishment. When the old peer cannot represent a 4-octet ASN inside a 2-octet AS_PATH, the new speaker substitutes the reserved value AS_TRANS = 23456. The path length is preserved, which keeps loop detection and best-path selection intact, and the real ASN is carried out-of-band in the optional transitive attributes AS4_PATH and AS4_AGGREGATOR.

The practical consequence: on an old router, a peering with a real 4-byte ASN looks like a peering with AS 23456. Everything else — prefix counts, next hops, communities — is normal, which is why this substitution is so easy to forget during an outage.

Capability Negotiation, Step by Step

1. Both speakers send an OPEN message; a 4-octet-capable speaker includes the 4-octet AS number capability (code 65).
2. If both peers advertise it, the session runs in 4-octet mode and AS_PATH is encoded with 4-octet entries.
3. If the peer does not advertise it, the session stays in mixed mode: AS_PATH uses 2-octet entries, non-mappable ASNs become 23456, and AS4_PATH carries the truth.
4. A receiver that understands AS4_PATH reconstructs the real path; a receiver that does not simply sees AS_TRANS.

Two asymmetries cause real-world confusion. AS4_PATH is only attached when the AS_PATH actually had to be rewritten, so its presence is inconsistent — do not write filters that depend on it. And AS_TRANS is a reserved value that Cisco IOS refuses to accept in configuration: router bgp 23456 is rejected outright.

Reading It in the CLI

show ip bgp 10.10.10.0/24
  BGP routing table entry for 10.10.10.0/24
  ...
    4200000000 65001 65002, (received & used)
    AS4_PATH: 4200000000 65001 65002

show ip bgp neighbors 10.0.0.2
  BGP neighbor is 10.0.0.2, remote AS 4200000000
  ...
    Four-octet AS number capability advertised and received

In asplain format a 4-byte ASN is printed as a plain decimal integer (4200000000); in asdot format it prints as 64086.59904. Both are display formats for the same value: choose one with bgp asnotation dot and standardise across your team, because mixing notations in filters and documentation is a classic source of silent route leaks.

Migration Strategy That Does Not Break Peering

1. Inventory first

show ip bgp summary | include ^[0-9]
show ip bgp neighbors | include remote AS|BGP state

List every eBGP and iBGP peer, the local/remote ASN, and whether the peer supports 4-byte ASNs. Sort peers into three groups: same-AS (internal), 2-byte external, 4-byte external.

2. Upgrade one speaker at a time, from the core outward

Upgrade route reflectors one at a time, verifying prefix counts and path attributes after each reboot. Then move layer by layer toward the edge. Any router that still runs 2-byte-only code is fine — it keeps working in mixed mode.

3. Reconfigure the edge peering that uses a real 4-byte ASN

router bgp 200
 no neighbor 10.0.0.4 remote-as 23456
 neighbor 10.0.0.4 remote-as 4200000000
 clear ip bgp 10.0.0.4 soft

Before the change the session was configured against the AS_TRANS placeholder; after it, against the true ASN. Do it in a maintenance window: some platforms bounce the session when the remote-as value changes.

4. Use dual-AS peering when you merge two autonomous systems

router bgp 65000
 neighbor 10.0.0.9 remote-as 65099
 neighbor 10.0.0.9 local-as 65100 no-prepend replace-as dual-as

local-as ... dual-as lets a router accept sessions using either the global or the secondary ASN, so customers can migrate their configuration on their own schedule while the two ASNs merge.

Verification and Guardrails

• After each upgrade, confirm the AS_PATH length to key prefixes is unchanged — if a path suddenly grows by one hop, AS4_PATH reconstruction is failing and you may be creating a forwarding loop.
• Never filter on 23456 in inbound policy: legitimate real ASNs may also be masked there depending on the neighbour's capability set, and matching it in the wrong direction drops valid routes.
• Keep RPKI/IRR objects dual-published during the transition if you use origin validation — see our RPKI deployment notes.
• Add a monitoring check that alerts when a session that previously advertised the 4-octet capability stops doing so — that is the leading indicator of an image rollback.

Related posts: BGP best-path selection in 13 steps, standard, extended and large communities and BGP session stuck in Idle/Active.

原文链接：https://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/border-gateway-protocol-bgp/datasheet_c78_516825.html