Latest Cisco, PMP, AWS, CompTIA, Microsoft Materials on SALE Get Now Get Now

BGP AS-Path Features: What local-as, allowas-in, as-override and Prepending Actually Cost You

Network Infrastructure ｜ Configuration ｜ Advanced ｜ 20 min read

Four BGP features exist to edit the AS_PATH, and three of them weaken the protocol's only loop-prevention mechanism. That is not an accident or an oversight — it is the deliberate price of solving problems the original design did not anticipate. A company that acquires another company cannot re-number every customer's BGP session overnight, so local-as lets one router present two autonomous system numbers at once. A customer running the same AS at three sites behind an MPLS VPN has an AS_PATH that legitimately contains their own AS, so allowas-in or as-override has to permit it. Each feature is correct for its use case and dangerous outside it.

The fourth, prepending, does not weaken anything; it simply makes a path look longer so that other autonomous systems prefer a different one. It is the most widely used and the least reliable of the four, because path length is step four of the best-path algorithm and any provider who sets local preference at ingress has already decided at step two. Understanding why prepending frequently accomplishes nothing is more useful than knowing the syntax, and the answer is always the same: somebody upstream made the decision before your prepend was ever considered.

This article covers all four with their trade-offs. Section one states what problem each one solves and which loop protection it removes. Section two builds local-as for an AS migration, including the no-prepend, replace-as, and dual-as modifiers that most documentation lists without explaining. Section three covers the same-AS-at-multiple-sites problem and the choice between allowas-in on the customer and as-override on the provider. Section four covers remove-private-as and prepending. Section five is what to do about the loop prevention you removed, which is mostly Site of Origin.

Blog ClaimThree of these four commands disable the only loop detection eBGP has, which makes Site of Origin not an optional refinement but the replacement protection any design using allowas-in or as-override is obliged to deploy.
Four features that edit or relax the AS_PATH: local-as presents a second AS, allowas-in and as-override solve the same-AS problem from opposite ends, and only the last two of the set leave loop prevention intact.

What Problem Does Each of These Features Solve?

What is each one actually for?

local-as presents a second autonomous system number to a specific neighbour, so a router that has moved into a new AS can continue speaking to peers configured for the old one — the enabling feature for a merger or acquisition. allowas-in tells a router to accept updates whose AS_PATH contains its own AS number, which is required when a customer uses the same AS at several sites behind a provider network. as-override solves the same problem from the provider side by rewriting the customer's AS out of the path before advertising it onward. remove-private-as strips private AS numbers from outbound advertisements. Prepending repeats an AS number to make a path longer.

A Deeper Dive into the Four Problems

Why eBGP loop detection exists and what removing it costs

A BGP speaker discards any eBGP update whose AS_PATH already contains its own AS number. That single check is the whole of eBGP loop prevention — there is no hop count, no sequence number, and no timer. It works because a path that has already visited your autonomous system and come back must have gone in a circle. Three of the four features here interfere with that check, and each therefore creates the possibility of a genuine routing loop that nothing in BGP will detect.

The consequences are not theoretical. A customer with two sites, both attached to the same provider, both running allowas-in, can learn a prefix originated at site A, advertise it back into the provider from site B, and have it returned to site A as a better path — producing a forwarding loop between the two sites that persists until someone notices. Site of Origin exists precisely to catch that case, which is why section five treats it as mandatory rather than optional.

The four features compared

Feature Problem solved Configured on Direction affected Replacement protection needed
local-as AS migration without re-numbering peers Either end of an eBGP session Both None if the migration is short-lived
allowas-in Same customer AS at multiple sites The receiving router (usually a CE) Inbound Site of Origin
as-override Same customer AS at multiple sites The PE, toward the CE Outbound Site of Origin
remove-private-as Private ASes leaking to the internet eBGP session, outbound Outbound None
as-path prepend Influencing which path others prefer Usually outbound in a route-map Either None

What the loop check looks like when it fires

! The peer is advertising it...
R-PEER# show ip bgp neighbors 192.0.2.1 advertised-routes | include 203.0.113
 *> 203.0.113.0/24   192.0.2.2   0   65000 65100 i
!
! ...and we never see it, because the path contains our own AS.
R1# show ip bgp 203.0.113.0/24
% Network not in table
!
! The check happens before policy, so no filter change helps and
! nothing appears in received-routes either. Confirm with a debug:
R1# debug ip bgp updates in
BGP(0): 192.0.2.2 rcv UPDATE about 203.0.113.0/24 -- DENIED due to: AS-PATH contains our own AS
Two of these are permanent, three are temporaryremove-private-as and prepending belong in a steady-state configuration and stay there. local-as exists for the duration of a migration. allowas-in and as-override exist for as long as a customer keeps a shared AS across sites, which is often years but is still a customer topology decision that could change. Recording which category each instance falls into, in the configuration itself, is what lets a later engineer tell a deliberate exception from an accident.
iBGP has no equivalent checkAS_PATH does not change within an autonomous system, so it cannot detect an internal loop. That is why iBGP requires a full mesh or route reflection with ORIGINATOR_ID and CLUSTER_LIST — the loop prevention discussed here applies only to eBGP sessions. None of the four features in this article affects iBGP.
Decide the exit criteria before enabling any of the first threeEach of these features is a temporary accommodation in most designs — a migration that will finish, a customer topology that could be renumbered. Writing down when it will be removed, at the moment it is added, is the difference between a controlled exception and a permanent weakening that outlives everyone who understood why it was there.
Sub claimEvery one of these features solves a real problem the protocol did not anticipate, and three of them pay for it with the only loop detection eBGP has — which makes knowing which protection to add back part of knowing the feature.

How Do I Configure local-as for an AS Migration?

What does each modifier change?

The bare command prepends the configured local AS in front of the real AS on advertisements to that neighbour, and accepts inbound updates containing the local AS. The peer therefore sees two AS numbers where it previously saw one. no-prepend stops the local AS being prepended to received updates as they enter the local table. replace-as, which requires no-prepend, substitutes the local AS for the real one on outbound advertisements so the peer sees only the old number — this is the combination that makes a migration invisible to the peer. dual-as allows the peer to configure either the old or the new AS as remote-as, so the peer can be updated on their own schedule.

A Deeper Dive into local-as

The migration scenario

AS 65000 acquires AS 65200. The acquired routers will move into AS 65000, but their customers all have remote-as 65200 configured and cannot all be changed on one night. local-as 65200 on each customer-facing session lets the router run in AS 65000 while continuing to appear as 65200 to those customers, and dual-as lets each customer switch to remote-as 65000 whenever they are ready.

! ===== The acquired router, now in AS 65000 =====
router bgp 65000
 bgp router-id 10.0.0.1
 !
 ! Customer still configured for the old AS 65200
 neighbor 192.0.2.2 remote-as 65100
 neighbor 192.0.2.2 local-as 65200 no-prepend replace-as dual-as
 !
 address-family ipv4 unicast
  neighbor 192.0.2.2 activate
 exit-address-family
! The customer may keep 'remote-as 65200' or switch to 65000
! at a time of their choosing, without coordination.

What the peer sees with each combination

Configuration Peer sees for a locally originated prefix Peer's remote-as must be Use case
local-as 65200 65200 65000 65200 Rare — exposes both ASes
local-as 65200 no-prepend 65200 65000 65200 Changes inbound handling only
local-as 65200 no-prepend replace-as 65200 65200 Clean migration — peer sees no change
...replace-as dual-as 65200 65200 or 65000 Lets the peer cut over independently
No local-as 65000 65000 Migration complete 
! Verify what the session is actually presenting
R1# show ip bgp neighbors 192.0.2.2 | include local AS|Local AS
  Local AS number 65200 no-prepend replace-as dual-as
!
! And what the customer sees on their side
R-CUST# show ip bgp 10.100.0.0/16
  65200
    192.0.2.1 from 192.0.2.1 (10.0.0.1)
      Origin IGP, metric 0, localpref 100, valid, external, best
! ^ Only 65200. The real AS 65000 is invisible to them.

Running the migration and knowing when it is finished

A migration using local-as has a definite end state, and the value of dual-as is that each peer reaches it independently. The sequence per customer is: they change remote-as from the old number to the new one, the session re-establishes, and you then remove the local-as line from that neighbour. Until every customer has done so, the router carries a mixture — some sessions presenting the old AS and some the new — which is entirely normal and is visible in one command.

The trap is the last ten percent. Customers who never respond leave local-as statements in place indefinitely, and a year later nobody remembers whether they are load-bearing. Track the list explicitly, set a date, and treat a remaining local-as after that date as a defect to chase rather than a configuration to preserve.

! How many sessions are still presenting the old AS?
R1# show running-config | include local-as
 neighbor 192.0.2.2 local-as 65200 no-prepend replace-as dual-as
 neighbor 192.0.2.6 local-as 65200 no-prepend replace-as dual-as
!
! Which AS is a given peer actually using in its remote-as?
R1# show ip bgp neighbors 192.0.2.2 | include remote AS|Local AS
BGP neighbor is 192.0.2.2,  remote AS 65100, external link
  Local AS number 65200 no-prepend replace-as dual-as
!
! After the customer switches to remote-as 65000, remove it
R1(config-router)# no neighbor 192.0.2.2 local-as
! ^ This resets that one session. Schedule it with the customer.

Restrictions worth knowing before you plan around it

  • It applies only to eBGP sessions. Configuring it on an iBGP neighbour is rejected.
  • The local AS cannot be the router's own AS, and cannot be the neighbour's AS.
  • It is configured per neighbour, so a phased migration can convert customers in any order.
  • Changing it resets the session with that neighbour, so each change is a brief outage for that customer only.
  • The local AS is accepted in inbound AS_PATHs, which is a deliberate relaxation of loop detection for the duration.
! It is per-neighbour, so a phased migration is straightforward
router bgp 65000
 ! Customers not yet cut over
 neighbor 192.0.2.2 local-as 65200 no-prepend replace-as dual-as
 neighbor 192.0.2.6 local-as 65200 no-prepend replace-as dual-as
 ! This one has already moved to remote-as 65000 - no local-as needed
 neighbor 192.0.2.10 remote-as 65300
!
! Removing it when a customer has cut over resets that session only
R1(config-router)# no neighbor 192.0.2.2 local-as
Pitfall: forgetting that local-as lengthens the AS path Symptom: after enabling local-as without replace-as, traffic that used to arrive over this path shifts to an alternative provider, and the change is attributed to something else entirely. Cause: without replace-as, every advertisement toward that peer carries two AS numbers instead of one, so the path is one hop longer at best-path step four everywhere downstream. Confirm: on the peer, show ip bgp <prefix> shows two ASes where one was expected. Fix: add no-prepend replace-as so the peer sees only the local AS. If both numbers must be visible for a transitional reason, expect and account for the extra path length.
Sub claimlocal-as ... no-prepend replace-as dual-as is the only combination that makes an AS migration invisible to a peer and lets that peer cut over on their own schedule — the shorter forms all leak the change into the path.

How Do I Handle a Customer That Uses the Same AS at Multiple Sites?

Which of the two solutions should I use?

as-override on the provider edge, in almost every case. It rewrites the customer's AS number out of the path before the PE advertises to the CE, so the CE's loop check never fires and the CE needs no configuration at all. That keeps the accommodation under provider control, applies uniformly to every site, and does not require the customer to weaken anything on their own equipment. allowas-in on the customer router is the alternative, and it is appropriate when the customer controls both ends and the provider will not or cannot configure as-override. Both must be paired with Site of Origin, because both remove the check that would otherwise catch a real loop.

A Deeper Dive into the Two Solutions

as-override on the PE

When PE-2 advertises to CE-2, it examines the AS_PATH for occurrences of CE-2's AS number and replaces each with its own. CE-2 therefore receives a path containing the provider's AS rather than its own, passes its loop check, and installs the route. The customer sees a path that is factually wrong — their own prefix appears to originate in the provider's AS — which is the cost of the mechanism.

! ===== PE-2, in the customer VRF =====
router bgp 65000
 address-family ipv4 vrf CUST-A-VPN
  neighbor 172.16.2.2 remote-as 65100
  neighbor 172.16.2.2 activate
  neighbor 172.16.2.2 as-override
 exit-address-family
!
! What CE-2 receives for a prefix originated at site 1
CE-2# show ip bgp 172.16.1.0/24
  65000 65000
    172.16.2.1 from 172.16.2.1 (10.0.0.2)
      Origin IGP, localpref 100, valid, external, best
! ^ The customer's own 65100 was replaced with the provider's 65000.
!   CE-2's loop check sees no 65100 and accepts the route.

allowas-in on the CE

The customer router relaxes its own check, accepting updates whose AS_PATH contains its AS up to a configured number of times. The default when no number is supplied is three; the range is one to ten. Unlike as-override, the path remains truthful — the customer can see that the prefix originated at their own other site.

! ===== CE-2, accepting its own AS in the path =====
router bgp 65100
 address-family ipv4 unicast
  neighbor 172.16.2.1 remote-as 65000
  neighbor 172.16.2.1 activate
  neighbor 172.16.2.1 allowas-in 2
  ! Range 1-10; the default when no number is given is 3.
  ! Set the smallest value the topology actually requires.
 exit-address-family
!
CE-2# show ip bgp 172.16.1.0/24
  65000 65100
    172.16.2.1 from 172.16.2.1 (10.0.0.2)
      Origin IGP, localpref 100, valid, external, best
! ^ The path is truthful: 65100 originated it. CE-2 accepted it
!   because allowas-in permits up to two occurrences.

The two compared

Property as-override allowas-in
Configured on PE, per VRF neighbour CE, per neighbour
Under whose control Provider Customer
Customer configuration required None One command per session
AS_PATH remains truthful No — the customer AS is rewritten Yes
Applies uniformly to all sites Yes, if configured on every PE Only where the customer configured it
Path length seen by the customer Same length, different numbers Unchanged
Loop protection removed Yes Yes
Recommended Yes, with SoO Where the provider will not configure override

Why the two should not both be enabled

Configuring as-override on the PE and allowas-in on the CE at the same time is harmless in the sense that routing works, but it means two independent relaxations of the same check where one was needed. More practically it obscures the design: an engineer reading the CE configuration cannot tell whether allowas-in is load-bearing, and removing the PE-side override later appears to change nothing until the day the customer removes their own command. Choose one, document it, and remove the other.

Neither feature affects the customer's own best-path choiceas-override changes the numbers in the path but not its length, so a customer comparing two paths at step four sees the same lengths they would have seen. allowas-in changes nothing about the path at all. Both features decide whether a route is accepted; once accepted it competes normally. That matters when a customer has both an MPLS path and a direct backdoor between two sites — neither feature makes the MPLS path win, and the usual answer there is local preference on the customer's own routers.
Pitfall: allowas-in with the default count on a large topology Symptom: a routing loop forms between two customer sites and persists, with traffic ping-ponging until a link saturates. BGP reports no problem and every session is stable. Cause: allowas-in with no number permits three occurrences of the local AS, which is enough for a path to traverse the customer's own network twice and still be accepted. Nothing in BGP will now detect the loop. Confirm: show ip bgp <prefix> on both CEs shows a path containing the local AS more than once; a traceroute alternates between the two sites. Fix: set the smallest count the topology requires, usually 1 or 2, and deploy Site of Origin so the provider network stops the route from returning to its origin site.
Sub claimas-override is the better of the two because the accommodation lives with the provider who understands the topology — but both remove the same check, so both incur the same obligation to deploy Site of Origin.

How Do I Use remove-private-as and Prepending Correctly?

What are the rules for each?

remove-private-as applies only to eBGP sessions in the outbound direction. In its bare form it removes private AS numbers only when the path contains nothing but private numbers, stopping at the first public AS it encounters — which is frequently not what people expect. The all keyword removes every private AS regardless of position, and replace-as substitutes the local AS for each removed number so path length is preserved. Prepending is configured in a route-map with set as-path prepend, applied outbound to influence what other autonomous systems prefer, or inbound to influence only your own step-four comparison. Its effect depends entirely on whether the receiving network compares path length before it applies its own local preference.

A Deeper Dive into Both

remove-private-as and its three forms

Form Path 65100 64512 65010 becomes Path 64512 64513 becomes Path length preserved
remove-private-as Unchanged — stops at the public 65100 (empty) No
remove-private-as all 65100 65010 (empty) No
remove-private-as all replace-as 65100 65000 65010 65000 65000 Yes 
! Strip private ASes before advertising to the internet
router bgp 65000
 address-family ipv4 unicast
  ! Bare form: only strips if the path is ENTIRELY private
  neighbor 198.51.0.6 remove-private-as
  !
  ! 'all' strips them even alongside public ASes - usually correct
  neighbor 198.51.0.6 remove-private-as all
  !
  ! 'replace-as' keeps the path the same length
  neighbor 198.51.0.6 remove-private-as all replace-as
 exit-address-family
!
! Verify from the receiving side
R-TRANSIT# show ip bgp 203.0.113.0/24
  65000 65000
    198.51.0.5 from 198.51.0.5 (10.0.0.2)
! ^ replace-as substituted 65000 for the customer's private AS.

Why the bare form surprises people

Use all replace-as as the default choice on any session facing the public internet. Removing numbers without replacing them shortens the path, which makes your advertisement look artificially better than it is and can attract traffic the design did not anticipate; replace-as keeps the length honest at no cost.

The unqualified command was specified to handle the simple case of a customer using a private AS with no downstream autonomous systems. As soon as a path mixes public and private numbers — a private-AS customer of a public-AS customer of yours — the bare form leaves everything alone, because it stops at the first public AS. The symptom is private AS numbers continuing to appear in your advertisements despite the command being configured, and the fix is the all keyword.

Prepending, and why it often accomplishes nothing

Prepending lengthens the AS path so that other autonomous systems, comparing at best-path step four, prefer a shorter alternative. It fails whenever the receiving network has already decided at step two by setting local preference at ingress — which most transit providers do as a matter of course, precisely so their own policy governs rather than their customers'. Three prepends is the practical ceiling; beyond that many networks filter or ignore the additional length, and the marginal effect of the fourth and fifth is essentially zero.

! Outbound prepending - influences OTHER autonomous systems
route-map PREPEND-TRANSIT-B permit 10
 set as-path prepend 65000 65000 65000
!
router bgp 65000
 address-family ipv4 unicast
  neighbor 198.51.0.6 route-map PREPEND-TRANSIT-B out
 exit-address-family
!
! Prepend whatever the leftmost received AS is, N times
route-map PREPEND-LAST permit 10
 set as-path prepend last-as 2
! ^ Useful in a template where the AS varies per neighbour.
!
! Inbound prepending - affects ONLY our own step-4 comparison
route-map DEPREF-IN permit 10
 set as-path prepend 65000 65000
router bgp 65000
 address-family ipv4 unicast
  neighbor 198.51.0.6 route-map DEPREF-IN in
! ^ Local preference would be the better tool here in most designs.

Prepending the right AS, and per-prefix prepending

Two details separate a prepend that works from one that produces confusion. The AS you prepend should be your own — prepending somebody else's number is legal on Cisco platforms and is a form of AS_PATH forgery that some networks filter and all of them regard as hostile. And a prepend applied to the whole session affects every prefix you advertise, which is rarely the intent; usually only a subset needs de-preferencing over that path, and the route-map should match that subset rather than permitting everything.

Per-prefix prepending is also what makes partial load distribution possible across two providers. Advertising half your prefixes with a prepend toward provider A and the other half with a prepend toward provider B splits inbound traffic roughly in proportion, whereas prepending everything toward one provider simply moves all of it.

! WRONG - prepends everything over this session
route-map PREPEND-ALL permit 10
 set as-path prepend 65000 65000
!
! RIGHT - only the prefixes that should prefer the other path
ip prefix-list DEPREF-VIA-B seq 5 permit 203.0.113.0/24
ip prefix-list DEPREF-VIA-B seq 10 permit 198.51.100.0/22
!
route-map TRANSIT-B-OUT permit 10
 match ip address prefix-list DEPREF-VIA-B
 set as-path prepend 65000 65000
route-map TRANSIT-B-OUT permit 20
 ! Everything else advertised normally over B
!
! Confirm the split is what you intended
R1# show ip bgp neighbors 198.51.0.6 advertised-routes
   Network          Next Hop   Metric LocPrf Weight Path
 *> 203.0.113.0/24   198.51.0.5                    0 65000 65000 65100 i
 *> 192.0.2.0/24     198.51.0.5                    0 65100 i
! ^ One prepended, one not. That is a deliberate split.

What to use instead when prepending fails

If the receiving network publishes communities that set local preference inside their AS, use those — a community is an instruction that acts at step two, while a prepend is a request that acts at step four and only if step two did not already decide. Most transit providers document a set of such communities. Where no community exists and prepending is ignored, the remaining options are advertising a more specific prefix over the preferred path, or accepting that inbound traffic engineering across that provider is not available to you.

! A provider community that sets local preference inside their AS
route-map DEPREF-VIA-B permit 10
 ! Example format only - each provider publishes its own values
 set community 65400:80 additive
!
router bgp 65000
 address-family ipv4 unicast
  neighbor 198.51.0.6 route-map DEPREF-VIA-B out
  neighbor 198.51.0.6 send-community
 exit-address-family
! ^ Without send-community the tag never leaves and nothing happens.
Pitfall: prepending against a provider that sets local preference Symptom: prepends are added, verified as present in the provider's looking glass, and inbound traffic distribution does not change at all — adding more prepends changes nothing either. Cause: the provider sets local preference on your prefixes at ingress, deciding at best-path step two; AS path length is step four and is never reached. Confirm: a public looking glass in the provider's AS shows your prepends present alongside an unchanged local preference and an unchanged best path. Fix: use the provider's published local-preference communities. Prepending is a request that a provider may have already overruled by policy; a community is an instruction they agreed to honour.
Verify from outside, not from your own routerYour router shows what it advertised; it cannot show what anyone did with it. A public looking glass in the provider's autonomous system shows both — your prepends present in the path, and the local preference the provider applied. If the two appear together and the best path did not move, prepending is not the mechanism for that provider and no further prepending will help.
Three prepends, then stopIf three prepends have not shifted traffic, a fourth will not either. Excessive prepending is visible to everyone, is filtered by some networks, and signals that the operator has not found the actual lever. Move to communities, or accept the limit.
Sub claimPrepending acts at step four and local preference acts at step two, which means every case where prepending appears not to work is a case where somebody upstream already decided — and the answer is their communities, not more prepends.

Which Features Weaken Loop Prevention, and What Then?

What replaces the protection you removed?

Site of Origin, an extended community that tags every prefix with the customer site it entered from. A PE will not advertise a prefix back toward a site whose SoO value it carries, which restores exactly the protection that allowas-in and as-override removed — scoped to a VPN site rather than to an autonomous system. It is configured on the PE, inbound from each CE, and it is the only mechanism that reliably prevents the two-site loop these features make possible. Where a customer has two routers at one site, both attachments must carry the same SoO value, or the protection blocks legitimate traffic between them.

A Deeper Dive into Site of Origin and the Remaining Risk

Configuring SoO

! ===== PE-1, site 1: tag everything from this site =====
route-map SOO-SITE1 permit 10
 set extcommunity soo 65000:1
!
router bgp 65000
 address-family ipv4 vrf CUST-A-VPN
  neighbor 172.16.1.2 remote-as 65100
  neighbor 172.16.1.2 activate
  neighbor 172.16.1.2 route-map SOO-SITE1 in
  neighbor 172.16.1.2 as-override
 exit-address-family
!
! ===== PE-2, site 2: a DIFFERENT value =====
route-map SOO-SITE2 permit 10
 set extcommunity soo 65000:2
!
router bgp 65000
 address-family ipv4 vrf CUST-A-VPN
  neighbor 172.16.2.2 route-map SOO-SITE2 in
  neighbor 172.16.2.2 as-override
 exit-address-family

! Verify the tag is attached and being honoured
PE-2# show bgp vpnv4 unicast vrf CUST-A-VPN 172.16.1.0/24 | include Extended
      Extended Community: RT:65000:100 SoO:65000:1
!
! PE-1 will not advertise this back toward site 1
PE-1# show ip bgp vpnv4 vrf CUST-A-VPN neighbors 172.16.1.2 advertised-routes | include 172.16.1
! (no output - the SoO matches this site, so it is suppressed)

Dual-homed sites and the shared SoO value

A customer site with two CE routers attached to two different PEs must have the same SoO value on both attachments. If the two PEs tag with different values, each considers the other's prefixes to be from a different site and advertises them onward, which restores the loop the SoO was meant to prevent. Getting this wrong is easy because the natural instinct is one value per PE rather than one value per site.

! ===== Site 1 is dual-homed to PE-1 and PE-3 =====
! BOTH must use 65000:1 - one value per SITE, not per PE
!
! On PE-1:
route-map SOO-SITE1 permit 10
 set extcommunity soo 65000:1
!
! On PE-3:
route-map SOO-SITE1 permit 10
 set extcommunity soo 65000:1
! ^ Same value. A different value here breaks the protection.
!
! Audit: every PE serving a site should agree
PE-3# show running-config | include extcommunity soo
 set extcommunity soo 65000:1

What to do when SoO is not available

Site of Origin is an MPLS L3VPN mechanism. A design that relaxes AS_PATH checking outside that context — two sites of the same autonomous system connected through a plain eBGP provider, for instance — has no equivalent, and needs a different approach. Three options exist and none is as clean.

The first is to renumber: give one site a different autonomous system number, which removes the problem entirely and is usually cheaper than the ongoing risk. The second is to filter explicitly: on each site's router, an outbound AS-path or prefix-list filter that refuses to re-advertise anything learned from the provider back toward the provider, which prevents the loop by preventing the re-advertisement rather than by detecting it. The third is to accept the risk with bounds — the lowest possible allowas-in count, a tight maximum-prefix, and monitoring on prefix counts — which is a mitigation rather than a solution.

! Option 2: never re-advertise provider-learned prefixes upstream
ip as-path access-list 25 permit ^$
ip as-path access-list 25 permit ^65100(_65100)*$
! ^ Only our own prefixes leave. Anything learned from the provider,
!   including our sibling site's prefixes, is not re-advertised.
!
router bgp 65100
 address-family ipv4 unicast
  neighbor 172.16.1.1 filter-list 25 out
  neighbor 172.16.1.1 allowas-in 1
  neighbor 172.16.1.1 maximum-prefix 500 80 restart 15
 exit-address-family
!
! Detect a loop that forms anyway
CE-1# show ip bgp regexp _65100_.*_65100_ | include Total
Total number of prefixes 0
! ^ Non-zero here means a path traversed our AS twice. Investigate.

The residual risk after SoO

SoO prevents a prefix returning to the site it came from. It does not prevent every loop a relaxed AS_PATH check could permit — a three-site topology with unusual policy can still construct one, and SoO on a non-MPLS design is not available at all. Two additional controls are worth having: a maximum-prefix limit on every CE-facing session, which bounds the damage of any loop that does form, and a monitoring alert on prefix counts, which detects one within an update cycle.

Feature enabled Protection removed Replacement Additional bound
allowas-in eBGP loop detection at the CE SoO on the PE Lowest workable count; maximum-prefix
as-override eBGP loop detection at the CE SoO on the PE maximum-prefix on CE sessions
local-as Acceptance of the local AS inbound Time-bounded migration Remove once the peer cuts over
remove-private-as None — —
as-path prepend None — —

Verification checklist

! Which sessions have a relaxation configured?
R1# show running-config | include allowas-in|as-override|local-as
!
! Does every one of them have a corresponding SoO?
PE-1# show running-config | include extcommunity soo
!
! Is any prefix carrying our own AS more than once?
CE-2# show ip bgp regexp _65100_.*_65100_
! ^ Any output here is a path that traversed the customer AS twice.
!
! Are the prefix counts what they should be?
CE-2# show ip bgp summary | include 172.16.2.1
Exam contextThese four features appear in the CCIE Enterprise Infrastructure blueprint under BGP configuration and in the MPLS L3VPN material, and are examined by scenario: a task describes a merger, or a customer with a shared AS, and expects the correct command with the correct modifiers. The reliably tested items are the no-prepend replace-as combination for a transparent migration, the choice between as-override and allowas-in, and the requirement for Site of Origin alongside either. ENARSI 300-410 covers allowas-in, remove-private-as, and prepending; the SoO and as-override material sits with the L3VPN topics.
Sub claimSite of Origin is not an optional refinement to as-override and allowas-in — it is the replacement for the protection those commands remove, and a design using either without it has no loop detection at all.

Conclusion

These four commands sit on a spectrum. remove-private-as and prepending edit the path without touching anything the protocol relies on, and can be deployed freely. local-as relaxes loop detection for a specific neighbour and a specific transitional purpose, which is acceptable because the transition ends. allowas-in and as-override remove the check entirely for a class of prefixes and do so permanently, which is why they are the two that carry an obligation — deploy Site of Origin, or accept that a loop between two customer sites will go undetected until someone notices the traffic.

The recurring theme is that each feature makes the AS_PATH less truthful, and the AS_PATH is the only thing eBGP trusts. local-as shows a peer an autonomous system the router is no longer in. as-override replaces a customer's AS with the provider's, so the customer's own prefix appears to originate somewhere it did not. allowas-in leaves the path truthful but stops believing it. Each of these is fine as long as somebody has thought about what now catches the case the path used to catch, and each becomes dangerous the moment it is inherited by an engineer who was not told why it was there.

Practically: use no-prepend replace-as dual-as for a migration so the peer sees no change and can cut over independently, and remove it when they do. Prefer as-override to allowas-in because the accommodation belongs with the provider, and pair it with one Site of Origin value per customer site — not per PE. Use remove-private-as all rather than the bare form, because the bare form stops at the first public AS and rarely does what people expect. And when prepending does not shift traffic, stop adding prepends and go looking for the provider's communities, because the decision was made two steps earlier in the algorithm than the one you are trying to influence.

Reference Notes

  1. RFC 4271, Section 9.1.2 — a BGP speaker rejects any eBGP UPDATE whose AS_PATH contains its own autonomous system number.
  2. RFC 4271, Section 5.1.2 — AS_PATH construction on eBGP advertisement, which is what prepending and local-as manipulate.
  3. RFC 4271, Section 9.1.2.2 — AS path length is compared after local preference in the decision process, which is why prepending loses to ingress local-preference policy.
  4. RFC 4360, Section 5 — the Route Origin extended community, implemented by Cisco as Site of Origin.
  5. RFC 4364, Section 4.3.5 — Site of Origin prevents a route from being advertised back to the site it was learned from, restoring loop protection in a VPN.
  6. RFC 6996 — private AS ranges 64512–65534 and 4200000000–4294967294.
  7. Cisco IOS-XE BGP Configuration Guide — neighbor local-as applies only to eBGP sessions and may not use the router's own AS or the neighbour's AS.
  8. Cisco IOS-XE BGP Configuration Guide — replace-as requires no-prepend, and substitutes the local AS for the real AS in outbound advertisements.
  9. Cisco IOS-XE BGP Configuration Guide — dual-as allows the peer to establish the session using either the real AS or the configured local AS.
  10. Cisco IOS-XE BGP Configuration Guide — neighbor allowas-in accepts a count from 1 to 10, defaulting to 3 when no value is supplied.
  11. Cisco IOS-XE BGP Configuration Guide — neighbor as-override replaces occurrences of the neighbour's AS in the AS_PATH with the local AS on outbound advertisements.
  12. Cisco IOS-XE BGP Configuration Guide — remove-private-as without all removes private AS numbers only when no public AS appears in the path; replace-as substitutes the local AS to preserve path length.