VIPs, DIPs and PIPs in Microsoft Azure

A virtual machine (VM) deployed into Microsoft Azure is associated with several types of IP address. These are:

• VIP – virtual IP address
• DIP – dynamic IP address
• PIP – instance-level public IP address

The DIPs are private to the VNET or cloud service in which the VM is hosted, while the VIP and the PIP are exposed on the internet. A VM may have endpoints configured on it describing how traffic should be load balanced before being routed to the VM.

Azure supports two types of load balancer: the Azure Load Balancer associating a VIP/port combination with a DIP/port combination on the VM; and the Internal Load Balancer associating a DIP/port combination on the load balancer with the DIP port/combination on a VM.

Azure supports Network Security Groups which can be used to allow and deny traffic flowing in or out of a VNET, between subnets, and in or out of a VM. It also supports Endpoint Access Control Lists to restrict traffic arriving at the VIP.

This post describes the features provided by VIPs, DIPS and VIPs.

VIP

A VIP is the public IP address associated with a VM. Every Azure VM has a VIP, with all the VMs in a cloud service having the same VIP. The VIP is allocated at random from a pool of IP addresses managed by Microsoft. However, it is possible to reserve an IP address from the Microsoft pool and allocate that reserved IP address as a VIP. There is a limit of 5 reserved IPs for a subscription. Unless a reserved IP address is used, the VIP is given up and returned to the Microsoft pool once the last VM with that VIP is deallocated or deleted. Internet-bound traffic coming from the VM is SNATted to have the VIP be its source address.

DIP

A DIP is an internal IP address associated with a VM. This IP address is associated automatically with the VM when it is created and remains associated with it while it is deployed. The DIP survives system reboots as well as service healing migration of the VM. If the VM is deleted or changed into a stopped/deallocated state it loses its DIP, which may then be allocated to another VM.

DHCP is used to provide the DIP to the VM on a near-infinite lease. The address comes either from the range configured for the subnet the VM is deployed into or from a private range provided by Microsoft.

Alternatively, the DIP can be a static IP address allocated to the VM on creation. This address comes from the range configured for the subnet the VM is deployed into. It is a good practice to use a distinct subnet for statically-allocated DIPs to avoid the possibility of collision between a dynamically and statically allocated DIP.

Azure supports the ability for a VM to have multiple virtual NICs, with each NIC being allocated a distinct DIP. This multi-NIC feature is useful for virtual appliances exposing DIPs in distinct subnets or for providing distinct backplanes for traffic into a VM (such as for management). A VM always has a default NIC but may have zero or more secondary NICs depending on its instance type, as described in the following table:

Note that A8 and A9 instances also have a 32 Gbps InfiniBand network, but this requires the use of special HPC APIs.

PIP

A PIP is a public instance-level IP address associated with the VM in addition to the VIP. Traffic to the PIP goes directly to the VM and is not routed through the Azure Load Balancer. Internet-bound traffic from a VM with a configured PIP is also sent over the PIP rather than going through the VIP. Consequently, there is no need to configure an endpoint when using a PIP. The PIP must be appropriately firewalled to restrict traffic to only that desired. A PIP is useful for workloads such as passive FTP that require a large number of ports to be opened, which is impractical when using the VIP which supports only a limited number of endpoints.

Endpoint

An endpoint associates a DIP/port combination on a VM with a port on either the Azure Load Balancer for public-facing traffic or the Internal Load Balancer for traffic inside a VNET (or cloud service). Distinct endpoints are configured for the TCP and UDP protocols. Azure supports two types of endpoint: port-forwarded and load-balanced.

A port-forwarded endpoint provides a unique association between a port on the load balancer and the default DIP/port combination for a VM.

A load-balanced endpoint uses a hash-based algorithm to distribute traffic destined for a specific port on the load balancer to a specific default DIP/port combination on any of the VMs configured to share this endpoint. Azure supports three distribution algorithms for a load-balanced endpoint:

• default – routes traffic based on source IP, source port, destination IP, destination port and protocol
• sourceIP – routes traffic based on source IP and destination IP
• sourceIPProtocol – routes traffic based on source IP, destination IP and protocol

sourceIP and sourceIPProtocol are supported only on the Azure Load Balancer. They are intended to support legacy applications requiring “session affinity” where traffic from a particular source should always be routed to the same VM. The default algorithm is a more suitable choice in a horizontally-scaled environment.

When a load-balanced endpoint is configured it is advisable to also configure a load-balancer probe which sends periodic probes to a configured http URL or TCP port on each VM in the load-balanced set. If the probe fails to get an appropriate response in a configured time interval then the VM is taken out of load-balancer rotation – i.e., no traffic is distributed to it.

Azure Load Balancer

All inbound traffic to the VIP is routed through the Azure Load Balancer which firewalls and distributes it. The Azure Load Balancer only allows inbound traffic to reach a VM if there is a configured endpoint which maps some port on the VIP to a port on the DIP. The Azure Load Balancer supports only the TCP and UDP protocols, all other internet protocols are denied.

The Azure Load Balancer supports all three methods of distributing load-balanced traffic: default, sourceIP and sourceIPProtocol.

Internal Load Balancer

An Internal Load Balancer can be configured to port-forward or load-balance traffic inside a VNET or cloud service. The Internal Load Balancer supports only the TCP and UDP protocols, all other internet protocols are denied.

The Internal Load Balancer only supports the default mechanism for distributing load-balanced traffic – i.e., source IP, source port, destination IP, destination port and protocol.

Network Security Groups

A Network Security Group (NSG) is created in a specified region for an Azure subscription. It comprises a set of allow/deny rules regulating the flow of traffic between a specified source and destination. The source comprises a specific IP range, port range and protocol. The destination similarly comprises a specific IP range, port range and protocol. The IP range can be expresses as a CIDR value or one of a set of special values indicating the INTERNET, VIRTUAL_NETWORK, or AZURE_LOADBALANCER (to allow load-balancer probes).

Once created a Network Security Group can be associated with subnets or VMs in the subscription and provide the ability to control the flow of traffic:

• through the Azure Load Balancer to and from a VNET
• between two subnets in a VNET
• in and out of the default NIC of a VM

Only one NSG may be associated with a subnet or VM. However, these can be different so traffic to a VM could be filtered through an NSG on the subnet and an NSG on it. Note that an NSG only affects the default NIC on a VM.

The use of Network Security Groups therefore allows the sophisticated control of traffic flowing through a VNET. Specifically, it can be used to prevent any traffic leaving a VNET.

Endpoint Access Control List

An Endpoint Access Control List (ACL) can be configured for an endpoint associated with either the Azure Load Balancer or the Internal Load Balancer. This list comprises a set of allow/deny rules declaring that specific IP ranges are allowed or denied access to the endpoint. An ACL only affects traffic inbound to the endpoint and has no impact on traffic going out through the load balancer.

Note that Endpoint ACLs and NSGs are orthogonal features and cannot be applied simultaneously to the same VM.