BYOIP Customer CIDR

The customer CIDR is the central BYOIP resource. It represents one IPv4 prefix you have brought into Zenlayer, the line it's announced on, and the ASN that originates it. Every other BYOIP operation — allocation, announcement updates, deletion — refers back to this resource.

Customer CIDR → EIP Pool → Allocated EIPs

What You Provide

When you add a customer CIDR, you commit to three values:

Field	What it controls	Notes
CIDR	The IPv4 prefix you own	Must be routable on the public internet; /24 or shorter is the practical minimum
ISP	The line type used to advertise the prefix	The platform only accepts ISPs that support auto announcement
ASN	The origin ASN on the public route	Must be on the platform's supported list and be authorized by RPKI for this CIDR

The CIDR itself is the identifier. Operations that target a specific customer CIDR — query, update ASN, delete — use the prefix directly. There is no separate synthetic ID to keep track of.

Attributes Surfaced on the CIDR Detail Page

Once the CIDR is accepted, its detail view carries the following attributes:

Attribute	Description
CIDR	The IPv4 prefix you brought in
ISP	The advertising line type
Origin ASN	The ASN currently originating the prefix
Pool ID	The EIP pool that holds addresses from this CIDR
Customer-owned flag	Marks every address in the pool as customer-owned so it can be told apart from Zenlayer-assigned addresses
IP allocation details	For each address, whether it has been allocated and which workload it is bound to

Use the IP allocation details whenever you need to answer "which workload is using this address?" — it's the quickest path to pin an address down to a specific resource.

From Customer CIDR to EIP Pool

Acceptance of a customer CIDR creates — and is coupled to — exactly one EIP pool:

1. You submit the CIDR, ISP, and ASN.

2. The platform validates the request, runs the RPKI check, and begins announcing the prefix.

3. The prefix is registered with the EIP resource system, which exposes the block as a pool.

4. Allocation requests targeting that pool return addresses from the CIDR.

The pool is the only way to pull addresses out of the CIDR — there is no lower-level mechanism. Conversely, once the CIDR is deleted, the pool goes with it.

Lifecycle States

A customer CIDR moves through a small set of states driven by what you do in the console:

State	Meaning
Validating	Request was accepted and RPKI / ASN checks are running.
Active	Prefix is announced and the EIP pool is available for allocation.
Updating	An origin ASN change is in progress; existing allocations continue to work.
Deleting	Withdrawal is in progress; allocation is no longer allowed.
Error	Validation failed or the platform could not bring the prefix into service. The event log will tell you why (see Best Practices).

Relationship to Allocated EIPs

The customer CIDR cannot be cleanly removed while any of its addresses are still bound. Releasing the CIDR is therefore a reverse-order operation:

1. Unbind EIPs that were allocated from the pool.

2. Release those EIPs.

3. Delete the customer CIDR. This also withdraws the announcement and removes the pool.

The delete operation refuses to proceed if any address is still allocated — the check prevents a silent outage where a prefix is pulled out from under a live workload.

---

Frequently Asked Questions

Can I change the ISP line after creation? No. ISP selection is set at create time. If you need to move to a different line, the path is to delete and re-add under the new ISP.

Can multiple pools share one CIDR? No. Each accepted customer CIDR maps to exactly one EIP pool.

What happens to my allocations if I update the origin ASN? Nothing. Allocated EIPs keep working; the change only affects how the prefix is announced on the public route.