> For the complete documentation index, see [llms.txt](https://docs.console.zenlayer.com/welcome/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.console.zenlayer.com/welcome/elastic-compute/networking/01-overview-4/03-origin-asn.md).

# BYOIP Origin ASN and RPKI

Every customer CIDR carries an origin ASN — the ASN that sits at the right edge of the AS-path when the rest of the internet looks up your prefix. Two gates decide whether a given `(CIDR, ASN)` pair can be announced: a platform-level supported-ASN check, and an RPKI ROA check.

![RPKI validation gate before the CIDR is accepted](/files/ZugoJyyQxaKBk5vGB3eA)

## What the Origin ASN Does

The origin ASN is the last ASN in the AS-path for your prefix. It's what appears in looking-glass output, what peers' import policies filter on, and what RPKI validators compare against. Choosing it is a traffic-engineering and identity decision:

* If you already operate an ASN, using it keeps the AS-path consistent with anything else you announce from that ASN.
* If the ASN you want to use is not yet on the supported list, you won't be able to pick it — the platform only announces from ASNs that have been onboarded for auto announcement.

## Supported ASN Check

Before you pick an ASN, confirm it is eligible. The console exposes the list of origin ASNs currently supported for auto announcement. Private ASN ranges are rejected; so are ASNs that haven't been enabled for the flow.

If your ASN isn't on the list, that's the constraint to resolve first — either by using an ASN that is supported, or by working with Zenlayer via [support](mailto:support@zenlayer.com) to add yours.

## RPKI Validation

RPKI is the second gate, and the one that catches the most surprises. Before the prefix is accepted, Zenlayer evaluates your ROA against the `(CIDR, origin ASN)` pair you submitted. The check must come back **Valid** — `NotFound` and `Invalid` both block the creation.

Common reasons a ROA fails validation:

| Cause                 | What it looks like                                                                      | Fix                                                        |
| --------------------- | --------------------------------------------------------------------------------------- | ---------------------------------------------------------- |
| No ROA exists         | Validation returns `NotFound`                                                           | Publish a ROA covering the prefix and ASN through your RIR |
| Wrong ASN in the ROA  | Validation returns `Invalid` with a different origin                                    | Publish or update the ROA to authorize the ASN you want    |
| `maxLength` too short | Valid ROA exists but doesn't cover the specific prefix length you're trying to announce | Raise `maxLength` to ≥ the prefix length                   |
| ROA expired           | Validation returns `Invalid` on an otherwise correct ROA                                | Renew the ROA with your RIR                                |

Publishing a fresh ROA propagates through the RPKI repositories in minutes to a few hours depending on your RIR. Don't submit the create until you've confirmed the new ROA is visible to public validators.

## Updating the Origin ASN

You can change the origin ASN on an already-accepted CIDR. The rules are the same as for creation:

1. The new ASN must be on the supported list.
2. A valid ROA must authorize the `(CIDR, new ASN)` pair.
3. The CIDR must already be in the announcement system.

The operational sequence matters:

1. Publish (or update) the ROA for the new ASN first.
2. Wait for RPKI propagation.
3. Submit the ASN change.

If you flip the order — submit the update first, then publish the ROA — validation will fail and the update is rejected. Existing allocations are not affected during the update; the change only rewrites how the prefix is announced.

***

## Frequently Asked Questions

**Can I use a private ASN?** No. The platform validates origin ASN values and rejects private ASN ranges.

**Can Zenlayer tell me which ASNs are available?** Yes. The console shows the list of origin ASNs currently supported for auto announcement. Pick from that list.

**Is RPKI checked only on create?** No. Both initial creation and origin-ASN updates re-run the RPKI check. There is no path into the announcement system that skips it.

**If the ROA expires after the CIDR is active, does the announcement stop?** Not from the Zenlayer side — the prefix keeps being announced. But downstream networks that enforce RPKI will drop the route once the ROA is `Invalid`, so practical reachability degrades. Renew the ROA before it expires.