BGP AS Override

Learn how BGP AS-Override resolves routing issues when customer sites use the same AS number in MPLS VPNs. Step-by-step lab guide with configs and verification.

In the last blog on BGP Loop Prevention, we deeply explored how the BGP routing protocol avoids routing loops using its AS Path attribute. (If you missed it, Click here to check it out first—it will help you connect the dots!)

We learned that in eBGP, if a router sees its own AS number inside the AS Path of an incoming update, it immediately rejects that route. The logic is simple: “If the route already passed through me, then accepting it again might cause a loop.”

This rule is powerful and reliable for avoiding loops, but now let’s take it one step further with a real-world situation. Imagine a large company with 500 branch offices worldwide. To simplify operations, the company decides to use the same AS number at every branch. Each branch connects to the service provider’s network.

Sounds simple, right? But here’s where the problem begins…

Background: Why Does eBGP Need Loop Prevention?

Before diving into AS Override, let’s revisit why BGP has this strict loop prevention.

• Every BGP update carries an AS Path that lists all AS numbers the route has traversed.
• If a router sees its own AS number in that list, it assumes the route is looping back and discards it.

This mechanism keeps the internet safe from endless routing loops that could waste bandwidth and destabilize networks.

But the same safety net can sometimes block legitimate communication—especially in enterprise or service provider environments where multiple sites share the same AS number.

The Challenge: Multi-Site Enterprises with the Same AS

Now let’s come back to our example:

• A company has 500 branches.
• To keep things simple, every branch uses AS 200 (a private AS).
• All branches connect through a service provider, say AS 300.

Here’s the issue:

• When Branch A (AS 200) advertises its routes to the provider (AS 300), the provider forwards them to Branch B (also AS 200).
• But Branch B rejects the routes. Why? Because the AS Path still contains AS 200, which Branch B sees as its own AS number.
• BGP thinks it’s a loop—even though it’s not.

Result? Branches cannot talk to each other through the provider’s network.

To better understand this, I’ve set up a lab in GNS3. The topology is shown in the diagram above.

In this setup, we have a small MPLS VPN network connecting two customer sites. The service provider is running BGP with ASN 300, while the customer is using the same ASN 200 at both sites. Because of this, whenever CE1 or CE2 receive updates from each other, they reject them since their own AS number appears in the AS path.

Below are the configurations for each router:

After completing the lab setup and applying the configurations on all routers, I verified the WAN-to-WAN connectivity between the PE routers. The test was successful — R2 was able to reach the WAN interface IP of R3 and vice-versa. Please see the output below:

Next, I verified the BGP status between both customer sites and the service provider. The BGP sessions were successfully established. Please see the output below:

On both PE routers, I checked the VRF routing tables for BGP. As you can see, the routes from both customer sites are successfully present in the PE routers. Please refer to the output below:

From the R2 PE router, I verified the advertised routes toward CE1. As expected, R2 is advertising the loopback IP of CE2 to CE1.

However, on CE1 the routes are not being received from the PE router. Please check the output below.
But why is this happening?

I enabled the BGP debug at CE-1 Router R4 end

Also, I am not able to ping the loopback ip of R5(CE-2) from the R4 (CE-1)  and vice-versa

As shown in the error above, the routes are being denied because the same AS number appears in the AS_Path. This behavior occurs due to BGP’s built-in loop prevention mechanism.

Since both branches are using the same AS number, but we still need communication between the two sites, this creates a challenge. To resolve this issue, we can use the BGP AS-Override feature.

The Solution: BGP AS Override

This is where BGP AS Override comes to the rescue.

The idea is simple: the service provider (AS 300) overrides the customer’s AS number in the AS Path with its own AS number before sending the update to another customer site.

So instead of Branch B seeing its own AS number, it only sees the provider’s AS number. This makes Branch B accept the route without treating it as a loop.

Same thing is happening at another end (between PE-2 and CE-2)

How AS Override Works: Step-by-Step Example

Let’s break it down with a simple flow:

1. Site A (AS 200) advertises the route 4.4.4.4/32 to the ISP (AS 300).
   • The AS Path is [200].
2. The ISP receives the route from Site A with AS Path [200].
3. When the ISP forwards this route to Site B (also AS 200), it prepends its own AS.
   • Now the AS Path is [300 200].
4. Site B receives the route 4.4.4.4/32 with AS Path [300 200].
   • But Site B notices its own AS number (200) inside the path.
   • According to eBGP loop prevention rules, Site B assumes this could be a loop and
   • rejects the route.

And that’s exactly the problem AS Override solves.

I configured BGP AS-Override on both PE routers under the BGP configuration for the respective VRFs.

And after as-override configuration I am able to learn the CE-2 routes at CE-1 and CE-1 routes at CE-2

Please check below output

If you look at the AS_Path on the CE routers (R4 and R5), you’ll notice that it has changed. The service provider has replaced the customer’s actual AS number with its own AS number.

Also, now I am to reach the CE-2 loopback ip from the CE-1 and vice-versa, please see the below output

With AS Override enabled on the ISP side:

• Instead of forwarding the route with [300 200], the ISP replaces AS 200 with its own AS.
• Site B then receives the route 4.4.4.4/32 with AS Path [300].
• No duplicate AS detected → Site B accepts the route → Communication is established.

Now Branch A and Branch B can talk to each other seamlessly through the provider’s network.

When Should You Use AS Override?

AS Override is most commonly used in:

• MPLS VPN deployments by service providers.
• Large enterprises with multiple sites using the same AS number.
• Provider Edge (PE) ↔ Customer Edge (CE) eBGP sessions where sites need to talk to each other via the provider’s backbone.

But remember: AS Override must be used carefully. If misconfigured, it could open the door for actual routing loops. Always apply it only where it’s needed—typically on the provider’s side of PE-CE connections.

Wrapping Up

BGP loop prevention is a rock-solid mechanism that keeps networks stable. But in multi-site enterprise deployments with the same AS number, it can also block legitimate communication.

That’s where BGP AS Override shines—allowing service providers to modify the AS Path so that routes are accepted between sites, while still keeping the global routing loop-free.

If you’re working in an enterprise or service provider environment, understanding AS Override is a must-have skill. It’s a small configuration, but it can make a massive difference in building scalable and stable networks.