Understanding BGP Allowas-in and Solving eBGP Routing Loops

Learn how BGP Allowas-in helps overcome eBGP routing loop issues in MPLS VPNs and multi-homed networks. Step-by-step lab, configs, and troubleshooting included.

The Border Gateway Protocol (BGP) is the backbone of inter-domain communication, enabling autonomous systems (ASes) across the globe to exchange routing information. While BGP is robust and scalable, certain scenarios—especially in MPLS VPN environments or multi-homed networks—introduce challenges.

One such challenge is the eBGP routing loop problem, where routes are rejected due to the presence of the local AS in the AS_PATH. In this blog, we’ll revisit the history of eBGP routing loops, see how AS-Override provides one solution, and then dive deep into BGP allowas-in, a customer-side feature that can resolve the same problem in a different way.

🔹 The eBGP Routing Loop Problem

One of BGP’s fundamental mechanisms to prevent loops is its AS_PATH check. When a router receives an update containing its own AS number in the AS_PATH, it assumes the route has already passed through its AS and rejects it.

This works well for avoiding loops but creates problems in designs where customers reuse the same AS number across multiple sites.

🔹 How AS-Override Solves the Problem

In our previous blog, we explored the AS-Override solution. Here, the service provider PE router modifies the AS_PATH by replacing the customer’s AS with its own.

• Route from Site A: AS_PATH {200}
• Service Provider rewrites: AS_PATH {65000}
• Delivered to Site B: Looks like it came from SP’s AS, so Site B accepts it.

In short, AS-Override tricks the receiving site into believing the route came from a different AS, avoiding the false loop detection.

This solution works well when the service provider is willing to apply the fix. But what if you want to keep control on the customer side?

🔹 Introducing BGP allowas-in

Unlike AS-Override, which modifies the AS_PATH on the provider side, Allowas-in provides flexibility by allowing the customer router to intentionally accept these routes.

Instead of discarding the route as a loop, the router says: “It’s okay, I’ll accept this route even though my AS is in the path.”

This gives customers flexibility in scenarios where service providers don’t enable AS-Override, or where the true AS_PATH visibility must be preserved.

Example

In this example, the service provider is using ASN 300, while the customer has two branch sites, CE-1 and CE-2, both configured with the same ASN 200. When CE-1 advertises the route 4.4.4.4/32, it is sent to the service provider with AS 200 in the path. The service provider then forwards the route toward CE-2, appending its own ASN. As a result, the AS_PATH received at CE-2 becomes [300 200].

At this point, CE-2 detects its own ASN (200) in the AS_PATH. According to the eBGP loop prevention mechanism, the route is rejected—even though the route is valid and should be accepted. This loop prevention rule unintentionally blocks communication between the two customer sites.

So, how can we enable connectivity between these branches? This is where the BGP Allowas-in feature comes into play. Instead of rejecting the update, Allowas-in permits the router to accept routes containing its own ASN in the AS_PATH.

Let’s verify this with a simple lab. Below are the configurations of all routers, so you can try it yourself:

Now, let’s verify the connectivity and BGP session status. On both PE routers, we checked the BGP peering with their respective CE routers, and the sessions were successfully established. Refer to the output below for confirmation:

Although the BGP sessions are established, communication between the CE-1 loopback IP and the CE-2 loopback IP is still not working

On both PE routers, we verified the routes being advertised toward the CE routers. As shown in the output below, PE-1 is advertising the routes learned from CE-2, and similarly, PE-2 is advertising the routes learned from CE-1.

Since the PE routers are successfully advertising the prefixes, the CE routers should normally accept these routes. Let’s verify this on the customer side.

Surprisingly, both CE routers are not accepting the routes. To investigate further, I enabled BGP debugging, and the logs clearly show that the routes are being rejected due to the eBGP loop prevention mechanism. Same thing is happening at another end also.

To resolve this issue and enable communication between the loopback IPs of both CE routers, we configured the allowas-in command on each CE router, as shown below.

Now, let’s verify the received routes on the CE routers. Previously, these routes were not being learned—so this check will confirm whether the allowas-in configuration is working correctly.

Great! The expected routes are now visible in the routing table, which confirms that the allowas-in command is allowing BGP to accept routes even when the local AS number appears in the AS_PATH.

Next, let’s test end-to-end connectivity by pinging the loopback IP of CE-2 from CE-1, and vice versa.

Perfect—that’s exactly what we expected, and the connectivity is now working properly. Hopefully, this walkthrough helped you understand the concept of BGP allowas-in, along with the step-by-step configurations and troubleshooting we used in this lab.

🔹 Use Cases for allowas-in

1. MPLS VPNs
   • Customer routes traverse the service provider’s backbone and return carrying the customer’s AS.
   • Without allowas-in, the routes are rejected.
2. Multi-homed Customers
   • A customer connected to the same ISP at multiple points may receive routes containing its AS number.
   • allowas-in ensures these legitimate routes are not dropped.
3. Complex Lab/Training Environments
   • Engineers reusing configs with the same AS across test sites often rely on allowas-in to avoid rejection.

🔹 Risks and Best Practices

Use with caution: Allowing your own AS in the path can introduce real loops if the topology is not carefully designed.

Best practices:

• Use allowas-in only when you trust the SP’s routing design.
• Always set a reasonable limit (e.g., allowas-in 1 or allowas-in 2) rather than leaving it open.
• Combine with careful route filtering and policies to avoid blackholing or loops.

🔹 Wrapping Up

BGP’s loop-prevention mechanism is critical, but it sometimes rejects legitimate routes in same-AS topologies.

• AS-Override (provider-side) solves the problem by rewriting the AS_PATH.
• allowas-in (customer-side) solves it by accepting the route despite the AS match.