Wireless Access

Hi! New to Aruba but not to networking or VMware for that matter. Going to deploy VMC and VMM to VMware for my customer.

I have heard that there are some issues and caveats surrounding the port group security policy settings in VMware (all shoduld be enabled) but are there any particular ramifications that need to be considerd?

Is there any documentation that describe recomended best practices or supported designs regarding this?

Have you seen the virtual appliance installation guide here?  https://support.arubanetworks.com/Documentation/tabid/77/DMXModule/512/Default.aspx?EntryId=34189

Thanks, yes I have but as far as I can see it does not elaborate on the subject, it just says that it must be selected this way.

Putting the vSwitch or Port Group into promiscuous mode allows the VMM or VMC to hear and receive all frames destined to the Port Group or vSwitch, including frames that would otherwise be blocked by L2 security policy applied to the vSwitch, or other types of frames that would traditionally be dropped by the vSwitch by default.

When forged transmits are set to allow, the vSwitch or Port Group will allow the VM to send out frames using a different MAC address than the one assigned to the VM by the hypervisor. Important in this respect is to features like:
• VLANs (dot1q trunking)
• Use of multiple interfaces (If more than gig0/0/1 is used in the data path)
• VRRP (Generated MAC of (00:00:5E:00:01:VRID)
• Multicast (MAC depends on multicast traffic type)

By Enabling MAC Changes this setting allows the VM to change their unicast and allows the device to see other unicast frames. Generally, if
promiscuous mode and forged transmits are enabled this should be set to ‘enable’ as well to allow the VMM or VMC to send or respond to packets sent to it.

@Cordless

Thanks for the dive into the specifics. Are there any caveats to beware of? Would it be better to isolate the VMC/VMM on their own vSwitch to avoid any other issues/risks (whatever they may be, loops?). What about dvSwitches and their portgroups, any other considerations for those?

Hey Borgsquirrel

Feel free to put the VMs into their own virtual port group or vDS and override the settings no there. This reduces any perceived security risk or impact on the other workloads sharing that vDS. 

Also, for VMware people out there, feel free to create two virtual port groups with the same untagged VLAN ID or for vMCs, two or more vPGs with 4095 is fine. I'll try to write something up for those concerned, but I duplicate virtual port groups all the time when a VMware or server team get all anxious about enabling those settings.