Azure peering down [sc-m-eu-pr-exr-001]

Question

Azure peering down [sc-m-eu-pr-exr-001]

Louis Lau Sui Hao 0

image (23).png

We found the peering to Azure was down around 8AM CET time

There are no activities on going during that time frame.

The link is stable now but flapping for one hour and back to normal, we are unsure this will happen again or not.

Is there any maintenance from Microsoft side for the client SCHOTT.

Regards,

Louis

Mohammed Yunus Ulla 1 Reputation point Microsoft Employee Moderator

2026-08-18T04:38:03.52+00:00
Hi Louis,

From the screenshot, the circuit-level status is marked unhealthy because Microsoft Peering BGP availability became unhealthy on both Primary IPv4 and Secondary IPv4 near the end of the 24-hour window. However, Private Peering stayed healthy, and for Microsoft Peering the ARP availability appears healthy on both links. Packet drop also appears healthy.

This suggests the issue was specific to the Microsoft Peering BGP availability path, rather than a complete ExpressRoute circuit outage. To investigate further, please confirm whether the BGP sessions for Microsoft Peering were actually down on your CE router at that time, or whether they remained established while Azure Monitor reported unhealthy availability.

Please also check the ExpressRoute metrics for the affected window, especially:

BGP Availability for Microsoft Peering primary/secondary

ARP Availability

Bits In/Out

Dropped packets

Any route changes on the CE side

If BGP was established from your router side but Azure still showed Microsoft Peering BGP availability unhealthy, this may need Azure Support review with the exact timestamp, circuit resource ID, and peering location to validate whether there was an MSEE/backend event or maintenance impact.

1 answer

Your answer

Mohammed Yunus Ulla 1 Reputation point Microsoft Employee Moderator

2026-08-18T04:38:03.52+00:00

Hi Louis,

From the screenshot, the circuit-level status is marked unhealthy because Microsoft Peering BGP availability became unhealthy on both Primary IPv4 and Secondary IPv4 near the end of the 24-hour window. However, Private Peering stayed healthy, and for Microsoft Peering the ARP availability appears healthy on both links. Packet drop also appears healthy.

This suggests the issue was specific to the Microsoft Peering BGP availability path, rather than a complete ExpressRoute circuit outage. To investigate further, please confirm whether the BGP sessions for Microsoft Peering were actually down on your CE router at that time, or whether they remained established while Azure Monitor reported unhealthy availability.

Please also check the ExpressRoute metrics for the affected window, especially:

BGP Availability for Microsoft Peering primary/secondary

ARP Availability

Bits In/Out

Dropped packets

Any route changes on the CE side

If BGP was established from your router side but Azure still showed Microsoft Peering BGP availability unhealthy, this may need Azure Support review with the exact timestamp, circuit resource ID, and peering location to validate whether there was an MSEE/backend event or maintenance impact.

Answer 1

Hello @Louis Lau Sui Hao

Based on the screenshot, the ExpressRoute circuit itself was not completely down. Private Peering remained healthy, while Microsoft Peering showed unhealthy BGP availability on both Primary and Secondary IPv4 paths.

Microsoft specifically notes that during maintenance between the Microsoft Edge (MSEE) and Microsoft core network, BGP Availability can appear down even when the BGP session between the customer edge and Microsoft Edge remains established.

Since the issue recovered after approximately one hour, maintenance or a transient Microsoft/provider-side routing event is possible. However, the screenshot alone cannot confirm that Microsoft maintenance caused it.

Please check Azure Service Health → Planned maintenance / Health history for the affected subscription and timeframe. Microsoft states that planned ExpressRoute maintenance is communicated through Azure Service Health, normally at least 14 days in advance.

I would also recommend checking with your ExpressRoute connectivity provider for any maintenance or BGP events during the same period.

If there is no corresponding Service Health notification and this happens again, open an Azure support request with the circuit resource ID, peering location, exact timestamps, and BGP/ARP availability metrics. Microsoft Support can confirm whether an MSEE or backend network event affected the circuit.

Sharing these references with you:

Microsoft Learn – Planned maintenance guidance for ExpressRoute | https://learn.microsoft.com/en-us/azure/expressroute/planned-maintenance

Microsoft Learn – Monitoring data reference for Azure ExpressRoute | https://learn.microsoft.com/en-us/azure/expressroute/monitor-expressroute-reference

Microsoft Learn – ExpressRoute circuits and peering | https://learn.microsoft.com/en-us/azure/expressroute/expressroute-circuit-peerings

Hope this helps.

Please "Accept the Answer" if this information helped you. This will help us and others in the community.

Allan Solomon Mejia 8,840 Reputation points

2026-08-18T16:07:59.7766667+00:00

Hello @Louis Lau Sui Hao ,

Please let us know if you need any further assistance. Otherwise, if the information provided resolved your issue, please click “Accept Answer” to help others who may encounter the same problem.

Thank you!