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

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