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


---

# 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/05-onboarding-lifecycle.md?ask=<question>
```

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.