Does "primary" on different peerings of the same ExpressRoute circuit always terminate on the same physical MSEE router?

Question

Does "primary" on different peerings of the same ExpressRoute circuit always terminate on the same physical MSEE router?

Peter Stieber 90

An ExpressRoute circuit can have both AzurePrivatePeering and MicrosoftPeering configured. Each peering gets its own primaryPeerAddressPrefix and secondaryPeerAddressPrefix (/30), its own VLAN, and its own BGP session — but a circuit only has two physical MSEE routers total (not two per peering).

Example (from a real circuit):

MicrosoftPeering — primary 123.0.0.0/30, secondary 123.0.0.4/30
AzurePrivatePeering — primary 10.0.0.0/30, secondary 10.0.0.4/30

Question: Is it guaranteed that the "primary" session on AzurePrivatePeering and the "primary" session on MicrosoftPeering always terminate on the same physical MSEE router (with only "secondary" on each being the other router)? Or can Azure provision them independently, such that e.g. AzurePrivatePeering primary and MicrosoftPeering primary could end up on different physical MSEEs?

We haven't found anything in the ExpressRoute circuit/peering REST API response that states this explicitly — the response only gives prefixes and VLANs per peering, with no field tying "primary" across peerings to the same underlying device. We're currently assuming primary↔primary/secondary↔secondary consistency across peerings on the same circuit based on general descriptions of ExpressRoute redundancy, but would like to confirm whether this is an architectural guarantee or just typical/observed behavior.

0 comments

1 answer

Your answer

Answer 1

Hi @Peter Stieber

Good question. I couldn't find Microsoft docs that call this an architectural guarantee in so many words, but the docs do treat primary and secondary as circuit-level paths, not per-peering ones. The ARP table doc says each circuit has two paths, primary and secondary, and the routing doc puts the first /30 of every peering on the primary link. So your primary-to-primary assumption lines up with how Microsoft describes it.

To check it on your own circuit and get it in writing:

Pull the ARP table for the primary path on both peerings with Get-AzExpressRouteCircuitARPTable -PeeringType AzurePrivatePeering -DevicePath Primary, then run it again with -PeeringType MicrosoftPeering.
Compare the Microsoft-side MAC address in both results. If they match, that's a good sign both primary sessions sit on the same MSEE.
If you need this as a design guarantee, open a support request on the circuit and ask the ExpressRoute team to confirm it in writing.

Is this for failover planning, like making sure a single MSEE failure only ever takes down the primary sessions together?

If this resolved your question, please consider accepting it as the answer. If you still need more detail, let me know and I'll be happy to keep helping.

Reference: