Can I have an ExpressRoute's Resoruce Group in another region from where it physcially terminates?

Question

I have an ExpressRoute circuit that physically terminates in Canada Central. However, the resource group for the ExpressRoute circuit is in North Central US.

My ExpressRoute Gateway is in Canada Central and peering seems to be okay. At least that's what the portal states.

When I go to the Connections circuit, it shows that its receiving my Azure subnets correctly (ASN 65515), but nothing from my remote site, an on-prem data center.

The connectivity between the on-prem data center and the peering in Canada Central looks good (Q in Q set up).

However I am not seeing any routes propagated in from on-prem.

Is this due to the ExpressRoute's resource group being in North Central US even though it physically terminates in Canada Central?

Thanks

Ken

Answer 1

Hi @Dedesko, Ken

Welcome to the Microsoft Q&A Platform! Thank you for asking your question here.

• No, the location of the resource group for your ExpressRoute circuit does not directly impact route propagation.  The resource group is primarily for management and billing; it doesn't dictate the physical location or routing behavior of the ExpressRoute circuit itself.  Your ExpressRoute circuit terminating in Canada Central and your gateway also being in Canada Central is the correct setup for physical connectivity
• Please verify again your BGP configuration on both your on-premises router and your Azure ExpressRoute gateway. 
• Make sure that your on-premises ASN is correctly configured and doesn't conflict with any Azure ASNs. Azure uses ASNs in the range 65000-65535 for private ASNs, so avoid using these on-premises.
•  Verify that the peer IP addresses configured on both sides are accurate and reachable. The on-premises router should peer with the primary and secondary IP addresses of your ExpressRoute gateway.
•  If you're using MD5 authentication, ensure the shared secret is identical on both sides. A mismatch will prevent BGP peering from establishing.
•  Check if any route filters are configured on either side that might be blocking the advertisement of your on-premises routes. This includes route maps, prefix lists, and access lists. Make sure your on-premises router is advertising the correct prefixes.
•  Although you mentioned peering is okay, NSGs applied to your Azure subnets could be blocking traffic even if routes are being learned.  Verify that your NSGs allow the necessary traffic from your on-premises network.
• For your reference: https://learn.microsoft.com/en-us/azure/virtual-network/network-security-groups-overview
•  Please verify again that you don't have any UDRs in your Azure subnets that might be interfering with traffic destined for your on-premises network. UDRs take precedence over BGP-learned routes.
• For your reference: https://learn.microsoft.com/en-us/azure/virtual-network/virtual-networks-udr-overview
•  Carefully verify the connection status in the Azure portal for any errors or warnings and also verify the effective route table on your ExpressRoute gateway to confirm that it's learning routes from your on-premises network. For your reference: https://learn.microsoft.com/en-us/azure/expressroute/expressroute-troubleshooting-expressroute-overview
• It is confirmed that your on-premises router is correctly advertising the routes you expect to reach your Azure VNet. Use show ip bgp to inspect the BGP table and see which prefixes are being advertised. Make sure that the interface connected to the ExpressRoute circuit is up and running.
•  Perform packet captures on both your on-premises router interface and your Azure ExpressRoute gateway interface to see if BGP traffic is being exchanged. This is the most direct way to diagnose BGP issues. For your reference: https://learn.microsoft.com/en-us/azure/network-watcher/packet-capture-overview
•  Enable BGP debugging on your on-premises router to get more detailed information about the BGP peering process.
•  Use Azure Network Watcher's IP flow verify to test connectivity between your on-premises network and your Azure VNet.

---

I hope this has been helpful!

Your feedback is important so please accept an answer if correct. Original posters help the community find answers faster by identifying the correct answer. Here is how.

If you still have questions, please let us know what is needed in the comments so the question can be answered.

Thanks,

Sai.