ExpressRoute Azure Private Peering

運用前提: 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も再確認してください。

ExpressRoute Azure Private Peeringを理解するための前提

Azure private peeringはAzure VNet/private workloadへのrouting domainで、CEとMicrosoft Enterprise Edge間にprimary/secondaryのeBGP sessionを構成する。 IPv4 peering interface用に/29または2つの/30を確保し、primary/secondary linkへ分ける。VNet address spaceと重複させない。

Microsoft側ASNは12076。Azure内部では65515–65520が予約されているためASN設計で衝突を避ける。 private peeringへ広告できるIPv4 prefixにはscale limitがあり、Premium add-onで上限が拡大する。無制限advertisementを前提にしない。

default routeはAzure private peeringで広告できるが、VNetのInternet pathをcorporate edgeへ引き込むためAzure platform/service到達性への影響を事前検証する。 primary/secondary両BGP sessionを成立させ、同一必要prefixを広告/受信することが高可用性の前提。片linkだけupは正常完了ではない。

通信や判断の流れを追う

On-premisesVPN / ProviderGateway / HubVNetWorkload

Control plane と data plane

Control planeControl planeはcircuit peering resourceにPeerASN、primary/secondary peer address prefix、VLAN ID、optional MD5等を設定する。CE側neighbor/filter/local-prefはcustomer/provider責任でAzure resourceには表れない。

Data planeData planeではCEとMSEEのeBGPで学習したrouteが各側RIB/FIBへ入り、provider circuitを通るpacket forwardingに使われる。BGP tableのrouteがVNet NIC effective routeまでpropagateしたかを終点側でも確認する。

Provider / responsibility boundary

Azure / Microsoft

ExpressRoute circuit、peering、MSEE側BGP、VNet gateway / FastPath、Azure route propagationを管理する。

Connectivity provider

customer edgeからMicrosoft edgeまでのL2/L3 service、cross-connect、VLAN等を担当する。provider provisioningはAzure resource stateと別に追う。

Customer edge

CE routerのBGP policy、local preference / AS path、prefix filter、冗長回線を管理する。片系だけ正常でもend-to-end冗長性は成立しない。

仕組み

primary/secondaryは同一circuitの冗長linkで、両方のBGP sessionを常時upにする。HSRP/VRRPをMicrosoft側HAの代わりとして使う設計ではない。

prefix advertisementはallowlist/aggregationを基本とし、最大prefix数とreserved/overlapをchange前に検証する。

default route広告は強力で、Azure VMのInternet egressやplatform endpointへの経路をcorporate networkへ変える。意図がない限り安易に広告しない。

route table/ARP tableはL2/BGP状態の証拠になるが、VNet gateway connectionやNSG/NVAを含むend-to-end到達性は別試験する。

DR circuitを追加する場合はAzure向けpath preferenceとon-prem向けreturn preferenceを両方向で設計し、stateful applianceの非対称を避ける。

Packet / route path

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

CE/MSEEのprimaryとsecondary interfaceがprovider L2で接続される。
各linkでeBGP sessionがEstablishedとなり、CEが許可on-prem prefixをMicrosoftへ広告する。
Microsoft側がVNet connection由来のAzure prefixesをCEへ広告する。
BGP best-path/policyを経てCE/MSEEのforwarding tableへrouteがinstallされる。
Azure側ではVNet gateway/FastPathがrouteをVNetへ反映し、workload effective routesにVirtualNetworkGateway pathが現れる。
link/circuit failure時に該当sessionのrouteがwithdrawされ、secondary/second circuit/VPN backupへ収束する。

BGP / route state の読み方

観測点	何を確認するか
Primary/secondary parity	両BGP sessionのroute count・重要prefixを比較し、standby linkに未advertised routeがないことを確認する。
Customer→Microsoft	advertised prefix、AS path、aggregation、prefix countをCEで確認し、MSEE route tableに反映された結果と突合する。
Microsoft→Customer	Azure prefixを両CE sessionで受信し、customer FIBへinstallされたbest pathを確認する。
Default route	0.0.0.0/0をadvertiseする場合、VNet effective routeとAzure service/Internet egressのobservable behaviorを受入項目にする。

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

設計判断

判断点	推奨	理由
Peer subnet	dedicated /29または2×/30を予約し、既存VNet/on-prem poolと重複させない。	後からのrenumberはprovider coordinationとBGP outageを伴う。
Prefix policy	explicit allowlist + aggregationを採用する。	route leak/prefix-limit超過と不要なblast radiusを抑える。
Default route	security architectureが明示的に要求する場合のみ広告する。	AzureのInternet/platform到達性をcustomer edgeへ依存させるため。
MD5	policyで必要な場合に両peerで一致させchange管理する。	片側だけの変更はBGP session全断を起こす。

確認手順

Azure Portal / provider / edge

Circuit → Peerings → Azure private peeringでPeer ASN、VLAN、primary/secondary peer subnet、stateを確認する。
Route table/ARP tableをprimary/secondary別に取得し、BGPとL2の状態を分離して確認する。
CE routerでneighbor summary、received/advertised routes、prefix count、best path/FIBを採取する。
VNet側representative NICのeffective routesで期待prefixがVirtualNetworkGateway由来として選択されるか確認する。

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 express-route peering list -g <rg> --circuit-name <circuit> -o table
az network express-route peering show -g <rg> --circuit-name <circuit> -n AzurePrivatePeering -o jsonc
az network express-route show -g <rg> -n <circuit> -o jsonc

PowerShell / endpoint — read-only first

$c = Get-AzExpressRouteCircuit -ResourceGroupName <rg> -Name <circuit>
Get-AzExpressRouteCircuitPeeringConfig -ExpressRouteCircuit $c -Name AzurePrivatePeering

障害切り分け

症状	疑う点	証拠	次の確認
secondaryだけBGP down	peer subnet/VLAN/provider link/CE neighbor差	peer state + CE neighbor + provider link	primaryとsecondary configをdiffする
BGP upだがAzure prefix不足	VNet connection/gateway propagation/prefix scale	MSEE/CE received routes + gateway connection	peering単体とVNet attachmentを分ける
sessionがdropする	prefix limit超過、MD5 mismatch、provider flap	prefix count + BGP notification/log	advertisement量とchange履歴を確認する
default route追加後にAzure service障害	Internet/platform pathがon-premへ強制	effective routes + firewall/proxy logs	default routeのblast radiusを確認し必要なexception/UDRを設計する

変更時の確認と rollback

peer変更前にprimary/secondary configuration、route table、CE neighbor configを保存する。
filter/advertisement変更は片linkずつdiffを確認し、両linkへ同時誤設定しない。
default routeのrollbackはwithdraw後、effective routesとInternet/platform reachabilityが元へ戻ったことを確認する。
peer subnet/VLAN変更はprovider作業を伴うため、単純なAzure設定undoと考えない。

ExpressRoute Azure Private Peering