Quartz 5

bgp

Properties2
tagsnetworking, bgp, routing, expressroute
aliasesBGP, dynamic routing, eBGP

3 min read

Border Gateway Protocol (BGP)

What it is

Border Gateway Protocol (BGP) is the standard exterior routing protocol that exchanges routing information between autonomous systems (ASes). In Azure it’s how your on-premises edge and ExpressRoute/VPN infrastructural peers advertise routes to (and receive routes from) Azure networks.

Why it exists

Static routes need manual changes when a network changes. BGP lets connected networks announce the address prefixes they can reach and withdraw them when they cannot. This makes hybrid routing adaptable, but a correct route policy and a resilient physical design are still necessary for useful failover.

Key ideas

  • Peers exchange reachability information. Azure learns on-premises prefixes, while the on-premises edge learns Azure prefixes. For ExpressRoute, BGP sessions run between the network edge and Microsoft enterprise edge routers; VPN Gateway can also use BGP.
  • An autonomous system number (ASN) identifies the routing domain in BGP. Azure and the peer use configured ASNs; supported values and default behavior depend on the service and configuration, so do not memorize one private range as a universal Azure requirement.
  • BGP is central to ExpressRoute and optional for some VPN Gateway designs. It is not required for simple VNet peering.
  • Route selection is not one simple universal order. Prefix specificity, service route sources, user-defined routes, and gateway propagation interact. Inspect effective routes for the affected subnet and use the current Azure route-selection guidance for the exact scenario.

Key facts

  • Advertising a default route (0.0.0.0/0) on ExpressRoute private peering can route associated VNet traffic to the on-premises network. The corporate edge then needs a design for internet-bound and Azure platform traffic; test carefully before calling this forced tunneling safe.
  • BGP can withdraw or change routes after a path event, but successful failover also depends on redundant gateways, circuits, devices, routes, and application dependencies.
  • Treat ASN values, prefix limits, and path attributes as configuration details to verify against the service documentation, not as a memorized magic number.

Northwind example

Northwind’s warehouse advertises 10.40.0.0/16 to Azure through its ExpressRoute BGP peer. Azure advertises the order VNet prefix back. When Northwind adds a second warehouse subnet, BGP can announce the new prefix without editing every VM route table. Before advertising a default route, Maya checks effective routes and confirms that required Azure services and internet egress still have a supported path. A BGP session alone does not prove a warehouse application can fail over.

How it fits

[on-premises routing domain]                  [Azure/provider routing domain]
        │  BGP session (eBGP over IPsec/ER)          │
        │  advertise corp prefixes <────>            │
        │  receive VNet prefixes                     │
        ▼                                             ▼
   on-prem network                               VNet routes

bgp - Microsoft diagram Diagram courtesy of Microsoft Learn / Azure docs: expressroute/expressroute-optimize-routing

Exam notes

  • BGP is most relevant to hybrid connectivity such as ExpressRoute and dynamic VPN routing.
  • It exchanges networks that are reachable; it does not replace network security or application identity.
  • Use effective routes and current route-selection guidance rather than applying an oversimplified precedence rule to every scenario.

Home · expressroute · vpn-gateway · route-table · virtual-wan

📘 Source: Microsoft Learn — Bgp

Graph View

Backlinks