If you would like to read the other parts in this article series please go to:
- Hybrid Network Infrastructure in Microsoft Azure (Part 1)
- Hybrid Network Infrastructure in Microsoft Azure (Part 2)
- Hybrid Network Infrastructure in Microsoft Azure (Part 3)
- Hybrid Network Infrastructure in Microsoft Azure (Part 4)
- Hybrid Network Infrastructure in Microsoft Azure (Part 5)
- Hybrid Network Infrastructure in Microsoft Azure (Part 7)
- Hybrid Network Infrastructure in Microsoft Azure (Part 8)
- Hybrid Network Infrastructure in Microsoft Azure (Part 9)
- Hybrid Network Infrastructure in Microsoft Azure (Part 10)
- Hybrid Network Infrastructure in Microsoft Azure (Part 11)
In part 1 of this series, I began the discussion about hybrid network infrastructure with some thoughts regarding what hybrid clouds are about, and then talked about some of the networking functionality that you get when you adopt Azure Infrastructure Services. There was also an introduction to the Datacenter Extension Reference Architecture Diagram that Tom put together with Jim Dial and several other people at Microsoft.
In part 2 of the series, Tom joined in as co-author and we went over site to site VPNs and point to site VPNs. In part 3 we took a look at the Azure dedicated WAN link service, which goes by the name of ExpressRoute, and also discussed the Azure Virtual Gateway, which is located on the edge of your Azure Virtual Network and enables you to connect your on-premises network to an Azure Virtual Network.
Then in 4, we spent the bulk of our time discussing what Azure Virtual Networks are and how they compare to the virtual networks we use in traditional on-premises Hyper-V installations. Part 5 went into a little more detail on Azure Virtual Networks and some special considerations you need to take into account.
This past month, Tom transitioned to a new position that is an exciting opportunity but it’s requiring more of his time to get up to speed, so I’ll be back finishing up this series without his collaboration (although probably not without his input).
In this, Part 6, I’ll continue with the discussion of Azure Virtual Networks as we keep working our way through our list of network capabilities that are available in Azure at the time this article was written (always keeping in mind that Azure is constantly changing and growing and adding new functionalities):
√ Site to site VPNs
√ Point to Site VPNs
√ Dedicated WAN links
√ Virtual network gateways
√ Azure Virtual Networks
> Inter-virtual Network connectivity
- External load balancers
- Internal load balancers
- Network Security Groups
- Virtual machine ACLs
- Third party proxy firewalls
- Dual-homed
- Dedicated public IP addresses
- Static IP addresses on virtual machines
- Public addresses on virtual machines
- DNS
Let’s move down the list and talk about inter-virtual network connectivity and external load balancing.
Inter-virtual Network Connectivity
In the last couple of articles in this series, we introduced the concept of the Azure Virtual Network – what it is, how you use it and some of the things you need to be aware of so that you stay out of trouble when using them. Azure Virtual Networks are the places where you will put your Azure virtual machines when you want them to connect to each other using traditional networking concepts and technologies.
Similarly to the way it is with any other networks that you can connect to one another, you can connect Azure Virtual Networks to other Azure Virtual Networks. Connecting Azure Virtual Networks to each other is similar to the way you might configure multiple logical network segments in a virtualized environment. For example, if you’re using Hyper-V, you can create multiple virtual networks that represent different logical collision domains and create a routed connection between those networks by using an inline network device, such as a firewall or layer 3 router. The routing device would have interfaces connected to each of the networks.
It’s not quite the same when you connect Azure Virtual Networks to each other. You can’t use a multi-homed virtual network device to connect different Azure Virtual Networks. Instead, you will need to create site-to-site VPN connections between all of the networks. In order to do this, you create a VPN gateway at the “edge” of each of the Azure Virtual Networks and then you connect the gateways to each other. The VPN gateways act in the role of a VPN router.
The concept and practice of site-to-site VPN isn’t new, and using site-to-site VPNs to connect Azure Virtual Networks to one another is very similar to any site-to-site VPN configuration you’ve done in the past. The difference is that you have to do it using mechanisms that are specific to Azure networking.
Understanding site to site connections
Here are a few key things that you need to know about the site-to-site connections that are used for connecting Azure Virtual Networks:
- IPsec tunnel mode is the VPN protocol used for these site-to-site VPNs. Gone are the days of PPTP and L2TP/IPsec for site-to-site VPN connectivity.
- The Azure Virtual Networks that you connect don’t have to be part of the same Azure subscription; you can connect Azure Virtual Networks that belong to different subscriptions.
- You can connect multiple Azure Virtual Networks to other Azure Virtual Networks. For example, you can connect Azure Virtual Network “1” to up to 10 other Azure Virtual Networks, and you can connect Azure Virtual Network “2” to up to 10 other Azure Virtual Networks, which can include Azure Virtual Network “1” if you like.
- The methodology that is used to connect Azure Virtual Networks to each other is similar to what you use when you connect an on-premises network to an Azure Virtual Network. However, you don’t have to connect your on-premises network to an Azure Virtual Network in order to connect Azure Virtual Networks to each other.
- Since the connection between the Azure Virtual Networks is a routed connection, you have to make sure that you’re using different network IDs on each of the connected networks, because otherwise routing won’t work.
- You need to take into account bandwidth issues at the level of the VPN gateway/router. Like any other VPN gateway, it has bandwidth limits. If you have multiple site-to-site VPN connections on the same VPN gateway, the bandwidth that is used for all the connections goes through that router and could cause you to hit the limits of the gateway (which is 100Mbps or 200Mbps depending on whether you are using the default gateway or are paying extra for the high-performance gateway).
You can learn more about inter-virtual network connectivity and how to connect virtual networks to each other by going to Configure a VNet to VNet Connection on Microsoft’s Azure web site.
External Load Balancers
Azure has two kinds of load balancers: internal load balancers and external load balancers. The external load balancers are also called “Internet Facing Load Balancers”. Similar to the load balancers that you use on-premises, you can use the external load balancers to load balance incoming connections from the Internet to virtual machines or cloud services contained within Azure.
External load balancers
The Azure external load balancer is an OSI transport layer load balancer and therefore it will load balance incoming TCP and UDP connections. Incoming connections to the public IP address exposed for a cloud service or virtual machine will be forwarded to the private IP address that is used by the virtual machine or cloud service on the Azure network. The load balancing algorithm uses a 5-tuple hash (5 different values) to map traffic to destination servers. This enables connections for the same transport layer session to be redirected to the same server within the Azure network.
Health monitoring
You can also take advantage of health monitoring when performing load balancing. Health monitoring is important because you shouldn’t load balance connections to virtual machines or cloud services elements that are offline. There are three ways that you can accomplish health monitoring when using an external load balancer in Azure:
- Guest Agent Probe – this is available only on Azure PaaS virtual machines (no load balancing health agent is available for Azure IaaS virtual machines). The guest agent will probe the web site using HTTP and if there is no HTTP 200 OK returned, then it marks the server as down and stops sending traffic to it.
- HTTP Custom Probes – this is another option that allows you to programmatically customize your probes by leveraging the Guest Agent.
- TCP Custom Probes – with this option you can use any TCP port you like to determine if the virtual machine or service is available.
When a load balanced virtual machine or service initiates an outbound connection, it uses Source NAT with the same virtual IP address that’s used for incoming connections. In addition, it takes advantage of full cone NAT for UDP, so that inbound connections can be accepted from any external host in response to an outbound request from the Azure virtual machine or cloud service.
One thing that you have to watch out for is source port exhaustion. This can be a problem if your virtual machine or cloud service is going to make a lot of outgoing connections. If you anticipate such a scenario, you should take advantage of the Azure Instance Level Public IP Addresses, a feature that allows you to have a dedicated IP address assigned to your VM or service.
You can learn more about external load balancing by going to the article “Load Balancer Overview”.
Summary
In this, part 6 in our series on Azure networking and network services, we went over Azure inter-network connectivity and Azure external load balancing. You can connect Azure Virtual Networks to each other using VPN gateways on each of the Azure Virtual Networks. The VPN gateways act as VPN routers and allow routed connections between Azure Virtual Networks. Note that unlike virtual network routing you might do on your own virtualization platform on-premises, you can’t use multi-homed machines on an Azure Virtual Network to connect different Azure Virtual Networks together.
Azure external load balancing allows you to load balance incoming connections to Azure virtual machines or cloud services. The load balancing algorithm uses a 5-tuple to make sure that connections that are part of the same session always go to the same virtual machine or cloud service within Azure. Source NAT is used to make sure that connections are dynamically mapped to a new instance of a virtual machine or cloud service in the event that these become unavailable and have to be moved to a new instance.
If you would like to read the other parts in this article series please go to:
- Hybrid Network Infrastructure in Microsoft Azure (Part 1)
- Hybrid Network Infrastructure in Microsoft Azure (Part 2)
- Hybrid Network Infrastructure in Microsoft Azure (Part 3)
- Hybrid Network Infrastructure in Microsoft Azure (Part 4)
- Hybrid Network Infrastructure in Microsoft Azure (Part 5)
- Hybrid Network Infrastructure in Microsoft Azure (Part 7)
- Hybrid Network Infrastructure in Microsoft Azure (Part 8)
- Hybrid Network Infrastructure in Microsoft Azure (Part 9)
- Hybrid Network Infrastructure in Microsoft Azure (Part 10)
- Hybrid Network Infrastructure in Microsoft Azure (Part 11)
