# 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.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.console.zenlayer.com/welcome/elastic-compute/networking/01-overview-4/03-origin-asn.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.