Product and service reviews are conducted independently by our editorial team, but we sometimes make money when you click on links. Learn more.

Networking for VMware Admins: Virtual vs Physical Switching

Networking for VMware Admins: Virtual vs Physical Switching
By , Steve Pantol

A good understanding of networking is becoming crucial for virtualization administrators and here to fill this gap is Chris Wahl and Steve Pantol's Networking for VMware Administrators. The book covers a wide range of virtual networking environments, addressing virtual switching and networking, and the differences between physical and virtual networks. With a focus on VMware vSphere, the text offers plenty of real-world examples which focus on building a good networking foundation. The following excerpt focuses on how virtual switching differs from physical switching.

Special Offer: Get 35% off this book at with coupon: TOMSITPRO -- valid through December 31, 2014.

Although it's easy to point to the obvious difference between physical and virtual switching -- one is hardware and the other is software -- there is a bit more to it than that. There are differences both in the process by which traffic is switched, and in the advanced services and features offered. In this chapter, we look athow a virtual switch operates on a VMware vSphere host running ESXi, along with some of the terminology of logical objects represented by the virtual switch.

Physical and Virtual Switch Comparison

So your first question might be - what exactly is a virtual switch? After all, the previous section of this book focused entirely on the theory and practice of switching, along with some routing, and most of it focused on plugging wires into fancy boxes so that data could move around.

To begin, let’s start by covering some basic functionality similarities and differences between physical and virtual switches. You might be surprised at how alike these two types of switches are; the differences can be subtle but have a profound impact on the design and configuration of a well-tuned virtual environment.


It’s important to note that a VMware virtual switch, or vSwitch as it is known, doesn’t use any special or proprietary type of modification on the traffic. All the frames that flow into a vSwitch follow the exact same standards as outlined by the Institute of Electrical and Electronics  Engineers (IEEE) 802.3 protocol, following the conceptual framework of the OSI Model’s Data-Link Layer, and the practical application of the TCP/IP Network Interface layer. If you think about it, this makes a lot of sense - as otherwise you’d need special equipment just to pass traffic into or out of an ESXi host and its vSwitch.

Figure 7.1 shows the layout of an IEEE 802.3 frame.

Additionally, ESXi hosts have the ability to use a wide variety of off-the-shelf network adapters (NICs) from the likes of Qlogic, Emulex, Intel, and others - consult the Hardware Compatibility List for an authoritative list. These use the standard connector types, RJ45/8p8c for copper or any of the standard fiber connector types, just as you would find in any other server that was running any other operating system or hypervisor. A vSwitch then begins using these network adapters and attached cables to switch traffic.


Because a vSwitch isn’t a physical device, you have some flexibility in configuration. If you need a larger number of virtual ports on your vSwitch, you can just edit its properties and adjust as needed. With physical switches, this could require a forklift switch upgrade, adding new switches, or adding line cards to a chassis-based switch.

Switching Decisions

Another major difference is how a vSwitch handles Layer 2 switching. That is, the knowledge and movement of data to MAC addresses on the network. A physical switch has a large table of MAC addresses that it keeps in memory to quickly figure out where a frame needs to be sent. The addresses that are remembered are for nodes that are both directly and remotely attached to the switch - that is, nodes directly plugged into a switch port and also nodes that are connected to another switch’s port.

Figure 7.2 shows the MAC addresses of devices connected to a virtual switch, as found in the vSphere Web Client.
A vSwitch does not concern itself with MAC addresses for nodes that are not directly attached to it. It only needs to know the MAC addresses for the virtual machines (VMs) and VMkernel port devices (covered further  in this chapter) that are consuming virtual ports on the vSwitch. Beyond that, the vSwitch has no clue where other devices live. If a frame enters the vSwitch from the outside world destined for an unknown MAC address, it is ignored by the vSwitch. This is an important distinction - a physical switch will flood unknown frames out of all ports except the one the frame was received on, as part of the mechanism it uses to learn MAC addresses. A software vSwitch does not need to go through a learning process, and therefore knows which MAC addresses do and don’t belong. Similarly, if a frame enters the vSwitch from one of its virtual ports, such as from a VM destined for an unknown MAC address, it is given over to an Uplink port to handle. This makes Layer 2 switching very simple and lightweight for a vSwitch. To sum it up, the switching logic looks like this:

  1. Ethernet Frame enters the vSwitch.
  2. If the destination  is to a known MAC address, switch the frame to the virtual port that owns that MAC address.
  3. If the destination  is to an unknown MAC address:

Drop  the frame if it came from an external source.Send the frame to a physical uplink if it came from an internal source. Figure 7.3 illustrates the virtual switching logic.Keep in mind that the vSwitch is only able to do Layer 2 switching. If a frame is trying to reach a MAC address on another VLAN, Layer 3 switching is required and the frame will be sent to the physical uplink with the hopes that a higher level switch can perform the inter-VLAN routing.