# Elastic IP: Standard vs Bypass

When you bind an Elastic IP (EIP) to a virtual NIC on a Zenlayer Elastic Compute (ZEC) instance, the platform offers two forwarding modes for that EIP:

* **Standard EIP** — the default mode, suitable for almost all workloads.
* **Bypass EIP** — an opt-in mode for latency- and throughput-sensitive workloads.

Both modes are served by the **same public-network forwarding plane**. Inbound and outbound traffic for either mode flows through the same gateway, is subject to the same bandwidth limits, and uses the same EIP address. The only thing that differs is **how each packet is processed inside the gateway** while it is on its way to or from your VM.

This document covers EIPs bound to a vNIC. To manage your EIPs, navigate to the [Elastic IPv4](https://console.zenlayer.com/zec/elastic-ip) page in the console.

***

## At a glance

![At a glance: both modes share the same forwarding plane](/files/YNGPrrgBgwBVDxvLQZCy)

Both VMs reach the Internet through the same forwarding plane. The difference is **whether the platform translates addresses for you** (Standard) or **delivers the public IP directly to the guest** (Bypass).

***

## What both modes have in common

* **Same forwarding plane.** Inbound and outbound traffic for the EIP is carried by the same shared public-network gateway.
* **Same EIP semantics.** One EIP maps to exactly one private IP on a vNIC. To expose multiple private IPs publicly, allocate one EIP per private IP.
* **Inbound preserves the original client source IP.** Your workload sees the real client address on incoming connections.
* **A vNIC can hold multiple EIPs**, each bound to a different (secondary) private IP on the same NIC.
* **Same bandwidth limits.** The per-EIP bandwidth quota you purchase applies identically in both modes.
* An EIP must be unbound before it can be released.

***

## Standard EIP

Standard mode is the default and the right choice for the vast majority of workloads.

### How it works

![Standard EIP: gateway translates EIP ↔ private IP](/files/H7tLzDs5x7ix2hmExD7Y)

* The gateway performs **address translation** between the EIP and the private IP. Your VM only ever sees its own **private IP**.
* The forwarding plane keeps **per-flow state** for each connection.

### Guest configuration

**No special configuration is needed inside the guest.** The VM only needs its private IP (typically obtained via DHCP). The EIP is invisible to the guest operating system.

### When to use Standard

* General-purpose public connectivity for a VM.
* Workloads with no unusual latency, throughput, or filtering needs.
* You want the platform's security group to apply to all traffic on the EIP, with no exceptions.
* You want the simplest possible setup — one private IP on one NIC, nothing else to configure inside the VM.

***

## Bypass EIP

Bypass mode tells the forwarding plane to take a **stateless fast path** and to **deliver the public IP directly to the VM** without translating addresses. The platform does not perform NAT for Bypass EIPs in either direction.

### How it works

![Bypass EIP: no translation in either direction](/files/LMVobANyCzLyIhSlT20G)

* Inbound packets are delivered **as-is** to the VM. The VM sees packets whose destination is the public EIP.
* Outbound packets must leave the VM with **source = EIP**. The gateway forwards them as-is to the Internet.
* The forwarding plane does not maintain per-flow state for the connection.

Because the platform is no longer doing the EIP↔private translation, the **guest operating system must be configured to own the EIP** as a local address on its NIC, in addition to its private IP.

### What this gets you

* **Lower per-packet processing cost** at the gateway.
* **Lower latency**, especially noticeable for short connections and for the first packets of new flows.
* **Higher sustained packet rate** for workloads that would otherwise be bounded by per-flow processing.
* **Optionally**, the platform security group can be skipped for the EIP at bind time. This option is **only available in Bypass mode** and shifts inbound filtering responsibility entirely to the guest.

### When to use Bypass

* **Latency-sensitive workloads**: real-time media, gaming servers, low-latency RPC endpoints, financial workloads.
* **High packet-rate workloads** that need maximum forwarding throughput.
* **Workloads that run their own firewall in the guest** and want to skip the platform security group on a specific EIP.

### Trade-offs to be aware of

* **The guest must be configured manually** to hold the EIP. With multiple EIPs and/or multiple private IPs on the same vNIC, this configuration grows non-trivial — see the example below.
* Connection-level features and visibility that depend on per-flow state at the gateway are not available for Bypass traffic.
* If you skip the platform security group, the platform no longer filters inbound traffic on that EIP. Make sure the guest has its own filtering in place before enabling this option.

***

## Side-by-side: how each mode behaves inside the forwarding plane

![Forwarding plane branch: shared lookup and metering, then per-mode processing](/files/fKHD7wCfbR18MQcfLZnk)

Both paths share the same gateway, the same metering, and the same bandwidth enforcement. The difference is the per-packet branch on the right side of the diagram.

***

## Configuring a Bypass EIP inside the guest (Ubuntu / netplan)

Because Bypass mode does no NAT, the guest OS must hold the public IP itself, alongside the private IP it gets from DHCP. The example below is for Ubuntu using netplan; the equivalent can be done with `ip addr` on any Linux distribution.

### Example 1 — single private IP, single Bypass EIP

Private IP: `10.0.0.10` (DHCP from the subnet `10.0.0.0/24`, gateway `10.0.0.1`). Bypass EIP: `203.0.113.10`.

```yaml
# /etc/netplan/01-bypass-eip.yaml
network:
  version: 2
  ethernets:
    ens3:
      dhcp4: true
      addresses:
        - 203.0.113.10/32
```

The DHCP lease provides the private IP and the default route. The Bypass EIP is added as an extra address with a `/32` mask so the kernel treats it as a host address only and does not try to route the public subnet over the private NIC.

### Example 2 — multiple private IPs and multiple Bypass EIPs

Private IPs: `10.0.0.10` (primary, DHCP) and `10.0.0.11` (secondary). Bypass EIPs: `203.0.113.10` (bound to `10.0.0.10`) and `203.0.113.11` (bound to `10.0.0.11`).

```yaml
# /etc/netplan/01-bypass-eip.yaml
network:
  version: 2
  ethernets:
    ens3:
      dhcp4: true
      addresses:
        - 10.0.0.11/24
        - 203.0.113.10/32
        - 203.0.113.11/32
```

This is enough for **inbound** traffic to either Bypass EIP to work correctly: the kernel replies on the same address the request was received on, so reply packets are sourced from the correct EIP automatically.

For **outbound** new connections that must be sourced from a specific Bypass EIP, applications should bind their sockets to the desired EIP. If you need the kernel to choose a specific EIP as the default source for traffic from a given private IP without per-application bind, you will need policy routing rules — for example, one routing table per (private IP, Bypass EIP) pair, selected by `ip rule add from <private IP> table <N>`. Setting that up is the operator's responsibility, not the platform's.

> The complexity of in-guest configuration grows with the number of public/private IP combinations. If a workload is genuinely simple (one private IP, one public IP), Bypass is straightforward; if a workload juggles many of each, factor the in-guest config burden into the decision.

***

## Multiple EIPs on one vNIC

You can bind multiple EIPs to the same vNIC by associating each EIP to a different secondary private IP on that NIC. This is supported in both modes.

![Multiple EIPs on a single vNIC, each bound 1:1 to a private IP](/files/iXwVbUIlWI384d1F8ApC)

Each EIP is bound 1:1 to a single private IP. To expose three private IPs publicly, allocate three EIPs.

**Important — do not mix modes on the same vNIC.** All EIPs bound to a single vNIC should use the **same** mode. If you need both Standard and Bypass EIPs on the same VM, attach them to different vNICs.

![All EIPs on one vNIC must share the same mode](/files/S2vJfjQQ8AHNBhgfWXGI)

If a single VM needs both Standard and Bypass EIPs, give it a second vNIC and put the Bypass EIPs there.

***

## IPv6

Public IPv6 addresses on this platform are **not ULA and not NAT'd**. Each VM is given a routable, public-Internet IPv6 address that is delivered directly to the guest, exactly the same way a Bypass EIP is delivered for IPv4.

![Public IPv6: routable address delivered directly to the VM, no NAT](/files/0nfw2k3u0TKzwjAaov6z)

What this means in practice:

* **There is no IPv6 NAT.** The gateway forwards IPv6 packets between the VM and the Internet without rewriting source or destination addresses.
* **The IPv6 address you see inside the guest is the address the Internet sees.** External services see exactly that address as the source of outbound IPv6 traffic.
* **Inbound IPv6 packets reach the guest with the public IPv6 as the destination.** The guest configures its IPv6 address normally (via SLAAC/DHCPv6 or static configuration); no extra alias is required because there is no second "private" IPv6 to translate to.
* **No "Standard vs Bypass" choice for IPv6.** The Standard / Bypass distinction is an IPv4-only concept, because it exists to describe whether the platform performs IPv4 NAT between an EIP and a private IP. IPv6 is always direct.

If you are already comfortable running a VM on Bypass IPv4, the IPv6 mental model is identical: the platform routes the public address to your guest and the guest owns it.

***

## Choosing a mode (IPv4 EIP)

| Question                                    | Standard | Bypass                             |
| ------------------------------------------- | -------- | ---------------------------------- |
| Default?                                    | Yes      | No — must be requested             |
| Same forwarding plane and bandwidth limits? | Yes      | Yes                                |
| Inbound preserves client source IP?         | Yes      | Yes                                |
| Multiple EIPs per vNIC?                     | Yes      | Yes                                |
| Per-packet processing cost                  | Baseline | Lower                              |
| Latency / packet rate                       | Baseline | Better                             |
| Per-flow state at the gateway               | Yes      | No                                 |
| Platform performs NAT for the EIP           | Yes      | No                                 |
| Guest must hold the EIP itself              | No       | Yes                                |
| Option to skip the platform security group  | No       | Yes                                |
| Recommended default                         | Yes      | Choose only with a specific reason |

**Quick rules of thumb**

* Default to **Standard** unless you have a measured reason to switch.
* Choose **Bypass** when you need (a) the lowest possible latency or highest possible packet rate on a vNIC EIP, or (b) the ability to skip the platform security group, **and** you are willing to configure the EIP inside the guest.

***

## Limits and caveats summary

* **One EIP, one private IP.** No EIP can be bound to multiple private IPs at the same time.
* **Unbind before release.** EIPs cannot be deleted while still associated.
* **Same-mode-per-NIC.** All EIPs on a single vNIC must share the same mode.
* **Bypass requires in-guest configuration.** The guest OS must hold the EIP as a local address; the complexity grows with the number of public/private IPs on the NIC.
* **Bypass forwarding is stateless** at the gateway: features that depend on per-flow state at the gateway are not available for Bypass EIPs.
* **Skipping the platform security group is only available for Bypass EIPs**, and shifts inbound filtering responsibility entirely to the guest.
* **Public IPv6 is not NAT'd.** The IPv6 address inside the guest is the same address the Internet sees; the Standard/Bypass distinction does not apply to IPv6.
* **Both IPv4 modes preserve the inbound client source IP.**


---

# 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/standard-vs-bypass-eip.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.