# EIP Line Split ## What it is In some parts of the world — Southeast Asia (Ho Chi Minh City, Jakarta), parts of Latin America, the Middle East, and anywhere the local peering economics pull the two apart — **international transit is much more expensive than in-country transit**. Paying the international rate for traffic that never leaves the country would waste money. The EIP Line Split feature lets one EIP serve both kinds of traffic on **one public address**, with the Mbps allowance divided between the two lines by a percentage you choose. A single EIP appears to the outside world as one IPv4 (or IPv6) address. What changes inside the platform is how the EIP's capacity is carved up: * A **domestic line** — used when the destination is inside the same country as the POP. * An **international line** — used for every other destination. You pick how much of the EIP's bandwidth goes to each line. Traffic is classified onto a line automatically by destination; you do not set per-destination rules. ![EIP line split — Hyperplane classifying domestic vs. international](/files/7HdqVDso39ce5fXphSxD) *** ## Why this is per-POP Not every region needs this feature. In locations where in-country and international transit cost the same, there is nothing to split — one cap over one line is fine. The feature is designed for POPs where the price delta between domestic and international is large enough that mixing them in one meter forces you to either: * Overpay (size the whole EIP as international bandwidth), or * Under-size (pick a small international allowance and hope domestic demand never spikes the bill). Line Split gives you the knob to match bandwidth purchase to traffic mix. **Examples of POPs where this applies today:** * **Ho Chi Minh City (Vietnam).** Domestic-to-Vietnam traffic is substantially cheaper than international. * **Jakarta (Indonesia).** Same pattern. Other POPs around the world — in Southeast Asia, Latin America, the Middle East, and wherever local peering is significantly cheaper than international transit — follow the same model. The console exposes the feature only on POPs where it is available. *** ## How the split is expressed You configure two numbers for an EIP that supports line split: * **Total bandwidth (Mbps)** — the same number you would pick for a non-split EIP. * **Split by percentage** — for example, 80 % domestic, 20 % international. The platform derives the per-line cap from that percentage. In the 80/20 example on a 100 Mbps EIP: * Domestic line: up to 80 Mbps. * International line: up to 20 Mbps. Each line has its own shaper. Hitting the domestic cap does not take away headroom from international, and vice versa — they do not borrow from each other. Domestic traffic shaped down to the domestic cap will drop even if the international line is idle. The split is expressed as a percentage rather than two absolute Mbps values so that resizing the EIP preserves the ratio. If you raise the 100 Mbps EIP to 200 Mbps, the 80/20 split becomes 160 / 40 automatically. *** ## How traffic is classified onto each line Classification happens in the data plane. The destination address of each packet is matched against the POP's **domestic prefix set** (the address ranges announced as in-country for that POP). Matches go on the domestic line; everything else goes on the international line. Three consequences to keep in mind: * **Classification is per-packet, not per-flow.** A single conversation that touches both domestic and international endpoints is split correctly. * **The domestic prefix set is maintained by the platform,** not by you. It reflects what the local peering actually covers, so what counts as "domestic" is whatever the POP's in-country upstreams will accept without hitting the international transit. * **There is no fallback between lines.** If domestic is full and international is idle, domestic traffic is still shaped — the cost model only works if each line stays within its own allowance. *** ## Observability — which line got shaped What is live today, and what is still in progress, is worth calling out clearly: * **Total drop counters (live).** The per-EIP `dropped` counters from [Bandwidth Cap](/welcome/elastic-compute/networking/01-overview/07-bandwidth-cap.md) — `ingress/egress_dropped_packets` and `ingress/egress_dropped_bytes` — are available today. They tell you *that* the EIP hit a cap and how much was trimmed, but they do **not** break down by line. * **Per-line drop counters (coming soon).** Breaking the same `dropped` counters down by line (domestic vs. international) so you can tell *which* line saturated is on the roadmap. Until it ships, a climbing `dropped` value on a line-split EIP tells you the EIP as a whole is being shaped, not which of the two lines caused it. * **Per-line bandwidth limit / shaping (coming soon).** Shaping each line independently at its own Mbps cap is also on the roadmap. **Today only per-line traffic (bytes) is accounted separately** — that is what makes the different price-per-GB on Data Transfer possible. Mbps-level shaping still runs against the EIP as a whole, not per line. In other words, the current production state is: **one shaper on the EIP, two byte counters** (one per line) for billing. Per-line shapers and per-line drop counters are the next iteration. Once per-line drop counters ship, the typical diagnosis workflow will be: 1. Total EIP traffic looks capped — `dropped` is climbing. 2. Query the counter broken down by line. 3. If only the international line is dropping, the split allocation to international is too small for your traffic mix. Raise the international percentage or the total bandwidth. 4. If both lines are dropping, the EIP itself is undersized. *** ## Relationship to billing methods Line Split is a **capacity** knob, not a billing method. It does not replace any of the methods in this guide; it sits alongside them: * On **Flat Rate** it slices the bandwidth cap between two lines. * On **Data Transfer** it still bills by bytes, but the price-per-GB differs by line: domestic GB are priced against the cheaper domestic rate, international GB against the international rate. The split percentage only caps the throughput per line; actual cost tracks the bytes that travelled on each. * On **Aggregated Burstable 95th**, each line contributes to its own 95th, with its own commitment and its own overage rate. In every case, the two lines are metered separately so the bill reflects real usage on each side. *** ## Current status What ships today on POPs that support line split: * **Per-packet route classification on Hyperplane.** Traffic is classified into domestic vs. international by destination, against the platform-maintained domestic prefix set. * **Per-line traffic accounting (bytes).** The two lines are metered separately so Data Transfer can bill domestic GB at the domestic rate and international GB at the international rate. What is still in progress: * **Per-line bandwidth limit (Mbps shaping).** Today shaping is applied at the EIP level; each line does not yet have its own independent Mbps cap. * **Per-line drop counters.** The `dropped` counters exist at the EIP level but are not yet broken down by line. * **Console / API knob to set the split percentage** on every POP — exposed on the EIP creation form only where the feature is fully in production. On POPs where line split is not yet enabled, EIPs behave as a single un-split line. --- # 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/09-eip-line-split.md?ask= ``` 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.