In previous part we explored Promiscuous mode policy. In this post, we are going to discuss MAC address Change and Forged Transmit policy settings. Well, these two policies are related to each other. So it is going to make much more sense to discuss both of them together.
As the policy name indicates, ‘MAC address change’ so it sounds something related to MAC addresses. So why not talk about them first.
As we all know MAC addresses are supposed to be globally unique. And that is true when it comes hardware network adapters. However, What about virtual adapters in virtualization?
- Can there be duplication of MAC address?
- It is possible in virtualized environment.
- Are there any types of MAC addresses?
- Yes we do have types of MAC addresses
Now that makes it interesting and important as well to know more about it.
So first of all, we will understand concepts related to MAC Address Types in virtual networking. By the way, I am not referring to Static or Dynamic allocation of MAC addresses. Understanding MAC address types and possibilities of changing MAC address is quite important before we talk about Forged transmit or MAC address change policies.
Anyway, isn’t that sound bit odd? I mean types of MAC addresses, are there any types as such?
As mentioned earlier, indeed we have. There are three types of MAC addresses from operational point of view in virtual networking as listed below. In fact it is applicable in physical networking too.
- Initial MAC address:
- Initial MAC address is assigned to a virtual machine (static or dynamic assignment) by vCenter Server or ESXi host and written into VMX file of virtual machine.
- This MAC address is similar to the MAC address of Physical ethernet card which is hardcoded into the card.
- However, there is possibility of changing the initial MAC address of a VM by editing VMX file unlike physical card MAC address which is Burned-in Address (BIA) on the Card.
- Generally vCenter Server assigns the MAC address to a virtual machine but ESXi also can assign it in the event, vCenter Server is not available.
- There are methods such as OUI (default), Range based and Prefix based that can be used to generate the MAC address.
- Effective MAC address:
- This is the MAC address which operating system reads during boot process from hardware configuration in VMX file and uses it to communicate.
- So this type of MAC address is going to be the same most of the time as your Initial MAC address.
- Why not 100%? We will see this with an example of Microsoft NLB shortly.
- Runtime MAC address:
- Runtime MAC address is the address that is presented to switch port.
Let’s understand MAC changes with an example of Windows NLB in unicast mode.
If you look at the diagram above, I have two Windows server VMs Web server 1 (MAC: 00:50:56:XX:XX:0B) and Web Server 2 (MAC: 00:50:56:XX:XX:0A) configured as web servers in Windows NLB cluster that host web.demo.local as some local (LAN) website. Now the caveat is, when users are going to connect to this website, which address they are resolved to? Obviously to the NLB Cluster virtual IP as your DNS IP address records points to it. Now there is interesting theory here. Let’s jump into it.
When NLB cluster is formed, it is configured with virtual IP and virtual MAC address is generated for it. As we know, MAC address is used to deliver the traffic in LAN. So every time, users are trying to connect to the website, they send traffic to the virtual MAC address of NLB cluster.
But this virtual MAC address is not physically connected on any switch. Since switch performs MAC learning (in physical switch, virtual switch does not need to perform learning), this virtual MAC address of NLB cluster will not be recognised by switch during learning process as it is not connected physically to any switch. And it is not updated in MAC table. So then, how the traffic gets delivered?
All hosts in the NLB cluster use the same MAC Address (virtual MAC, in fact, same IP address (VIP) as well). Each NLB cluster member server Operating System replaces its MAC address (Effective MAC not initial MAC) with virtual MAC Address that was generated by the NLB. So basically, each server in the NLB cluster uses the same virtual MAC address of a NLB cluster.
This puts switch into a situation. Since the virtual MAC is being used by multiple member servers, a switch will not be able to determine the port for the virtual MAC address of NLB cluster. Switch is forced to send the frames that are destined to NLB MAC address to all switch ports on the switch to make sure frames reach the correct destination.
So basically Unicast mode forces switch flooding, where all switch ports are flooded with NLB traffic, even to the ports that are used by non-NLB cluster servers.
So to summarise this, as per our scenario, when users receive frames, frame has source address as virtual MAC of NLB. So while responding, they will send data to virtual MAC of NLB as destination. And as described above, switch is forced to send packets to all ports. This is true not only in virtual but physical networking environment as well.
Ok that clears some air about these concepts. Now that we are through with it, let’s look at the policies MAC address change and Forged transmit.
We can set these two policies to Accept or Reject. In standard switches, they are set to Accept by default however in DVS, they are set to Reject by default. What does these Accept and Reject setting mean?
MAC address change:
This policy affects traffic that is incoming to a virtual machine from switch.
When the Mac address change is set to Accept, ESXi accepts the requests to change the effective MAC address to an address other than the initial MAC address. Typically, we don’t want this to happen as any malicious user can impersonate MAC address of the VM for some unethical purpose. However, there are use cases as well where we do this intentionally. Such as with Microsoft Network Load Balancing (NLB) in unicast mode where it is mandatory to use it.
Another use case can be of iSCSI initiator that relies on being able to get MAC address changes from certain types of storage. If you are using ESXi iSCSI with iSCSI storage, set the MAC address changes option to Accept.
When the Mac address change option is set to Reject, ESXi does not accept requests to change the effective MAC address to an address which is other than the initial MAC address.
Reject setting protects the host against MAC impersonation. The port that the virtual machine adapter used to send the request is disabled and the virtual machine adapter does not receive any more frames until the effective MAC address matches the initial MAC address.
Forged Transmits
The Forged transmits option is applicable for traffic that is transmitted from the virtual machine to the virtual switch.
When the Forged transmit option is set to Accept, ESXi does not compare source MAC address and effective MAC address. And hence the traffic is allowed.
If Forged transmit option is set to Reject. The policy will check if the source MAC address field has been tampered with or not. ESXi host compares the source MAC address that is being transmitted by the guest operating system with the effective MAC address of virtual machine adapter to see if they match. If the addresses do not match, the ESXi host drops the packet.
Conclusion:
Use MAC address change and Forged transmits policy options if there is valid use case available. Else it is better to keep reject not only due to security reasons but performance reasons as well which are caused due to switch flooding.
Next post in this series, Traffic shaping policy.