BGP prefers the route with the shortest AS_Path length (the number of included ASs) during BGP route selection.
Four types of AS_Path attributes are available: AS_Sequence, AS_Set, AS_Confed_Sequence, and AS_Confed_Set.
AS_Sequence: records in reverse order all the ASs through which a route passes from the local device to the destination.
AS_Set: records in random order all the ASs through which a route passes from the local device to the destination. The AS_Set attribute is used in route summarization scenarios.
AS_Confed_Sequence: records in reverse order all the sub-ASs within a BGP confederation through which a route passes from the local device to the destination.
AS_Confed_Set: records in random order all the sub-ASs within a BGP confederation through which a route passes from the local device to the destination.
Item |
Description |
---|---|
AS_Set |
BGP takes an AS_Set as one AS number even if the AS_Set contains multiple AS numbers. When the aggregate (BGP) command is run to manually generate a summary route, if as-set is specified in the command, an AS_Set will be carried in the summary route. Otherwise, no AS_Set will be carried. The information in the AS_Set is as follows:
|
AS_Confed_Sequence and AS_Confed_Set |
BGP ignores AS_Confed_Sequence and AS_Confed_Set when calculating the AS_Path length. |
After the command is run, BGP does not compare the AS_Path lists carried in candidate routes during route selection. |
|
The command can be run to configure an apply clause for a route-policy so that the ASs in the AS_Path of the route that matches the route-policy are cleared or replaced, or new ASs are added. NOTE:
The configuration of the apply as-path command may change the traffic forwarding path, or cause routing loops or route selection errors. Therefore, exercise caution when configuring the command. |
|
After the command is run, BGP removes all the private AS numbers (if any) from the AS_Path attribute in each Update message to be sent. The private AS number ranges from 64512 to 65534.
NOTE:
If the 4-byte private AS number function is enabled using the private-4-byte-as enable command, private AS numbers range from 64512 to 65534 and from 4200000000 to 4294967294 (64086.59904 to 65535.65534 in the format of x.y). |
|
After the command is run, BGP removes all the private AS numbers (if any) from the AS_Path attribute in each received Update message. The private AS number ranges from 64512 to 65534.
NOTE:
If the 4-byte private AS number function is enabled using the private-4-byte-as enable command, private AS numbers range from 64512 to 65534 and from 4200000000 to 4294967294 (64086.59904 to 65535.65534 in the format of x.y). |
|
After the command is run, BGP can use a fake AS number to set up a BGP peer relationship. If the local device uses the actual AS number to establish an EBGP peer relationship with a remote device, the actual AS number is carried in the AS_Path of the route sent to the remote device. If the local device uses the fake AS number to establish the EBGP peer relationship, the fake AS number is carried in the AS_Path of the route sent to the remote device. |
|
After the command is run, if the AS_Path attribute in the route that a PE will send to its connected CE through a BGP peer relationship contains an AS number the same as that of the CE, the PE replaces the AS number in the AS_Path attribute with its local AS number before advertising this route.
NOTE:
The peer substitute-as command applies only to PEs in BGP MPLS IP/VPN scenarios and may cause routing loops if it is improperly configured. Therefore, exercise caution when using the command. |
During BGP route selection, BGP compares the AS_Path length by calculating the number of ASs included in the AS_Sequence if AS_Sequence is carried in a route. If both AS_Sequence and AS_Set are carried in the route, BGP considers the AS_Path length to be the number of ASs included in the AS_Sequence plus 1. The following describes some common commands in detail by using examples.
In Figure 1, DeviceA advertises the route 10.0.0.0/8 to DeviceD through ISP1 and ISP2. After receiving this route, DeviceD checks its AS_Path attribute. This AS_Path attribute carries AS 65001, which is the same as the AS number of DeviceD. As a result, DeviceD discards this route.
To address this problem, run the peer public-as-only command on DeviceB so that DeviceB in ISP1 deletes AS 65001 before adding AS 100 (public AS) to the AS_Path attribute and forwarding the route to DeviceC in ISP2.
The AS_Path of a route carries the AS number of the remote peer. In this case, deleting private AS numbers may lead to a routing loop.
The AS_Path carries both public and private AS numbers, which indicates that the route has passed through the public network. In this case, deleting private AS numbers may lead to incorrect traffic forwarding.
Run the display bgp routing-table [ ip-address ] command to verify the configuration.
# Display the routing table of DeviceA.
[~DeviceA] display bgp routing-table BGP Local router ID is 10.1.1.1 Status codes: * - valid, > - best, d - damped, x - best external, a - add path, h - history, i - internal, s - suppressed, S - Stale Origin : i - IGP, e - EGP, ? - incomplete RPKI validation codes: V - valid, I - invalid, N - not-found Total Number of Routes: 6 Network NextHop MED LocPrf PrefVal Path/Ogn *> 172.16.1.0/24 10.1.3.2 0 65003 65005? * 10.1.1.2 0 65002 65004 65005? *> 172.16.2.0/24 10.1.3.2 0 65003 65005? * 10.1.1.2 0 65002 65004 65005? *> 172.16.3.0/24 10.1.3.2 0 65003 65005? * 10.1.1.2 0 65002 65004 65005? [~DeviceA] display bgp routing-table 172.16.1.0 BGP local router ID : 10.1.1.1 Local AS number : 65001 Paths: 2 available, 1 best, 1 select BGP routing table entry information of 172.16.1.0/24: From: 10.1.3.2 (10.1.5.1) Route Duration: 00h00m56s Direct Out-interface: GigabitEthernet0/1/0 Original nexthop: 10.1.3.2 Qos information : 0x0 AS-path 65003 65005, origin incomplete, pref-val 0, valid, external, best, select, active, pre 255 Advertised to such 2 peers: 10.1.3.2 10.1.1.2 BGP routing table entry information of 172.16.1.0/24: From: 10.1.1.2 (10.1.1.2) Route Duration: 00h34m43s Direct Out-interface: GigabitEthernet0/1/8 Original nexthop: 10.1.1.2 Qos information : 0x0 AS-path 65002 65004 65005, origin incomplete, pref-val 0, valid, external, pre 255, not preferred for AS-Path Not advertised to any peer yet
The preceding command output shows that DeviceA selects the route learned from DeviceC because this route has a shorter AS_Path length than that learned from DeviceB. To enable DeviceA to select the route learned from DeviceB, configure DeviceB to reduce the AS_Path length of the route or configure DeviceC to increase the AS_Path length of the route. In the following example, DeviceC is configured to increase the AS_Path length of the route. The detailed configurations on DeviceC are as follows:
# bgp 65003 # ipv4-family unicast undo synchronization peer 10.1.3.1 route-policy add_asn export //Apply export policy named add_asn to the routes to be advertised to BGP peer 10.1.3.1. # route-policy add_asn permit node 10 //Define the first node of add_asn. if-match ip-prefix prefix1 //Configure IP prefix list named prefix1. apply as-path 65003 65003 65003 additive //Add 65003, 65003, 65003 to the AS_Path of the route that matches the IP prefix list prefix1. # route-policy add_asn permit node 20 //Define the second node of add_asn to permit all other routes. # ip ip-prefix prefix1 index 10 permit 172.16.1.0 24 //Define the first index of prefix1 to match the route 172.16.1.0/24. ip ip-prefix prefix1 index 20 permit 172.16.2.0 24 //Define the second index of prefix1 to match the route 172.16.2.0/24. ip ip-prefix prefix1 index 30 permit 172.16.3.0 24 //Define the third index of prefix1 to match the route 172.16.3.0/24. #
Run the display bgp routing-table [ ip-address ] command to verify the configuration.
# Display the routing table of DeviceA.
[~DeviceA] display bgp routing-table BGP Local router ID is 10.1.1.1 Status codes: * - valid, > - best, d - damped, x - best external, a - add path, h - history, i - internal, s - suppressed, S - Stale Origin : i - IGP, e - EGP, ? - incomplete RPKI validation codes: V - valid, I - invalid, N - not-found Total Number of Routes: 6 Network NextHop MED LocPrf PrefVal Path/Ogn *> 172.16.1.0/24 10.1.1.2 0 65002 65004 65005? * 10.1.3.2 0 65003 65003 65003 65003 65005? *> 172.16.2.0/24 10.1.1.2 0 65002 65004 65005? * 10.1.3.2 0 65003 65003 65003 65003 65005? *> 172.16.3.0/24 10.1.1.2 0 65002 65004 65005? * 10.1.3.2 0 65003 65003 65003 65003 65005? [~DeviceA] display bgp routing-table 172.16.1.0 BGP local router ID : 10.1.1.1 Local AS number : 65001 Paths: 2 available, 1 best, 1 select BGP routing table entry information of 172.16.1.0/24: From: 10.1.1.2 (10.1.1.2) Route Duration: 00h33m30s Direct Out-interface: GigabitEthernet0/1/0 Original nexthop: 10.1.1.2 Qos information : 0x0 AS-path 65002 65004 65005, origin incomplete, pref-val 0, valid, external, best, select, active, pre 255 Advertised to such 2 peers: 10.1.3.2 10.1.1.2 BGP routing table entry information of 172.16.1.0/24: From: 10.1.3.2 (10.1.5.1) Route Duration: 00h02m12s Direct Out-interface: GigabitEthernet0/1/8 Original nexthop: 10.1.3.2 Qos information : 0x0 AS-path 65003 65003 65003 65003 65005, origin incomplete, pref-val 0, valid, external, pre 255, not preferred for AS-Path Not advertised to any peer yet
Route Attribute |
Route Learned from DeviceB |
Route Learned from DeviceC |
Comparison |
---|---|---|---|
PrefVal |
0 |
0 |
The same. |
Local_Pref |
- |
- |
The same. |
Route type |
Learned from a peer |
Learned from a peer |
The same. |
AIGP |
- |
- |
The same. |
AS_Path |
65002 65004 65005 |
65003 65003 65003 65003 65005 |
The route learned from DeviceB is optimal. |
AS numbers can be added to the AS_Path as required. However, if an AS number is added to the AS_Path of a BGP route, the route cannot be received by devices in this AS. Therefore, the local AS number is added in most cases. For example in Figure 2, if DeviceC adds AS 65001 to the AS_Path of a route before advertising the route to DeviceA, DeviceA will discard the route upon receipt because the route carries DeviceA's AS number.
Shield the actual path information.
Prevent a route from being discarded by replacing the AS_Path attribute of the route with a shorter one if the as-path-limit command is run on the device that receives this route.
Reduce the AS_Path length.
AS number replacement can also be used for the purpose of load balancing. Generally, BGP requires that the AS_Path attributes of the routes be the same so that load balancing can be implemented. To meet load balancing requirements, AS numbers can be replaced. For example in Figure 2, the apply as-path 65002 65004 65005 overwrite command can be run on DeviceA to replace the AS_Path of the route learned from DeviceC so that the route has the same AS_Path as that of the route learned from DeviceB, and the two routes are used to load-balance traffic. Detailed configurations on DeviceA are as follows:
# bgp 65001 # ipv4-family unicast undo synchronization peer 10.1.3.2 route-policy replace_asn import //Apply import policy named replace_asn to routes to be received from BGP peer 10.1.3.2. # route-policy replace_asn permit node 10 //Define the first node of the route-policy named replace_asn. if-match as-path-filter filter1 //Configure AS_Path filter named filter1. apply as-path 65002 65004 65005 overwrite //Replace the AS_Path of the route that matches filter1 with 65002, 65004, 65005. # route-policy replace_asn permit node 20 //Define the second node of replace_asn to permit all other routes. # ip as-path-filter filter1 permit ^65003 //Define AS_Path filter named filter1 to match all the routes learned from AS 65003. #
Run the display bgp routing-table [ ip-address ] command to verify the configuration.
# Display the routing table of DeviceA.
[~DeviceA] display bgp routing-table BGP Local router ID is 10.1.1.1 Status codes: * - valid, > - best, d - damped, x - best external, a - add path, h - history, i - internal, s - suppressed, S - Stale Origin : i - IGP, e - EGP, ? - incomplete RPKI validation codes: V - valid, I - invalid, N - not-found Total Number of Routes: 6 Network NextHop MED LocPrf PrefVal Path/Ogn *> 172.16.1.0/24 10.1.1.2 0 65002 65004 65005? * 10.1.3.2 0 65002 65004 65005? *> 172.16.2.0/24 10.1.1.2 0 65002 65004 65005? * 10.1.3.2 0 65002 65004 65005? *> 172.16.3.0/24 10.1.1.2 0 65002 65004 65005? * 10.1.3.2 0 65002 65004 65005?
The preceding command output shows that the AS_Path of the route received from AS 65003 has been replaced. In this case, the routes sent from AS 65002 and AS 65003 have the same AS_Path, which meets the load balancing conditions. Run the maximum load-balancing 2 command on DeviceA to set the maximum number of routes for load balancing to 2. Then, check the detailed BGP route information. The route 172.16.1.0/24 is used in the following example:
[~DeviceA] display bgp routing-table 172.16.1.0 BGP local router ID : 10.1.1.1 Local AS number : 65001 Paths: 2 available, 1 best, 2 select BGP routing table entry information of 172.16.1.0/24: From: 10.1.1.2 (10.1.1.2) Route Duration: 19h57m51s Direct Out-interface: GigabitEthernet0/1/0 Original nexthop: 10.1.1.2 Qos information : 0x0 AS-path 65002 65004 65005, origin incomplete, pref-val 0, valid, external, best, select, active, pre 255 Advertised to such 2 peers: 10.1.1.2 10.1.3.2 BGP routing table entry information of 172.16.1.0/24: From: 10.1.3.2 (10.1.5.1) Route Duration: 00h10m21s Direct Out-interface: GigabitEthernet0/1/8 Original nexthop: 10.1.3.2 Qos information : 0x0 AS-path 65002 65004 65005, origin incomplete, pref-val 0, valid, external, select, active, pre 255, not preferred for router ID Not advertised to any peer yet
The preceding command output shows that the route learned from DeviceB is optimal and is used by BGP along with the route learned from DeviceC (not optimal) for load balancing. Check the information about the route 172.16.1.0/24 in the IP routing table.
[~DeviceA] display ip routing-table Route Flags: R - relay, D - download to fib, T - to vpn-instance, B - black hole route ------------------------------------------------------------------------------ Routing Table : _Public_ Destinations : 9 Routes : 12 Destination/Mask Proto Pre Cost Flags NextHop Interface 10.1.1.0/30 Direct 0 0 D 10.1.1.1 GigabitEtherne0/1/8 10.1.1.1/32 Direct 0 0 D 127.0.0.1 GigabitEthernet0/1/8 10.1.3.0/30 Direct 0 0 D 10.1.3.1 GigabitEthernet0/1/0 10.1.3.1/32 Direct 0 0 D 127.0.0.1 GigabitEthernet0/1/0 127.0.0.0/8 Direct 0 0 D 127.0.0.1 InLoopBack0 127.0.0.1/32 Direct 0 0 D 127.0.0.1 InLoopBack0 172.16.1.0/24 EBGP 255 0 D 10.1.1.2 GigabitEthernet0/1/8 EBGP 255 0 D 10.1.3.2 GigabitEthernet0/1/0 172.16.2.0/24 EBGP 255 0 D 10.1.1.2 GigabitEthernet0/1/8 EBGP 255 0 D 10.1.3.2 GigabitEthernet0/1/0 172.16.3.0/24 EBGP 255 0 D 10.1.1.2 GigabitEthernet0/1/8 EBGP 255 0 D 10.1.3.2 GigabitEthernet0/1/0
The preceding command output shows that BGP has delivered the two routes with the same route prefix to the IP routing table for load balancing.
If none overwrite is specified in the apply as-path command, the device can clear the AS_Path attribute to shield the actual path information as well as shortening the AS_Path length. If the AS_Path attribute is empty, BGP considers its length as 0 during route selection.