Networking in Microsoft Azure – Part I

When moving into public cloud a lot of concepts that IT Pro’s use daily change, e.g. coping with elasticity, auto-scaling, micro-services rapid deployment, API’s. All of this requires a change of the mindset. One of these components that changes it networking. Public Cloud introduces subtle changes in networking that are often overlooked.

Age’s ago when I started learning about networking I was served the book from Andrew S. TanenbaumComputer Networks as the bible. Reference works like these might sound dry and hard to digest but provide a solid foundation you can build on. Maybe you have read this book as well or remember the OSI model from somewhere else. When talking about Public Cloud think about the two bottom layers: physical and datalink layers.

In Microsoft Azure you have the concept of a virtual network (VNET) in which you have subnets. Your virtual machines, services are deployed in the subnets.

Let’s do a little exercise and think about the below images. Both of these command prompts screenshots are coming from Windows Server 2012 R2 systems.

The first one is taken from a system on-premise with a high available firewall cluster. The network range is 172.31.0.0/24, the default gateway is 172.31.0.1 (cluster member 1: 172.31.0.2) and then you have the 172.31.0.10 which is another host on the network. The Windows host I took this screenshot from is on 172.31.0.102.

The second screenshot is taken on a host in Azure with the IP address 172.16.56.5. There is another host at 172.16.56.4 and the default gateway is at 172.16.56.1.

The big question now is what is the difference between the on-premise and the public cloud output. Can you spot the 6 differences? If you want to have a look don’t scroll further down for now.

.

.

.

.

.

.

.

The answer to the exercise above is the mac address in Azure. Every ARP request you send out on a Azure Virtual Network asking the MAC address for a specific IP address is always answered with the same simple MAC address: 12:34:56:78:9a:bc. On-premise this would never work because every devices that has a ethernet enabled networking stack will have a different MAC address. Each vendor has it’s own range of MAC addresses. You can lookup the vendor in list or on websites like this one.

Why is it that Azure always gives your host the same MAC back. That is because you are on a shared platform and the Virtual Network or VNET is a Layer 3 overlay instead of Layer 2 on the OSI model where you have the datalink layer. You can’t change a VM or other devices on the Azure platform and put this on a different switch port. That power was removed from you as a user and Microsoft created an abstraction layer on top of their infrastructure. You can read more about this on the following FAQ from Microsoft.

This has far reaching implications for software and appliances migrating into the Public Cloud space.

Recent Posts

jvhoof Written by:

One Comment

  1. Ehsan
    February 5, 2021
    Reply

    Thanks for sharing this. MAC address conflicts were bothering me and I couldn’t find the reason.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.