We'll walk through each tab on the port group's properties page and discuss each one, including a bit about why you'd want to change them. You'll find this information useful if you're preparing for your VCP5-DV exam, or if you're interested in learning about vSphere networking in general.
To clarify, this post is regarding options for a Virtual Machine Port Group. VMKernel Port Groups are slightly different, so I'm focusing on VM Port Groups for now.
The General Tab
The Network Label is extremely important to get right on all of your hosts; in this case, right means consistent. This is required by vMotion, which will validate that a VM's network requirements can be satisfied on the destination host. Differences in Port Group names, even as trivial as capitalization, can cause at best warnings, and at worst, failures with vMotion. No foolish consistency here.
The VLAN ID associates your Port Group with a specific VLAN. In the example, you'll notice that this field is set to None (0). In my test lab, I'm not using VLANs, so there is no need to change the default. However, if you are bringing multiple VLANs into your vSS (say, one for web servers, one for database servers, one for security servers), you must enter the VLAN ID that will provide the correct network access for your interfaces. VM interfaces in this port group will ONLY have access to the VLAN you define here.
The Security Tab
You'll find some more interesting options in the Security Tab: Promiscuous Mode, MAC Address Changes, and Forged Transmits. Note that the options are not checked by default; this tells you that you are currently using the configuration of the vSS itself. If you need to change these settings for a specific port group, check the box and set the appropriate value.
Promiscuous Mode: Enabling this option allows a network interface in this port group to see all frames on the VLAN that's defined for this port group. Why would you want to do this? The most common reason is that you've virtualized a network / packet analyzer (read: wireshark) and you want to view all frames on a VLAN, not just broadcasts and traffic to / from your VM. The default setting here is Reject, which will satisfy most of your VM connectivity requirements.
MAC Address Changes: Each virtual interface on a VM has its own MAC address; this address uniquely identifies your interface on a network, and is the true source and destination of network traffic. A virtual interface's MAC address is contained within the VM's configuration file (stored in its datastore folder as a .vmx file). In the event that the MAC address is changed from the value in the .vmx file, one of two things can happen (depending on your selection for the MAC Address Changes setting): if you've selected Accept, traffic will immediately move to the new MAC address; but if you've selected Reject, traffic to that interface will be dropped. Personally, I find that this setting is less significant in vSphere 5.1 than in previous versions. In 5.1, once a MAC address has been generated for a virtual interface, it does not change unless there is a collision with another virtual interface. Because vSphere 5.1 tracks generated MAC addresses, this condition is very unlikely. Of course, the default behavior handles these changes without interrupting your VM's connectivity.
Forged Transmits: This setting determines how vSphere handles frames that are sent with a source MAC address that is different from the source interface. By default, this type of traffic is passed. Changing this option to Reject would drop all frames with a forged source MAC address. Why would you want to do this? If you have any security concerns regarding a host masquerading as another host on your network, you may want to set this to Reject. In this scenario, ESXi would detect the different in source MAC and the virtual interface's MAC and quietly drop the frame.
Let's stop here for now. The next two tabs, Traffic Shaping and NIC Teaming, can be daunting, so make sure you're comfortable with these two tabs first.