Azure Route Server

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

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

Route ServerはBGP control-plane serviceであり、customer data trafficをNVA/VM間で転送しない。 1 VNetにつきRoute Serverは1つ。dedicated subnet名RouteServerSubnetが必要。

RouteServerSubnetにはUDRやNSGをassociateしない。 NVAはRoute Serverの両instance IPへBGP peeringしてHAを確保する。Route Server ASNは65515。

1 BGP peerから受け入れるrouteは最大4,000で、update時のcount behaviorにも注意が必要。 VPN/ExpressRoute gatewayとのbranch-to-branch route exchangeはdefaultではなく、明示enableやgateway条件が必要。

通信や判断の流れを追う

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で証明する。

仕組み

Route ServerはNVAからlearnしたBGP routeをAzure SDNへprogramし、Azure側prefixをNVAへadvertiseする。data packet自体はRoute Serverを通らない。

control-plane BGP pathをinspection NVAへforced routeしない。BGP sessionの安定性とdata plane inspection pathは分離する。

same-VNet inter-subnet trafficではVirtual network system routeがpreferredとなるため、Route Server BGPだけでNVA service insertionを実現できないケースがある。UDRが必要。

route exchangeのblast radiusが大きいため、prefix filtering/summary/no-advertise等をNVA/Route Server policyで管理する。

Packet path

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

NVAとRoute ServerがeBGP session確立。
NVAがprefixをadvertise。
Route Serverがrouteを受理しAzure SDNへ配布。
workload NICがBGP-derived routeをeffective stateで利用。
data packetはselected NVA/gatewayへ直接流れ、Route Server自体は通過しない。

設計判断

判断点	推奨	理由
Role	Route Server=control plane、NVA=data planeと図に分ける。	誤ったsecurity/latency想定を防ぐ。
Peer HA	各NVAを両Route Server instanceへpeer。	single BGP session依存を避ける。
Prefix hygiene	4,000/peer上限より十分低い運用headroomを持つ。	update burstでもsession teardownリスクを抑える。
Gateway integration	branch-to-branch要件を明示しsupported gateway mode確認。	BGP route sharingのdefaultを誤認しない。

確認手順

Azure Portal

Route Server → Peers / ASN / Branch-to-branch settingを確認。
RouteServerSubnetにNSG/UDRがないことを確認。
NVA側BGP summaryとAzure effective routesを双方確認。

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 show -g <rg> -n <route-server> -o jsonc
az network routeserver peering list -g <rg> --routeserver <route-server> -o table

PowerShell — read-only first

Get-Command -Module Az.Network *RouteServer*
# 利用中Az.Network versionのGet-AzRouteServer / peering cmdletを確認してread-only取得。

障害切り分け

症状	疑う点	証拠	次の確認
BGP session flap	route limit/update burst/control-plane reachability	NVA BGP logs + advertised route count	prefix filter/summaryとpeer path確認
routeはlearnedだがsame-VNet trafficがNVAへ行かない	preferred VNet system route	effective routes	UDR等のservice insertion方式を使用
gateway routesが交換されない	branch-to-branch未enable/条件不一致	Route Server/gateway config	supported条件へ合わせる
RouteServerSubnet deployment issue	NSG/UDR/名前/size要件違反	subnet config	dedicated supported configへ戻す

変更時の確認と rollback

route policy変更前に各peerのadvertised/learned prefix countを保存。
大量route変更は段階的にannounceしsession stabilityを監視。
Route Server作成/削除が既存gateway environmentへ影響し得るためmaintenance計画を持つ。
rollbackはBGP advertisementを元に戻し、effective route convergenceまで確認。

What changed recently

2026年の運用上の注意

2026年の現行security guidanceではRoute ServerをBGP control-plane onlyとして明示し、customer data trafficは扱わない点が強調されている。data path図にRoute Serverを「通過hop」として描かない。