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.

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

Setting Up a Peering

From the console, on a Border Gateway 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:

• A manual prefix list. You list specific CIDRs to advertise. Nothing else goes out. This is the safest default: you advertise exactly what you intend.

• All VPC 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.

• 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.

• Per-route selection. You choose route IDs to advertise when specific VPC routes need to be visible to the peer.

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.

Common Control Points

Keep advertisements explicit. Use advertised CIDRs, selected subnets, or selected route IDs 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.