Azure ExpressRoute Troubleshooting

Azure ExpressRoute issues can originate on the Tata Communications side, on the Azure side, or sit ambiguously between the two. Use the triage below to place the symptom, then follow the diagnostic steps. For ambiguous issues, start with Tata Communications support.

Triage

Symptom points to	Examples
Tata Communications side – raise a TC^x service request	Circuit stuck in Not Provisioned for an extended period; BGP transit subnet unreachable
Azure side – handle in your Azure subscription	Azure portal errors creating the circuit; Virtual Network Gateway not in Succeeded state; route-filter / IRR validation failures
Ambiguous – start with us	BGP up but no routes received; intermittent packet loss; asymmetric routing

Tata Communications-side issues

Circuit stuck in “Not Provisioned”

The Azure portal shows Provider status Not Provisioned for an extended period after you shared the service key.

Diagnostic steps: Confirm you shared the service key with Tata Communications via the TC^x Portal (without it, the interconnect cannot claim the circuit); confirm the Azure peering location is one Tata Communications supports (Tata Communications can confirm available metros); check the TC^xPortal for open service requests on this circuit.

Resolution: Raise a TC^x service request with the service key and order details.

BGP transit subnet unreachable

You cannot ping the MSEE peer IP on the /30 BGP transit subnet from your CPE.

Diagnostic steps: Confirm the VLAN/C-tag matches Tata Communications’ allocation (113 Private, 115 Microsoft Peering); confirm the IP allocation matches (your side is the first usable on the /30, Microsoft the second); confirm no customer-side ACL is blocking the subnet.

Resolution: If VLAN, IP and ACL are all correct, raise a TC^x service request and Tata Communications will verify the interconnect.

This applies where your circuit is delivered as L2VPN and you run the CPE session. On the default L3VPN delivery there is no CPE-to-MSEE session; if Private/Microsoft Peering does not come up, confirm the Azure peering is set to Peer ASN 4755 with the /30 subnets from Get Network Config, then raise a TCˣ service request.

BGP session not establishing

Session in Idle or Active, never Established, but ping works.

Diagnostic steps: Verify the peering ASN — on the default L3VPN delivery, Azure Private Peering uses Peer ASN 4755; on L2VPN, the remote ASN is Microsoft's 12076 and your local ASN must match your Azure setting;

Resolution: If ASN, MD5 and whitelisting are correct, raise a TC^x service request with your sanitised BGP configuration excerpt.

Intermittent packet loss

Connection up but periodic loss.

Diagnostic steps: Check whether utilisation is at or near the circuit’s bandwidth tier (Tata Communications can confirm); for BFD-enabled sessions, check for flapping and confirm matching 300 ms × 3 timers; check interface errors on your CPE.

Resolution: If utilisation is consistently high, plan a bandwidth upgrade via a TC^x change request; otherwise raise a TC^x service request.

Azure-side issues

Symptom	Where to look
Azure portal cannot create the circuit	ExpressRoute prerequisites in your Azure subscription
Virtual Network Gateway not in Succeeded state	VNet Gateway provisioning state
Routes received but traffic doesn’t reach Azure resources	VNet route tables, Network Security Groups, Azure Firewall
Microsoft Peering: route filter not applying	Route-filter rules and associated BGP community values
Microsoft Peering: IRR validation failed	Update your IRR route objects so advertised prefixes validate

Ambiguous issues – start with Tata Communications support

For symptoms that could be on either side – BGP established but no routes received, one-way (asymmetric) traffic, MTU-related drops, or intermittent reachability affecting some resources – Raise a TC^x service request with:

The circuit ID and Azure region
Timestamps when the issue began
Your CPE BGP session state (sanitised of MD5 keys)
A description of the affected traffic flow.

Need more help?

If this guide doesn’t resolve the issue or you’re unsure which side it’s on, contact Tata Communications support – we will engage Microsoft where the diagnosis points to the Azure side.