vSphere Distributed Virtual Switch ( DvSwitch)

All about vSphere Distributed Virtual Switch ( DvSwitch)

 

  1. vSphere Distributed Switch
  2. Private VLANs (pVLANs)
  3. Networking policies
  4. Configuration tasks

 

Explain vSphere distributed switch (DvSwitch).

1. Creates a centralized virtual switch that multiple ESXi hosts can subscribe to.

2. Reduces N/Wing configuration and changes and reduces the windows errors. As we don’t need to perform N/W configuration multiple times of each ESXi host individually.

3. Allows you to centrally manage N/Wing for VMs across multiple ESXi hosts.

4. Consistent N/W configuration & stats as VMs are migrated using VMotion.

5. DvPort groups similar to standard vSwitch port groups but on the VDS level

6. Increase capabilities – security, traffic control, vLAN and more

7. Ability to add 3rd party switch – Nexus 1000V.

Explain Private vLANs or pVLANs?

Primary:- Original vLAN that can be subdivided into multiple secondary pVLANs.

Secondary:- They exist only inside the primary vLAN.

Each secondary pVLAN has vLAN ID i.e. a secondary subset vLAN ID with the original or primary vLAN ID.

For example-

So every packet that goes IN and OUT of the secondary private vLAN gets an additional ID tag to it so that you can identify it. Here take an example original vLAN ID is 1 and secondary vLAN ID pVLAN is 12 so the packet would look like 1.12 so that the physical switch can understand where this packet will destined to. You can have multiple secondary pVlAN in three different modes promiscuous, isolated, community.

It associates each packet with an ID that the physical switch can use to identify the mode (promiscuous, isolated, community).

PVLANs Secondary Mode Nodes:-

Promiscuous:-

May send and receive packets to any secondary pVLANs.

Typically routers are attached to promiscuous ports.

Isolated:-

May only send and receive packets from the promiscuous pVLANs.

Community:-

May send and receive packets b/w any secondary pVLANs and also with the promiscuous pVLAN.

 

 

Q. How to perform VLAN Tagging?

Host -> configuration -> N/Wing -> properties of that switch -> edit after selecting the port groups in ports tab Example:- select VM N/W -> edit.

Where you can put VLAN ID 101 that is already configured on the physical switch by N/W administrator make sure that match.

If you want to create multiple VM port groups click on add button – > select virtual machine instead of VMKernal as it is VM port group or for VM traffic and put VLAN ID 102.

Both the VLAN’s going through the same uplink/NIC (physical) that is already configured. You don’t need dedicated physical NIC for every subnet for every VLAN in your infra.

You can use port trunking and VLAN tagging so that you can use or able to pass traffic into multiple VLANs with the same physical NIC.

All About VSwitch Security Policy properties consists of?

Security:- Policy Exceptions :-

  1. Promiscuous mode:- Reject/Accept
  2. MAC address Changes: Accept/Reject
  3. Forged Transmits: Accept/Reject

 

1. Promiscuous Mode:-

                          You are exposing all the packets that are coming into the vSwitch to all the VMs on this vSwitch. So the user in the VMs can see all the packets that are destined for all other VMs on this vSwitch. This is a security issue after all. You don’t want a VM to see the packet of a different VM on the same vSwitch. Set to accept in the scenarios like in troubleshooting or may be a wire shot or for some kind of detection system, that time you want to capture all of the packets that are coming into the vSwitch. By default it should be rejected.

2. MAC Address Changes:-

MAC address resides in the .VMX file of a guest OS. Whatever the .VMX file is registering for this particular VM, whatever the guest OS is hard coded to know the MAC address perspective, they would have to match otherwise the traffic isn’t going to be allowed. So MAC address changes for incoming traffic, same with the forged transmits but this is for the traffic that transmits from the VM and the guest OS that is hard coded with the MAC address and the MAC address that is in the configuration file should match for allowing the traffic transmission.

Example: when VM’s are migrated/VMotioned from one host to another it’s MAC address changes so be careful and select accept otherwise if you select reject it will interfere in VMotion process and forged transmit is also set as accept.

This setting denies incoming traffic to a VM when the MAC address defined in the configuration file .VMX doesn’t match the MAC address inside the guest OS.

3. Forged Transmits:-

                       This setting denies outgoing traffic from a VM when the MAC address defined in the .VMX file doesn’t match the MAC address inside the Guest OS.

1. Traffic Shaping:-

                         Status: Disabled by default

                         Average Bandwidth: 100000 Kbits/Sec

                         Peak Bandwidth:  100000 Kbits/Sec

                         Boost Size: 102400 Kbytes

2.NIC Teaming:-

Load balancing: Route based on the originating virtual port ID

Network Failure Detection: Link Status only

Notify Switches: Yes

Failback: Yes

                Select active and standby adapters for this port group. In a failover situation, standby adapters activate in the order specified below:-

                                Failover Order:-

a) Active adapter                                                                                          N/W’s

VMNIC 0 (Name of adapter)       10000full (Speed)             None

b) Standby Adapter

VMNIC 1 (Name of adapter)        10000 full (Speed)             0.0.0.1.255.255.254 (VLAN ID)

  • If you set fail back as yes the traffic is transmitting through active adapter when it is available. The moment it fails, the traffic transmitting fail-over to the standby adapter and the moment the active adapter comes available without the standby adapter failure the traffic transmission failback to the active adapter without waiting for the standby adapter to be failed. However it is not necessary to put failback to yes if only your organisation wants a standby adapter/NIC would be standby and active adapter must transmit the traffic only. But still by default the failback is set to yes.
  • Notify switches will always notify whenever you added a new uplink or physical NIC to the vSwitch. So the vSwitch is automatically notify that physical NIC and and say hey I have updated an uplink and you need to update your routing tables to acknowledge there is a new physical NIC here so that you can use it and you can avoid latency. Otherwise if you added a physical new uplink and notify switches is set to NO then it will take time to the MAC address tables updated, might provide-latency, may be dropped packets etc.
  • Network failover detection has two options link status only and Beacon probing. In link status only if a cable is plugged into a switch port it will detect that a particular port is up so as a result it thinks that there is a connectivity if N/W cable is unplugged it thinks that there is no connectivity and it’s going to report as failure and it will initiate failover. In Beacon probing it will still use link status but it is little more smarter it is sending continuous messages to that particular instance and if it doesn’t receive acknowledgement then it detects as failure and a result it will initiate a failover so by default it is set to link status only.