Route Server BGP Peering

Scope: Microsoft Learn / Azure Architecture Centerの一次資料を基準に、設計と運用で判断が必要な点をpacket path中心に整理。SKU、region、limitsは変更されるため、実装時はOfficial sourcesのcurrent documentationを再確認してください。

Route Server BGP Peeringを理解するための前提

各NVAはRoute Serverの2 instance IP双方とBGP peeringする。 Route Server ASNは65515で、NVA側にはAzure/IANA reserved ASNを使わない。

Route Serverは1 peerあたり最大4,000 routesを受け入れる。route update処理時の一時countもlimit判定へ影響する。 advertise/learn routeは「BGP Established」だけでなくprefix内容とnext hopまで確認する。

active-active NVAでは同prefix複数path、active-passiveではstandby advertisement/metric/withdrawal behaviorをvendor設計と整合させる。 no-advertise communityやNVA-side filterで不要prefixの外部伝播を抑え、route leak blast radiusを下げる。

通信や判断の流れを追う

SourceEffective routeNext hopDestinationReturn path

Control plane と data plane

Control planePortal / ARM / CLIで定義されたresource、association、route advertisement、peering flagなど。設定がSucceededでもpacket到達を保証しない。

Data plane実際のsource/destination/5-tupleが選ぶroute、NAT、security device、return path。Effective state、Next hop、logs、packet capture、application testで証明する。

仕組み

BGP session確立後、NVA advertisementがRoute Serverへ入りAzure SDNへprogramされる。

NVA failure時にroute withdrawalが正しく伝播すればAzure workloadのselected pathがalternateへconvergeする。stateful session preservationは別問題。

route countが上限へ近い設計はroutine updateでもsession teardownを引き起こし得るため、単純な「現在3,900だからOK」では危険。

Packet path

routing問題は「どのresourceがあるか」ではなく、packetが各hopで何を選ぶかを順に追う。

NVA→Route Server両instanceとTCP/179 BGP session確立。
NVA prefix advertisement。
Route Server validation/route distribution。
workload effective routesへ反映。
failure時はwithdraw→alternate route converge→new flow再開。

設計判断

判断点	推奨	理由
ASN	NVA ASNをinventoryしreserved ASN衝突を避ける。	session/config errorを防止。
Dual peering	両Route Server IPへpeer。	single control-plane pathを避ける。
Route headroom	4,000をlimitではなく警戒線として十分なmarginを設ける。	update burst behaviorを吸収。
Failover	withdraw/convergence timeとstate impactを実測。	BGP up/downだけではapplication HAを証明しない。

確認手順

Azure Portal

Route Server → Peeringsでpeer IP/ASN/stateを確認。
NVA CLIで両peerのBGP state、advertised/received routesを取得。
representative NIC Effective routesでprefix source/next hopを確認。

Verification discipline

subscription / resource group / resource IDを記録する。
同じsource・destinationでbefore/afterを比較する。
read-only evidenceを保存してから変更する。
control-plane successとapplication successを別々に判定する。

Azure CLI — read-only first

az network routeserver peering list -g <rg> --routeserver <route-server> -o table
az network routeserver peering show -g <rg> --routeserver <route-server> -n <peer> -o jsonc

PowerShell — read-only first

Get-Command -Module Az.Network *RouteServer*

障害切り分け

症状	疑う点	証拠	次の確認
片側peerだけEstablished	ACL/route/IP/ASN設定差	NVA BGP summary + Route Server peer	両instance path比較
sessionがroute update時に落ちる	4,000 route accounting超過	route count/update log	aggregation/filterでheadroom確保
wrong next hop	NVA advertisement policy	learned/effective route	next-hop/self/metric policy見直し
failover後new flow不達	withdraw/alternate advertisement遅延	BGP timeline + effective route	convergence/failover policy調整

変更時の確認と rollback

policy変更前にadvertised/received route dumpを取得。
filter変更はpermit/deny対象prefixをexplicit diff。
failure drillでpeer1/peer2/NVA1/NVA2を個別に落としconvergence測定。
rollbackでoriginal route count/path preferenceを復元。

Route Server BGP Peering