Options
Windows NLB Unicast with VMWare and 'Notify Switches'
Ov3r_Dr1v3
Member Posts: 6 ■□□□□□□□□□
Hi All,
Am just looking for a discussion around implementing Windows NLB in unicast mode within an ESXi cluster. I have read about the topic and am now trying to implement this in my lab as part of my studies. While it works fine, it is not working exactly how I expect it to work given what I have read.
Setup
From what I have read, when using Windows NLB in unicast mode you must:
Now, my understanding is that with 'Notify Switches' set to Yes (the default behavior), when certain operations occur on the VM such as powering on or VMotion, it will send a RARP to the physical switch which will then update its MAC table with the new port to forward traffic out of. This minimises the impact of vmotion, and without it the physical switch would have to wait to learn the new port to forward out of.
When I perform a vmotion of either NLB VM, my physical switch is learning the unicast MAC address. The MAC address table then expires after 5 minutes.
What I'm not quite getting is why this is occurring even though I have set 'notify switches' to no.
Any insight into this behavior, or perhaps where my understanding has gone wrong would be much appreciated.
Best Regards
Am just looking for a discussion around implementing Windows NLB in unicast mode within an ESXi cluster. I have read about the topic and am now trying to implement this in my lab as part of my studies. While it works fine, it is not working exactly how I expect it to work given what I have read.
Setup
- Two ESXi 5.1 hosts (SP-ESX-01 and SP-ESX-02). Both connected to the same Cisco switch.
- A distributed switch with two uplinks per host. VLAN's 100-102 trunked from the Cisco switch. Ports groups setup for each VLAN.
- Two Windows Server 2008 R2 VM's with NLB setup in unicast mode (unicast MAC is 02:bf:c0:a8:64:a0).
- Both VM's are connected to the protgroup 'VLAN100', which is setup to accept traffic on VLAN 100.
From what I have read, when using Windows NLB in unicast mode you must:
- Enable 'MAC Address Changes' and 'Forge Transmits' on the port group
- Set 'Notify Switches' to No.
Now, my understanding is that with 'Notify Switches' set to Yes (the default behavior), when certain operations occur on the VM such as powering on or VMotion, it will send a RARP to the physical switch which will then update its MAC table with the new port to forward traffic out of. This minimises the impact of vmotion, and without it the physical switch would have to wait to learn the new port to forward out of.
When I perform a vmotion of either NLB VM, my physical switch is learning the unicast MAC address. The MAC address table then expires after 5 minutes.
What I'm not quite getting is why this is occurring even though I have set 'notify switches' to no.
Any insight into this behavior, or perhaps where my understanding has gone wrong would be much appreciated.
Best Regards