BYOIP EIP Allocation
Once a customer CIDR is Active, its EIP pool is open for allocation. Pulling addresses out of that pool is the same operation as pulling addresses out of a default Zenlayer pool — you just point the allocation at the customer pool instead.
How Allocation Works
The allocation flow takes the usual EIP parameters, plus the pool you want the address to come from:
Look up the pool ID on the customer CIDR's detail page.
Submit an EIP allocation with that pool ID set as the target pool.
The platform reserves an address from the pool and returns a regular EIP object.
Everything past that point — binding to an instance, adding to a NAT Gateway SNAT entry, bandwidth configuration, releasing — uses the same flows as any other EIP. There is no BYOIP-specific bind, SNAT, or release path.
The Customer-Owned Flag
Every EIP carries a flag indicating whether its address came from a Zenlayer-assigned pool or from one of your customer CIDRs. This is the single lever that separates your addresses from the default supply.
The flag is useful in three places:
Allocation targeting — verify that an allocation actually came from the customer pool and not from the default pool because the pool ID was missed.
Inventory audits — answer "which of my live EIPs are on addresses I own?" without reasoning about prefix membership by hand.
Incident response — when a downstream system complains about a specific source IP, the flag tells you immediately whether the fix lives in the customer CIDR or somewhere else.
Using BYOIP EIPs with Other Services
Because customer-pool EIPs are ordinary EIPs on the runtime side, they plug into downstream services without additional configuration:
Instance
Bind directly to a network interface. The instance advertises your address for both inbound and outbound traffic.
NAT Gateway (SNAT)
Reference the EIP in a SNAT entry. Outbound traffic from the covered subnets then exits on your address.
NAT Gateway (DNAT)
Reference the EIP in a DNAT entry. Inbound port-forwards land on your address.
Load Balancer
Use as the front-end EIP. Clients see your address as the service's public IP.
In every case, the downstream service doesn't need to know the EIP came from a BYOIP pool — it only sees an EIP.
Releasing Allocations
Releasing a customer-pool EIP works the same way as releasing any other EIP — but the address returns to your pool, not to the Zenlayer-assigned pool. That means:
Released addresses can be re-allocated from the customer pool on later requests.
Releasing does not remove the customer CIDR. To retire the CIDR itself, every allocated EIP must be released first. See Customer CIDR — Relationship to Allocated EIPs.
Frequently Asked Questions
Can I pick a specific address from the pool? The pool determines the prefix; specific IP selection follows whatever the EIP allocation flow supports for your account.
Can I allocate more addresses than the CIDR contains? No. Once the pool is exhausted, new allocations targeting that pool are rejected until an address is released or additional CIDRs are added.
What if I forget the pool ID and allocate from the default pool? The allocation succeeds but lands on a Zenlayer-assigned address. You can tell by the customer-owned flag on the EIP. Release it and re-allocate with the correct pool ID if you need an address from your CIDR.
Last updated