Hyper-V: MAC Address allocation and apparent network issues MAC collisions can cause
In a physical only world, you don’t usually have to worry about MAC addresses that much as each NIC vendor carves off a MAC address from their ranges which have been allocated to them. However, in a virtual environment, you have to be a little more careful, particularly if you are using dynamic MAC address assignment. This post looks at how Hyper-V allocates dynamic MAC addresses and some potential problems you can face. So often it can be the last thing people think to check, but can be the root cause of otherwise unexplained network oddities.
Here’s a screenshot of a typical MAC collision problem – pings sometimes work, sometimes fail – and this is all on a local isolated network.
To start the walkthrough, I have a base install of Windows Server 2008 on a server with a single physical NIC – against best practice, but it serves fine for demonstration. I have already installed the RTM update (KB950050) to the server, but have not yet added the Hyper-V role. Let’s look at an output of “ipconfig /all”. You can see that the MAC address of the physical NIC is 00-13-20-F5-F8-7D and I’m obtaining an IP address from a DHCP server on the private test network I’m using.
Now let’s use Server Manager to enable the Hyper-V role. Note that Server Manager allows you to create an external virtual network switch during role enabling, but I am choosing not to do this. Let’s see what has happened in the registry after the Hyper-V role is enabled. Specifically, I’m looking at two keys which have been created under HKLM\Software\Microsoft\Windows\NT\CurrentVersion\Virtualization, as-yet unpopulated: MinimumMacAddress and MaximumMacAddress, plus another key in the worker node, CurrentMacAddress – again as-yet unpopulated. (The astute walking through this in front of a machine will notice that CurrentMacAddress also appears in the Virtualization node. That key is not used though.)
Next, I’m going to create my first virtual machine. As I haven’t created any virtual network switches yet, I’ll leave the network disconnected. I don’t need a hard disk. Also, I’m deliberately choosing not to start it. Let’s see what’s happened in the registry. MinimumMacAddress and MaximumMacAddress have been populated with 00-15-5d-c8-6a-00 and 00-15-5d-c8-6a-ff respectively – a range of 256 possible MAC addresses.
So where did this range come from? The first three bytes are the Microsoft IEEE Organizationally Unique Identifier, 00-15-5D which we use in Hyper-V. The next two bytes, C8-6A are derived from the lowest two octects of an IPv4 address on the server (the first IP address as NICs are enumerated). If you look at the second screenshot in this post, the IPv4 address on the only NIC on this server was 192.168.200.106. In Hex, this is “C0.A8.C8.6A”. The last two octets or bytes are C8 and 6A. The last byte of the address range is automatically generated with a minimum 00 and maximum FF.
You can probably now realize, that while this algorithm will work for many people, it may not necessarily be perfect and cause MAC address range clashes. To cope with multiple Hyper-V enabled servers, you would need to ensure address ranges are managed at a higher level across those servers, such as the use of SCVMM.
Let’s go back to the virtual machine I created. By default, when a virtual machine is created, it is allocated a dynamic MAC address. This can of course be changed in the settings for the virtual machine. Here’s the setting for the blank virtual machine. Notice that it’s set to Dynamic and the MAC address in the “Static” boxes show 00-00-00-00-00-00
Now I’m going to start the Virtual Machine and open the settings. Although some settings cannot be changed while a virtual machine is running (including changing static/dynamic MAC, or the static MAC itself), notice that the boxes under the static MAC address radio button are now populated with the first MAC address in the range defined in the registry: 00-15-5D-C8-6A-00.
Now for a bit of fun (and to make the walkthrough a bit simpler), let’s change the registry so that the maximum MAC address is 00-15-5D-C8-6A-02. (I’ll also do a reboot just to make sure the change takes effect) This change means that we are limited to three possible dynamically assigned MAC addresses, the last octet being 00 (in use by the “Blank” VM), 01 or 02.
Now, I’m going to create another virtual machine named 6A-01 and power it on, then create a third virtual machine named 6A-02 and power that on too. Let’s look at the settings for each of these while all three virtual machines are running. As expected 6A-01 has a MAC address ending 6A-01 and 6A-02 has a MAC address ending 6A-02. That’s why we have the “CurrentMacAddress” registry key to track what MAC address to assign to VMs in turn.
Can you guess though at this point what would happen though if I create another virtual machine and power it on? I don’t have any MAC addresses left in my available range and all MAC addresses are currently in use.
Did you guess correctly? Let’s now power off the very first virtual machine (“Blank”) I created with MAC address 6A-00, and then try to run through the New Virtual Machine Wizard again with my “No MAC Addresses Available In Range” virtual machine. Try to guess what will happen at the end.
The virtual machine starts successfully and now has a duplicate MAC address to the first virtual machine I created, ‘Blank’:
Last quiz question: What would happen then if I tried to start “Blank” – will it start or not? After all, it has already been allocated a MAC address ending 6A-00.
Actually, we will detect this as you can see above and stop the virtual machine from powering on. So in some ways, on a single Hyper-V enabled server, we’re relatively immune to duplicate MAC addresses across virtual machines running on a single server. However, due to the algorithm for choosing the ranges of MAC addresses, while relatively safe, there is no guarantee of being unique across an entire network. And of course, chances are that you will want packets from or to virtual machines on a Hyper-V server to “hit” the physical network.
So hopefully that gives you a better idea why it is important to manage MAC addresses across multiple servers in a virtual machine environment. While the walkthrough above was specific to Hyper-V, the same types of issues could arise in Virtual Server.