> For the complete documentation index, see [llms.txt](https://docs.console.zenlayer.com/welcome/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.console.zenlayer.com/welcome/elastic-compute/networking/01-overview-2/05-routing-modes.md).

# Border Gateway Routing Modes

A Border Gateway operates in one of two routing modes: **regional** or **global**. The mode controls how far the routes it handles travel.

The distinction matters because a Border Gateway lives in one region. Its BGP peers talk to it in that region. The question the mode answers is: once the gateway learns a prefix from a peer, is that prefix available to VPC workloads *only in the local region*, or *in every region the VPC has subnets in*?

**The default mode when creating a Border Gateway is regional.** You must explicitly switch to global mode if you want learned routes propagated to every region in the VPC.

![Regional vs Global Routing Modes](/files/QyzETveG1xo1zi37YQVj)

## Regional Mode

Learned routes and advertisements stay within the gateway's own region. The VPC route table in that region reflects them. Route tables in other regions do not.

Use regional mode when:

* **The peer only cares about one region's traffic.** A datacenter that only talks to workloads in one region has no reason to appear in other regions' route tables.
* **You want peerings in every region independently.** Each region has its own gateway and its own peer. You prefer parallel, regional scopes to a centralized one.
* **You're keeping blast radius small.** A route mis-advertised in one region doesn't propagate to others.

The traffic path for an instance in that region reaching a learned prefix: instance → VPC routing → Border Gateway → BGP peer. No cross-region hop.

An instance in a *different* region cannot reach a regionally learned prefix through this gateway. If it needs to, either deploy a second Border Gateway with its own session in that region, or switch this gateway to global mode.

## Global Mode

Learned routes are propagated from the gateway's region to every other region the VPC has subnets in, over Zenlayer's private backbone. The prefix appears in every region's VPC route table. Traffic from instances in other regions transits the backbone to the gateway's region, then exits to the BGP peer.

Use global mode when:

* **One external peering serves workloads in every region.** You don't want to maintain a separate BGP session per region; you peer once, globally.
* **The peer is your "single source of truth" for external prefixes.** Corporate datacenter, carrier upstream, central on-prem network — whatever needs to be reachable from everywhere should be learned into a global-mode gateway.
* **Regional mode would require too many redundant sessions.** Ten regions × one peer = ten BGP sessions to maintain in regional mode, one in global.

The trade-off is transit cost and latency. Traffic from a faraway region takes the long path over the backbone to reach the peer. If the peer is in the same physical location as the gateway's region, that's efficient. If the peer serves a workload whose latency matters, a per-region gateway may still be better.

## Choosing

| Your situation                                               | Mode     |
| ------------------------------------------------------------ | -------- |
| Datacenter connects to one region only                       | Regional |
| On-premises network should be reachable from every region    | Global   |
| You have a gateway per region already                        | Regional |
| You want to centralize external peering in one region        | Global   |
| Compliance requires routes stay within a region              | Regional |
| A single internet-adjacent peer serves the whole environment | Global   |

When unsure, start regional. It's strictly smaller blast radius and you can switch to global later if the need arises. Switching the other way — global to regional — requires you to re-establish sessions in the regions you now want to own.

## One Mode Per Border Gateway

A Border Gateway has one mode at a time. But a VPC is global — it spans every region you have subnets in — and **each region can have its own Border Gateway** (one per region). So a single VPC can hold multiple Border Gateways, each with its own mode.

That means mixed scopes within one VPC are fully supported. If one region needs local-only routing and another needs global routing, set the Border Gateway in the first region to **regional** and the one in the second region to **global** — both in the same VPC. You don't split into separate VPCs to mix modes.

What you can't do is run one Border Gateway in two modes at once, or attach a second Border Gateway to a region that already has one. Mode is a per-gateway choice, and a region holds at most one gateway.

## What Doesn't Change With Mode

* **The BGP session itself.** Configuration on the peer side is identical regardless of mode — the peer doesn't know or care.
* **Advertisement outward.** The set of prefixes the gateway advertises to its BGP peer is independent of mode. Mode affects where *learned* prefixes show up on your side; it doesn't affect what the peer sees from you.

## Common Mistakes

**Assuming regional mode will reach other regions "over the backbone."** It won't. Regional means regional. Other regions' VPC route tables don't hold the learned prefixes.

**Setting global mode on a gateway whose peer is latency-sensitive from one region but not others.** The distant regions all pay the backbone-transit cost whether they benefit from it or not. If only one region actually needs the peering, regional mode serves that region directly without affecting others.

**Changing mode on a live gateway during production hours.** Mode change takes effect quickly but does cause a reconvergence — route tables are rebuilt across the affected scope. Schedule the change for a quiet period.