In this post I will show you how to link two virtual networks using VNet Peering, a new feature in Microsoft Azure.
VNet Peering is the easiest and best performing way to connect two virtual networks (VNets). The alternative, VNet-to-VNet VPN, requires that you deploy gateways in each of the connected VNets. Then you must create a VNet tunnel between the two VNets. Because you must use a gateway, the VPN option limits network speeds between the VNets to the bandwidth capabilities of the gateway — 80 Mbps in the case of a Basic gateway (not 100 Mbps as often documented).
VNet peering links VNets using the underlying software-defined network, tunnelling packets across the physical data center networks using NVGRE. This means that you don’t need a gateway, and that two virtual machines in different VNets can communicate at the speed of their NICs (that’s going to be around 25 Gbps for some machines once a current hardware offload preview goes generally available).
My approach to linking VNets is that I always want to use VNet Peerng, but there are times that I must fall back to using VNet-to-VNet VPN. Here are some of the requirements and limitations of VNet Peering:
One of the reasons that I like VNet Peering is that, once you understand the limitations, deploying VNet Peering is both quick and easy (deploying a VPN gateway can take up to 1 hour). I have deployed two VNets in my lab, one for sales and one for accounting, both in the same region. Their applications were isolated, but now they wish to have some level of integration, and a network connection is required.
A peering must be created from each VNet to link it to the other VNet, so you will create two connections:
You can wrap things up there and click OK to create the peering. You will then go to the other VNet and repeat the configuration.
You should see the peering status of the two VNets switch to Connected after a few minutes. Now virtual machines on each VNet can talk at NIC speeds to virtual machines on the other VNet.
If virtual machines are failing to route with each other then check your network security groups to ensure that the traffic is allowed to and from the required virtual NICs/subnets.
There are four options to note. The first of these disables the VNet peering (and cross-VNet communications) until you are ready to enable it. The other options, used for complex hub/spoke architectures, are as follows: