BGP as the PE-CE Protocol: as-override, allowas-in, and SoO

BGP is the most powerful choice for the PE-CE protocol in an MPLS L3VPN - it scales, it carries policy, and it hands the provider fine-grained control. But it comes with a trap that catches every engineer once: BGP's loop-prevention, the thing that keeps the internet stable, actively breaks a very common enterprise VPN topology. When two of a customer's sites share the same AS number, they cannot reach each other, and BGP is doing it on purpose.

This article covers the three tools that fix it - as-override, allowas-in, and SoO - with real output from a CML lab that reproduces the failure and each fix. For the fundamentals, start at the complete MPLS guide.

Why customers reuse an AS number

An enterprise buys L3VPN service and runs BGP to the provider at every site. The simple thing to do - the thing every enterprise does - is use one private AS number, say 65100, at all of them. Site A is AS 65100, Site B is AS 65100, Site C is AS 65100. It is their internal number; why would they coordinate different ones?

And that is exactly the setup that breaks.

The failure, reproduced

In the lab, CE1 (Site A) and CE2 (Site B) are both AS 65100, connected through the provider (AS 100). CE1 advertises its loopback 11.11.11.11. That route travels: CE1 (65100) → PE1 → across the VPNv4 core → PE2 → toward CE2. When it arrives at CE2, its AS-path contains 65100.

CE2 is AS 65100. So CE2 looks at the incoming route, sees its own AS number in the path, and - following BGP's fundamental loop-prevention rule - silently discards it:

CE2#show ip route 11.11.11.11
% Network not in table

CE2#show ip bgp 11.11.11.11
% Network not in table

The route is being sent. It is being received. It is being thrown away at parse time, before it ever enters the BGP table. The only evidence is on the PE, in the policy-denied counters (with soft-reconfiguration enabled):

PE2#show ip bgp vpnv4 vrf CUST-A neighbors 10.2.2.2 | section Policy
  Local Policy Denied Prefixes:    --------    -------
    Bestpath from this peer:              4        n/a

Two sites of the same customer, both paying for VPN service, unable to reach each other. BGP is working exactly as designed - it just cannot tell "my own AS looping back through a mistake" from "my own AS legitimately at another site of the same company."

Fix 1: as-override (on the provider)

The cleanest fix, and the one providers prefer, lives on the PE. as-override tells the PE: when you advertise a route to a CE, and the CE's AS number appears in the AS-path, replace those occurrences with your own AS number.

router bgp 100
 address-family ipv4 vrf CUST-A
  neighbor 10.2.2.2 remote-as 65100
  neighbor 10.2.2.2 activate
  neighbor 10.2.2.2 as-override

Now the route that reaches CE2 no longer contains 65100 - the PE rewrote it to 100:

CE2#show ip bgp 11.11.11.11
BGP routing table entry for 11.11.11.11/32
  100 100
    10.2.2.1 from 10.2.2.1 (3.3.3.3)
      Origin IGP, localpref 100, valid, external, best

CE2#ping 11.11.11.11 source Loopback0
!!!!!
Success rate is 100 percent (5/5)

The AS-path is now 100 100 - CE2's own 65100 replaced by the provider's AS. No loop detected, route accepted, connectivity restored. The customer changed nothing; the fix is entirely on the provider side.

Why providers prefer this: it works transparently for every customer with reused AS numbers, requires no customer configuration, and keeps the loop-prevention semantics sensible (a genuine loop through the provider would still be caught by the provider's own AS appearing twice, which is why you sometimes pair it with SoO - see below).

Fix 2: allowas-in (on the customer)

The mirror-image fix lives on the CE. allowas-in tells the receiving router: accept a route even if my own AS appears in the path, up to N times.

router bgp 65100
 address-family ipv4
  neighbor 10.2.2.1 allowas-in 3

Now CE2 accepts the route despite seeing 65100 in the path:

CE2#show ip bgp 11.11.11.11
BGP routing table entry for 11.11.11.11/32
  100 65100
    10.2.2.1 from 10.2.2.1 (3.3.3.3)
      Origin IGP, localpref 100, valid, external, best

The AS-path here is 100 65100 - the original path, with 65100 present, but accepted anyway because allowas-in told CE2 to tolerate its own AS up to three times.

The number matters. allowas-in 3 means "tolerate my AS up to three times". Set it as low as your topology needs - a customer with three sites reachable through each other might legitimately see its AS a couple of times, but a large number is disabling loop prevention wholesale and inviting a genuine loop. If you are the customer and cannot influence the PE, this is your tool; otherwise prefer as-override.

Fix 3: SoO - the loop prevention you just removed

Here is the subtle problem. Both fixes above defeat BGP's loop prevention for the reused-AS case. But what happens when a customer site is dual-homed to two PEs? A route can now go out one PE, across the provider, and come back in the other PE to the same site - a real loop, and you have just disabled the mechanism that would have caught it.

Site of Origin (SoO) restores loop prevention at a finer granularity. It is an extended community stamped on routes as they enter the VPN from a site, identifying which site they came from. A PE will not re-advertise a route back to a site carrying that site's own SoO.

From the lab, SoO applied on the PE facing CE2:

route-map SOO-CE2 permit 10
 set extcommunity soo 100:22
!
router bgp 100
 address-family ipv4 vrf CUST-A
  neighbor 10.2.2.2 route-map SOO-CE2 in

And the route from CE2 now carries its site identity:

PE2#show ip bgp vpnv4 vrf CUST-A 22.22.22.22/32
      Extended Community: SoO:100:22 RT:100:1

If CE2 were dual-homed to a second PE, that PE would see a route arriving carrying SoO:100:22 - CE2's own site identity - and refuse to send it back into CE2's site. The backdoor loop that as-override and allowas-in re-opened is closed again.

Note this worked cleanly in the VRF context. BGP SoO via a route-map in the VPN address family stamps the extended community exactly as expected - unlike EIGRP's ip vrf sitemap, which behaves differently in a global table (a distinction we covered in the EIGRP SoO article).

The decision, in one place

1. You are the provider, customer reuses AS numbers: as-override on the PE. One config, all customers, loop safety retained.
2. Customer is dual-homed to multiple PEs: add SoO on top of as-override, to restore the loop prevention as-override removed.
3. You are the customer and cannot change the PE: allowas-in N on the CE, with N as small as possible.
4. Ideal, if you can arrange it: the customer uses different AS numbers per site and none of this is needed. Often impractical, but it is the cleanest design.

Troubleshooting

1. Two customer sites can't reach each other, same AS? This exact problem. Check the AS-path of a missing prefix - if the customer's own AS is in it, the receiving router dropped it.
2. as-override configured but still not working? It rewrites the AS on egress from the PE toward the CE. Confirm it is on the PE-CE neighbour, in the right VRF address family.
3. allowas-in accepting too much? The number is too high. Lower it to the minimum your topology requires.
4. Dual-homed site with a loop after enabling as-override? You removed loop prevention and need SoO to put it back at the site level.
5. SoO not stamping? In a VPN, apply it via a route-map on the PE-CE neighbour in the VRF address family - which does work, as shown above.

Key takeaways

• Two customer sites sharing an AS number cannot reach each other over L3VPN - BGP's loop prevention drops the route silently. It is working as designed.
• as-override (on the PE) rewrites the customer AS to the provider AS in the path. Providers prefer it: one config, transparent to the customer, loop safety retained.
• allowas-in N (on the CE) tolerates the customer's own AS in the path N times. Use it when you cannot change the PE, with N as small as possible.
• Both fixes weaken loop prevention. For a dual-homed site, add SoO to restore it at site granularity - a route will not be sent back to the site it came from.
• BGP SoO via a route-map in the VRF address family stamps the extended community correctly.
• The cleanest design is different AS numbers per site, if the customer can arrange it.

Next: dual-hub DMVPN designs that actually fail over. The full cluster index lives on the MPLS pillar, cross-linked to BGP.