# Border Gateway Best Practices ## Plan your address space before peering The single most common Border Gateway problem isn't a BGP session that won't come up — it's a session that comes up perfectly while carrying overlapping prefixes. If your VPC and the peer both use `10.10.0.0/16`, BGP will advertise both sides and traffic will end up in the wrong place. Before you configure a peering, map the address space on both ends and confirm there is no overlap. Renumbering later is painful. ## Start with an explicit prefix list, not "advertise all subnets" "All subnets" is convenient and dangerous. A subnet you add for an unrelated internal service becomes visible to your BGP peer the moment it exists. Start with a manual advertised prefix list covering exactly the subnets the peer needs to reach. Revisit the list when you actually want to expose new subnets — that review is the feature, not overhead. ## Prefer regional mode unless you have a reason for global [Regional mode](/welcome/elastic-compute/networking/01-overview-2/05-routing-modes.md) keeps the blast radius of a misconfiguration inside one region. Global mode propagates learned routes — and mistakes — to every region the VPC reaches. Use regional until you have a clear reason to flip to global (single peering that must serve every region, centralized on-prem connectivity, etc.). Going regional → global later is a single toggle; going the other way is much more work. ## Use distinct ASNs on each side Using the same ASN on both sides of a BGP session requires extra configuration (allowas-in or similar) and makes it easier to create loops when you add a third party. Even when the platform allows it, pick different ASNs — one of them can still be a private-range ASN. The default is quieter. ## Check the VPC route table after any session change When a BGP session comes up, drops, or has its advertised prefix set changed, the VPC route table updates. Always verify the table looks the way you expect before routing production traffic over the session. Navigate to [**VPC → Route Tables**](https://console.zenlayer.com/zec/route), select the table, and look for Dynamic Routes from the gateway. ## Size your advertised set carefully on global-mode gateways Every prefix learned by a global-mode gateway propagates to every region's route table. Large numbers of prefixes learned from a hub-style peering multiply the state carried on the backbone and in every VPC route table. Keep the peer's advertised set as small as practical, and avoid using global mode for broad route tables that only one region needs. ## Treat BGP as a reachability signal, not an access-control signal BGP tells your VPC *where to send traffic for a prefix*. It does not tell the target instance *whether to accept it*. Border Gateway itself does not have security groups — access control has to live on the workload side: OS-level firewalls, application-level auth, or an in-path appliance. Don't assume the presence of a Dynamic Route implies authorized access. ## Schedule mode and policy changes for quiet windows A [routing-mode change](/welcome/elastic-compute/networking/01-overview-2/05-routing-modes.md) or a significant shift in advertised prefixes triggers a reconvergence. Route tables are rebuilt in every region affected, and existing connections may see a brief loss during the churn. Outside of emergencies, make these changes when traffic is low. ## Document your BGP configuration with your peer BGP troubleshooting is much faster when both sides have a written agreement on ASNs, advertised prefixes, VLANs, passwords, and expected route scope. When something breaks, the documented expectation is what you compare against. *** ## Troubleshooting **BGP session won't come up.** Check the basics first: can the two sides reach each other on the peering IP at all (ping or tcpdump on port 179)? Confirm the peer's ASN matches what you configured. If the transport is a private line or interconnect, confirm it is up and not flapping. Most "BGP won't come up" issues are actually transport issues. **Session comes up but no prefixes are learned.** Confirm the peer is actually advertising prefixes by checking the peer's routing output. Also confirm the Border Gateway is in the routing mode you expect. **Prefixes are learned but traffic isn't flowing.** Check the VPC route table — the Dynamic Routes should be installed with the Border Gateway as next hop. If they are, look at what happens to the packet once it lands on the workload instance: OS firewalls, application-layer rules, or a more specific policy route that's capturing the traffic before it reaches the learned route. **Traffic works in one direction but not the other.** Asymmetric advertising. Your side advertises what the peer needs, but the peer isn't advertising what your side needs (or vice versa). Verify the advertised prefix list on both ends. **Route flapping.** Usually caused by transport instability — BGP follows the session liveness. Stabilize the underlying connection and the flapping usually stops. If the transport is solid and the session still flaps, check the peer ASN, password, and link settings on both sides. **Global-mode routes not visible in another region.** Confirm the gateway's mode is actually global (not regional) and that the VPC has a subnet in the region you're checking. Global mode propagates to regions the VPC has subnets in — if the VPC doesn't exist in a region, there's no route table for it there. **Deleting a Border Gateway is rejected.** Resources still reference it — BGP neighbors, advertised route sets, or policy routes that name it as next hop. Remove those references, then retry the delete. --- # 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/06-best-practices.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.