Understanding switch constructs

Virtual networking isn’t a new thing. It has been around for a while and we get better at it as the months pass us by. Who hasn’t heard of SDN? Well before I buy into that realm and blog about it, lets harken back to a device which most people have had to deal with. VMware hosts attach themselves to most networks. VMWare provide a number of networking methods to provide intra-guest and inter-host communication. This communication from the physical card to the VM kernel and into a guest VM is very interesting. This blog will explore what a vSwitch can provide.

By default a new ESXi host will have the vSwitch0 installed by default. The first physical NIC will have a virtual adapter or vmnic0 assigned in the switch construct. This vmnic is presented through the VMware Hypervisor and presented to the construct. Upon installation you will assign a management IP. This is marked as a vmkernel port in which a various array of traffic types can pass. The first point of call for most is connection into the host with the VMware vSphere client.

It is important to note that although the behaviour of the vSwitch is designed to replicate that of a physical there are quite a few differences that need to be appreciated.

  • MAC address learning
    • The vSwitch is authoritative regarding this. It pulls the MAC address assigned to the NIC presented to the guest VM from the configuration file.
    • No learning is required in the traditional sense – record/store/forward
  • Zero participation in Spanning-Tree
    • Blocks inbound BPDUs
    • It uses, for a lack of a better term,  Split Horizon Switching
      • Packets received on one uplink cannot be passed and forwarded out another.
      • This is how it avoids creating network loops and a potential ‘Resume generating transaction’
  • Port-Groups are like ‘VLANs without the tagging’.
    • Guests are bound to port groups and different actions can take place.
    • Port-groups reside inside a vSwitch and can have different forwarding options applied.
  • Dynamic port allocation
    • Supports up to 4096 ports.
    • Subtract 8 for internal communications and forwarding leaving a total of 4088.
    • Supports up to 40Gb forwarding per vSwitch.
    • This doesn’t scale unlike Distributed vSwitch.
  • Additional to SPAN in 5.1
    • Support for RSPAN and ERSPAN
    • True IDP support
  • LACP support
    • Provides hosts bundled connectivity which can aid in HA mechanisms host and physical switch side.

My initial thoughts about the vSwitch are positive. The notion of dumb switch is tired. The spec sheet and throughput in software leveraging server backplane is impressive. There is a lot to be desired about the scalability options which saw the introduction of the distributed vSwitch. I find that it is rather a scary notion the simplicity in which someone can install this. This gives administrators without a strong networking background the ability to create sub-optimal situations for virtual networking environments. Although it houses a simple interface and point and click connectivity the VMware vSwitch requires thought and planning to ensure stable and high throughput operations.

4 thoughts on “Understanding switch constructs”

  1. Good post! There are a few catches tho!

    First, unless they brought this in in 5.1, prior versions didn’t block BPDU’s it just ignored them.

    Second while traffic coming in pNIC1 will not be forwarded put pNIC2 of the user bridges two vNICs traffic may flow like this:

    pNIC1 -> vNIC1 -> vNIC2 -> pNIC2

    Combine these together and you can start to see all sorts of fun if you have BPDU Guard running on your VM Host ports.

    1. Agreed – nice post.

      Almost positive that all changes in 5.1 to networking apply only to the vDS, not the native vSwitch. This includes the new “BPDU Filter” feature, which as Kurt points out, didn’t exist in prior versions. If you’re running vDS, on vSphere 5.1, you have the option to filter BPDUs.


      I raised a stink about this at VMworld 2012, as it should be straightforward to do simple BPDUguard at the edge. Maybe in 6.0, who knows.

      Also – regarding the apparent ease by which a VMware admin can do networking…..1000v all the way baby! 🙂

    2. Thanks for the heads up. Scary that the thought that this construct can create a bridging loop when VMware state “we designed in it a way that it couldn’t” – No wonder they use the tag line “We aren’t a networking company”!

Leave a Reply

Your email address will not be published. Required fields are marked *