2.4 BGP & Custom Route Propagation

BGP & Custom Route Propagation

Dynamic routing in hybrid enterprise architectures relies on Border Gateway Protocol (BGP) to automatically exchange network reachability information between on-premises datacenters, SD-WAN fabrics, and Azure Virtual Networks. Understanding how Azure evaluates routing conflicts between dynamically learned BGP prefixes, static User-Defined Routes (UDRs), and platform system routes is critical for designing predictable, resilient enterprise networks.

The Longest Prefix Match (LPM) Rule

When a packet arrives at an Azure virtual network interface, the SDN routing engine evaluates all candidate routes in the subnet's Effective Route Table. The primary and most fundamental decision criteria in IP routing is Longest Prefix Match (LPM).

+-----------------------------------------------------------------------------------------+
|                         Longest Prefix Match (LPM) Evaluation                           |
|                                                                                         |
|   Packet Destination: 10.1.4.55                                                         |
|                                                                                         |
|   Candidate Routes in Effective Table:                                                  |
|   1. 10.0.0.0/8         (System Route -> None)                      Prefix Length: /8   |
|   2. 10.1.0.0/16        (UDR -> Virtual Appliance 10.0.1.4)         Prefix Length: /16  |
|   3. 10.1.4.0/24        (BGP Route -> VirtualNetworkGateway)        Prefix Length: /24  |
|   4. 0.0.0.0/0          (UDR -> Internet)                           Prefix Length: /0   |
|                                                                                         |
|   >>> WINNING ROUTE: Route 3 (10.1.4.0/24) because /24 is the longest (most specific)   |
+-----------------------------------------------------------------------------------------+

The LPM Principle

Core Rule: A more specific route (longer subnet mask / higher CIDR prefix length) ALWAYS wins over a less specific route, regardless of whether the route originated from a UDR, BGP advertisement, or System Route.

Route Precedence for Identical Prefixes

When multiple routing sources advertise the exact same address prefix (e.g., both a UDR and a BGP advertisement specify 10.20.0.0/16), Azure resolves the tie using strict Administrative Precedence:

+-----------------------------------------------------------------------------+
|                   Route Precedence Hierarchy (Identical Prefixes)           |
|                                                                             |
|   Rank 1 (Highest):  User-Defined Route (UDR)                               |
|                             v                                               |
|   Rank 2:            BGP Learned Routes (ExpressRoute > VPN)                |
|                             v                                               |
|   Rank 3 (Lowest):   Default System Routes                                  |
+-----------------------------------------------------------------------------+

Detailed Priority Order

1. User-Defined Route (UDR):
   • Highest administrative priority.
   • Explicitly designed to allow administrators to override dynamic routing behavior.
2. BGP Learned Routes:
   • Routes propagated dynamically via ExpressRoute, S2S VPN, or Azure Route Server.
   • Dynamic Route Sub-Precedence:
     • If the identical prefix is advertised over both ExpressRoute and VPN Gateway, ExpressRoute is preferred over VPN.
     • If multiple BGP paths exist across the same connection type, the route with the shortest AS Path is selected.
3. Default System Routes:
   • Lowest priority.
   • Overridden automatically by any matching UDR or BGP route.

Disabling BGP Route Propagation (DisableGatewaySubnetRoutes)

By default, when a Route Table is created, the property Propagate gateway routes is enabled (disableBgpRoutePropagation: false). This means all BGP routes learned by the Virtual Network Gateway are automatically injected into the subnet's effective route table.

The Enterprise Firewall Bypass Problem

Consider an enterprise hub-and-spoke network with an Azure Firewall in the hub and a default UDR 0.0.0.0/0 -> 10.0.1.4 on the spoke subnet. The on-premises network advertises specific branch subnets (e.g., 172.16.50.0/24) via BGP over ExpressRoute.

+-----------------------------------------------------------------------------------------+
|               Scenario A: Propagate Gateway Routes ENABLED (Firewall Bypassed)          |
|                                                                                         |
|   Effective Routes on Spoke Subnet:                                                     |
|   - 0.0.0.0/0         -> UDR: Azure Firewall (10.0.1.4)                                 |
|   - 172.16.50.0/24    -> BGP: VirtualNetworkGateway (Learned from On-Premises)          |
|                                                                                         |
|   Result: Packet to 172.16.50.10 matches 172.16.50.0/24 via LPM.                        |
|   Traffic flows DIRECTLY to Gateway, completely bypassing Azure Firewall inspection!     |
+-----------------------------------------------------------------------------------------+
                                            vs.
+-----------------------------------------------------------------------------------------+
|               Scenario B: Propagate Gateway Routes DISABLED (Enforced Inspection)       |
|                                                                                         |
|   Effective Routes on Spoke Subnet:                                                     |
|   - 0.0.0.0/0         -> UDR: Azure Firewall (10.0.1.4)                                 |
|   (BGP route 172.16.50.0/24 is BLOCKED from entering the subnet route table)            |
|                                                                                         |
|   Result: Packet to 172.16.50.10 matches 0.0.0.0/0.                                     |
|   Traffic is forced through Azure Firewall (10.0.1.4) for full security inspection!      |
+-----------------------------------------------------------------------------------------+

Implementation

To enforce security inspection, set disableBgpRoutePropagation: true on the spoke route table. This ensures that no learned BGP routes override your summary UDRs.

// Azure Bicep: Spoke Route Table with BGP Propagation Disabled
resource spokeRouteTable 'Microsoft.Network/routeTables@2023-05-01' = {
  name: 'rt-spoke-isolated'
  location: 'eastus'
  properties: {
    disableBgpRoutePropagation: true // Blocks learned BGP routes from injecting
    routes: [
      {
        name: 'force-all-traffic-to-firewall'
        properties: {
          addressPrefix: '0.0.0.0/0'
          nextHopType: 'VirtualAppliance'
          nextHopIpAddress: '10.0.1.4'
        }
      }
    ]
  }
}

Autonomous System Numbers (ASN) & BGP Configuration

BGP uses Autonomous System Numbers (ASNs) to identify routing domains and prevent routing loops.

Azure ASN Allocations & Constraints

BGP Peering Addresses

• Azure VPN Gateway: Assigns private IP addresses from the GatewaySubnet as BGP peer addresses. It also supports APIPA (Automatic Private IP Addressing) addresses in the range 169.254.21.0/24 to 169.254.22.255/24 for multi-S2S tunnels.
• Azure Route Server: Establishes eBGP peering sessions with third-party NVAs using standard VNet subnet IP addresses.

BGP Communities in Azure Networking

In ExpressRoute Microsoft Peering, Microsoft advertises public IP prefixes for Azure services (Storage, SQL, Cosmos DB). To allow customers to filter routes and control traffic paths, Microsoft tags prefixes with BGP Communities:

1. Regional BGP Communities:
   • Format: 12076:51004 (East US), 12076:51005 (West US), 12076:52001 (North Europe).
   • Allows on-premises routers to prefer local regional Azure paths.
2. Service BGP Communities:
   • Format: 12076:5010 (Azure Storage), 12076:5020 (Azure SQL), 12076:5050 (Azure Cosmos DB), 12076:5250 (Azure Monitor).
   • Allows enterprises to accept routes only for specific approved cloud services over ExpressRoute.

Comprehensive Azure Routing Decision Matrix