Welcome to episode 9 of the Datanauts podcast! Join Chris Wahl and Ethan Banks as they assume their silo-busting roles of Server Dude and Network Guy. In today’s episode they mix some virtualization peanut butter with networking chocolate to build a vSwitch Peanut Butter Cup.
Networks no longer stop at the physical switchport. Rather, networks extend into hypervisors where we find virtual switches. Virtual switches present networking to the virtual machines that connect to them. Network engineers ignore these virtual switches at their peril. At the same time, virtualization engineers ignore the physical network at theirs. Let’s work together to configure a vSwitch as good as it can be.
Show Notes:
Section 1 – What’s A vSwitch?
-Where does the vSwitch stop and the hypervisor’s physical uplink to the network start?
-There are different vSwitches, including VMware’s default, NSX vSwitch, Cisco’s Nexus1000V, and Open vSwitch. Is there a “right” choice?
- Technical differences
- Cost concerns
- Hypervisor support
-What is a distributed vSwitch?
- NIOC
- Inbound traffic shaping
- PVLAN support
- Netflow
- LLDP
- Port mirroring
- LACP (instead of just a static port channel)
- Traffic filtering
- SR-IOV
- 40Gb NIC support
-How are networking maximums influenced by hardware?
- Type of NIC used
- Speed of the NIC (1, 10, and 40 GbE)
- Combination of 1 GbE and 10 GbE (10 x 10 GbE + 4 x 1 GbE)
- Virtual Interface Cards (VICs)
Section 2 – vSwitch Design
-Is there anything about NIC drivers in ESX to pay special attention to?
-Does adding more virtual switchports take away system resources?
- Elastic ports
-Is it true a vSwitch can never form a bridging loop?
-802.1q tagging concerns
- EST, VST, VGT
- Towards the guests
- Towards the host/physical networks
- When to isolate
-Is there a best practice for the VLANs that a vSwitch should be carved into? I have seen…
- One or more for guests depending on security needs, mostly
- One for managing the VMware infrastructure
- One for storage traffic
- One for VMotion & maybe FT
-Can you map specific vNICs to specific physical ports via the vSwitch? If so, what’s the use case?
-Link load balancing & 802.3ad LACP concerns
- LAG bandaids
- This is a recent addition to ESX
- When is LACP a good idea?
- When are the standard load balancing methods preferred?
-Should the physical plumbing change when connecting a single host/single vSwitch vs. multiple hosts/distributed vSwitch?
-What happens when a physical Ethernet link on the host goes down?
-When a host has been plumbed and vSwitch configured, what sort of failure scenarios should be tested for, and how?
- Cable/NIC failure to a host
- Physical switch failure
- Other?
Section 3 – Takeaways And Future
-Lab environment
- Home lab (heavy CapEx, but best way to tinker)
- Ravello lab (free for vExperts, pay by the drip)
- VMware Hands on Lab
-Study materials
- Pluralsight course + Networking book
- Go for a CCNA R&S or DC + VCP
-License for VDS
- You can get a 60 day trial of Enterprise Plus
-Busting silos in your environment
- A virtual switch can be a great conversation-starter and learning point
- Lots of cross-over: storage, network, and compute, backup, security, monitoring, application teams, etc.
- Don’t design them in a silo; come up with a design, then share with the team
- Gather input and you’ll usually learn new things about your environment that will alter your design
- Get all the stakeholders involved in decisions
Thanks guys. This was by far the best Datanauts show so far. Really informative and perfect amount of information. This is a favourite show for me on packetpushers.net
Thanks, Tristan. We’ll keep trying to generate favorites.
Great show guys really enjoyed it and got a lot of useful information.
Alex
Great – thanks for saying so! We are indeed trying to make the show practical, so it’s good to know folks are getting a benefit.
Hello there,
Just “reverse arping in” to let you know I’m a regular user of the show and to add a small comment on the vSwitch discussion LACP topic.
As far as I know if you don’t use LACP for load balancing, vmware will only balance the outbout traffic and the best you can to to manage the inboud traffic in some “manual way” like pairing NIC, etc in a king of failover config and not a real load balancing.
But I think that in most situations it really doesn’t matter because one is most interested in the VMs outbound traffic (the first thing that comes to my mind is web servers), so it doesn’t matter if you just don’t balance the in bound because there will be a huge asymmetric pattern.
I do also have a home lab (and I don’t think one can live without one), but that sort of testing is one that is I miss because you need extra fancy hardware like several switches, several NICs and my single NIC server connected to a single switch isn’t enough to do a real test 🙂
regards,
Rui
A great show, I really appreciated an expert like Chris validating what I thought I knew (it’s been a while) and the schooling around the distributed vswitch.
I found the topic of inbound traffic distribution when not using LACP both vague and somewhat misleading: “the switch will work out which port the traffic came from”! Unless something smart is done by the vswitch around MAC addressing (which I don’t believe is the case), there will be a significant difference between inbound and outbound load across the pswitch to pNIC links.