Understanding 4-Byte AS Support in C12K and CRS-1

Introduction

RFC 4271 has defined an Autonomous System number as a “2-octet unsigned integer,” which has been widely deployed on all BGP-configured routers on the Internet today. Similar to predictions that IPv4 address space will be exhausted, Regional Internet Registries (RIRs) predict the current pool of unassigned 2-Byte AS numbers will run out in 2011. IETF has defined a new 4-Byte AS number in RFC 4893, and the RIRs (including ARIN, RIPE NCC and APNIC) began issuing 4-byte AS numbers to ISPs on 1 Jan 2009; RIPE NCC will assign a 4-byte only AS number by default unless there is a specific request for a 2-byte only AS number.

This whitepaper will discuss the impact to ISPs when using C12K or CRS-1 running Cisco IOS Software or IOS XR Software, how a gradual deployment/migration can be achieved, and how to configure 4-byte AS numbers in IOS XR Software.

What’s New with 4-byte AS Number

The new AS number is 4-bytes and split into two 2-byte values, in X.Y syntax. The support for the 4-byte AS is advertised via BGP capability negotiation. In order to ensure interoperability with existing BGP peers that do not support 4-byte AS, encoding of BGP OPEN message is reserved and 4-byte AS support is exchanged between the BGP peers via the capability field.

In this whitepaper, we will refer to the BGP speaker that supports 4-byte AS as NEW speaker, and the BGP speaker that does not support 4-byte AS as OLD speaker.

When BGP attempts to establish a session with its peer, the OPEN message may include an optional parameter, called Capabilities. A NEW speaker will include the NEW (4-byte AS) capability when it attempts to OPEN a session with its peer. An OLD speaker should simply ignore the NEW capability advertised by its peer and continue to operate in OLD mode, as detailed in RFC 3392.

If the NEW speaker advertises and receives the 4-byte AS capability from its peer, it will just encode the 4-byte AS number in its AS_PATH or AGGREGATOR attributes when exchanging information with this peer.

If the NEW speaker does not receive the 4-byte AS capability from a particular peer, it indicates this peer is an OLD speaker. Two new attributes are introduced, namely AS4_PATH and AS4_AGGREGATOR. Both attributes are optional transitive. These new attributes use the same encoding as the original ASPATH and AGGREGATOR except the AS Number used is 4-bytes instead of 2-bytes. The NEW speaker will substitute a reserved 2-byte AS number (called AS_TRANS with AS # 23456) for each 4-byte AS so that ASPATH and AGGREGATOR is still 2-byte in length and ASPATH length is still preserved, and at the same time insert the new AS4_PATH and AS4_AGGREGATOR, which will contain the 4-byte encoded copy of the attributes. The NEW speaker will then advertise ASPATH and/or AGGREGATOR together with the AS4_PATH and/or AS4_AGGREGATOR. The OLD speaker that receives these new attributes will preserve and blindly pass them along even though it does not understand them. Subsequent NEW speakers will merge the ASPATH and/or AGGREGATOR with the AS4_PATH and/or AS4_AGGREGATOR to retrieve the original 4-byte AS information without losing any attribute contents, as illustrated in the Figure 1.

Incident: MS08-020, NR-4002/0 (UDP Host Flood)

Figure 1

Figure 1 is an example how AS4_PATH works in a mixed environment with both NEW and OLD BGP speakers. The figure illustrates how an OLD speaker can interoperate with NEW speakers in a mixed environment in the Internet.

Since Router C is an OLD speaker AS, Router B substitutes ASPATH with AS_TRANS (AS# 23456) and encodes the 4-byte AS information into AS4_PATH in BGP updates advertised to Router C.

Router C does not understand the AS4_PATH content, but it will preserve the AS4_PATH attribute and send it along to Router D.

Since Router D supports 4-byte AS, it will in turn merge the information received from both ASPATH and AS4_PATH, and encodes 4-byte AS when it advertises the ASPATH attribute to Router E, and so forth.

The AGGREGATOR scenario will work exactly the same way in a mixed environment, as described in Figure 1.

A special note on confederation: In order to prevent the possible propagation of confederation path information from escaping outside of a confederation, the AS_CONFED_SEQUENCE and AS_CONFRED_SET are declared invalid in the new AS4_PATH attribute, as per the RFC. Details about confederation support with 4-byte AS are contained in RFC 4893.

Support of 4-byte AS on C12K and CRS-1

Both CRS-1 and XR12K support 4-byte AS since IOS XR Software Release 3.4.0, while C12K running 12.0S does not support 4-byte AS. Below are frequently asked questions related to 4-byte AS support with 12.0S.

Question: Does C12K support 4-byte AS in 12.0S today?
Answer: 4-byte AS is supported in 12.0(32)S12 and 12.0(32)SY8 on C12K today (as of March, 2008).

Question: Without 4-byte AS in 12.0S on C12K, can C12K still interoperate with our BGP peers that support 4-byte AS?
Answer: As described in the previous section, the existing C12K running 12.0S deployed on the Internet can fully interoperate with peers with 4-byte AS capability in a mixed environment with both OLD and NEW speakers. It allows ISPs to continue to use their existing C12K with 12.0S, even after January 2009, until they migrate the C12K to run the latest version of IOS Software or IOS XR Software on which 4-byte AS is fully supported, hence a gradual migration.

Question: What is the plan to support 4-byte AS in 12.0S for C12K?
Answer: 4-byte AS is supported on C12K in 12.0(32)S12 and 12.0(32)SY8. It is also planned for 12.0(33)S3 releases. Alternatively, customers can migrate to a version of IOS XR Software that already supports 4-byte AS. Please contact your Cisco representatives for more information.

Configuring 4-byte AS

It is in fact very simple to configure 4-byte AS number in IOS XR Software, as shown in the following example:

RP/0/RP0/CPU0:P1(config)#router bgp ?    
<1-65535> AS # for our autonomous system
<1-65535>. AS # for our autonomous system (xx.yy format)
RP/0/RP0/CPU0:P1(config)#router bgp 100.1
RP/0/RP0/CPU0:P1(config-bgp)#address-family ipv4 unicast
RP/0/RP0/CPU0:P1(config-bgp)#...

RP/0/RP0/CPU0:P1(config-bgp-af)#commit
RP/0/RP0/CPU0:Jul 31 10:07:02.812 : config[65740]: %MGBL-CONFIG-6-DB_COMMIT :
Configuration committed by user 'cisco'. Use 'show configuration commit changes 1000000022' to view the changes.
RP/0/RP0/CPU0:P1#show run router bgp
router bgp 100.1
address-family ipv4 unicast

!

All the show/clear commands remain the same, except they are now capable of recognizing and displaying 4-byte AS numbers, as shown in the following example:

RP/0/RP0/CPU0:P1#clear bgp as ?
<1-65535> Clear peers with the AS number
<1-65535>. Clear peers with the AS number (xx.yy format)

All the show/clear commands remain the same, except they are now capable of recognizing and displaying 4-byte AS numbers, as shown in the following example:

RP/0/RP0/CPU0:P1#clear bgp as ?
<1-65535> Clear peers with the AS number
<1-65535>. Clear peers with the AS number (xx.yy format)

The 4-byte AS BGP Extended Community can also be configured, as shown below:

RP/0/RP0/CPU0:P1(config)#extcommunity-set ?
  cost  EIGRP Cost Community type extended community
  rt    BGP Route Target (RT) extended community
  soo   BGP Site of Origin (SoO) extended community

RP/0/RP0/CPU0:P1(config)#extcommunity-set soo extcommsooset
RP/0/RP0/CPU0:P1(config-ext)#?
  #-remark     Remark beginning with '#'
  *            Wildcard (any community or part thereof)
  A.B.C.D/M:N  Extended community - IPv4 prefix format
  A.B.C.D:N    Extended community - IPv4 format
  ASN:N        Extended community - 2 byte ASN format
  NN           Autonomous system number (2 bytes)
  X.Y:N        Extended community - 4 byte ASN format
  abort        Discard RPL definition and return to top level config
  end-set      End of set definition
  exit         Exit from this submode
  ios-regex    Traditional IOS style regular expression
  show         Show partial RPL configuration

RP/0/RP0/CPU0:P1(config)#extcommunity-set rt extcommrtset
RP/0/RP0/CPU0:P1(config-ext)#?
  #-remark     Remark beginning with '#'
  *            Wildcard (any community or part thereof)
  A.B.C.D/M:N  Extended community - IPv4 prefix format
  A.B.C.D:N    Extended community - IPv4 format
  ASN:N        Extended community - 2 byte ASN format
  NN           Autonomous system number (2 bytes)
  X.Y:N        Extended community - 4 byte ASN format
  abort        Discard RPL definition and return to top level config
  end-set      End of set definition
  exit         Exit from this submode
  ios-regex    Traditional IOS style regular expression
  show         Show partial RPL configuration

The 4-byte AS BGP Extended Community can also be configured, as shown below:

RP/0/RP0/CPU0:P1#show bgp neighbor 10.1.1.2

BGP neighbor is 10.1.1.2
 Remote AS 200, local AS 23456, external link
 Remote router ID 10.10.66.222
  BGP state = Established, up for 00:05:58
  Last read 00:00:57, hold time is 180, keepalive interval is 60 seconds
  Last write 00:00:53, Last write before reset 00:07:26
  Precedence: internet
  Neighbor capabilities:
    Route refresh: advertised and received
    4-byte AS: advertised
    Address family IPv4 Unicast: advertised and received
  Received 98 messages, 0 notifications, 0 in queue
  Sent 103 messages, 4 notifications, 0 in queue
  Minimum time between advertisement runs is 30 seconds

 For Address Family: IPv4 Unicast
  BGP neighbor version 7

[Output truncated]

The 4-byte AS BGP Extended Community can also be configured, as shown below:

G1#show run | b router bgp
router bgp 200
 no synchronization
 bgp log-neighbor-changes
 neighbor 10.1.1.1 remote-as 23456
 no auto-summary

[output truncated]

G1#show ip bgp
BGP table version is 21, local router ID is 10.10.66.222
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.1/32       10.1.1.1                 0             0 23456 23456 ?
*> 1.61.0.0/16      10.1.1.1                 0             0 23456 23456 ?
*> 192.100.1.0      10.1.1.1                 0             0 23456 23456 ?

Acknowledgments

Written by Wilson Ching, TME, Service Provider Group

References

Implementing BGP on Cisco IOS XR Software
http://www.cisco.com/en/US/docs/ios_xr_sw/iosxr_r3.6/routing/configuration/guide/rc36bgp.html

RFC 4893, BGP Support for Four-octet AS Number Space
http://www.ietf.org/rfc/rfc4893.txt

RFC 3392, Capabilities Advertisement with BGP-4
http://www.ietf.org/rfc/rfc3392.txt?number=3392

Generic Subtype for BGP Four-octet AS specific extended community, draft-ietf-idr-as4octet-extcomm-generic-subtype-00.txt
http://www.ietf.org/internet-drafts/draft-ietf-idr-as4octet-extcomm-generic-subtype-00.txt

ARIN Number Resource Policy Manual, 16-bit and 32-bit AS Numbers
https://www.arin.net/policy/nrpm.html#five1

RIPE NCC - Autonomous System (AS) Number Assignment Policies and Procedures, 32-bit AS Numbers
http://www.ripe.net/ripe/docs/asn-assignment.html#19

APNIC - Policies for Autonomous System number management in the Asia Pacific region, Timetable for moving from two-byte only AS numbers to four-byte AS numbers
http://www.apnic.net/policy/asn-policy.html#6.3


This document is part of the Cisco Security Center.

This document is provided on an "as is" basis and does not imply any kind of guarantee or warranty, including the warranties of merchantability or fitness for a particular use. Your use of the information on the document or materials linked from the document is at your own risk. Cisco reserves the right to change or update this document at any time.

Back to Top

Cisco Security Center