Configuring vSS and vDS Features. Flashcards
Common vSS Policies.
There are three main policies for vSSs:
- Security
- Traffic shaping
- Teaming and Failover
Each policy can be set at the switch level and be overridden at the port group level if necessary.
Common vDS Policies.
Policies that can be set at the port group level on a vDS and be overridden at the port level include:
- Security
- Traffic Shaping
- VLAN
- Teaming and Failover
- Resource Allocation
- Monitoring
- Miscellaneous (port blocking)
- Advanced (override settings).
Two-step process:
First, you configure the port group to allow changes to a particular setting at port level,
and then you locate the port that you want to configure.
Configuring dvPort Group Blocking Policies.
This isn’t your everyday setting. It’s more of a “one-off” scenario setting that can come in handy if you know how to use it. Suppose that you want to isolate all machines on a port group from the network for a period of time while you make a software change. After the change, you want to connect them all again.
Configuring Load Balancing and Failover Policies.
If you assign more than one vmnic (physical NIC) to a switch or port group, you can configure load balancing and failover policies using the vmnics that you assign. This is the concept of NIC teaming, which you should clearly understand is not using more than one vNIC on a VM, but instead using more than one vmnic on a switch or port group.
On a port group of a vSS or a vDS, you will find a list of policy exceptions, as shown on a vSS for Teaming and Failover in Figure 6-9. They are called exceptions because they each have a default setting, but that setting can be changed if necessary. Each of these settings and the options that you have are discussed next.
Configuring Load Balancing and Failover Policies: Load Balancing.
There are five load balancing options from which you can choose:
1. Route based on the originating virtual port ID: The physical NIC is determined by the ID of the virtual port to which the VM is connected. This option has the lowest overhead and is the default option for vSSs and port groups on vSSs.
- Route based on source MAC hash: All of VM’s outbound traffic is mapped to a specific physical NIC that is based on the MAC address associated with the VM’s virtual network interface card (vNIC). This method has relatively low overhead and is compatible with all switches[md]even those that do not support the 802.3ad protocol.
- Route based on IP hash: The physical NIC for each outbound packet is chosen based on a hash of the source and destination addresses contained in the packet. This method has the disadvantage of using more CPU resources; however, it can provide better distribution of traffic across the physical NICs. This method also requires the 802.3ad link aggregation support or EtherChannel on the switch.
- Route based on physical NIC load: The virtual switch checks the actual load of the physical uplinks and takes steps to reduce overloaded uplinks by redirecting traffic to the other available uplinks. Only available on the vDS.
- Use explicit failover order: The switch will always choose from its list of active adapters the highest order uplink that is not currently in use.
Configuring Load Balancing and Failover Policies: Failover Policies.
- Link Status Only: This option relies solely on the link status that the network adapter provides. In other words, “Do I feel electricity?” or with fiber, “Do I see a light?” This option detects cable pulls and physical switch failures, but it does not detect configuration errors that are beyond the directly connected switch. This method has no overhead and is the default.
- Beacon Probing: This option listens for link status but also sends out beacon packets from each physical NIC that it expects to be received on the other physical NIC. In this way, physical issues can be detected as well as configuration errors, such as improper settings on Spanning Tree Protocol (STP) or VLANs. Also, you should not use Beacon Probing with IP-hash load balancing because the way the beacon traffic is handled does not work well with this option and can cause a “network flapping” error.
Notify Switches.
The following are your two simple options with regard to notifying switches:
- Yes: If you select this option, the switch is notified whenever a VM’s traffic will be routed over a different physical NIC because of a failover event. In most cases, this is the setting that you want to configure because it offers the lowest latency for failover occurrence and for vMotion migrations.
- No: If you select this option, the switch will not be notified and will not make the changes to its MAC address table. You should select this option only if you are using Microsoft Network Load Balancing (NLB) in unicast mode because selecting Yes prevents the proper function of Microsoft Network Load Balancing in unicast mode.
Failback.
On each switch and/or port group, you can assign vmnics (physical NICs) as Active, Standby, or Unused, as shown in Figure 6-10.
If a vmnic is listed as Active, it will be used unless it fails. If a vmnic fails, the first vmnic in the Standby list is used. Now, what if the first vmnic should come back? Then should you go back to it immediately, or should you stay with the vmnic that is currently working fine?
The following are your two simple options for Failback settings:
Yes: If you select this option, a failed adapter that has recovered will be returned to Active status immediately after its recovery, thereby replacing the vmnic that is working fine. This might be an advantage if the primary adapter is somehow superior to the secondary one, such as a faster speed or other features. The disadvantage of this option is that a “flapping” connection could cause the system to play “ping pong” with itself, continually changing between adapters.
No: If you select this option and an adapter fails and then recovers, the adapter that took its place when it failed will continue to be used. This “if it ain’t broke, don’t fix it” approach avoids the “ping pong” of the other option but might leave the traffic on a slower or less desirable adapter.
Configuring VLAN and PVLAN Settings.
vSphere fully supports IEEE 802.1Q tagging.
On vSS port groups, you can configure the VLAN setting on the General tab of the properties for the port group, as shown in Figure 6-12. You can do so by typing the VLAN number from your network in the box labeled VLAN ID (Optional). If you have VMs that need to receive packets from more than one subnet and provide their own tagging for more than one subnet, you should select All (4095).
On vDS port groups, you can configure the VLAN in a much more granular fashion. You might have noticed that the VLAN setting is one of the options under Policies. On this setting, you have three options from which to choose: VLAN, VLAN Trunking, and Private VLAN.
Configuring VLAN Policy Settings on a vDS.
If you select VLAN, the screen changes, and you are presented with a simple box in which you can input a number, as shown in Figure 6-13. This number should be an actual VLAN number that you are using on your physical network and that you want to incorporate into your virtual network as well, on this port group. Your range of choices is from 1 to 4094.
Configuring VLAN Trunking Policies on a VDS.
This option establishes the port group as a trunk that can carry multiple VLANs to VMs that are connected to it. However, rather than having to carry all 4094 VLANs just to have more than one, on vDSs, this setting can be pruned to carry only the VLANs or range of VLANs that you specify, as shown in Figure 6-14.
Configuring Private VLAN Policy Settings on a vDS.
Allows you to use a VLAN that you have created on the vDS that can be used only by your vSphere environment and not by your external network.
You can create and use three types of private VLANs in your vSphere:
- Promiscuous: This is named (numbered) by the primary VLAN that you chose from your physical network. It is the remaining piece that is not separated from the primary VLAN. VMs on this VLAN can be reached by any VM in the same primary VLAN.
- Isolated: This is a private VLAN used to create a separate network for one VM in your virtual network that is not used at all in the physical world. It can be used to isolate a highly sensitive VM, for example. If a VM is in an isolated VLAN, it will not communicate with any other VMs in other isolated VLANs or in other community VLANs. It can communicate with promiscuous VLANs.
- Community: This is a private VLAN used to create a separate network to be shared by more than one VM. This VLAN is also used only in your virtual network and not in your physical network. VMs on community VLANs can communicate only to other VMs on the same community or to VMs on a promiscuous VLAN.
Configuring Traffic Shaping Policies.
When you decide to use traffic shaping, your goal should be to free up available bandwidth by limiting the bandwidth usage on port groups that contain VMs that can function with less bandwidth.
Traffic Shaping Policies for vSphere Standard Switches.
On vSSs, all traffic shaping is for outbound traffic only. As with other policies, you can configure traffic shaping on a vSS at the switch level, and then you can override it at the port group level. After you enable traffic shaping, you can configure three main settings for outbound traffic on vSS switches and port groups:
- Average bandwidth (kbit/s): This establishes the number of kilobits per second to allow across a port, averaged over time. It should be an amount based on that which you have observed or monitored in the past.
- Peak bandwidth (kbit/s): This is the maximum
aggregate traffic measured in kilobits per second that will be allowed for a port group or switch. It should be an amount that will not hamper the effective use of the VMs connected to the port group or switch. - Burst size (KB): This is the maximum number of bytes to be allowed in a burst. A burst is defined as exceeding the average bandwidth. This setting determines how long the bandwidth can exceed the average as a factor of how far it has exceeded the average. The higher it goes, the less time it can spend there. In other words, this setting is a factor of “bandwidth X time.”
Traffic Shaping Policies for vSphere Distributed Switches.
The biggest difference from that of vSSs is that it can be configured for both inbound (ingress) and outbound (egress) traffic.
