BYOIP Best Practices

The recommendations below are grouped by what you're trying to protect: publishing the prefix safely, keeping operations clean during day-to-day use, and avoiding surprises at retirement. A troubleshooting checklist follows.

Publishing the Prefix

• Publish the ROA first, not last. Creation will fail if RPKI doesn't return Valid for the (prefix, ASN) pair. Publish, wait for propagation, verify with a public validator, then create.

• Keep maxLength aligned with what you'll announce. If you plan to announce /24, make sure maxLength covers /24. A ROA that only covers /22 will leave a more-specific /24 announcement Invalid.

• Pick a supported origin ASN up front. The console's supported-ASN list is authoritative. Choosing an unsupported ASN — including any private ASN — means the create fails and nothing is announced.

• Don't keep the same prefix active on another network. If a second network is still originating the prefix, traffic can bounce or black-hole. Coordinate the cutover before directing production traffic onto the customer pool.

Day-to-Day Operations

• Audit with the customer-owned flag. Filter EIPs by the customer-owned flag when confirming that critical workloads are using your own address space rather than a default Zenlayer EIP pool. The flag is the fastest answer to "is this EIP ours?"

• Record the pool ID where allocations happen. The pool ID is the only thing separating an allocation targeted at your CIDR from one targeted at the default pool. Keep it in whatever runbook or template drives EIP creation.

• Update the ROA before the ASN change, not after. If you plan to move the origin ASN, publish the new ROA first, confirm propagation, then submit the ASN update. The update re-runs the RPKI check and will reject otherwise.

• Don't rely on ASN changes to fix live reachability issues. ASN updates don't affect allocations; they change how the prefix is announced. If traffic is mis-pathed, investigate routing before changing identity.

Retirement

• Drain before you delete. The delete path checks for allocated addresses and rejects removal while any are still in use. Move workloads off, release the EIPs, then delete the CIDR.

• Clean up the ROA if you're rotating the prefix. If the prefix is moving to another network, remove the ROA authorization for Zenlayer so the new origin isn't shadowed by a stale Valid authorization.

---

Troubleshooting

Symptom	What to check
Create fails with an RPKI error	(1) A ROA exists for the prefix. (2) The ROA authorizes the exact ASN you submitted. (3) maxLength covers the prefix length. (4) The ROA hasn't expired. Re-publish and wait for propagation before retrying.
Create fails with unsupported ASN	The ASN is not on the supported-ASN list. Pick one from the list, or arrange with Zenlayer via support to have your ASN added. Private ASNs are always rejected.
EIP allocation lands on a Zenlayer-assigned address instead of yours	The allocation didn't target the customer pool. Check the customer-owned flag; release and re-allocate with the correct pool ID.
CIDR is stuck in Validating	The RPKI check hasn't returned Valid. Most common cause is a newly published ROA that hasn't propagated yet — wait and recheck with a public validator.
CIDR deletion fails	One or more addresses are still allocated. Query the CIDR's IP allocation details, unbind the workloads, release the EIPs, then retry the delete.
Partners report the prefix as Invalid after an ASN update	The new ROA either didn't propagate yet or doesn't match. Wait for propagation or fix the ROA; the Zenlayer side of the update succeeds only when the validation passes, so an Invalid read downstream means the ROA is out of sync with the origin.