Cloud networking for architects

Designing networking for Azure IaaS

Optimizing networking for IT workloads hosted in Azure IaaS requires an understanding of Azure virtual networks (VNets), address spaces, routing, DNS and load balancing.

Architecture

Planning

Determine the address space of the VNet

Virtual machines are assigned an address configuration from the address space of the subnet by DHCP:

  • Address/subnet mask

  • Default gateway

  • DNS server IP addresses

You can also reserve a static IP address.

Virtual machines can also be assigned a public IP address

Table shows the address spaces for the different types of VNets.

 

Type of VNet Virtual network address space
Cloud-only Arbitrary private address space
Interconnected cloud-only Arbitrary private, but not overlapping with other connected VNets
Cross-premises Private, but not overlapping with on-premises
Interconnected cross-premises Private, but not overlapping with on-premises and other connected VNets

Determine the subnets within the VNet and the address spaces assigned to each

There are two types of subnets in a VNet, a gateway subnet and a virtual machine-hosting subnet.

The Azure gateway subnet is needed by Azure to host the two virtual machines of your Azure gateway. Specify an address space with at least a 29-bit prefix length (example: 192.168.15.248/29). A 28-bit or smaller prefix length is recommended, especially if you are planning to use ExpressRoute.

A best practice for determining the address space of the Azure gateway subnet is the following:

  1. Decide on the size of the gateway subnet.

  2. In the variable bits in the address space of the VNet, set the bits used for the gateway subnet to 0 and set the remaining bits to 1.

  3. Convert to decimal and express as an address space with the prefix length set to the size of the gateway subnet.

With this method, the address space for the gateway subnet is always at the farthest end of the VNet address space.

Here is an example of defining the address prefix for the gateway subnet: The address space of the VNet is 10.119.0.0/16. The organization will initially use a site-to-site VPN connection, but will eventually get ExpressRoute. Table 2 shows the steps and results of determining the gateway subnet address prefix in network prefix notation (also known as CIDR).

Virtual machine-hosting subnets are where you place Azure virtual machines, which you can do according to typical on-premises guidelines, such as a common role or tier of an application or for subnet isolation.

Azure uses the first 3 addresses on each subnet. Therefore, the number of possible addresses on an Azure subnet is 2n - 5, where n is the number of host bits. Table 3 shows the range of virtual machines required, the number of hosts bits needed, and the corresponding subnet size.

Here are the steps and example of determining the gateway subnet address prefix:

  1. Decide on the size of the gateway subnet. For our example, we chose /28.
  2. Set the bits in the variable portion of the VNet address space (b) to 0 for the gateway subnet bits (G), otherwise 1 (V). For our example, we are using the 10.119.0.0/16 address space for the VNet.

    10.119. bbbbbbbb . bbbbbbbb
    10.119. VVVVVVVV . VVVVGGGG
    10.119. 11111111 . 11110000

  3. Convert the result from step 2 to decimal and express as an address space. For our example, 10.119. 11111111 . 11110000 is 10.119.255.240, and with the prefix length from step 1, (28 in our example), the resulting gateway subnet address prefix is 10.119.255.240/28.
Virtual machines required Host bits Subnet size
1-3 3 /29
4-11 4 /28
12-27 5 /27
28-59 6 /26
60-123 7 /25

 

Determine the DNS server configuration and the addresses of the DNS servers to assign to VMs in the VNet

Azure assigns virtual machines the addresses of DNS servers by DHCP. DNS servers can be:

  • Supplied by Azure: Provides local name registration and local and Internet name resolution

  • Provided by you: Provides local or intranet name registration and either intranet or Internet name resolution

 

Table shows the different configurations of DNS servers for each type of VNet.

 

Type of VNet DNS server
Cloud-only Azure-supplied for local and Internet name resolution
Azure virtual machine for local and Internet name resolution (DNS forwarding)
Cross-premises On-premises for local and intranet name resolution
Azure virtual machine for local and intranet name resolution (DNS replication and forwarding)

Determine the load balancing configuration (Internet-facing or internal)

In some cases, you want to distribute incoming traffic to a set of servers that have the same role. Azure IaaS has a built-in facility to do this for Internet-facing and internal traffic loads.

Azure Internet-facing load balancing randomly distributes unsolicited incoming traffic from the Internet to the members of a load-balanced set.

Azure internal load balancing randomly distributes unsolicited incoming traffic from other Azure VMs or from intranet computers to the members of a load-balanced set.

Determine the use of virtual appliances and user-defined routes

If you need to forward traffic to virtual appliances in your VNet, you may need to add one or more user-defined routes to a subnet.

 

Determine how computers from the Internet will connect to virtual machines

There are multiple ways to provide Internet access to the virtual machines on a VNet, which includes access from your organization network through your proxy server or other edge device.

Method Deployment model
1. Endpoints and ACLs configured on cloud services Classic
2. Network security groups Resource Manager and classic
3. Internet-facing load balancer with inbound NAT rules Resource Manager
4. Network security appliances in the Azure Marketplace (not shown) Resource Manager and classic

Additional security is provided by:

  • Remote Desktop and SSH connections, which are authenticated and encrypted.

  • Remote PowerShell sessions, which are authenticated and encrypted.

  • IPsec transport mode, which you can use for end-to-end encryption.

  • Azure DDOS protection, which helps prevent external and internal attacks

 

an Internet-connected computer connecting to a virtual machine in a cloud service using an endpoint, a virtual machine on a subnet using a network security group, and a virtual machine on a subnet using an external load balancer and inbound NAT rules

For multiple VNets, determine the VNet-to-VNet connection topology

VNets can be connected to each other using topologies similar to those used for connecting the sites of an organization.

A daisy chain configuration connects the VNets in a series.

A spoke and hub configuration connects multiple VNets to a set of central VNets, which are themselves connected to each other.

A full mesh configuration connects every VNet to each other.

Additional planning for a cross-premises VNet

Determine the cross-premises connection to the VNet (S2S VPN or ExpressRoute)

You can connect to VMs in a VNet in the following ways:

  • Administration of VNet VMs from your on-premises network or the Internet

  • IT workload access from your on-premises network

  • Extension of your network through additional VNets

Security for connections is provided by the following:

  • P2S uses the Secure Socket Tunneling Protocol (SSTP)

  • S2S and VNet-to-VNet VPN connections use IPsec tunnel mode with AES256

  • ExpressRoute is a private WAN connection

Type of connection Purpose
Site-to-Site (S2S) VPN Connect 1-10 sites (including other VNets) to a single VNet.
ExpressRoute A private, secure link to Azure via an Internet Exchange Provider (IXP) or a Network Service Provider (NSP).
Point-to-Site (P2S) VPN Connects a single computer to a VNet.
VNet peering or VNet-to-VNet (V2V) VPN Connects a VNet to another VNet.

 

Determine the on-premises VPN device or router

Your on-premises VPN device or router acts as:

  • An IPsec peer, terminating the S2S VPN connection from the Azure gateway.

  • The BPG peer and termination point for the private peering ExpressRoute connection.

a cross-premises VNet connected to an on-premises VPN router or device

Add routes to your intranet to make the address space of the VNet reachable

Routing to VNets from on-premises consists of the following:

  1. A route for the VNet address space that points toward your VPN device.

  2. A route for the VNet address space on your VPN device that points across the S2S VPN or ExpressRoute connection

shows the routing information needed by the on-premises routers and the VPN router or device that represents the address space of the VNet

For ExpressRoute, plan for the new connection with your provider

ou can create an ExpressRoute connection with private peering between your on-premises network and the Microsoft cloud in three different ways:

  • Co-located at a cloud exchange

  • Point-to-point Ethernet connections

  • Any-to-any (IP VPN) networks


Determine the Local Network address space for the Azure gateway

For the routing to on-premises or other VNets from a VNet, Azure forwards traffic across an Azure gateway that matches the Local Network address space assigned to the gateway.

You can define the Local Network address space in the following ways:

  • Option 1: The list of prefixes for the address space currently needed or in use (updates might be needed when you add new subnets).

  • Option 2: Your entire on-premises address space (updates only needed when you add new address space).

Because the Azure gateway does not allow summarized routes, you must define the Local Network address space for option 2 so that it does not include the VNet address space

Here is an example of defining the prefixes for the Local Network address space around the address space "hole" created by the VNet:

  • An organization uses portions of the private address space (10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16) across their on-premises network. They chose option 2 and 10.100.100.0/24 as their VNet address space.
shows a cross-premises VNet and an ExpressRoute connection from an on-premises router to Microsoft Azure

shows a cross-premises VNet and the Local Network address space on the Azure gateway, which represents the reachable address space on the on-premises network
shows the steps and resulting prefixes that define the Local Network address space for this example
Step Results
1. List the prefixes that are not the root space for the VNet address space. 172.16.0.0/12 and 192.168.0.0/16
2. List the non-overlapping prefixes for variable octets up to but not including the last used octet in the VNet address space. 10.0.0.0/16, 10.1.0.0/16…10.99.0.0/16, 10.101.0.0/16…10.254.0.0/16, 10.255.0.0/16 (255 prefixes, skipping 10.100.0.0/16)
3. List the non-overlapping prefixes within the last used octet of the VNet address space. 10.100.0.0/24, 10.100.1.0/24…10.100.99.0/24, 10.100.101.0/24…10.100.254.0/24, 10.100.0.255.0/24 (255 prefixes, skipping 10.100.100.0/24)

 




Configure on-premises DNS servers for DNS replication with DNS servers hosted in Azure

To ensure that on-premises computers can resolve the names of Azure-based servers and Azure-based servers can resolve the names of on-premises computers, configure:

  • The DNS servers in your VNet to forward to on-premises DNS servers

  • DNS replication of the appropriate zones between DNS servers on-premises and in the VNet


Determine the use of forced tunneling

The default system route for Azure subnets points to the Internet. To ensure that all traffic from virtual machines travels across the cross-premises connection, create a routing table with the default route that uses the Azure gateway as its next-hop address. You then associate the route table with the subnet. This is known as forced tunneling.

shows a cross-premises VNet with DNS servers in the on-premises network and on a subnet in the VNet. DNS replication and forwarding has been configured between the two DNS servers

shows a cross-premises VNet with a user-defined route for a subnet pointing to the Azure gateway