Virtual Machine with 2 NICs


Colorful Ethernet CableIn Azure Resource Manager (ARM), Network Interface Cards (NICs) are a first class resource.  You can defined them without a Virtual Machine.

UPDATE:  As a reader kingly point out, NIC means Network Interface Controller, not Network Interface Card as I initially wrote.  Don’t be fooled by the Azure logo ;) 

Let’s take a step back and look at how the different Azure Lego blocks snap together to get you a VM exposed on the web.  ARM did decouple a lot of infrastructure components, so each of those are much simpler (compare to the old ASM Cloud Service), but there are many of them.

Related Resources

Here’s a diagram that can help:

image

Let’s look at the different components:

  • Availability Set:  contains a set of (or only one) VMs ; see Azure basics: Availability sets for details
  • Storage Account:  VM hard drives are page blobs located in one or many storage accounts
  • NIC:  A VM has one or many NICs
  • Virtual Network:  a NIC is part of a subnet, where it gets its private IP address
  • Load Balancer:  a load balancer exposed the port of a NIC (or a pool of NICs) through a public IP address

The important point for us here:  the NIC is the one being part of a subnet, not the VM.  That means a VM can have multiple NICs in different subnets.

Also, something not shown on the diagram above, a Network Security Group (NSG) can be associated with each NIC of a VM.

One VM, many NICs

Not all VMs can have multiple NICs.  For instance, in the standard A series, the following SKUs can have only one NIC:  A0, A1, A2 & A5.

You can take a look at https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-windows-sizes/ to see how many NICs a given SKU support.

Why would you want to have multiple NICs?

Typically, this is a requirement for Network Appliances and for VMs passing traffic from one subnet to another.

Having multiple NICs enables more control, such as better traffic isolation.

Another requirement I’ve seen, typically with customer with high security requirements, is to isolate management traffic and transactional traffic.

For instance, let’s say you have a SQL VM with its port 1443 open to another VM (web server).  That VM needs to open its RDP port for maintenance (i.e. sys admin people to log in and do maintenance).  But if both port are opened on the same NIC, then a sys admin having RDP access could also have access to the port 1443.  For some customer, that’s unacceptable.

So the way around that is to have 2 NICs.  One NIC will be used for port 1443 (SQL) and the other for RDP (maintenance).  Then you can put each NIC in different subnet.  The SQL-NIC will be in a subnet with NSG allowing the web server to access it while the RDP-NIC will be in a subnet accessible only from the VPN Gateway, by maintenance people.

Example

You will find here an ARM template (embedded in a Word document due to limitation of the Blog platform I’m using) deploying 2 VMs, each having 2 NICs, a Web NIC & a maintenance NIC.  The Web NICs are in the web subnet and are publically load balanced through a public IP while the maintenance NICs are in a maintenance subnet and accessible only via private IPs.  The maintenance subnet let RDP get in, via its NSG.

The template will take a little while to deploy, thanks to the fact it contains a VM.  You can see most of the resources deployed quite fast though.

If you’ve done VMs with ARM before, it is pretty much the same thing, except with two NICs references in the VM.  The only thing to be watchful for is that you have to specify which NIC is primary.  You do this with the primary property:


"networkProfile": {
  "networkInterfaces": [
    {
      "id": "[resourceId('Microsoft.Network/networkInterfaces', concat(variables('Web NIC Prefix'), '-', copyIndex()))]",
      "properties": {
        "primary": true
      }
    },
    {
      "id": "[resourceId('Microsoft.Network/networkInterfaces', concat(variables('Maintenance NIC Prefix'), '-', copyIndex()))]",
      "properties": {
        "primary": false
      }
    }
  ]
}

If you want to push the example and test it with a VPN gateway, consult https://azure.microsoft.com/en-us/documentation/articles/vpn-gateway-howto-point-to-site-rm-ps/ to do a point-to-site connection with your PC.

Conclusion

Somewhat a special case for VMs, a VM with 2 NICs allow you to understand a lot of design choices in ARM.  For instance, why the NICs are stand-alone resource, why they are the one to be part of a subnet and why NSG are associated to them (not the VM).

To learn more, see https://azure.microsoft.com/en-us/documentation/articles/virtual-networks-multiple-nics/

3 thoughts on “Virtual Machine with 2 NICs

  1. Anonymous

    Don’t take this the wrong way, since you obviously know your stuff, but NIC is actually Network Interface *Controller*. You may already know that. but if you’re posting super accurate information like you normally do, it might be worth mentioning? =/

    Love your posts man. Keep up the great work!

    Reply
  2. Pingback: Azure Weekly: Oct 31, 2016 – Build Azure

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s