AS_Path

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.

Table 1 describes the AS_Path-based route selection rules.
Table 1 AS_Path-based route selection rules

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:
  • If the routes used in the summarization carry the same AS_Sequence, this AS_Sequence is carried in the summarized route, and the AS_Set of the summarized route is null.
  • If the routes used in the summarization carry different AS_Sequences, all the AS numbers carried in the AS_Sequences are included in the AS_Set of the summarized route.

AS_Confed_Sequence and AS_Confed_Set

BGP ignores AS_Confed_Sequence and AS_Confed_Set when calculating the AS_Path length.

bestroute as-path-ignore

After the command is run, BGP does not compare the AS_Path lists carried in candidate routes during route selection.

apply as-path

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.

peer public-as-only

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).

peer public-as-only import

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).

peer fake-as

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.

peer substitute-as

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.

Deleting Private AS Numbers

As public AS resources are limited, carriers generally use private AS numbers when deploying VPNs. Private AS numbers, however, must not be advertised to the Internet because they may cause routing loops. In Figure 1, both ISP1 and ISP2 use 65001 as a private AS number.
Figure 1 Networking in which a private AS needs to be deleted

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.

Before using the peer public-as-only command, note the following restrictions: BGP does not remove private AS numbers in the following scenarios:
  • 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.

The preceding limitations also apply to confederation scenarios.

Adding AS Numbers

In Figure 2, AS 65005 imports three routes and advertises them to AS 65001 through two paths.
Figure 2 Networking in which new AS numbers are added to the AS_Path

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
The preceding command output shows that the AS_Path length of the route learned from DeviceB is shorter than that of the route learned from DeviceC and that the route learned from DeviceB is selected as the optimal route. Table 2 shows the attribute comparison of the routes that DeviceA learns from DeviceB and DeviceC.
Table 2 Attribute comparison of the routes that DeviceA learns from DeviceB and DeviceC

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.

Replacing AS Numbers

If overwrite is specified in the apply as-path command, the AS numbers in the AS_Path attribute can be replaced. AS number replacement can be flexibly applied to the following scenarios:
  • 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.

Clearing the AS_Path

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.

Copyright © Huawei Technologies Co., Ltd.
Copyright © Huawei Technologies Co., Ltd.
< Previous topic Next topic >