Networking to and within the Azure Cloud, part 2

This is the second blog post of a three-part series. Before you begin reading, I would suggest reading the first post Networking to and within the Azure Cloud, part 1. Hybrid networking is a nice thing, but the question then is how do we define hybrid networking? For me, in the context of the connectivity to virtual networks, ExpressRoute’s private peering or VPN connectivity, it is the ability to connect cross-premises resources to one or more Virtual Networks (VNets). While this all works nicely, and we know how to connect to the cloud, how do we network within the cloud? There are at least 3 Azure built-in ways of doing this. In this series of 3 blog posts, my intent is to briefly explain: Hybrid networking connectivity options Intra-cloud connectivity options Putting all these concepts together Intra-Cloud Connectivity Options Now that your workload is connected to the cloud, what are the native options to communicate within the Azure cloud? There are 3 native options: VNet to VNet via VPN (VNet-to-VNet connection) VNet to VNet via ExpressRoute VNet to VNet via Virtual Network Peering (VNet peering) and VNet transit My intent here is to compare these methods, what they allow, and the kind of topologies you can achieve with these. VNet-to-VNet via VPN As exposed in the below picture, when 2 VNets are connected together using VNet-to-VNet via VPN, this is what routing tables look like for both virtual networks: This is interesting with 2 VNets, but it can grow by some measure: If you notice, the route tables for VNet4 and VNet5 indicate how to reach VNet3. However, VNet4 is not able to reach VNet5. Despite this being the case, there are 2 methods to achieve this: Full Mesh VNet-to-VNet Using BGP enabled VPNs With both of these methods, all 3 VNets know how to reach each VNet. Obviously this could scale to many more VNets, assuming the limits of the VPN Gateways are respected (maximum number of tunnels, etc.). VNet-to-VNet via ExpressRoute While maybe not everyone realizes, linking a VNet to an ExpressRoute circuit has an interesting side-effect when you are linking more than one VNet to the same ExpressRoute circuit. For example, when you have 2 VNets linked to the same ExpressRoute circuit, this is what the route table looks like: Interestingly, both VNets are able to communicate with each other, without going outside of the Microsoft Enterprise Edge (MSEE) router. This makes possible the communication between VNets that are either within the same geopolitical region or globally, except on National Clouds, if this is an ExpressRoute Premium circuit. This means you can use the world wide Microsoft backbone, to connect multiple VNets together. And by the way, that VNet-to-VNet traffic is free, as long as you can connect these VNets to the same ExpressRoute circuit. In the example below, you would have 3 VNets connected to the same ExpressRoute circuit: You also see in the picture above the different routes that appear in each VNet’s subnet’s Effective Route Table (read that, it’s very useful to understand why routing doesn’t work like you expect, if that ever happens). VNet-to-VNet with Virtual Network Peering The final option to connect multiple VNets together is to use Virtual Network Peering, which is constrained within one Azure region. This peering arrangement between 2 VNets makes the VNets behave essentially like if this were 1 big virtual network, but you can govern/control these communications with NSGs and route tables. For an illustration of what this means, see below: So taking that to the next level, you could imagine a topology where you would have a hub and spoke topology like this: Peering is non-transitive, therefore in that case, HR VNet cannot talk directly to Marketing VNet, however they can all three, HR, marketing, and engineering, talk to the Hub VNet, that would contain shared resources, like Domain Controllers, Monitoring Systems, Firewalls, or other Network Virtual Appliances (NVA). Using a combination of User-Defined-Routes applied on the spoke VNets and NVA in the centralized Hub VNet. However, like in the case of VPN, if for some reason you would need each VNet to be able to talk to each other, you could create a topology similar to this as well: When using VNet peering, one of the great resource that can be shared is the Gateways, both VPN and ExpressRoute gateways. That would look something like this: This way, you do not have to deploy an ExpressRoute or VPN Gateway in every spoke VNet, but can centralize the security stamp and Gateway access into the Hub Vnet. Please make sure to check out the next post when it comes out to put all these concepts together!
Quelle: Azure