> For the complete documentation index, see [llms.txt](https://docs.console.zenlayer.com/welcome/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.console.zenlayer.com/welcome/elastic-compute/networking/01-overview-4/05-onboarding-lifecycle.md).

# BYOIP Onboarding Lifecycle

Onboarding a customer CIDR is a five-step flow. Each step has a clear completion signal, so you can stop and resume without re-running the earlier work.

![End-to-end onboarding flow](/files/f0kI1aa1KOcoMMbXnTlX)

| # | Step                     | Signal you're done                                                                             |
| - | ------------------------ | ---------------------------------------------------------------------------------------------- |
| 1 | Prepare                  | You own the prefix, you've picked an ISP and a supported ASN, and a matching ROA is propagated |
| 2 | Check supported ASNs     | The ASN you want appears in the console's supported-ASN list                                   |
| 3 | Create the customer CIDR | CIDR shows `Active` and a pool ID is displayed                                                 |
| 4 | Allocate EIPs            | EIPs appear in your account flagged as customer-owned                                          |
| 5 | Bind EIPs                | Workloads are reachable on your addresses                                                      |

## 1. Prepare

Before you touch the console:

* **Confirm ownership.** You must be the RIR-registered holder of the prefix.
* **Pick the ISP line.** This governs how the prefix is advertised.
* **Pick a supported origin ASN.** If you don't already know yours is supported, the next step verifies it.
* **Publish a ROA** authorizing the `(prefix, ASN)` pair. Raise `maxLength` to cover the longest prefix you intend to announce.
* **Wait for propagation.** ROA updates take minutes to a few hours depending on your RIR. Check with a public RPKI validator before moving on.

## 2. Check Supported ASNs

Open the supported-ASN list in the console and confirm your chosen origin ASN is there. If it isn't, you'll need to pick another ASN from the list, or arrange with Zenlayer via [support](mailto:support@zenlayer.com) to have yours added before you retry.

## 3. Create the Customer CIDR

Submit CIDR, ISP, and origin ASN in the console. Under the hood, Zenlayer:

1. Validates the form fields.
2. Runs the RPKI check against `(CIDR, ASN)`.
3. Registers the prefix with the announcement system.
4. Exposes the block as an EIP pool.
5. Surfaces the pool ID on the CIDR detail page.

The CIDR reaches `Active` once all five finish. If the RPKI check fails, the CIDR doesn't advance past `Validating` — fix the ROA and retry.

## 4. Allocate EIPs

Allocate addresses from the pool. Use the normal EIP allocation flow and set the target pool to the one shown on the CIDR detail page. Each allocation returns a regular EIP carrying the customer-owned flag.

## 5. Bind EIPs

Bind the allocated EIPs to whatever consumes an EIP: instance NICs, NAT Gateway SNAT / DNAT entries, load balancer front-ends. No BYOIP-specific steps here — once the EIPs exist, they flow through the same bind path as any other EIP.

***

## Retiring a Customer CIDR

Retirement is the onboarding flow in reverse, and the order is enforced by the platform:

1. **Move workloads off.** Drain or repoint any service still using a customer-pool EIP.
2. **Unbind and release the EIPs.** The customer CIDR cannot be deleted while any of its addresses are allocated.
3. **Delete the customer CIDR.** This withdraws the announcement and removes the pool.
4. **Update the ROA.** If you don't want Zenlayer to be able to originate the prefix in the future, remove the authorization at your RIR.

Leaving orphaned ROAs isn't harmful, but cleaning them up removes the authorization — useful if you're rotating the prefix to another network.