Summary

  • Ordinary BGP treats the local ASN in AS_PATH as loop evidence. allowas-in changes the receiver's verdict; as-override changes the path before that receiver sees it.
  • Both mechanisms can support sites that reuse one ASN, but neither authenticates a prefix, proves forwarding or makes a broad exception safe. Route Target and Site of Origin solve different problems.
  • A defensible change preserves the path before and after mutation, records neighbor and address-family scope, verifies prefix and site controls, follows the route into the FIB and packets, and proves rollback.

The correct rejection

Consider an illustrative service, not a reported incident. Branch A and Branch B both use the same customer ASN behind a provider network. Branch A advertises a prefix. The provider carries it to Branch B, where the customer router sees its own ASN in AS_PATH and rejects the route. The session is established, the provider has the route, and the branch still cannot use it.

The rejection is not a mysterious interoperability failure. It is the ordinary safety verdict. RFC 4271 requires a BGP speaker to exclude a route containing its own ASN from the decision process; operation configured to accept such a route lies outside that specification. The path is saying, in effect, “this information has already crossed your routing domain.” RFC 4271

Two remedies are proposed. The customer can permit a limited number of its own ASN occurrences on receipt. That is commonly called allowas-in or allow-own-as. Or the provider can replace occurrences of the customer's ASN before advertising the route back to that customer. That is as-override.

The two options are often described as interchangeable reachability knobs. They are not. The first preserves the path and changes the receiver's acceptance rule. The second changes the evidence so the default rule no longer fires. One spends authority at the customer boundary; the other spends custody of path history at the provider boundary.

AS_PATH is evidence, not authentication

AS_PATH supports loop detection and influences route selection, but it is not a signed transcript of physical forwarding. RFC 4272 notes that a speaker verifies the presence of its own ASN rather than validating every claimed transition. It also explains how false or shortened paths can influence selection and permit loops. The practical conclusion is restrained: AS_PATH is valuable operational evidence precisely because it is imperfect, mutable and interpreted locally. RFC 4272

That makes a self-AS exception more consequential than its command-line size suggests. With receiver acceptance, the operator changes how many appearances are tolerated, perhaps only for one peer, address family, route map or origin condition. FRRouting, for example, documents occurrence limits and additional origin or route-map scope, while RFC 7938 describes allowas-in as widely available but non-standardized in a particular reused-private-AS data-centre design. Those controls prove that scope exists; they do not create a universal safe count. FRRouting BGP documentation, RFC 7938

With sender rewrite, the receiver can keep its ordinary rejection rule because the matching ASN is no longer visible. FRRouting and Junos document replacement of AS_PATH occurrences equal to the peer's ASN with the provider's local ASN. Junos also notes that repeated occurrences introduced by customer prepending are replaced. The resulting path may retain a similar length while losing the identity that explained who inserted those positions. FRRouting BGP documentation, Junos as-override

This is why a post-change route-table screenshot is weak evidence. It shows the path after the decision that needs scrutiny. A proper record preserves the customer's original advertisement, the provider's received path, the intended export before mutation, the path actually exported, and the receiving customer's accepted route. Without that chain, an investigator cannot distinguish a legitimate bounded rewrite from unexpected path loss.

Membership, origin and authorization are different controls

Provider VPN terminology can make several controls sound interchangeable. They are not. In RFC 4364, a Route Target determines which VPN routes are eligible for import. A Site of Origin identifies the site from which a route was learned and is used to prevent that route from being redistributed back to a CE at that site. Prefix authorization answers yet another question: whether this customer or attachment was entitled to originate the prefix at all. RFC 4364

Route Target membership cannot replace lost self-AS evidence. It may deliver the same bad or circulating route to precisely the VPN members configured to receive it. Site of Origin is closer to the loop problem, but it works only when the relevant attachments set and enforce it consistently. It does not authenticate a customer and does not prove that every return path crosses the same enforcement point.

Cisco's current IOS XR documentation makes the risk explicit in its documented L3VPN workflow: AS override loses information and can lead to loops, so Site of Origin is used as a compensating control in that scenario. The conclusion should remain local to the design. It does not mean every use of as-override automatically has SoO coverage, or that SoO is sufficient for arbitrary topologies. Cisco IOS XR BGP documentation

RFC 9835 reinforces the separation in a management model: as-override, allow-own-as, its occurrence maximum, and Site of Origin are distinct parameters. A model is not a cross-vendor behavioural guarantee, but it is useful evidence against collapsing four decisions into one checkbox. RFC 9835

Follow one route through both exceptions

Start with the strict state. Capture Branch A's Adj-RIB-Out and the provider edge's Adj-RIB-In. Record the route distinguisher and Route Targets if the service uses a VPN, but do not mistake them for proof of origin. At the remote edge, capture the path before customer export. At Branch B, preserve the rejected-route view and the explicit self-AS reason where the platform exposes it.

For a receiver-side exception, document the effective policy after group inheritance: exact neighbour, AFI/SAFI, maximum permitted occurrences, origin-only behaviour if present, and any prefix or route-map condition. Confirm that a control route outside the intended prefix set remains rejected. The key evidence is not the configured line but the compiled scope that the speaker actually applies.

For a sender-side rewrite, make a token-by-token diff of AS_SEQUENCE before and after export. Do not inspect only the origin. If the customer prepended its ASN several times, a platform may replace every matching occurrence. Store the original display outside the mutable router because the rewritten advertisement cannot reconstruct the lost identity by itself.

Then verify the controls that supposedly replace the spent evidence. Is the route authorized for the attachment? Are Route Targets limited to the intended service? Is Site of Origin attached where the design requires it and rejected on return to that site? Do any parallel attachments, route reflectors or redistribution points bypass the check? RFC 6368's discussion of remapping and accept-own-AS workarounds is a reminder that a customer using BGP internally may have consequences beyond the PE–CE session. RFC 6368

Acceptance is still not delivery. Confirm selection in the Loc-RIB, resolve the next hop, inspect the FIB or hardware entry and send controlled traffic in both directions. Include a safe failure exercise that would expose unintended re-entry without creating production circulation. Compare packet path, counters and loss during the exception and after its removal.

RFC 7705 supplies a useful caution from ASN migration: manipulating path history can allow a router to accept a route that ordinary self-AS rejection would have stopped. It is not a specification for as-override; it demonstrates why “the route became usable” cannot be the only success condition. RFC 7705

The rollback must restore evidence, not just reachability

A reversible change has an explicit end state. One option is to assign distinct site ASNs and remove the exception. Another is a deliberately persistent, narrow receiver allowance. A third is provider override with verified site-loop controls. The correct choice depends on topology, operating boundaries and migration cost; no cited source supplies a universal winner.

Rollback means more than deleting a command. The strict or replacement design must once again reject a canary path with the local ASN where expected, preserve authorized inter-site reachability, install the intended FIB entries and carry packets without circulation. If the operation cannot state which evidence returns after rollback, it has documented a configuration action rather than a recovered safety property.