Understanding BGP 4-byte ASN

Understanding BGP 4-byte ASN

BGP Autonomous System Number (ASN) is a 2-byte (16-bits) entity. 2-bytes give 65536 possible numbers, of which, 0, 23456, 65535 and 64512- 65534 (private ASN) are reserved by IANA. Of the remaining, 39000+ ASNs are already used.

RFC 4893 discusses about 4-byte ASN. 4-bytes provide ASNs ranging from 0 to 4294967296. 0-65535 are called mappable-ASN. The 4-byte ASN can be represented in one of three ways-

asplain - simple decimal representation of the ASN. For example, ASN 7747 will be represented as 7747, while 123456 will be represented as 123456.
asdot+ - breaks the number up in two 16-bit values as low-order and high-order, separated by a dot. All the 2-byte ASNs can be represented in the low-order value. For example, ASN 65535 will be 0.65535, 65536 will be 1.0, 65537 will be 1.1 and so on. The last ASN 4294967296 will be 65535.65535.
asdot - it is a mixture of asplain and asdot+. Any ASN in the 2-byte range is represented as asplain and any ASN above the 2-byte range is represented as asdot+. For example, 65535 will be 65535 while 65536 will be 1.0. Cisco uses this form of implementation.

ASN role in BGP

BGP carries ASN in-

- OPEN messages

- AS_PATH attribute

- AGGREGATOR attribute

- COMMUNITY attribute

Terminology

Old BGP Speaker- BGP Speaker running 2-byte ASN

New BGP Speaker- BGP Speaker running 4-byte ASN

Interaction with Neighbors

New BGP Speaker advertises to its neighbor that it uses a 4-byte ASN using BGP Capability Advertisements. If the neighbor also advertises that it uses a 4-byte ASN i.e. a New BGP Speaker, the two neighbors can inform each other of their 4-byte ASNs using OPEN messages.

If the neighbor is an Old BGP Speaker and responds that it does not support 4-byte ASN, the New BGP Speaker can still bring up the neighbor relationship, but cannot advertise its 4-byte ASN to this Old BGP neighbor. Instead, the New BGP speaker uses a reserved 2-byte ASN, 23456, called AS_TRANS (even if multiple ASNs use this). The New BGP Speaker adds this ASN to the OPEN message.

Path attribute interoperability

A BGP Speaker now knows whether its neighbor is a New BGP Speaker or an Old BGP Speaker.

A New BGP Speaker advertises the routes to its New BGP neighbors with AS_PATH carrying 4-byte ASN, as compared to an AS_PATH carrying 2-byte ASN when advertising to an Old BGP neighbor during which it adds the AS_TRANS ASN instead of adding its own 4-byte ASN. The router also adds a new attribute, AS4_PATH, to the route. The AS4_PATH attribute is an optional transitive attribute which carries the real AS_PATH list, carrying both 4-byte and 2-byte ASN. The New BGP Speaker adds the AS4_PATH attribute only if there are any 4-byte ASN in the AS_PATH list.

Definition: Optional Transitive

"Optional" meaning it is only used when needed, and

"Transitive" meaning it is passed along to other neighbors by BGP speakers who do not understand the attribute.

When an Old BGP Speaker advertises routes with AS4_PATH and AS_PATH attributes to a New BGP Speaker, the New BGP Speaker uses both attributes to reconstruct the path: AS4_PATH for 4-byte ASNs and AS_PATH for 2-byte ASNs.

The New BGP Speaker constructs the AS_PATH attribute by replacing 4-byte ASN with an AS_TRANS. In this way, the AS_PATH shows the correct number of hops.

Definition: AGGREGATOR attribute

When a number of routes are summarised (aggregated), the summarised route loses details. The AGGREGATOR attribute is added to the summarised route which includes the Router-ID and the ASN of the router performing the aggregation.

This attribute is not included in BGP decision process.

A new attribute AS4_AGGREGATOR is introduced for similar reasons. If the New BGP Speaker has to send the AGGREGATOR attribute and if the aggregating ASN is a 4-byte ASN, then the speaker constructs the AS4_AGGREGATOR attributes by copying the attribute length and attribute value from the AGGREGATOR attribute, places the attribute length and attribute value in the AS4_AGGREGATOR attribute, and replaces the 4-byte ASN with AS_TRANS ASN. Again, if the aggregating ASN is 2-byte, then AS4_AGGREGATOR is not sent.

NOTE

Under certain circumstances, it is not possible to reconstruct the entire AS path information from AS_PATH and AS4_PATH attributes. This can occur when two or more routes carrying the AS4_PATH attribute are aggregated by an Old BGP Speaker, and the AS4_PATH attribute carries atleast one 4-byte ASN. In that case, either the AS4_PATH attribute would be lost, or both AS_PATH and AS4_PATH would contain partial valid information, which will result in incomplete AS path information.

BGP Communities are supported in 4-byte ASN environment by using new Extended Community attribute called 4-Octet AS-specific BGP Extended Community. This new community now has 4-byte ASN field and 2-byte arbitrary number, as opposed to 2-byte ASN field in legacy Community attribute.

Sample Scenario

R1 and R3 routers are using 4-byte ASN. While R2 router is only capable of using 2-byte ASN.

The following shows BGP configuration on R1 and R2 routers.

BGP Configuration

R1(config)# router bgp ?

  <1-4294967295>  Autonomous system number

  <1.0-XX.YY>     Autonomous system number

R1(config)# router bgp 1.100

R1(config-router)#^z

R1# sh run | begin bgp

router bgp 65636 ! 4-byte ASN 1.100 changes to 65636 in running-config

 no synchronization

 bgp log-neighbor-changes

 network 1.1.1.1 mask 255.255.255.255

 neighbor 10.1.1.2 remote-as 200

 no auto-summary

R2# show run | begin bgp

router bgp 200

 no synchronization

 bgp log-neighbor-changes

 neighbor 10.1.1.1 remote-as 23456        ! R2 is configured to form eBGP neighborship with R1 and R3 using AS_TRANS ASN 23456

 neighbor 10.2.2.2 remote-as 23456

 no auto-summary

When R1 discovers R2, it sends a BGP Open message and all the capabilities including 4-byte ASN support. It pretends to be in AS 23456 while the actual ASN is hide in the Capability Advertisement.

Since R2 is not capable of understanding 4-byte ASN and as it is configured to peer with R1 in AS 23456, it will accept the BGP Open message and form neighbors with R1.

R1 forms neighbor with R2

R1#

00:07:46: BGP: 10.1.1.2 passive open to 10.1.1.1

00:07:46: BGP: 10.1.1.2 went from Active to Idle

00:07:46: BGP: 10.1.1.2 went from Idle to Connect

00:07:46: BGP: 10.1.1.2 rcv message type 1, length (excl. header) 26

00:07:46: BGP: 10.1.1.2 rcv OPEN, version 4, holdtime 180 seconds

00:07:46: BGP: 10.1.1.2 went from Connect to OpenSent

00:07:46: BGP: 10.1.1.2 sending OPEN, version 4, my as: 23456, holdtime 180 seconds

00:07:46: BGP: 10.1.1.2 rcv OPEN w/ OPTION prameter len: 16

00:07:46: BGP: 10.1.1.2 rcvd OPEN w/ optional parameter type 2 (Capability) len 6

00:07:46: BGP: 10.1.1.2 OPEN has CAPABILITY code: 1, length 4

00:07:46: BGP: 10.1.1.2 OPEN has MP_EXT CAP for afi/safi: 1/1

00:07:46: BGP: 10.1.1.2 rcvd OPEN w/ optional parameter type 2 (Capability) len 2

00:07:46: BGP: 10.1.1.2 OPEN has CAPABILITY code: 128, length 0

00:07:46: BGP: 10.1.1.2 OPEN has ROUTE-REFRESH capability(old) for all address-families

00:07:46: BGP: 10.1.1.2 rcvd OPEN w/ optional parameter type 2(Capability) len 2

00:07:46: BGP: 10.1.1.2 OPEN has CAPABILITY code: 2, length 0

00:07:46: BGP: 10.1.1.2 OPEN has ROUTE-REFRESH capability for all address-families

BGP: 10.1.1.2 rcvd OPEN w/ remote AS 200

00:07:46: BGP: 10.1.1.2 went from OpenSent to OpenConfirm

00:07:46: BGP: 10.1.1.2 send message type 1, length (incl. header) 53

00:07:46: BGP: 10.1.1.2 went from OpenConfirm to Established

00:07:46: %BGP-5-ADJCHANGE: neighbor 10.1.1.2 Up

The show ip bgp neighbors command shows the capabilities advertised by a BGP Speaker to its neighbor(s).

show ip bgp neighbors

R1# show ip bgp neighbors

BGP neighbor is 10.1.1.2,  remote AS 200, external link

  BGP version 4, remote router ID 10.1.1.2

  BGP state = Established, up for 00:01:44

  Last read 00:00:44, last write 00:00:44, hold time is 180, keepalive interval is 60 seconds

  Neighbor capabilities:

    Route refresh: advertised and received(new)

Four-octets ASN Capability: advertised ! Only advertised, not received

    Address family IPv4 Unicast: advertised and received

  Message statistics:

    InQ depth is 0

    OutQ depth is 0

                         Sent       Rcvd

    Opens:                  1          1

    Notifications:          0          0

    Updates:                1          0

    Keepalives:             4          3

    Route Refresh:          0          0

    Total:                  6          4

  Default minimum time between advertisement runs is 30 seconds

 For address family: IPv4 Unicast

  BGP table version 2, neighbor version 2/0

 Output queue size : 0

  Index 1, Offset 0, Mask 0x2

  Member of update-group 1

                                 Sent       Rcvd

  Prefix activity:               ----       ----

    Prefixes Current:               1          0

    Prefixes Total:                 1          0

    Implicit Withdraw:              0          0

    Explicit Withdraw:              0          0

    Used as bestpath:             n/a          0

    Used as multipath:            n/a          0

                                   Outbound    Inbound

  Local Policy Denied Prefixes:    --------    -------

    Total:                                0          0

  Number of NLRIs in the update sent: max 0, min 0

  Address tracking is enabled, the RIB does have a route to 10.1.1.2

  Connections established 1; dropped 0

  Last reset never

Connection state is ESTAB, I/O status: 1, unread input bytes: 0

Mininum incoming TTL 0, Outgoing TTL 1

Local host: 10.1.1.1, Local port: 179

Foreign host: 10.1.1.2, Foreign port: 42061

Enqueued packets for retransmit: 0, input: 0  mis-ordered: 0 (0 bytes)

Event Timers (current time is 0x914D0):

Timer          Starts    Wakeups            Next

Retrans             5          0             0x0

TimeWait            0          0             0x0

AckHold             5          3             0x0

SendWnd             0          0             0x0

KeepAlive           0          0             0x0

GiveUp              0          0             0x0

PmtuAger            0          0             0x0

DeadWait            0          0             0x0

iss: 3162196817  snduna: 3162197028  sndnxt: 3162197028     sndwnd:  16174

irs: 1401371415  rcvnxt: 1401371537  rcvwnd:      16263  delrcvwnd:    121

SRTT: 662 ms, RTTO: 4385 ms, RTV: 1530 ms, KRTT: 0 ms

minRTT: 72 ms, maxRTT: 336 ms, ACK hold: 200 ms

Flags: passive open, nagle, gen tcbs

Datagrams (max data segment is 1460 bytes):

Rcvd: 8 (out of order: 0), with data: 5, total data bytes: 121

Sent: 9 (retransmit: 0, fastretransmit: 0), with data: 5, total data bytes: 210

When R1 advertises a BGP UPDATE message carrying NLRI for prefix 1.1.1.1/32, it also includes a NEW AS_PATH attribute (AS4_PATH designated by RFC) along with the mandatory AS_PATH attribute.

R2 router accepts it as coming from AS 23456. It also forwards the same update message to R3 after appending its own ASN 200 to the AS_PATH attribute. However, since R3 understands the NEW AS_PATH attribute, it will reconstruct the original AS_PATH list from this attribute.

1.1.1.1/32 on R2 and R3

R2# show ip bgp 1.1.1.1

BGP routing table entry for 1.1.1.1/32, version 6

Paths: (1 available, best #1, table Default-IP-Routing-Table)

  Advertised to update-groups:

    10.1.1.1 from 10.1.1.1 (1.1.1.1)

      Origin IGP, metric 0, localpref 100, valid, external, best

R3# show ip bgp 1.1.1.1

BGP routing table entry for 1.1.1.1/32, version 2

Paths: (1 available, best #1)

Flag: 0x820

  Not advertised to any peer

  200 65636

    10.2.2.1 from 10.2.2.1 (10.1.1.2)

      Origin IGP, localpref 100, valid, external, best

Aggregating 1.1.1.1/32 to 1.0.0.0/24 on R1

R1 aggregates 1.1.1.1/32 to 1.0.0.0/24 and advertises only the summarized route to R2.

router bgp 1.100

 aggregate-address 1.0.0.0 255.0.0.0 summary-only

When R1 advertises this summarized route to R2, it copies all the information from regular AGGREGATOR attribute and puts in a NEW AGGREGATOR attribute, except the ASN. The regular AGGREGATOR attribute has ASN 23456 while NEW AGGREGATOR attribute has AS 65636.

Again, since R3 router can understand this NEW AGGREGATOR attribute, it can reconstruct the correct AS_PATH list.

Aggregated route

R2# show ip bgp 1.0.0.0

BGP routing table entry for 1.0.0.0/8, version 7

Paths: (1 available, best #1, table Default-IP-Routing-Table)

Flag: 0x820

  Advertised to update-groups:

  23456, (aggregated by 23456 1.1.1.1)

    10.1.1.1 from 10.1.1.1 (1.1.1.1)

      Origin IGP, metric 0, localpref 100, valid, external, atomic-aggregate, best

R3# show ip bgp 1.0.0.0

BGP routing table entry for 1.0.0.0/8, version 5

Paths: (1 available, best #1)

Flag: 0x820

  Not advertised to any peer

  200 65636, (aggregated by 65636 1.1.1.1)

    10.2.2.1 from 10.2.2.1 (10.1.1.2)

      Origin IGP, localpref 100, valid, external, atomic-aggregate, best

Further reading:

RFC 4893: BGP Support for 4-octet AS number space http://www.ietf.org/rfc/rfc4893.txt

http://www.networkworld.com/community/node/35767

Page updated

Google Sites

Report abuse