Now that Global VNet peering has gone to GA I had a large university in California ask how to set this up.
What is Global VNet peering?
Global VNet peering in Azure is the ability to peer VNets or virtual networks across regions (see regional availability below).
Some benefits of Global VNet peering include:
- Private Peering traffic stays on Azure network backbone
- Low latency and high bandwidth VNet region to VNet region connectivity
- No more VNet to VNet VPN configuration which means no VPN encryption, no gateways, no public internet necessary
- No downtime setting up Global VNet peering with portal or ARM templates
What are some limitations of Global VNet peering?
Currently, one limitation as of April 2018, is that Global VNet peering is not available in all regions. It is slated to be available in the future for all regions:
- The virtual networks can only exist in the following regions: West Central US (Wyoming), West US 2 (Washington), Central US (Iowa), US East 2 (Virginia), Canada Central (Toronto), Canada East (Quebec City), Southeast Asia (Singapore) Korea South (Buscan), South India (Chennai), Central India (Pune), West India (Mumbai), UK South (London), UK West (Cardiff), West Europe (Netherlands)
You cannot use Global VNet peering to communicate with VIPs of load balancers in another region. VIP communication requires source IP to be on the same VNet as the LB IP:
- Resources in one virtual network cannot communicate with the IP address of an Azure internal load balancer in the peered virtual network. The load balancer and the resources that communicate with it must be in the same virtual network.
This is a big one as it bit us with a customer. You must not check ‘use remote gateways’ or ‘allow gateway transit’ like you select when setting up intra regional VNet peering:
- You cannot use remote gateways or allow gateway transit. To use remote gateways or allow gateway transit, both virtual networks in the peering must exist in the same region.
VNet Global peerings are not transitive meaning downstream VNets in one region cannot talk with downstream VNets in another region.
The last one is to use Global VNet peering both VNets must be in the same subscription and use same Azure AD so cross subscription Global VNet peering is not currently supported.
How do I setup Global VNet peering?
It is fairly straightforward to setup Global VNet peering and I documented the steps below:
1) Setup VNets in each supported Global VNet supported region (April 2018 supported regions listed above). In my case, I created a VNet in US West 2 and West Central US
2) For testing create a VM in each region and associate it to a VNet you are going to use with Global VNet peering to test VM connectivity. The VMs cannot be associated with a downstream VNet as you recall since transitive downstream VNets are not supported with Global VNet peering.
3) Enable Global VNet peering:
3a) On one of the VNets you want to Global peer, go to Peerings and click Add
3b) Fill out the peering and select the VNet in the other region you want to Global Peer with – Important – don’t check any of the checkboxes!
3c) Setup peering in other direction by repeating step 3a and 3b but with the VNet peering in the other region – also don’t click any checkboxes and pick the other VNet in the other region you want to Global peer with:
4) Let it finish provisioning and then validate VNet Global peering is Connected on both VNets:
5) Test Global VNet connectivity with Telnet, PSPing or Ping Note: ensure firewalls allow ports you are telneting to, ICMP, etc.:
Test connectivity from one direction:
Then test connectivity from the other direction:
6) You are done! Congratulations Global VNet peering is complete!
This post first appeared on MSDN Blogs | Get The Latest Information, Insights, Announcements, And News From Microsoft Experts And Developers In The MSDN Blogs., please read the originial post: here