VPN Gateway BGP Configuration

Border Gateway Protocol (BGP) is the de facto internet routing protocol (RFC 4271) used to exchange routing information between autonomous systems (AS). In Azure VPN Gateway, BGP allows dynamic exchange of routes between your on-premises network and Azure virtual networks. Without BGP, you must manually configure static routes for each network prefix, which doesn't scale and cannot automatically adapt to network changes or failures.

BGP provides several benefits: - Automatic route propagation: When you add or remove subnets in Azure, BGP automatically advertises the changes to on-premises routers. - Redundancy and failover: With multiple VPN tunnels, BGP can detect path failures via keepalive timers and switch traffic to an alternate path. - Route selection: BGP applies policies (e.g., local preference, AS path prepend) to influence which path traffic takes. - Loop prevention: BGP includes AS path information to prevent routing loops.

Azure VPN Gateway supports BGP for both site-to-site (S2S) and VNet-to-VNet connections. When you enable BGP, the VPN gateway becomes a BGP router. It establishes a BGP peering session with your on-premises VPN device over the IPsec tunnel. The BGP peering uses TCP port 179.

Key components: - Autonomous System Number (ASN): Azure VPN Gateway requires a unique ASN for each BGP peer. Azure uses a default ASN of 65515 for its VPN gateways, but you can assign a custom ASN (public or private) for your on-premises router. - BGP peer IP address: This is the IP address of the VPN gateway's BGP endpoint. For active-active gateways, each instance has its own BGP peer IP. - BGP peering: The VPN gateway and on-premises router exchange route information. The gateway advertises the VNet address space and any routes from connected ExpressRoute or other VPN connections. - Route propagation: BGP routes are propagated to the VNet's route table. You can see them in the effective routes for a network interface.

1. Create a VPN gateway with BGP enabled: When creating the gateway, set the -EnableBgp parameter to $true.

$gw = New-AzVirtualNetworkGateway -Name 'VNet1GW' -ResourceGroupName 'RG1' `
     -Location 'EastUS' -IpConfigurations $ipconfig `
     -GatewayType Vpn -VpnType RouteBased -GatewaySku VpnGw1 `
     -EnableBgp $true -Asn 65515

Note: BGP is only supported on RouteBased VPN gateways. PolicyBased gateways do not support BGP.

2. Configure local network gateway with BGP settings: The local network gateway represents your on-premises network. You must specify the on-premises BGP peer IP and ASN.

$local = New-AzLocalNetworkGateway -Name 'OnPremGW' -ResourceGroupName 'RG1' `
     -Location 'EastUS' -GatewayIpAddress '203.0.113.1' `
     -AddressPrefix @('10.0.0.0/16') `
     -Asn 65001 -BgpPeeringAddress '10.0.0.254'

Note: The -AddressPrefix parameter is optional when using BGP because routes are exchanged dynamically. However, it's recommended to include the on-premises address space for initial routing.

3. Create a connection with BGP enabled: The connection between the VPN gateway and local network gateway must have BGP enabled.

New-AzVirtualNetworkGatewayConnection -Name 'S2SConnection' -ResourceGroupName 'RG1' `
     -VirtualNetworkGateway1 $gw -LocalNetworkGateway2 $local `
     -ConnectionType IPsec -SharedKey 'abc123' -EnableBgp $true

Azure VPN Gateway uses these defaults. You can modify the hold timer on the on-premises router, but Azure does not allow changing it on the gateway side.

When multiple paths exist to the same destination, BGP uses a multi-step decision process. The most important attributes for exam purposes:

In Azure, you can influence path selection using AS path prepending (adding AS numbers to make the path longer) or by setting MED on routes advertised from on-premises.

When BGP is enabled on a VPN gateway, the gateway automatically propagates BGP-learned routes to the VNet's route tables. You can see these routes in the Azure portal under 'Virtual network gateway' -> 'BGP peers' -> 'Routes'. The routes appear as 'BGP' source in effective routes.

Important: BGP routes are not automatically propagated to peered VNets unless you enable 'Allow gateway transit' on the peered VNet gateway. Even then, only static routes and BGP routes from the VPN gateway are propagated; routes from ExpressRoute are not propagated over VPN (unless using a gateway transit scenario).

An active-active VPN gateway has two instances, each with its own public IP and BGP peer IP. This provides high availability. When configuring BGP, you must:

Azure VPN Gateway can coexist with ExpressRoute in the same VNet. BGP is used for both, but they are separate routing domains. By default, Azure prefers ExpressRoute over VPN for the same prefix. This is enforced by assigning a lower local preference to VPN routes (100) compared to ExpressRoute (not set, default 100 but ExpressRoute routes are considered 'direct' and take precedence). You can override this using BGP communities or custom route tables.

To check BGP status from Azure side:

# Get BGP peer status
Get-AzVirtualNetworkGatewayBGPPeerStatus -VirtualNetworkGatewayName 'VNet1GW' -ResourceGroupName 'RG1'

# Get BGP learned routes
Get-AzVirtualNetworkGatewayLearnedRoutes -VirtualNetworkGatewayName 'VNet1GW' -ResourceGroupName 'RG1'

# Get BGP advertised routes
Get-AzVirtualNetworkGatewayAdvertisedRoutes -VirtualNetworkGatewayName 'VNet1GW' -ResourceGroupName 'RG1' -Peer '10.0.0.254'

From Azure portal, you can view BGP status under the VPN gateway's 'BGP peers' blade.

Common BGP issues: - BGP session not establishing: Check that the on-premises VPN device has the correct BGP peer IP (the gateway's BGP IP, not the public IP). Also ensure firewall allows TCP 179. - Routes not propagating: Verify that BGP is enabled on both the gateway and the connection. Check that the on-premises router is advertising the correct prefixes. - Route flapping: Frequent route updates can cause instability. Check for inconsistent network configurations or timers. - ASN mismatch: The on-premises ASN must match what is configured in the local network gateway.

VNet-to-VNet connections can also use BGP. Each VNet's gateway must have BGP enabled and use unique ASNs (private ASNs are fine). The BGP peering works similarly to S2S, but over Microsoft's backbone instead of the internet.

Azure supports BGP communities (RFC 1997) to tag routes. For example, ExpressRoute uses community values to indicate the region. VPN Gateway does not support custom community configuration, but it respects communities received from on-premises.

A global enterprise has headquarters in New York and a disaster recovery site in Chicago. They want to connect both sites to Azure East US and Azure West US using two VPN gateways. Each on-premises site has two VPN devices (active-active). BGP is configured on each VPN gateway with ASN 65515. On-premises routers use ASN 65001 for NY and 65002 for Chicago. Each on-premises router establishes a BGP session with both Azure gateways. BGP advertises the on-premises prefixes (e.g., 10.1.0.0/16 for NY, 10.2.0.0/16 for Chicago). Azure advertises VNet prefixes. If the primary tunnel from NY to East US fails, BGP automatically withdraws the routes, and traffic goes through the secondary tunnel to West US. To prefer the local Azure region, on-premises routers use AS path prepending on the backup path (e.g., prepend AS 65001 twice to make the path longer). This ensures traffic uses the shortest AS path. Common misconfiguration: forgetting to enable BGP on the connection itself, which results in no BGP session even if the gateway is BGP-enabled.

A company uses ExpressRoute for primary connectivity to Azure. They set up a VPN gateway as a backup. BGP is used on both connections. The ExpressRoute circuit advertises the same on-premises prefixes as the VPN. Azure prefers ExpressRoute over VPN because ExpressRoute routes are considered 'direct' (lower administrative distance). However, BGP local preference can be used to override this. In production, the network engineer configures the VPN gateway to prepend its AS number multiple times to ensure that VPN routes have a longer AS path, making ExpressRoute preferred. If ExpressRoute fails, BGP withdraws those routes, and the VPN routes become active. The failover time is determined by BGP timers (hold timer 180s) or BFD (if configured on ExpressRoute). A common mistake is assuming that Azure automatically fails over between ExpressRoute and VPN without BGP path selection tuning.

An organization has a hub VNet with a VPN gateway and multiple spoke VNets peered to the hub. The spoke VNets need to communicate with on-premises networks. The hub VPN gateway has BGP enabled. On-premises routes are propagated to the hub VNet route table. For spoke VNets to receive these routes, the peering must have 'Allow gateway transit' enabled on the hub side and 'Use remote gateway' on the spoke side. BGP routes are then propagated to the spoke VNets. However, spoke VNets cannot advertise their own routes to on-premises via the hub gateway unless they use a VPN gateway in the spoke. The exam tests this limitation: gateway transit only propagates routes from the hub gateway to spokes, not the other way around.