> 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/04-dynamic-routing.md).

# Border Gateway Dynamic Routing

Dynamic routing on Border Gateway is BGP. You set up a peering between the gateway and a neighbor router — another Border Gateway in a different VPC, or a routing endpoint in another cloud — and the two sides exchange prefixes. Routes you advertise go out; routes the peer advertises arrive in your VPC route table as **Dynamic Routes** and can be forwarded automatically.

The value is that both sides adapt to change. The peer adds a new subnet, advertises it, and the prefix appears in your VPC route table without you touching cloud configuration. A session drops, and the prefixes it carried are withdrawn automatically.

## What You Control on the Cloud Side

When you configure BGP on a Border Gateway, you're deciding three things:

* **Who you peer with** — the interconnect link, VLAN, peer ASN, and optional password.
* **What you advertise outward** — which of your VPC's subnets, routes, or CIDRs the peer learns.
* **What routing mode the learned prefixes take** — regional versus global propagation. See [Routing Modes](/welcome/elastic-compute/networking/01-overview-2/05-routing-modes.md).

The mechanics of the BGP session itself are handled by the platform.

## Setting Up a Peering

From the console, on a [Border Gateway](https://console.zenlayer.com/zec/borderGateway) that's already attached to a VPC, you add a BGP neighbor. You specify:

* **The VLAN ID** for the interconnect.
* **The peer's AS number.**
* **An optional BGP password.**
* **The link type and bandwidth.**

Once the session is up, the gateway is ready to exchange prefixes.

## Controlling What You Advertise

You don't automatically advertise everything. On each Border Gateway you choose one of these patterns:

* **Advertise all visible subnets.** Every subnet in the attached VPC is advertised. New subnets added later are advertised automatically. Good for simple setups; risky when you don't want every subnet exposed.
* **Advertise custom route.** You choose specific route IDs to advertise when only certain VPC routes need to be visible to the peer.
* **Advertise custom CIDR IP range.** You list specific CIDRs to advertise. Nothing else goes out. This is the safest default: you advertise exactly what you intend.
* **Per-subnet selection.** You toggle advertisement on or off for each subnet. Use when "all" is too broad but the list of allowed subnets changes often enough that maintaining a CIDR list is painful.

Pick the most restrictive pattern that meets the need. Advertising a prefix you didn't mean to — especially one that overlaps with the peer's own space — can create routing loops or cause the peer to drop traffic.

## What You Learn Back

Routes the peer announces arrive in the VPC route table as **Dynamic Routes**. They look like any other route entry from a forwarding point of view: destination prefix, next hop (the Border Gateway), priority.

Behavior worth knowing:

* **Withdrawals are automatic.** If the peer stops advertising a prefix, it's removed from the route table. If the BGP session drops entirely, all prefixes learned from that session are withdrawn.
* **Longest-prefix match still applies.** A learned `/24` overrides a less specific route for traffic matching the `/24`.
* **Propagation to other regions depends on mode.** In regional mode, the learned prefix stays in the local region's route table. In global mode, it's propagated to every region the VPC reaches, over Zenlayer's private backbone. See [Routing Modes](/welcome/elastic-compute/networking/01-overview-2/05-routing-modes.md).

## Common Control Points

**Keep advertisements explicit.** Use advertised CIDRs, selected routes, or per-subnet selection to control what the peer learns from you.

**Choose regional or global propagation.** Regional mode keeps learned prefixes in the local region. Global mode sends learned prefixes over the private backbone so other reachable regions can use them.

**Avoid overlapping peer routes.** If two peers advertise the same prefix, route selection becomes operationally harder to reason about. Prefer non-overlapping advertisements, or keep the overlap intentional and documented.

## What Dynamic Routing Doesn't Solve

* **Address overlap.** BGP will happily advertise `10.0.0.0/16` from both sides of a peering if both sides configured it. Routing won't do what you want; plan your address space first.
* **Transport failure.** BGP assumes the underlying transport works. If the private link is flapping, BGP sessions will flap with it and route tables will churn. Fix the transport first, then trust BGP.

## Things to Check Before Going Live

1. **Your ASN and theirs are different.** A matched ASN on both ends requires additional configuration and isn't normally what you want.
2. **Prefix lists are explicit.** Don't lean on "all subnets" advertising for a production peering unless you've audited the subnet list.
3. **The VPC route table looks right in a dry-run test.** Bring the session up, check the learned routes, and verify traffic flows before routing production workloads over the peering.
4. **Your peer knows what to expect.** Agree on advertised prefixes and ASNs before scheduling a cutover. BGP troubleshooting is much faster when both sides know what "correct" looks like.