Today, let’s discuss the practical use of the local-as feature and how it is applied during ASN replacement processes.

Before diving into the discussion, let’s take a look at the topology diagram:

Local-as experiment topology

In this topology, you can see that our downstream customer’s devices are connected to our core devices, which in turn are connected to the upstream devices.

The ASNs (Autonomous System Numbers) of the upstream, our core, and the customer are as follows:

  • Upstream: AS64998
  • Core (ours): AS65000 (current global ASN), AS64999 (to be used after replacement)
  • Customer: AS65001

In this topology, all interface IP addresses and initial BGP sessions have already been configured. Both the core router (ours) and the customer’s router have announced their own loopback addresses as test routes.

1. Deploying the Local-as Feature

The local-as feature comes with several commonly used options, which are as follows:

  • <as_num>: Specifies the autonomous system number. It can be written in plain number format or in ‘higher 16 bits’.’lower 16 bits’ (asdot notation) format.
  • alias: Treats this AS as an alias for the system AS.
  • no-prepend-global-as: Prevents the global autonomous system number from being prepended in advertised paths.
  • private: Hides the local AS from paths learned through this peering.

You can configure the local-as feature by directly specifying the ASN you want to use for establishing the BGP session with the peer.

  • alias: Allows the peer to choose either your current ASN or the local-as ASN as the peer ASN.
  • no-prepend-global-as: Controls whether your global ASN is added to the route AS-Path before sending routes. When you configure local-as, it may result in routes sent to the upstream containing both your original global ASN and the configured local-as, no-prepend-global-as can prevent this.
  • private: Ensures that the ASN specified in the local-as configuration is not added to the AS-Path after receiving routes from the upstream.

Before starting the experiments, let’s first check the BGP session status and configuration files:

JSON
// Upstream Router AS64998
[edit protocols bgp group external]
root@isp# show
peer-as 65000;
neighbor 10.10.0.1 {
    export export-lo0;
    peer-as 64999;
}

JSON
// Core Router AS65000/AS64999 (after replacement)
[edit protocols bgp group external]
root@CR# show
type external;
neighbor 10.10.0.0 {
    local-address 10.10.0.1;
    export export-lo0;
    peer-as 64998;
}
neighbor 10.20.0.1 {
    import accept-all;
    peer-as 65001;
}

// BGP status
root@CR# run show bgp summary
Threading mode: BGP I/O
Default eBGP mode: advertise - accept, receive - accept
Groups: 2 Peers: 2 Down peers: 0
Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
inet.0
                       2          2          0          0          0          0
Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
10.10.0.0             64998         14         14       0       0        4:03 Establ
  inet.0: 1/1/1/0
10.20.0.1             65001          5          3       0       1           5 Establ
  inet.0: 1/1/1/0

JSON
// Customer's Router AS65001
[edit protocols bgp group external]
root@Client# show
type external;
neighbor 10.20.0.0 {
    export export-lo0;
    peer-as 65000;
}

We can see that the BGP session between them has already been configured and is in the established state. Now, let’s proceed with the experiments.

Next, we will experiment with the local-as feature and its sub-options one by one.

1.1 Local-as <ASN>

Suppose, due to business requirements, we need to change the ASN used to connect with the upstream to 64999. Directly replacing the global ASN might introduce potential instability and would require updating all BGP session configurations simultaneously.

So, how can we change the ASN used for peering without replacing the global ASN? This is where the local-as feature comes into play.

Note: If you are implementing an ASN change in a production environment and any prefixes are being announced by this ASN, ensure that you update your RPKI records and notify your upstream provider to update their prefix filters. This will help prevent service interruptions after the ASN change.

Let’s start by updating our local configuration:

JSON
// Core Router
root@CR# top show | compare
[edit protocols bgp group external neighbor 10.10.0.0]
+      local-as 64999;

[edit protocols bgp group external]
root@CR# commit
kenv: unable to get vmtype
commit complete

[edit protocols bgp group external]
root@CR# run show bgp summary
Threading mode: BGP I/O
Default eBGP mode: advertise - accept, receive - accept
Groups: 2 Peers: 2 Down peers: 1
Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
inet.0
                       1          1          0          0          0          0
Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
10.10.0.0             64998          2          0       0       0           2 Active
10.20.0.1             65001       6196       6168       0       1 1d 22:27:03 Establ
  inet.0: 1/1/1/0

We can see that after configuring local-as 64999, the BGP connection with the upstream has been disconnected.

This happens because we are now using AS64999 to negotiate the BGP session with the upstream, but their configuration has not been updated, so the negotiation fails.

Next, let’s notify the upstream to update their corresponding configuration:

JSON
// ISP Router 
root@isp# show | compare
[edit protocols bgp group external neighbor 10.10.0.1]
-  peer-as 65000;
+  peer-as 64999;

[edit protocols bgp group external]
root@isp# commit
commit complete

[edit protocols bgp group external]
root@isp# run show bgp summary
Groups: 1 Peers: 1 Down peers: 0
Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
inet.0
                       2          2          0          0          0          0
Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
10.10.0.1             64999          5          5       0       0          37 2/2/2/0              0/0/0/0

After the BGP session has been re-established, we can check the specific routes received on the client router.

JSON
// Client's Router
[edit protocols bgp group external]
root@Client# run show route protocol bgp

inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

172.16.36.1/32     *[BGP/170] 00:27:49, localpref 100
                      AS path: 65000 64999 64998 I, validation-state: unverified
                    > to 10.20.0.0 via ge-0/0/1.0

From the route details, we can see that the routes sent by the upstream have been successfully received. In the AS-PATH attribute, apart from the upstream’s ASN, we can also see our global ASN and the ASN configured using the local-as feature.

This occurs because the router uses the ASN configured with local-as when establishing the BGP connection with the upstream. According to the BGP RFC 7705 specification (click here to view the RFC), when passing routes to downstream devices, the router must add its own ASN to the AS-PATH attribute to ensure the integrity of the path and prevent routing loop.

1.2 Local-as <ASN> alias

Before introducing this sub-option, let’s “turn back time” — roll back the configuration to the pre-migration state.

The alias option allows you to negotiate the BGP session with the peer using either the global ASN or the ASN configured with local-as. It serves as an excellent transition solution, especially when the migration windows of both parties do not align.

The configuration is also straightforward:

JSON
// Core Router
root@CR# show | compare
[edit protocols bgp group external neighbor 10.10.0.0 local-as 64999]
+   alias;

[edit protocols bgp group external]
root@CR# commit
kenv: unable to get vmtype
commit complete

[edit protocols bgp group external]
root@CR# run show bgp summary
Threading mode: BGP I/O
Default eBGP mode: advertise - accept, receive - accept
Groups: 2 Peers: 2 Down peers: 0
Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
inet.0
                       2          2          0          0          0          0
Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
10.10.0.0             64998          5          4       0       0           0 Establ
  inet.0: 1/1/1/0
10.20.0.1             65001       6306       6283       0       1 1d 23:16:53 Establ
  inet.0: 1/1/1/0

After applying the configuration, we can see that the BGP session on our local router has been restored. Now, let’s take a look at the upstream router:

JSON
// ISP Router
root@isp# show neighbor 10.10.0.1
export export-lo0;
peer-as 65000;

[edit protocols bgp group external]
root@isp# run show bgp summary
Groups: 1 Peers: 1 Down peers: 0
Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
inet.0
                       2          2          0          0          0          0
Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
10.10.0.1             65000          6          6       0       1          58 2/2/2/0              0/0/0/0

On the upstream router, the peer-as is still set to our global ASN, but the BGP session has been successfully established.

Next, we will change the upstream router’s peer-as to our new ASN:

JSON
// ISP Router
[edit protocols bgp group external neighbor 10.10.0.1]
-  peer-as 65000;
+  peer-as 64999;

[edit protocols bgp group external]
root@isp# commit
commit complete

[edit protocols bgp group external]
root@isp# run show bgp summary
Groups: 1 Peers: 1 Down peers: 0
Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
inet.0
                       2          2          0          0          0          0
Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
10.10.0.1             64999          4          4       0       0           2 2/2/2/0              0/0/0/0

After updating the configuration, the BGP session is also successfully established. This demonstrates how the alias feature can act as a seamless transition tool in such scenarios.

1.3 private

When this option is enabled, routes received from the upstream and passed to the downstream will include only your Global ASN in the AS-PATH, excluding the ASN configured via the local-as feature. This helps maintain the AS-PATH length consistent with the original path.

The purpose of this feature is to prevent the AS-PATH from becoming longer due to the addition of the ASN configured with local-as, which could affect the downstream’s route selection. If the AS-PATH length grows during migration, the downstream’s route selection algorithm might prioritize other paths (shorter AS-PATHs generally have higher priority). By keeping the AS-PATH length unchanged, this ensures that your routes won’t be downgraded to backup routes due to suboptimal path length.

Note: The private sub-option is mutually exclusive with alias.

The configuration is shown below:

JSON
// Core Router
root@CR# show | compare
[edit protocols bgp group external neighbor 10.10.0.0 local-as]
+   private;
-   alias;

[edit protocols bgp group external]
root@CR# commit
kenv: unable to get vmtype
commit complete
JSON
// Client's Router
root@Client# run show route protocol bgp

inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)  
+ = Active Route, - = Last Active, * = Both  

172.16.36.1/32     *[BGP/170] 00:27:49, localpref 100  
                      AS path: 65000 64999 64998 I, validation-state: unverified  
                    > to 10.20.0.0 via ge-0/0/1.0  
// Before configuration: AS-PATH includes the ASN configured via the local-as feature  

[edit protocols bgp group external]  
root@Client# run show route protocol bgp  

inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)  
+ = Active Route, - = Last Active, * = Both  

172.16.36.1/32     *[BGP/170] 00:00:08, localpref 100  
                      AS path: 65000 64998 I, validation-state: unverified  
                    > to 10.20.0.0 via ge-0/0/1.0  
// After configuring local-as private: ASN configured via the local-as feature is removed

With this feature, seamless migration can be achieved without impacting downstream operations.

1.4 no-prepend-global-as

When customers send their routes to you and you pass these routes to the upstream, according to RFC specifications, the router will include both its Global ASN and the ASN configured via the local-as feature in the AS-PATH.

By enabling the no-prepend-global-as option, the router removes the global ASN from the AS-PATH when sending routes. This prevents the AS-PATH from becoming longer during the migration process, which could cause the routes to be downgraded to backup paths due to their longer AS-PATH.

It is important to note that the no-prepend-global-as option can be enabled simultaneously with the private option.

Here is the configuration:

JSON
// Core Router
root@CR# set neighbor 10.10.0.0 local-as no-prepend-global-as

[edit protocols bgp group external]
root@CR# commit
kenv: unable to get vmtype
commit complete

After completing the configuration, let’s check the routes received by the ISP router:

JSON
// ISP Router
root@isp# run show route protocol bgp 192.168.192.169

inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

192.168.192.169/32 *[BGP/170] 00:00:14, localpref 100
                      AS path: 64999 65000 65001 I, validation-state: unverified
                    > to 10.10.0.1 via ge-0/0/0.0

[edit protocols bgp group external]
root@isp# run show route protocol bgp 192.168.192.169

inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

192.168.192.169/32 *[BGP/170] 00:00:04, localpref 100
                      AS path: 64999 65001 I, validation-state: unverified
                    > to 10.10.0.1 via ge-0/0/0.0
// AS-PATH after enabling no-prepend-global-as: Global ASN (65000) is removed

As seen, the length of the AS-PATH in the routes received by the ISP router remains consistent with the routes received before the migration.

In this article, we looked at the local-as feature in BGP and its four options: <ASN>, alias, private, and no-prepend-global-as. These options help make network migrations smoother, keep routing stable, and avoid problems caused by AS-PATH changes.

By using these features the right way, you can make sure your network stays reliable and avoid issues during transitions.

Thank you for taking the time to read. Should you have any queries or seek further clarification, feel free to leave a comment. I’m here to help!

If you are interested, you can check out my previous articles.

If you found value in my article, kindly consider showing support. Your generosity is deeply appreciated!