BGP 4 Byte AS number Support

https://blog.initialdraft.com/archives/3985/?utm_source=tuicool（原文）

Long time ago when BGP was under development, it was assumed that a 16 bit (2 bytes) number for the Autonomous System (AS) was more than enough (65536 AS Numbers), but the same situation as with IPv4 happened, we are running out of AS numbers “basically” at the same speed as IPv4 addresses. Strategies where put in place to keep the business rolling, like reusing old orphan AS numbers, but something drastically had to be done. The solution was to create a bigger AS number space with 32 bits (4 bytes) that provides a pool of 4,294,967,296 BGP AS numbers.

The problem with this new strategy of a bigger AS space is that Old BGP systems that only support 2 bytes AS number would have problems to deal with this new design. Some kind of backward compatibility implementation was needed. In this post we are going to discuss the details.

The 4 byte AS implementation and compatibility design is built around the following features:

• New capability for the 32 bit (4 byte) AS numbers
• New optional transitive attributes (AS4_PATH and AS4_AGGREGATOR)
• New extended communities
• A well known transit AS number “23456″ to represent 4 bytes AS numbers to old BGP devices that don’t understand the 4 byte as.

The issues with the 4 byte as number presents at peering build up and when Old 2 byte only BGP devices are in the middle of the transit path.

Peering:

When building a session, the devices that support the new 4 byte AS number advertise a new capability (Code 65) to let the peer know that they can work with this new 32 bit BGP AS format. If both support the capability they will exchange AS path information in a 4 octets format.

I have captured the Open Message of a BGP peer with 4 Byte ASN support:

Border Gateway Protocol    OPEN Message        Marker: 16 bytes        Length: 58 bytes        Type: OPEN Message (1)        Version: 4        My AS: 23456        Hold time: 180        BGP identifier: 192.168.0.1        Optional parameters length: 29 bytes        Optional parameters            Capabilities Advertisement (8 bytes)                Parameter type: Capabilities (2)                Parameter length: 6 bytes                Multiprotocol extensions capability (6 bytes)                    Capability code: Multiprotocol extensions capability (1)                    Capability length: 4 bytes                    Capability value                        Address family identifier: IPv4 (1)                        Reserved: 1 byte                        Subsequent address family identifier: Unicast (1)            Capabilities Advertisement (4 bytes)                Parameter type: Capabilities (2)                Parameter length: 2 bytes                Route refresh capability (2 bytes)                    Capability code: Route refresh capability (128)                    Capability length: 0 bytes            Capabilities Advertisement (4 bytes)                Parameter type: Capabilities (2)                Parameter length: 2 bytes                Route refresh capability (2 bytes)                    Capability code: Route refresh capability (2)                    Capability length: 0 bytes            Capabilities Advertisement (5 bytes)                Parameter type: Capabilities (2)                Parameter length: 3 bytes                Unknown capability (3 byte)                    Capability code: Unknown capability (131)                    Capability code: Private use (131)                    Capability length: 1 byte                    Capability value: Unknown            Capabilities Advertisement (8 bytes)                Parameter type: Capabilities (2)                Parameter length: 6 bytes                Support for 4-octet AS number capability (6 bytes)                    Capability code: Support for 4-octet AS number capability (65)                    Capability length: 4 bytes                    Capability value                        AS number: 65537

You can see that initially the router “presents” itself with a “My AS” of 23456 to be able to communicate with any device (it does not know yet the capabilities of the other side). It advertise on the Open messages that it supports the 4 bytes AS number (Support for 4-octet AS number capability) and indicates its real AS number (65537, in dotted format 1.1), if the other side also support 4 bytes ASN, then the real AS is used.

If one of the peering sides is only 2 byte ASN capable and the 4 byte side possess an AS that is also larger than two bytes (25000 is 2 bytes compatible AS, 256000 is not), the 4 byte speaker will swap its 4 byte AS number with the well known AS number 23456. If the AS number fit into a 16 bit format, then no other manipulation is done.

The only issue at the peering phase with replacing the AS number with the AS_TRANS number (23456) is that the device believes that is pearing with an AS that in reality does not exist.

Transit through a 2 byte BGP only capable device

The AS Path is a Well known Mandatory attribute, which means that every BGP speaking device should process it and understand it. A 2 byte only capable device wouldn’t understand a 4 byte AS number in the path. The AS Path is crucial on the BGP decision process and a very important factor on the loop prevention.

When a Updates needs to be pushed from a 4 byte capable BGP router to a 2 byte only device the following happens: If the 4 byte AS capable device possess a large 32 bit AS number, the 32 bit AS in the AS_PATH is replaced with the “23456″ AS_TRANS number.The “real” AS PATH including the 32 bit AS number is “encoded” into two optional transitive attributes, AS4_PATH and AS4_AGGREGATOR, because this attributes are “optional transitive” the 2 byte BGP speaker won’t touch it or see it, as it does not know anything about it, but will forward it to the next BGP device.

When a 4 byte AS capable BGP peer receives an update from a 2 byte only peer, it will use both the AS_PATH and AS4_PATH attribute to rebuild the transit information. The AS_PATH information is needed because in the 2 byte AS domain additional AS could have been pushed by 2 byte capable devices (they don’t touch the AS4_PATH!), and the AS4_PATH is also needed to correctly reflect the real AS number that where translated to “23456”.

This mechanism would be clearly seen on my configuration example.

Configuration

I have built a simple topology with 5 routers connected together using ethernet interfaces and peering between them using loopback interfaces.

Two of the devices are running 2 byte only capable IOS (R3 and R4), they are marked “Red” in the graph. The rest are using 32 bit capable IOS images (R1, R2 and R5).

Two key points: You can see that 2 Byte only routers are peering with 4 byte capable routers using the AS_TRANS number (23456), and that I’m using dotted format for writing ASN numbers (I’m too lazy to write big numbers).

Here the configuration:

R1router bgp 1.1 no synchronization bgp asnotation dot bgp log-neighbor-changes neighbor 2.2.2.2 remote-as 2.2 neighbor 2.2.2.2 ebgp-multihop 255 neighbor 2.2.2.2 update-source Loopback0 no auto-summaryR2router bgp 2.2 no synchronization bgp asnotation dot bgp log-neighbor-changes neighbor 1.1.1.1 remote-as 1.1 neighbor 1.1.1.1 ebgp-multihop 255 neighbor 1.1.1.1 update-source Loopback0 neighbor 3.3.3.3 remote-as 300 neighbor 3.3.3.3 ebgp-multihop 255 neighbor 3.3.3.3 update-source Loopback0 no auto-summaryR3router bgp 300 no synchronization bgp log-neighbor-changes neighbor 2.2.2.2 remote-as 23456 neighbor 2.2.2.2 ebgp-multihop 255 neighbor 2.2.2.2 update-source Loopback0 neighbor 4.4.4.4 remote-as 400 neighbor 4.4.4.4 ebgp-multihop 255 neighbor 4.4.4.4 update-source Loopback0 no auto-summaryR4router bgp 400 no synchronization bgp log-neighbor-changes neighbor 3.3.3.3 remote-as 300 neighbor 3.3.3.3 ebgp-multihop 255 neighbor 3.3.3.3 update-source Loopback0 neighbor 5.5.5.5 remote-as 23456 neighbor 5.5.5.5 ebgp-multihop 255 neighbor 5.5.5.5 update-source Loopback0 no auto-summaryR5router bgp 5.5 no synchronization bgp asnotation dot bgp log-neighbor-changes neighbor 4.4.4.4 remote-as 400 neighbor 4.4.4.4 ebgp-multihop 255 neighbor 4.4.4.4 update-source Loopback0 no auto-summary

In R5 I’m going to advertise a network into BGP: network 192.168.55.0, to see the Update process.

R4 Receives the Following UPDATE from R5 (the device originating the update)

Border Gateway Protocol    UPDATE Message        Marker: 16 bytes        Length: 61 bytes        Type: UPDATE Message (2)        Unfeasible routes length: 0 bytes        Total path attribute length: 34 bytes        Path attributes            ORIGIN: IGP (4 bytes)                Flags: 0x40 (Well-known, Transitive, Complete)                    0... .... = Well-known                    .1.. .... = Transitive                    ..0. .... = Complete                    ...0 .... = Regular length                Type code: ORIGIN (1)                Length: 1 byte                Origin: IGP (0)            NEW_AS_PATH: 327685 (9 bytes)                Flags: 0xc0 (Optional, Transitive, Complete)                    1... .... = Optional                    .1.. .... = Transitive                    ..0. .... = Complete                    ...0 .... = Regular length                Type code: NEW_AS_PATH (17)                Length: 6 bytes                AS path: 327685                    AS path segment: 327685                        Path segment type: AS_SEQUENCE (2)                        Path segment length: 1 AS                        Path segment value: 327685            AS_PATH: 23456 (7 bytes)                Flags: 0x40 (Well-known, Transitive, Complete)                    0... .... = Well-known                    .1.. .... = Transitive                    ..0. .... = Complete                    ...0 .... = Regular length                Type code: AS_PATH (2)                Length: 4 bytes                AS path: 23456                    AS path segment: 23456                        Path segment type: AS_SEQUENCE (2)                        Path segment length: 1 AS                        Path segment value: 23456            NEXT_HOP: 5.5.5.5 (7 bytes)                Flags: 0x40 (Well-known, Transitive, Complete)                    0... .... = Well-known                    .1.. .... = Transitive                    ..0. .... = Complete                    ...0 .... = Regular length                Type code: NEXT_HOP (3)                Length: 4 bytes                Next hop: 5.5.5.5 (5.5.5.5)            MULTI_EXIT_DISC: 0 (7 bytes)                Flags: 0x80 (Optional, Non-transitive, Complete)                    1... .... = Optional                    .0.. .... = Non-transitive                    ..0. .... = Complete                    ...0 .... = Regular length                Type code: MULTI_EXIT_DISC (4)                Length: 4 bytes                Multiple exit discriminator: 0        Network layer reachability information: 4 bytes            192.168.55.0/24                NLRI prefix length: 24                NLRI prefix: 192.168.55.0 (192.168.55.0)

Pay special attention to the highlighted sections.

In the “NEW_AS_PATH” (AS4_PATH), you can see there that R5 (AS 5.5) has included its real AS number on that optional transitive attribute, and that the AS_PATH includes the 23456 ASN so R4 (2 byte only capable) can understand it.

When the update reaches R3 interface heading to R2 (Update going from R3 to R2), it looks like this:

Border Gateway Protocol    UPDATE Message        Marker: 16 bytes        Length: 58 bytes        Type: UPDATE Message (2)        Unfeasible routes length: 0 bytes        Total path attribute length: 31 bytes        Path attributes            ORIGIN: IGP (4 bytes)                Flags: 0x40 (Well-known, Transitive, Complete)                    0... .... = Well-known                    .1.. .... = Transitive                    ..0. .... = Complete                    ...0 .... = Regular length                Type code: ORIGIN (1)                Length: 1 byte                Origin: IGP (0)            AS_PATH: 300 400 23456 (11 bytes)                Flags: 0x40 (Well-known, Transitive, Complete)                    0... .... = Well-known                    .1.. .... = Transitive                    ..0. .... = Complete                    ...0 .... = Regular length                Type code: AS_PATH (2)                Length: 8 bytes                AS path: 300 400 23456                    AS path segment: 300 400 23456                        Path segment type: AS_SEQUENCE (2)                        Path segment length: 3 ASs                        Path segment value: 300 400 23456            NEXT_HOP: 3.3.3.3 (7 bytes)                Flags: 0x40 (Well-known, Transitive, Complete)                    0... .... = Well-known                    .1.. .... = Transitive                    ..0. .... = Complete                    ...0 .... = Regular length                Type code: NEXT_HOP (3)                Length: 4 bytes                Next hop: 3.3.3.3 (3.3.3.3)            NEW_AS_PATH: 327685 (9 bytes)                Flags: 0xe0 (Optional, Transitive, Partial)                    1... .... = Optional                    .1.. .... = Transitive                    ..1. .... = Partial                    ...0 .... = Regular length                Type code: NEW_AS_PATH (17)                Length: 6 bytes                AS path: 327685                    AS path segment: 327685                        Path segment type: AS_SEQUENCE (2)                        Path segment length: 1 AS                        Path segment value: 327685        Network layer reachability information: 4 bytes            192.168.55.0/24                NLRI prefix length: 24                NLRI prefix: 192.168.55.0 (192.168.55.0)

Look how the “NEW_AS_PATH” (AS4_PATH) is untouched (327685). Why?, because the update have only passed through 2 bytes capable routers, and they don’t understand that attribute, on the other hand the AS_PATH have been properly updated (300 400 23456).

When the update reaches R2 (4 byte capable), he is going to use both attributes to rebuild the “real” transit, replacing the occurrences of 23456 on the AS_PATH with the information on the AS4_PATH.

When the Update goes out from R2 to R1, it looks like this:

Border Gateway Protocol    UPDATE Message        Marker: 16 bytes        Length: 59 bytes        Type: UPDATE Message (2)        Unfeasible routes length: 0 bytes        Total path attribute length: 32 bytes        Path attributes            ORIGIN: IGP (4 bytes)                Flags: 0x40 (Well-known, Transitive, Complete)                    0... .... = Well-known                    .1.. .... = Transitive                    ..0. .... = Complete                    ...0 .... = Regular length                Type code: ORIGIN (1)                Length: 1 byte                Origin: IGP (0)            AS_PATH: 131074 300 400 327685 (21 bytes)                Flags: 0x40 (Well-known, Transitive, Complete)                    0... .... = Well-known                    .1.. .... = Transitive                    ..0. .... = Complete                    ...0 .... = Regular length                Type code: AS_PATH (2)                Length: 18 bytes                AS path: 131074 300 400 327685                    AS path segment: 131074 300 400 327685                        Path segment type: AS_SEQUENCE (2)                        Path segment length: 4 ASs                        Path segment value: 131074 300 400 327685            NEXT_HOP: 2.2.2.2 (7 bytes)                Flags: 0x40 (Well-known, Transitive, Complete)                    0... .... = Well-known                    .1.. .... = Transitive                    ..0. .... = Complete                    ...0 .... = Regular length                Type code: NEXT_HOP (3)                Length: 4 bytes                Next hop: 2.2.2.2 (2.2.2.2)        Network layer reachability information: 4 bytes            192.168.55.0/24                NLRI prefix length: 24                NLRI prefix: 192.168.55.0 (192.168.55.0)

Look how the “AS4_PATH” (NEW_AS_PATH) is no longer in this update. Why?, because both devices understand perfectly the 4 byte format. In this update, the whole path is perfectly reflected on the AS_PATH attribute 131074 300 400 327685 (in dotted format: 2.2 300 400 5.5)