A detailed breakdown of the alias option for the local-AS setting in BGP on Juniper devices, showing how this mode influences AS-path prepending in both eBGP and iBGP peering. It covers configuration examples, route propagation scenarios, and illustrates how the local AS and global AS values are prepended differently depending on peer type.
This series of techpost will provide a comprehensive overview of the various BGP local AS configuration options available on Juniper devices. Local AS is a powerful feature used in scenarios such as network migrations, mergers, and acquisitions. It enables BGP sessions to present a local AS number instead of the global AS when establishing peerings. We will detail the behavior of each configuration option, covering both the iBGP and eBGP use cases. A summary table of AS paths of all the routes after each local AS option is included for quick reference and comparison.
Five local AS options are available, each catering to a range of use cases, from seamless network migrations to complex multi-homing scenarios:
These options allow network operators to modify AS path information, influencing how routes are perceived and propagated within and beyond their autonomous system. The following sections provide an in-depth exploration of the default option, highlighting its strengths and limitations.
In Junos, the local AS alias option is used to make the router appear to a BGP peer as if it belongs to either the router's global AS or an alternate AS number (the local AS), effectively treating the local AS as an alias for the global AS. During the BGP session establishment, the AS number sent in the OPEN message can alternate between the global AS and the local AS. If the session is established using the local AS, then only the local AS is prepended to the AS path; if it is established using the global AS, then only the global AS is prepended. This is ideal during gradual migration of an acquired network where some devices use the old AS, and others use the new AS.
Note: While a router can alternate between the global AS and the local AS, the external BGP peer must still explicitly configure the peer-as knob to specify which AS it would like to peer with.
protocols {
bgp {
group test {
local-as 65551 alias;
neighbor <address> {
peer-as 64501;
}
}
}
}
Key behaviors:
Peer Establishment: BGP sessions use either the local ASN or Global ASN in their OPEN message.
Local AS applied to eBGP peer:
Routes advertised from eBGP peers with local-as alias configuration to other eBGP peers will have the global ASN number prepended to the AS path.
Routes advertised from eBGP peer with local-as alias configuration to other iBGP will NOT have the local ASN or the global ASN number prepended to the AS path.
Local AS applied to iBGP peer:
Routes advertised from iBGP peers with local-as alias configuration to other eBGP peers will only have the global ASN prepended to the AS path.
Routes advertised from iBGP peers with local-as alias configuration to other iBGP peers will NOT have the local ASN or the global ASN prepended to the AS path.
The primary goal of this document is to validate the behavior of the alias local AS option and understand how the AS path is prepended or modified in different scenarios. It takes various route propagation scenarios into account and lists the expected AS path for each route.
We examine the AS path in three distinct contexts:
Show route advertising-protocol output. Displays the AS path that will be advertised to the neighbor, including the AS numbers being prepended.
Actual BGP UPDATE message content (captured via traceoptions). Reflects the AS path as it appears within the real BGP UPDATE message sent to the peer.
Local routing table (RIB) representation. Shows the AS path stored in the local routing table prior to any AS path modifications.
Capturing both the show route advertising-protocol output and the actual BGP UPDATE message allows us to identify and analyze any discrepancies between the intended advertisement and the actual message transmitted.
The example environment consists of five routers arranged in a star topology, with router R3 serving as the central node and Device Under Test (DUT). Each router's global AS number is indicated within the square boxes. This is the base topology and currently does not show local-as configuration. The local-as configuration will be applied on R3 (DUT) towards either R1 (eBGP) or R4 (iBGP), depending on the specific example scenario. For each example, the topology will indicate where local-as is applied and how the route propagates. This topology is purposefully designed to thoroughly evaluate various route propagation behaviors and to analyze the effects of local AS configurations in each context.
The following five example scenarios cover all the cases where local AS alias configuration on an eBGP setup - peering on Local AS impacts the AS path.
Please note that "*" in below examples marks the neighbor on which R3 (DUT) has the local-as configuration applied.
Example 1: Route propagation from eBGP* (R1) to eBGP (R2)¶
This example describes the propagation of routes learned via eBGP from R1 to the eBGP peer R2, where R3 applies a local AS alias on its eBGP session with R1. R1 advertises its loopback address 192.0.2.1/32 to R3, which then re-advertises the prefix to R2.
AS path of prefix 192.0.2.1/32 in the routing table inet.0 on R3:
RE3# run show route 192.0.2.1
inet.0: 20 destinations, 20 routes (20 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.0.2.1/32 *[BGP/170] 00:01:28, localpref 100
AS path: 64501 I, validation-state: unverified
> to 198.51.100.1 via ge-0/0/0.0
AS path of prefix 192.0.2.1/32 in the show route advertising-protocol output on R3:
Example 2: Route propagation from eBGP* (R1) to iBGP (R4)¶
This example describes the propagation of routes learned via eBGP from R1 to the iBGP peer R4, where R3 applies a local AS alias on its eBGP session with R1. R1 advertises its loopback address 192.0.2.1/32 to R3, which then re-advertises the prefix to R4.
AS path of prefix 192.0.2.1/32 in the routing table inet.0 on R3:
RE3# run show route 192.0.2.1
inet.0: 20 destinations, 20 routes (20 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.0.2.1/32 *[BGP/170] 00:03:17, localpref 100
AS path: 64501 I, validation-state: unverified
> to 198.51.100.1 via ge-0/0/0.0
AS path of prefix 192.0.2.1/32 in the show route advertising-protocol output on R3:
Notice the discrepancy in the show advertise command which indicates that the global AS will be prepended to the AS path. Whereas, in the actual BGP UPDATE message, the global AS is not prepended. Since R4 is an internal peer to R3, R3 will not prepend the global AS to the AS path.
Example 3: Route propagation from DUT (R3) to eBGP* (R1)¶
This example examines the AS path of a direct/static route advertised to an eBGP peer. R3 advertises its loopback address 192.0.2.3/32 to R1.
AS path of prefix 192.0.2.3/32 in the routing table inet.0 on R3:
Notice that the show advertise command and the BGP UPDATE message show different AS paths. Always follow the BGP UPDATE message as the source of truth.
Example 4: Route propagation from eBGP (R2) to eBGP* (R1)¶
This example describes the propagation of routes learned via eBGP from R2 to the eBGP peer R1, where R3 applies a local AS alias on its eBGP session with R1. R2 advertises its loopback address 192.0.2.2/32 to R3, which then re-advertises the prefix to R1.
AS path of prefix 192.0.2.2/32 in the routing table inet.0 on R3:
RE3# run show route 192.0.2.2
inet.0: 20 destinations, 20 routes (20 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.0.2.2/32 *[BGP/170] 00:01:40, localpref 100
AS path: 64502 I, validation-state: unverified
> to 198.51.100.5 via ge-0/0/2.0
AS path of prefix 192.0.2.2/32 in the show route advertising-protocol output on R3:
The show advertise command indicates that the global AS will be prepended, however, the BGP UPDATE message actually prepends the local AS.
Example 5: Route propagation from iBGP (R4) to eBGP* (R1)¶
This example describes the propagation of routes learned via iBGP from R4 to the eBGP peer R1, where R3 applies a local AS alias on its eBGP session with R1. R4 advertises its loopback address 192.0.2.4/32 to R3, which then re-advertises the prefix to R1.
AS path of prefix 192.0.2.4/32 in the routing table inet.0 on R3:
RE3# run show route 192.0.2.4
inet.0: 20 destinations, 20 routes (20 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.0.2.4/32 *[BGP/170] 00:01:04, localpref 100
AS path: I, validation-state: unverified
> to 203.0.113.1 via ge-0/0/4.0
AS path of prefix 192.0.2.4/32 in the show route advertising-protocol output on R3:
The following five example scenarios cover all the cases where local AS alias configuration on an eBGP setup - peering on Global AS impacts the AS path.
Example 1: Route propagation from eBGP* (R1) to eBGP (R2)¶
This example describes the propagation of routes learned via eBGP from R1 to the eBGP peer R2, where R3 applies a local AS alias on its eBGP session with R1. R1 advertises its loopback address 192.0.2.1/32 to R3, which then re-advertises the prefix to R2.
AS path of prefix 192.0.2.1/32 in the routing table inet.0 on R3:
RE3# run show route 192.0.2.1
inet.0: 20 destinations, 20 routes (20 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.0.2.1/32 *[BGP/170] 00:05:39, localpref 100
AS path: 64501 I, validation-state: unverified
> to 198.51.100.1 via ge-0/0/0.0
AS path of prefix 192.0.2.1/32 in the show route advertising-protocol output on R3:
Example 2: Route propagation from eBGP* (R1) to iBGP (R4)¶
This example describes the propagation of routes learned via eBGP from R1 to the iBGP peer R4, where R3 applies a local AS alias on its eBGP session with R1. R1 advertises its loopback address 192.0.2.1/32 to R3, which then re-advertises the prefix to R4.
AS path of prefix 192.0.2.1/32 in the routing table inet.0 on R3:
RE3# run show route 192.0.2.1
inet.0: 20 destinations, 20 routes (20 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.0.2.1/32 *[BGP/170] 00:05:39, localpref 100
AS path: 64501 I, validation-state: unverified
> to 198.51.100.1 via ge-0/0/0.0
AS path of prefix 192.0.2.1/32 in the show route advertising-protocol output on R3:
We see that the UPDATE message does not include the global AS in the AS path. This is because R4 is an internal peer to R3, and they belong to the same AS.
Example 3: Route propagation from DUT (R3) to eBGP* (R1)¶
This example examines the AS path of a direct/static route advertised to an eBGP peer. R3 advertises its loopback address 192.0.2.3/32 to R1.
AS path of prefix 192.0.2.3/32 in the routing table inet.0 on R3:
Example 4: Route propagation from eBGP (R2) to eBGP* (R1)¶
This example describes the propagation of routes learned via eBGP from R2 to the eBGP peer R1, where R3 applies a local AS alias on its eBGP session with R1. R2 advertises its loopback address 192.0.2.2/32 to R3, which then re-advertises the prefix to R1.
AS path of prefix 192.0.2.2/32 in the routing table inet.0 on R3:
RE3# run show route 192.0.2.2
inet.0: 20 destinations, 20 routes (20 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.0.2.2/32 *[BGP/170] 00:00:50, localpref 100
AS path: 64502 I, validation-state: unverified
> to 198.51.100.5 via ge-0/0/2.0
AS path of prefix 192.0.2.2/32 in the show route advertising-protocol output on R3:
Example 5: Route propagation from iBGP (R4) to eBGP* (R1)¶
This example describes the propagation of routes learned via iBGP from R4 to the eBGP peer R1, where R3 applies a local AS alias on its eBGP session with R1. R4 advertises its loopback address 192.0.2.4/32 to R3, which then re-advertises the prefix to R1.
AS path of prefix 192.0.2.4/32 in the routing table inet.0 on R3:
RE3# run show route 192.0.2.4
inet.0: 20 destinations, 20 routes (20 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.0.2.4/32 *[BGP/170] 00:01:10, localpref 100
AS path: I, validation-state: unverified
> to 203.0.113.1 via ge-0/0/4.0
AS path of prefix 192.0.2.4/32 in the show route advertising-protocol output on R3:
The following five example scenarios cover all the cases where local AS alias configuration on an iBGP setup - peering on Local AS impacts the AS path.
Example 1: Route propagation from iBGP* (R4) to eBGP (R1)¶
This example describes the propagation of routes learned via iBGP from R4 to the eBGP peer R1, where R3 applies a local AS alias on its iBGP session with R4. R4 advertises its loopback address 192.0.2.4/32 to R3, which then re-advertises the prefix to R1.
AS path of prefix 192.0.2.4/32 in the routing table inet.0 on R3:
RE3# run show route 192.0.2.4
inet.0: 20 destinations, 20 routes (20 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.0.2.4/32 *[BGP/170] 00:02:03, localpref 100
AS path: I, validation-state: unverified
> to 203.0.113.1 via ge-0/0/4.0
AS path of prefix 192.0.2.4/32 in the show route advertising-protocol output on R3:
Example 2: Route propagation from iBGP* (R4) to iBGP (R5)¶
This example describes the propagation of routes learned via iBGP from R4 to the iBGP peer R5, where R3 applies a local AS alias on its iBGP session with R4. R4 advertises its loopback address 192.0.2.4/32 to R3, which then re-advertises the prefix to R5.
AS path of prefix 192.0.2.4/32 in the routing table inet.0 on R3:
RE3# run show route 192.0.2.4
inet.0: 20 destinations, 20 routes (20 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.0.2.4/32 *[BGP/170] 00:02:03, localpref 100
AS path: I, validation-state: unverified
> to 203.0.113.1 via ge-0/0/4.0
AS path of prefix 192.0.2.4/32 in the show route advertising-protocol output on R3:
Example 4: Route propagation from eBGP (R1) to iBGP* (R4)¶
This example describes the propagation of routes learned via eBGP from R1 to the iBGP peer R4, where R3 applies a local AS alias on its iBGP session with R4. R1 advertises its loopback address 192.0.2.1/32 to R3, which then re-advertises the prefix to R4.
AS path of prefix 192.0.2.1/32 in the routing table inet.0 on R3:
RE3# run show route 192.0.2.1
inet.0: 20 destinations, 20 routes (20 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.0.2.1/32 *[BGP/170] 00:00:42, localpref 100
AS path: 64501 I, validation-state: unverified
> to 198.51.100.1 via ge-0/0/0.0
AS path of prefix 192.0.2.1/32 in the show route advertising-protocol output on R3:
Example 5: Route propagation from iBGP (R5) to iBGP* (R4)¶
This example describes the propagation of routes learned via iBGP from R5 to the iBGP peer R4, where R3 applies a local AS alias on its iBGP session with R4. R5 advertises its loopback address 192.0.2.5/32 to R3, which then re-advertises the prefix to R4.
AS path of prefix 192.0.2.5/32 in the routing table inet.0 on R3:
RE3# run show route 192.0.2.5
inet.0: 20 destinations, 20 routes (20 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.0.2.5/32 *[BGP/170] 00:01:38, localpref 100
AS path: I, validation-state: unverified
> to 203.0.113.5 via ge-0/0/6.0
As path of prefix 192.0.2.5/32 in the show route advertising-protocol output on R3:
The following five example scenarios cover all the cases where local AS alias configuration on an iBGP setup - peering on Global AS impacts the AS path.
Example 1: Route propagation from iBGP* (R4) to eBGP (R1)¶
This example describes the propagation of routes learned via iBGP from R4 to the eBGP peer R1, where R3 applies a local AS alias on its iBGP session with R4. R4 advertises its loopback address 192.0.2.4/32 to R3, which then re-advertises the prefix to R1.
AS path of prefix 192.0.2.4/32 in the routing table inet.0 on R3:
RE3# run show route 192.0.2.4
inet.0: 20 destinations, 20 routes (20 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.0.2.4/32 *[BGP/170] 00:00:55, localpref 100
AS path: I, validation-state: unverified
> to 203.0.113.1 via ge-0/0/4.0
AS path of prefix 192.0.2.4/32 in the show route advertising-protocol output on R3:
Example 2: Route propagation from iBGP* (R4) to iBGP (R5)¶
This example describes the propagation of routes learned via iBGP from R4 to the iBGP peer R5, where R3 applies a local AS alias on its iBGP session with R4. R4 advertises its loopback address 192.0.2.4/32 to R3, which then re-advertises the prefix to R5.
AS path of prefix 192.0.2.4/32 in the routing table inet.0 on R3:
RE3# run show route 192.0.2.4
inet.0: 20 destinations, 20 routes (20 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.0.2.4/32 *[BGP/170] 00:00:55, localpref 100
AS path: I, validation-state: unverified
> to 203.0.113.1 via ge-0/0/4.0
AS path of prefix 192.0.2.4/32 in the show route advertising-protocol output on R3:
Example 4: Route propagation from eBGP (R1) to iBGP* (R4)¶
This example describes the propagation of routes learned via eBGP from R1 to the iBGP peer R4, where R3 applies a local AS alias on its iBGP session with R4. R1 advertises its loopback address 192.0.2.1/32 to R3, which then re-advertises the prefix to R4.
AS path of prefix 192.0.2.1/32 in the routing table inet.0 on R3:
RE3# run show route 192.0.2.1
inet.0: 20 destinations, 20 routes (20 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.0.2.1/32 *[BGP/170] 00:00:51, localpref 100
AS path: 64501 I, validation-state: unverified
> to 198.51.100.1 via ge-0/0/0.0
AS path of prefix 192.0.2.1/32 in the show route advertising-protocol output on R3:
Example 5: Route propagation from iBGP (R5) to iBGP* (R4)¶
This example describes the propagation of routes learned via iBGP from R5 to the iBGP peer R4, where R3 applies a local AS alias on its iBGP session with R4. R5 advertises its loopback address 192.0.2.5/32 to R3, which then re-advertises the prefix to R4.
AS path of prefix 192.0.2.5/32 in the routing table inet.0 on R3:
RE3# run show route 192.0.2.5
inet.0: 20 destinations, 20 routes (20 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.0.2.5/32 *[BGP/170] 00:01:03, localpref 100
AS path: I, validation-state: unverified
> to 203.0.113.5 via ge-0/0/6.0
As path of prefix 192.0.2.5/32 in the show route advertising-protocol output on R3:
