6 mins read

BGP – AS_TRANS 23456

1. Intro

This Post is about the operation of BGP in a network with a mix of 2-byte and 4-byte AS numbers.

The 2-byte AS number, also known as a 16-bit AS number, provides a pool of 65,536 AS numbers, which has been exhausted. The 4-byte AS numbers are specified in RFC 4893 and provide a pool of 4,294,967,296 AS numbers.

RFC 4893 introduces two new optional transitive BGP attributes, AS4_PATH and AS4_AGGREGATOR and also introduces a reserved, well-known, 2-byte AS number, AS 23456, called AS_TRANS. These are used to propagate 4-byte AS path information across BGP speakers that do not support 4-byte AS numbers.

In this post we will configure a simple setup to introduce some of the AS_TRANS operations.

The config for this setup is the following:

2. Configuring a 4-byte AS

As we can see in the config above, it is really simple to configure a 4-byte AS number. In our example, R2 and R5 have the 4-byte AS, in AS-dot notation format or plain number format, using the following CLI commands:

Note: By default, AS numbers configured in AS-dot notation, are displayed in ASplain format in the BGP show commands. For example, the 200.222 AS number is displayed as 13107422:

AS4 PA[3]: 300 13107422 100 

### This default behavior can be disabled with: 

set routing-options autonomous-system asdot-notation 

AS path: 444 300 200.222 100 

### Note: regex ca be problematic with AS-dot format. 

3. Peering 2-byte and 4-byte capable routers

In our example, on R4 we disabled the 4-byte support using the disable-4byte-as CLI command. But now, how can R4 peer with R5 which has a 4-byte AS?

### We can see the R4 peer has no 4-byte support:

root@R5# run show bgp neighbor 
Peer: 17.8.3.1+179 AS 444      Local: 17.8.3.2+53794 AS 65444
  Group: AS-444                Routing-Instance: master
  Forwarding routing-instance: master  
  Type: External    State: Established    Flags: <Sync>
  Last State: OpenConfirm   Last Event: RecvKeepAlive
  Last Error: None
  Export: [ BGP-EXPORT ] 
  Options: <PeerAS LocalAS Refresh>
  Options: <GracefulShutdownRcv>
  Holdtime: 90 Preference: 170
  Graceful Shutdown Receiver local-preference: 0
  Local AS: 65444 (private) Local System AS: 5000000
  Number of flaps: 0
  Receive eBGP Origin Validation community: Reject
  Peer ID: 17.0.0.4        Local ID: 17.0.0.5          Active Holdtime: 90
  Keepalive Interval: 30         Group index: 0    Peer index: 0    SNMP index: 2     
  I/O Session Thread: bgpio-0 State: Enabled
  BFD: disabled, down
  Local Interface: ge-0/0/1.0                       
  NLRI for restart configured on peer: inet-unicast
  NLRI advertised by peer: inet-unicast
  NLRI for this session: inet-unicast
  Peer supports Refresh capability (2)
  Stale routes from peer are kept for: 300
  Peer does not support Restarter functionality
  Restart flag received from the peer: Notification
  NLRI that restart is negotiated for: inet-unicast
  NLRI of received end-of-rib markers: inet-unicast
  NLRI of all end-of-rib markers sent: inet-unicast
  Peer does not support LLGR Restarter functionality
  Peer does not support 4 byte AS extension
  Peer does not support Addpath
  Table inet.0 Bit: 20000
    RIB State: BGP restart is complete
    Send state: in sync
    Active prefixes:              1
    Received prefixes:            1
    Accepted prefixes:            1
    Suppressed due to damping:    0
    Advertised prefixes:          1
  Last traffic (seconds): Received 19   Sent 1    Checked 210 
  Input messages:  Total 11     Updates 2       Refreshes 0     Octets 303
  Output messages: Total 10     Updates 1       Refreshes 0     Octets 221
  Output Queue[1]: 0            (inet.0, inet-unicast)

The solution is simple, R5 will have advertise itself as a 2 byte AS, at his choosing, this is why we are using the local-as feature:

The private knob is being use to optimize the BGP session, and keep this local-as hidden from other eBGP peers.

4. AS_TRANS

When R4 is receiving a prefix which has a 4-byte AS in the as-path, that 4-byte AS is replaced with the AS_TRANS AS (23456 AS). Next, we can see how the 4-byte 13107422 AS (200.222 AS) was replaced with AS_TRANS (23456):

### 13107422 AS (200.222) was replaced with AS_TRANS (23456): 

root@R4# run show route receive-protocol bgp 17.8.11.1 detail 

inet.0: 24 destinations, 24 routes (24 active, 0 holddown, 0 hidden)
* 192.168.10.0/26 (1 entry, 1 announced)
     Accepted
     Nexthop: 17.8.11.1
     AS path:
     AS2 PA[3]: 300 AS_TRANS 100 
     AS4 PA[3]: 300 13107422 100 
     Merged[3]: 300 13107422 100 I 

But, we have 2 as-paths, AS2 and AS4. A really old router, which has no support for 4-byte AS will:

  • only read and use the AS2 as-path (AS2 PA[3]: 300 AS_TRANS 100) – this one has the 23456 AS
  • forward in a transitive manner the AS4 as-path (AS4 PA[3]: 300 13107422 100) – this one has the original 200.222 AS

Any receiving router later down the road, will read both AS2 and AS4 paths and will be able to reconstruct the original 4-byte AS path. In our case, R5 will reconstruct the original path using a merge between AS2 and AS4.

Note: In our topology, on R4 we partially disabled the 4-byte AS support (using the disable-4byte-as). I’m saying partially because we can’t fully disable the 4-byte support on a modern Junos router. So, it will use a 2 byte AS to form peering relationships (AS444 to AS65444), but will still be able to read and understand the AS4 as-path. On an actual old router would be unable to read the AS4 as-path, hence this information would probably not be displayed (but will still be blindly forwarded in a transitive manner to other routers).


External Resources: