# 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 Gateway One Border Gateway has one mode at a time. In the current VPC model, a VPC has a single Border Gateway, so choose the mode that matches the scope you want for learned routes. If one region needs local-only routing and another region needs global routing, model that as separate VPCs or separate regional deployments instead of trying to attach multiple Border Gateways to the same VPC. ## 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. --- # 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-2/05-routing-modes.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.