A virtual switch (vSwitch) is a software-based Layer 2 switch that functions similarly to a physical switch. A vSwitch connects virtual machines (VMs) within a virtualized server and to external physical networks using physical network interface cards (pNICs). A virtualized server can have several vSwitches, however network traffic cannot move from one vSwitch to another within the same virtual switch, and the vSwitches cannot share the same pNIC. Virtual Switches is best used for network and security settings.
Most popular virtual network switches are as follows:
- Cisco Nexus 1000VE Series Virtual Switch
- Cisco Application Virtual Switch (AVS)
- Open vSwitch (OVS)
- IBM DVS 5000v
- vSphere Switch
Three vSwitches are connected to the VMs’ virtual network interface cards (vNICs) as well as the pNICs in the virtual server illustrated below. vSwitch1 and vSwitch3 are connected to pNIC 1 and pNIC 3, respectively, to access the physical network adapter; however, vSwitch2 is not connected to any pNICs. Because network traffic cannot move from one vSwitch to multiple virtual switches, network traffic from VM1 destined for the external network, or VM0, must pass through the virtual next-generation firewall (NGFWv).
There are different ways to configure multiple virtual switches. One of the downsides of standard vSwitches is that every vSwitch that is part of a cluster of virtualized servers needs to be configured individually in every virtual host. This problem is solved by using distributed virtual switching, a feature that aggregates vSwitches together from a cluster of virtual servers and treats them as a single distributed virtual switch. These are some of the benefits of distributed switching:
- vSwitch configuration management for several servers in a cluster is centralized, making administration easier.
- During a live Virtual Machine migration, networking statistics and rules are migrated alongside virtual machines.
- Consistency of configuration across all hosts connected to the distributed switch
Containers, like VMs, use virtual Switches (also known as virtual bridges) to communicate within a node (server) and with the outside world.
The diagram below shows how Docker0 assigns a virtual Ethernet interface (veth) to each container it creates. The container sees the veth interface as eth0. The bridge’s subnet block assigns IP addresses to the eth0 device. As new Docker containers are built on the node, each one is given an eth0 interface and an IP address from the same private address space. Only containers within the same node can communicate with each other after that. By default, containers on other nodes are not reachable, however, this can be fixed by utilizing OS-level routing or an overlay network.
If Docker is installed on another node using the default configuration, it ends up with the same IP address as the first node, and this needs to be resolved on a node-by-node basis. A better way to manage and scale containers and the networking connectivity between them within and across nodes is to use a container orchestrator such as Kubernetes.
Download our Free CCNA Study Guide PDF for complete notes on all the CCNA 200-301 exam topics in one book.
We recommend the Cisco CCNA Gold Bootcamp as your main CCNA training course. It’s the highest rated Cisco course online with an average rating of 4.8 from over 30,000 public reviews and is the gold standard in CCNA training:
