# 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](mailto:support@zenlayer.com) 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. |


---

# 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/06-best-practices.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.