BGP with VPN Gateway

運用前提: hybrid connectivityはAzure resourceだけで完結しません。Azure / Microsoft edge、connectivity provider・Internet、customer edge、BGP route、VNet effective route、stateful security device、applicationを別failure domainとして観測し、control-planeのSucceededをdata-plane成功の代わりにしません。SKU・limit・availability・preview statusは変わるため、導入時は末尾のcurrent Microsoft Learnも再確認してください。

BGP with VPN Gatewayを理解するための前提

VPN GatewayのBGPはeBGPでAzure/on-prem間のprefixを動的交換し、static address prefixの手動更新を減らす。 BGP sessionがConnectedでも、必要prefixがadvertised/learned routeへ存在しなければdata planeは成立しない。peer stateとroute contentを分けて確認する。

APIPA BGP addressを使う場合、VPN Gateway用に許可されたAPIPA rangeとsession initiation条件をcurrent guidanceで確認する。 active-activeでは複数BGP session/tunnelが同時に存在し、片tunnel切断時は該当route withdrawalによる収束を設計する。

VPN GatewayはBGP peerあたりのprefix上限を持ち、過剰広告はsession断の原因になる。aggregation/filterでadvertisementを制御する。 VPN Gateway NATとBGPを併用する場合、Enable BGP Route Translationによりlearned/advertised prefixのNAT後表現が変わるため設計図へ明示する。

通信や判断の流れを追う

On-premisesVPN / ProviderGateway / HubVNetWorkload

Control plane と data plane

Control planeControl planeではgateway ASN、BGP enabled、Azure BGP peer IP/APIPA、Local Network Gatewayのremote ASN/BGP peer、ConnectionのBGP/NAT設定を持つ。route policyのcustomer側設定はAzure resourceからは見えない。

Data planeData planeで実際に利用されるのはBGP tableそのものではなく、Azure SDNへ反映されroute selectionを経た結果。広告 → 受信 → best path → effective route → forwardingの各段階を分ける。

Provider / responsibility boundary

Azure側

VPN Gateway resource、GatewaySubnet、public IP、connection、Local Network Gateway、BGP設定を管理する。

Internet / provider

IPsec packetが通るunderlay。Azure VPN GatewayがSucceededでも、途中のNAT・firewall・ISP品質は別failure domain。

On-premises

VPN deviceのIKE/IPsec proposal、route/BGP、NAT、policy、HA状態を管理する。Azure側だけではremote peerの実転送を証明できない。

仕組み

on-prem routerはAzure BGP peerへeBGP sessionを確立し、許可したon-prem prefixesを広告する。Azure側はVNet/connected networkの到達性をpeerへ広告する。

Azure PortalのBGP peersではpeer statusだけでなくlearned/advertised routesを閲覧できる。route数が多い場合はCSV/CLI/PowerShellで全件確認する。

同一prefixが複数pathから来る場合、Azureのroute selectionとcustomer BGP policyを別に理解する。単純に「BGPなら最短AS path」とだけ仮定しない。

VNet peering gateway transitを使うとspoke prefix advertisement/learningへ影響する。remote gateway useと同一prefix制約を確認する。

NAT route translationを有効化するとIngressSNAT/EgressSNAT ruleに基づきadvertised/learned prefixが変換される。APIPA BGP peer IP自体はNAT対象にしない。

Packet / route path

同一prefix/flowを広告元からdestinationまで追い、connection state・BGP table・effective route・実packetを混同しません。

IPsec tunnelが成立し、on-prem routerがAzure BGP peer IPへTCP/179 sessionを確立する。
双方がBGP UPDATEでprefixを広告し、filter/policy後のrouteがBGP tableへ入る。
Azure VPN Gatewayがlearned routeをAzure routingへ伝播し、spoke/workloadのeffective route候補になる。
workload packetのdestinationに対しAzure route selectionが行われ、VirtualNetworkGateway pathがbestならtunnelへ送られる。
remote側でもAzure advertised prefixをRIB/FIBへinstallし、replyのreturn pathをVPNへ戻す。
peer/tunnel failure時はroute withdrawal/hold timerによりpathが消え、残存BGP/static pathへ再収束する。

BGP / route state の読み方

観測点	何を確認するか
Peer status	ConnectedDuration、MessagesReceived/Sent、RoutesReceivedを記録する。Connected + RoutesReceived=0はroute advertisement側を疑う。
Learned routes	Origin EBgp、SourcePeer、Network、NextHop/AS pathを確認し、期待remote prefixの存在と重複を検査する。
Advertised routes	peerごとにAzureから広告するprefixを確認し、on-prem routerのreceived routeと一致させる。
Effective routes	BGP learned routeがNIC/subnetのeffective routeとして本当に選択されるか確認する。UDR等の競合を含めて最終forwardingを見る。

判定ルールAdvertised ≠ Learned ≠ Installed/Effective ≠ Reachable。各段階を別証拠として採取し、どこでprefixが消えたかを特定します。

設計判断

判断点	推奨	理由
Prefix policy	summary/allowlistを定義し、必要以上のRFC1918やdefaultを無制限に広告しない。	route leakとprefix limit超過を防ぎ、障害domainを限定する。
APIPA	既存device要件で必要な場合のみ使い、Azure許可rangeとinitiation挙動を確認する。	genericな169.254/16なら何でも良いわけではない。
HA	active-activeなら各peerでadvertisement/learningを同等にし、片peer withdrawalをテストする。	平常時route数差は潜在的な片系不備のsignalになる。
NAT	overlap解消時はNAT mappingとBGP Route Translationを一体で管理する。	routing table上のprefix表現とsecurity ruleのprefix表現がずれる事故を防ぐ。

確認手順

Azure Portal / provider / edge

VPN Gateway → ConfigurationでASN/BGP enabled、BGP peer IP/APIPAを確認する。
Monitoring → BGP peersでpeer status、Routes received、learned/advertised routeを確認する。
on-prem routerでneighbor state、received-routes、advertised-routes、best route/FIBを同時採取する。
代表VM NICのeffective routesでBGP routeのsource/next hopを確認し、実packet testへ接続する。

Verification discipline

subscription / resource group / resource ID / region / connection名を固定し、同名resourceの取り違えを防ぐ。
control-planeのProvisioningStateだけで完了判定せず、peer/session/route/metricと実packetの結果を別々に保存する。
advertised route・learned route・effective routeを混同しない。各段階で「誰が誰へ何を広告し、最終的にどのFIBへ入ったか」を確認する。
変更前後で同一source/destination/protocolを再試験し、既存sessionの継続を新規flowの成功と誤認しない。

Azure CLI — read-only first

az network vnet-gateway list-bgp-peer-status -g <rg> -n <gateway> -o table
az network vnet-gateway list-learned-routes -g <rg> -n <gateway> -o table
az network vnet-gateway list-advertised-routes -g <rg> -n <gateway> --peer <peer-ip> -o table

PowerShell / endpoint — read-only first

Get-AzVirtualNetworkGatewayBgpPeerStatus -ResourceGroupName <rg> -VirtualNetworkGatewayName <gateway>
Get-AzVirtualNetworkGatewayLearnedRoute -ResourceGroupName <rg> -VirtualNetworkGatewayName <gateway>
Get-AzVirtualNetworkGatewayAdvertisedRoute -ResourceGroupName <rg> -VirtualNetworkGatewayName <gateway> -Peer <peer-ip>

障害切り分け

症状	疑う点	証拠	次の確認
BGP Idle/Disconnected	TCP/179到達、peer IP/ASN、APIPA initiation、tunnel state	peer status + remote neighbor log	IPsecとBGPを別layerとして確認する
BGP Connectedだがroute 0	remote network statement/filter、prefix limit	RoutesReceived + remote advertised-routes	remoteが本当にUPDATEを送っているか確認する
routeはlearnedだがVMへ反映されない	UDR、more-specific route、gateway propagation、peering transit	NIC effective route	BGP tableをdata-plane routeと誤認しない
sessionが突然drop	prefix limit超過、remote flap、underlay loss	route count、BgpDisconnectedEvent、remote logs	advertised prefix数とaggregate/filter policyを確認する

変更時の確認と rollback

変更前にpeer status、learned/advertised routes、remote neighbor policyを保存する。
route filter変更は追加/削除prefixを差分化し、いきなりdefault/summaryへ置換しない。
ASN/APIPA変更は双方同時changeとして扱い、rollback値を明記する。
rollback後はBGP Establishedだけでなく期待route集合と実forwardingを比較する。