Sam Walker

VCP-NV 6 Blueprint Section 3 Notes

Blog Post created by Sam Walker on Aug 10, 2015

Section 3 – Configure and Manage vSphere Networking

Objective 3.1 – Configure and Manage vSphere Standard Switches (vSS)

Identify vSS capabilities

  • Configured on a per-host basis
  • Effectively a virtual patch-panel
    • A ‘switch’ will maintain a MAC address table, the vSS will maintain MAC records for only connected devices
  • VLAN (4094 per fabric)
  • Egress traffic shaping
  • Security
    • Promiscuous mode – Copies every frame to every VM on the portgroup
    • MAC address changes – Allows VM to change MAC – required for clustering
    • Forged Transmits – Allows VM to have a different MAC add to that its registered with
  • Load Balancing
    • IP Hash – uses both links based on source & destination IP – better throughput, but requires physical switch config, Cisco EtherChannel, for example
    • Originating virtual port – based on switch ID port.  Spread across links, but not ‘balanced’.
    • MAC hash – spread across links based on MAC algorithm
    • Explicit failover – specify which link is used
  • Network Failure Detection – options are:
    • Link status only (i.e., is the link up)
    • Beacon probing (beacon probes sent out up to the physical network to identify failures higher up the stack…  More robust than ‘cable failure’.  Don’t use with IP hash).
  • Notify Switches
    • Yes – updates physical switches when failure events occur
    • No – Doesn’t update physical switch infrastructure – use with NLB Unicast
  • Failback
    • Yes – In the event a path is restored after a failure, traffic will flow over the original uplink. Can cause problems with flapping ports.
    • No – After a failure, the traffic will continue over the recovery uplink.

Add/Configure/Remove vmnics on a vSS

  1.png

Configure vmkernel ports for network services

2.png

Add/Edit/Remove port groups on a vSS

3.png

Choose Switch, Choose VLAN, Finish

 

To delete, select PG & choose ‘X’:

4.png

Determine use cases for a vSphere Standard Switch

  • Non-Enterprise+ customers!
  • Small deployments
  • Test & Dev (not running a well-protected vCenter for example)
  • Standalone hosts

Objective 3.2 – Configure and Manage vSphere Distributed Switches (vDS)

Identify vDS capabilities

  • VSS With the additional…
    • vCenter management (i.e., one CFG point)
    • Backup & restore (new feature of 5.5)
    • Load based teaming (LBT)
    • Network I/O Control
    • Healthcheck (new feature of 5.5)
    • Ingress Traffic Shaping
    • VXLAN
    • PVLAN
    • Netflow & PortMorroring
    • Network resource pools (new feature of 5.5)
    • Route based on physical load (Load-based teaming/LBT)

Create/Delete a vDS

Create

5.png

Choose compatibility / version, choose number of uplinks, NIOC, whether to create default PG (plus name), next, finish.

 

Add/Remove ESXi hosts from a vDS

6.png

7.png

8.png

9.png

10.png

11.png

Next, Next, Finish.

 

Edit general vSphere vDS settings

Name, no of uplinks, NIOC, MTU, CDP/LLDP

12.png

Uplinks, LACP, PVLAN, NetFlow, Port Mirroring, Healthcheck:

13.png

Add/Configure/Remove dvPortgroups

14.png

15.png

Configure dvPort settings

16.png

Add/Remove uplink adapters to dvUplinkgroups

To Add

17.png

To Remove

18.png

19.png

20.png

 

Create/Configure/Remove virtual adapters

Assuming this is referring to vmkernel adapters –

21.png

Migrate virtual adapters to/from a vSS

 

Migrate virtual machines to/from a vDS

There are two options:

  1. 1)      Edit the settings of on an individual VM basis (i.e., right-click on the VM, ‘Edit Settings’, select the network adapter and choose a port group on the vDS / vSS
  2. 2)      Migrate on the vDS level - Right-click on the vDS, select ‘Migrate VMs to another Network’ (vSphere 6 specific – different on vSphere 5).

Monitor dvPort state

22.png

Determine use cases for a vDS

  • Enterprise+ customers
  • Environments that want to have consistent configuration from a single point
  • Use of additional features (LBT, NIOC, Ingress traffic shaping, VXLAN, PVLAN, Netflow, etc)

 

Objective 3.3 – Configure and Manage vSS and vDS Policies

Identify common vSS and vDS policies

  • Security
    • Promiscuous mode – Copies every frame to every VM on the portgroup
    • MAC address changes – Allows VM to change MAC – required for clustering
    • Forged Transmits – Allows VM to have a different MAC add to that its registered with

Configure dvPortgroup blocking policies

23.png

Block all ports – also can block on an individual port basis.

Configure load balancing and failover policies

  • Load Balancing
    • IP Hash – uses both links based on source & destination IP – better throughput, but requires physical switch config, Cisco EtherChannel, for example
    • Originating virtual port – based on switch ID port.  Spread across links, but not ‘balanced’.
    • MAC hash – spread across links based on MAC algorithm
    • Explicit failover – specify which link is used
    • (VDS Only) Route based on physical load (Load-based teaming/LBT)
  • Network Failure Detection – options are:
    • Link status only (i.e., is the link up)
    • Beacon probing (beacon probes sent out up to the physical network to identify failures higher up the stack…  More robust than ‘cable failure’.  Don’t use with IP hash).
  • Notify Switches
    • Yes – updates physical switches when failure events occur
    • No – Doesn’t update physical switch infrastructure – use with NLB Unicast
  • Failback
    • Yes – In the event a path is restored after a failure, traffic will flow over the original uplink. Can cause problems with flapping ports.
    • No – After a failure, the traffic will continue over the recovery uplink.

 

Configure VLAN settings

4x types:

  • None – VLANs configured at the switched (so the host is using native VLAN presented from the switch)
  • VLAN – Specifies a VLAN, tagging done by the hypervisor, the guest is unaware of the VLAN its on.
  • VLAN trunking – Specifies a range of VLANs, tagging done by the guest OS.  Presents the entire trunk to the guest.
  • PVLAN – Private VLANs:
    • I can’t use Visio….!

24.png

  • Promiscuous PVLAN = the primary, all can communicate with promiscuous.
  • Community PVLAN = VMs can communicate with each other and VMs in the promiscuous PVLAN.
  • Isolated PVLAN = VMs can communicate with the promiscuous PVLAN only

Configure traffic shaping policies

25.png

Ingress = Inbound & Egress = Outbound (available on a vDS), only egress is available on a vSS

Enable TCP Segmentation Offload (TOE) support for a virtual machine

Enabled in 3x places; ESXi host, the physical NIC & the VM, also on older OSes on guest. 

  • ESXi host (by default this is enabled).

26.png

or

27.png

Make sure the value is 1

  • Vmnic:

28.png

And on the VM – change the advanced settings on the VM & add the row:

29.png

Enable Jumbo Frame support on appropriate components

Required end-to-end (physical device (another ESXi host or storage array) physical switch, virtual switch, VMkernel.

Physical device & physical switch – consult device manufacture, but for the switch normally something like:

Conf t > interface ten1/1 > mtu 1600 / mtu 9000 > Ctrl+Z > wr

Jumbo frames are anything above 1500, not just 9000.  As discussed previously, the recommended minimum for NSX is 1600 (although it will work with an MTU of 1550, always use 1600).

From VMware:

Configure the switch:

30.png

Then the VM Kernel interface:

31.png

 

Determine appropriate VLAN configuration for a vSphere implementation

  • None – switch tagging (limited use cases in modern infrastructures – perhaps with the exception of PXE boot for AutoDeploy)
  • VLAN – as a rule, the majority of environments…  saves the administrative overhead of guest tagging, plus allows multiple port groups to share the same infrastructure easily.
  • VLAN Tagging – if you require guest tagging.  If, for example, an appliance that can’t share vNICs, or you go beyond 10 vNICs & require more than 10 VLANs to be presented to a VM.  Additional overhead of configuration within the guest.
  • PVLAN – for environments nearing the VLAN limit (think hosting companies PaaS, etc).  It seems this requirement no longer exists with VXLAN.

Outcomes