# 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](/files/CuvcJlR4mIUpXcejQv7U) ## 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](/welcome/elastic-compute/networking/01-overview-4/06-best-practices.md#troubleshooting)). | ## 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. --- # 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/02-customer-cidr.md?ask= ``` 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.