Border Gateway Protocol

Border Gateway Protocol (BGP) is a path-vector routing protocol used to exchange information about reachable IP networks. Routers establish BGP sessions with configured peers and advertise address ranges called prefixes. Advertisements include attributes such as the autonomous system path, which helps prevent routing loops and influences route selection. An autonomous system number (ASN) identifies a routing domain; private ASNs are commonly used in hybrid cloud networks.

BGP separates route discovery from packet forwarding. A router learns candidate routes through BGP, applies routing policies, and installs eligible routes into its routing table. Packets then follow the forwarding table rather than interacting with BGP directly. External BGP exchanges routes between autonomous systems, while internal BGP distributes BGP routing information within an autonomous system.

In a hybrid deployment, an organization might advertise its on-premises prefix, 172.20.0.0/16, to a cloud network and receive the cloud prefix, 10.40.0.0/16, in return. This removes the need to maintain a separate static route for every changing network. AWS Direct Connect uses BGP on virtual interfaces, while dynamically routed AWS Site-to-Site VPN connections exchange BGP routes through IPsec tunnels. Other cloud providers use the same protocol for comparable connectivity services, although their routing policies and limits differ.

Troubleshooting should distinguish transport failure, BGP session failure, route exchange failure, and data-plane failure. For a private circuit, verify the connection, VLAN configuration, peer addressing, and reachability first. For a VPN, verify that the IPsec tunnel is established before investigating its BGP session. BGP uses TCP port 179, so inspect relevant router access controls and firewalls. Incorrect peer IP addresses, mismatched configured ASNs, or authentication settings can prevent a session from reaching the Established state.

An established session does not prove that the required routes are being exchanged or used. Check advertised and received prefixes, import and export filters, maximum-prefix limits, next-hop reachability, and route selection. Then inspect the cloud routing configuration. For example, a VPN may have a healthy BGP session while the required route is absent from a VPC route table because propagation is disabled. With a transit gateway, verify attachment associations and propagation into the intended transit gateway route table.

Route selection is policy-driven, not a measurement of current latency or available bandwidth. Attributes such as local preference and AS path can influence selection, but managed cloud services expose only selected controls and apply service-specific priorities. Packet forwarding generally uses the longest matching installed prefix. Consequently, an unintended more-specific route can divert traffic even when another route appears to have preferable BGP attributes.

Redundant BGP sessions can improve availability by withdrawing unavailable paths and allowing alternatives to become active. However, failover is not instantaneous: failure detection, routing convergence, and application recovery all take time. Test backup paths explicitly, including whether the same destination prefixes are reachable through them. Do not assume that a VPN automatically backs up a private circuit merely because both connections exist.

Finally, verify the complete bidirectional packet path. Correct BGP routes do not override security groups, network ACLs, host firewalls, or missing return routes. Asymmetric routing can break stateful inspection, and MTU problems can allow small probes while larger application requests fail. BGP neither encrypts application traffic nor guarantees authorization to advertise a prefix. Use appropriate transport protection, peer authentication where supported, and explicit prefix filtering to reduce unintended route advertisements.