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