Basics of VMware Network Virtualization

What is the virtual Switch? 

How is a virtual network realized

• A Virtual switch is similar in concept to a physical switch.
• It has ports organized into port groups.
• It has uplinks used to connect the virtual switch to the physical world.
• It also supports connections to help you manage your virtual infrastructure. 

The way a virtual machine connects to a port on a virtual switch is similar in concept to the way a computer's physical network adapter connects to a physical switch. Only instead of using a wired Ethernet cable, the virtual machine's connection to the port on the virtual switch is often referred to as a 'virtual wire'. The virtual switch can also have one or more uplinks.

Uplinks are used to connect the virtual switch within the ESXi host, to an external physical switch. Just as you can connect uplink ports between two physical switches. In the "virtual world" you can connect or 'uplink" a virtual switch to an external physical switch. The uplinks shown in this graphic, are represented logically. The uplinks are the physical network adapter ports found within the ESXi host.

Types of Virtual Switch's

Just like physical switches, Virtual switches come in different forms each with different features

vSphere provides two types of virtual switches 

• The VMware vSphere Standard switch or VSS. 

Virtual standard switch creation and configuration are per host. 

• The VMware vSphere Distributed switch or VDS. 

Introduction to Virtual Standard Switches 

Let's take a look at a Virtual Standard Switch. 
The installation of an ESXi host creates a default Virtual Standard Switch named vSwitch0. This virtual switch consists of ports within a port group that virtual machines can connect to, and uplinks that allow access to and from the physical network. Also, during the installation of your ESXi host, you are prompted for an IP address. 
This IP address is used to allow management of the host. This IP address is referred to as management IP. It is assigned to a VMKernel port, vmk0. 

This management port is part of your very first Virtual Standard Switch, vSwitch0. 
Keep in mind Virtual Standard Switch creation and configurations are per host. If you have 3 hosts, and you need a virtual network called "QA", a virtual switch and supporting port group need to be created three times, once on every host. 

Manages virtual machine and networking with a centralized management interface at the datacenter level. 

Introduction to Virtual Distributed Switches 

Now let's compare that to a Virtual Distributed Switch: The Virtual Distributed Switch expands upon the model of a Virtual Standard Switch by providing a centralized management. 
This is done by giving you the ability to create just one Virtual Distributed Switch that can span multiple hosts allowing all hosts to share the same configuration. 

For example. if you have sixteen hosts and wish to create a virtual switch you may have the option to create a 'Virtual Distributed Switch°. 

If you choose this option you would only have to create the switch once. During the creation process, you would specify that it spans all sixteen hosts. This also allows for Initial configuration and subsequent changes to be made just once. 

All changes will be automatically distributed to all sixteen hosts 

Virtual Standard Switches 

Now let's look a bit closer at the Virtual Standard Switch. A Virtual Standard Switch is available in all vSphere Editions. A Virtual Standard Switch consists of:

• Port groups 
• VMkemel ports 
• And uplink ports 

Policies such as security, traffic shaping and NIC teaming can be defined at the virtual switch level. 

Virtual switch level policies can be overridden at the port group level and VLANs are also assigned only at the port and port group level. 

Uses and Benefits of a Virtual Standard Switch 

More information on the Uses, Functions, Benefits, and Disadvantages of a Virtual Standard Switch. 

• Uses

Virtual Standard Switches are used for: 

• Virtual machine to virtual machine communication and virtual machine to physical machine communication.
• Virtual Standard switches use special ports called VMkernel ports for the following types of network communication: 

• Management 
• vMotion 
• IP Storage 
• FT Logging 

• Functions

A Virtual Standard Switch acts very similarly to a physical switch, however, standard switches do not support Spanning Tree Protocol (STP). Virtual switches don't require STP because they cannot be connected to one another and therefore do not pose the possibility of creating a loop between the virtual switches Virtual switches do not learn MAC addresses like a physical switch as the virtual machine is directly connected through a virtual wire. 

The benefits of Virtual Standard Switches are: They are simple to create. and support the most common network features, such as VLANs, security, and NIC teaming policies. 
The disadvantages of Virtual Standard Switches are: They do not provide a centralized management interface, and do not have all the features of a Virtual Distributed Switch. 

User and Benefits of a Virtual Distributed Switch: 

Now let's take a closer look at the use and benefits of a Virtual Distributed Switch. 

Virtual Distributed Switches allow for a centralized management model that makes them: 

• Faster to deploy 
• Easier to manage 
• Less prone to error 
• The primary benefit of a Virtual Distributed Switch is centralized management. 

This is achieved because the vSphere Distributed Switch can span two or more hosts.

When the orange port group Is created within the Virtual Distributed Switch -It is created once but has a span equal to that of the Virtual Distributed Switch. 

Policies are now applied at the port group and port level as opposed to the virtual switch level and port group level. 

The ability to apply policies at the individual port makes this virtual switch act more like a physical switch. 

Again, when the blue port group is created on the Virtual Distributed Switch, it Is created once but has a span equal to that of the Virtual Distributed Switch. 

Policies are now applied at the port group and port level as opposed to the virtual switch level and port group level. 

Since policies are applied at the port group, and not at the Virtual Distributed Switch level, more general features are added at the Distributed Switch level such as: 

• Private VLANs 
• NetFlow 
• Port Mirroring 
• Network I/O control. 

• Keep in mind Virtual Distributed Switches do require an Enterprise Plus vSphere license.

Virtual Standard Switches VS Virtual Distributed switches 

Now we'll compare Virtual Standard Switches to Virtual Distributed Switches. With Virtual Standard Switches there is no centralized management. 

Virtual Standard Switches must be created repeatedly on each host, which is time-consuming, and prone to error.
The port groups within each Virtual Standard Switch must be created repeatedly. One example of a common error is failing to recreate each set of port groups with exactly the same names for each Virtual Standard Switch. The names are case sensitive, and failure to match standard port group names will, for example. cause vMotion to fail. 

In contrast, vSphere Virtual Distributed Switches are created just once and span multiple hosts. You determine the span of the Virtual Distributed Switch by specifying what hosts to include either during or after creation. 

Port groups only have to be created once. The port groups' span is equal to the span of the Virtual Distributed Switch. Any changes you make to the port groups are only made once. To summarize: Virtual Distributed Switches are easier to maintain due to their centralized management. When you create the switch, you create just one, make a change, and make it just once. 

Overview of how a Physical switch is realized 

So far, we've discovered what a virtual switch is, the different types of virtual switches and their capabilities, but you haven't yet discovered how a virtual network is realized. 

Before that, we'll take a quick look at how a physical network is realized. 

A physical network is defined or realized by connecting different physical switches to different router interfaces. 
In this example: Switch 1 supports the 10.1.1.0 network by being connected to interface 1. 

Switch 2 supports the 10.1.2.0 network by being connected to interface 2. The purpose of dividing the network into different segments is to speed up network performance by minimizing the amount of broadcast traffic on each segment. Broadcast traffic on Switch1 will not be forwarded by Router 1 to Switch 2 and vice versa. Assuming proper routing configuration in the router and correct IP addressing of the PCs, then PC 1 on the 10.1.1.0 network can communicate to PC 8 on the 10.1.2.0 network. Even though broadcast traffic is dropped by the router, unicast traffic will be forwarded. 

A network is defined or realized by binding the IP address and subnet mask to the interface on the router 

Any Switches connected to that interface will be connected, by default to that network segment.

VLANs

In the previous example, we discovered how to realize two physical networks: 

A router is configured with two interfaces, each with a different network defined.
One switch is connected to one interface, and one switch to the other. 

Rather than use two switches to connect the interfaces, it is also possible using a single switch with VLANs. The VLANs, for example, define those specific ports that support the 10.1.1.0 network, and those ports that support the 10.1.2.0 network. 
In this example, VLAN 101 (the green ports) support the 10.1.1.0 network, and VLAN 102 (the blue ports) support the 10.1.2.0 network. 

So, what is the purpose of VLANs? 
VLANs can split up one physical switch into separate logical switches. This means fewer physical switches are deployed, less cabling is needed, and fewer ports are wasted. 
Only members of a VLAN can see that VLAN's broadcast traffic. 
Unicast traffic can pass between VLANs once a routing decision is made. 

Split switches into separate virtual switches 
1. Only members of a VLAN can see that VLAN's traffic 
2. Traffic between VLAN's must go through a router. 

A network with and without VLAN's 

Here is an example of a network without VLANs and one with VLANs. 

Without VLAN's, Each group is on a different IP network and on a different switch. 

Look closely at the diagram without VLANs. Here, each group of computers is connected to a different IP network, on a different switch. 

This is accomplished by connecting each physical switch to a dedicated interface on the router. 

Each router interface has a specific IP address and subnet mask bound to the interface to define the network segment. 

Now, look at the diagram with VLANs. 

In this example, the same number of networks is supported, but this time it is accomplished by using only one physical switch. As you can see, VLANs can reduce the number of physical switches, cables, and complexity in your data center. 

A network with VLAN's 

Now let's expand on the example with VLANs. Here you can trunk two physical switches together to allow a single physical link to carry traffic for more than one VLAN. 

Inter-switch links or uplinks are configured as trunks, allowing them to carry frames from multiple VLANs for that switch. 

Each frame carries a tag that identifies which VLAN it belongs to. If this example were designed to exclude VLAN tagging, three physical connections would be needed between the two switches, instead of just one. 

Adding a new connection for each new VLAN does not scale well. In summary, physical networks are realized in one of two ways: 

One, have separate physical switches that connect to a specific router interface, where each interface has a network defined, or two, by defining VLANs on ports with physical switches to isolate traffic. 

In both cases the traffic between two defined networks must be controlled by a router, it could be two switches connected to a physical router, or a switch that supports Layer 3 routing. 

We've covered the basics of both a virtual switch and realizing a physical network. Now we'll look at how a virtual network is realized. 

How a Virtual Network is Realized 

A virtual network is realized very much like a physical network, but by using virtual switches instead of physical switches. In this example, we allow the virtual switch to define the network. Just like in our physical example without VLANs. 

When a virtual switch is created with no VLANs defined, this means the virtual switch itself defines the network segment. 

The network segment is determined by the VLAN assigned to the access port on the physical switch uplink. 

In this example: vSwitch0 uplinks are connected to access ports, with VLAN 101 defined on physical Switch 1, and physical Switch 2. 

vSwitch1 uplinks are connected to access ports, with VLAN 102 defined on physical Switch 1, and physical Switch 2. vSwitch2 uplinks are connected to access ports, with VLAN 103 defined on physical Switch 1, and physical Switch 2. 

Overview of how a Virtual Network is realized 

A virtual network can also be realized by assigning VLANs to port groups within the virtual switch. 

Just like in our physical example with VLANs, if different VLANs are assigned to multiple ports on the physical switch, one physical switch can be logically split into multiple switches. 

Assigning the VLAN to the port group will require that the ports on the physical switch be either configured as VLAN trunk ports or tagged.

In this example, the blue port group on vSwitch0 is assigned to VLAN 101. The green port group is assigned to VLAN 102 and the orange port group is assigned to VLAN 103.

All the ports on the physical switch are configured to support all three VLANs, creating trunk ports or tagging for all three VLANs across all four physical ports.

A Virtual Network Can be Realized in two ways

In summary, you can realize virtual networks in two ways. 

The first method creates multiple virtual switches per host, where each virtual switch defines a network using a single port group. 

The virtual switches will be configured with one port group, and no VLANs will be assigned to the port groups. 

Keep in mind this solution will require more uplinks than method two.

Each virtual switch will need at least one uplink; two uplinks are required if fault tolerance and load balancing is desired. 

Method two creates a single virtual switch per host, where each virtual switch defines multiple networks, by using multiple port groups.

Each port group is assigned a VLAN. 

This solution requires fewer uplinks than the two required in method one to provide fault tolerance and load balancing. 

Normally, at least two uplinks are added to the virtual switch to provide fault tolerance and load balancing. 

The benefits of this are: fewer uplinks are required, less management overhead, and a more scalable design. 

Each scenario has its advantages, but in most scenarios managing fewer virtual switches, as in method two, is preferable. 

Virtual switch Deployment Considerations 

The deployment of both Virtual Standard Switches and Virtual Distributed Switches can be a manual or automated process.

For example, power shell scripts, or vCenter Orchestrator workflows are used to automate the deployment of a virtual switch just before virtual machines are deployed. 

In either case, configuration of the physical switches, routers, and firewalls is needed. 

Access Ports 

The deployment of the virtual switches has been successfully automated using a PowerShell script. 

Virtual networks defined at the virtual switch level have been deployed, so what's next? 

Again, deployment of the virtual switches is only part of the process. 

The access ports on the physical switch will need to be configured, typically before virtual switches are deployed. 

• Do you have permissions to configure or modify the access ports?
• Do you have the specialized knowledge to make those changes? 
• What if you need to automate the entire process? 

Trunk Ports 
Let's assume virtual networks defined at the port group level have been deployed automatically, so what's next? 

Automating the deployment of the virtual switches, port groups and assigning VLANs to port groups is only part of the process. 

Trunk ports must still be configured on the physical switches. 

As the vSphere administrator: 
• Do you have permissions to create or modify the trunk ports? 
• Do you have the specialized knowledge to make those changes? 
• What if you need to automate the entire process? 


Router Configuration 

You also need to consider the configuration of the physical router Here, the vSphere administrator creates two virtual switches and defines two different networks at the virtual switch level or port group level. 

Next. the network administrator configures the proper access ports or trunk ports on the physical switches. 

Let's assume that both teams have completed these steps 

Can these different virtual networks communicate with each other? 
Do the routing protocols need to be changed or updated to Support access to and from the newly defined VLANs? 
The configurations on your data center's physical routers will probably need updating to support these changes Realizing a fully functional virtual network can require multiple steps to complete. both within vSphere. and on your physical network devices. 
Many of the steps to deploy applications and the virtual machines that support them can be automated within your current vSphere environment. 

Once the vSphere virtualization component is completed. without network virtualization in place, it is up to the network team to configure the physical ports. routing protocols and venous network services on the physical network. Due to corporate add or change requests to processes and policies, changes can take network teams days. if not weeks. to implement 

Firewall and Security Configuration Updates 

Now take it one step further. 
The vSphere admins have defined and deployed the virtual networks. 

The networking team has configured the physical access ports or trunk ports, and the routing protocols are properly configured. 

Are the virtual machines on these new virtual networks protected by firewall rules? Do you need to update or add new firewall rules? 
There are many considerations beyond just creating the virtual switches and connecting them to the physical network. 

Additional Network Services 

After virtual switches have been configured and connected to the physical network, and the firewall rules are in place, are there any other physical network services that need to be configured to support these new virtual networks? 

You will still need to configure : 
• Specialized edge gateway or router 
• Load Balancer 
• VPN 
• NAT 
• Virus and malware endpoint protection service or more.

Are these additional network services simple to implement. manage and keep updated? How many different management interfaces will you need? 
How complex does this management become? Can the deployment of these services be automated? 
How well do these additional network services integrate with the newly deployed virtual networks? How will they affect performance, security, and management? 
These are some of the challenges you face in a data center with server virtualization in place. but without network virtualization. 

Networked Virtual Switches Not Equal to Complete Network Virtualization 

As you have seen, even though we can realize a virtual network by creating virtual switches, then fully integrating them with our physical switches, routers, firewalls, and other network services; creating virtual switches is not the same as network virtualization made possible by NSX. 

Without network virtualization in place, after virtual switches are deployed, we must rely on, and wait for the network team to configure the physical switch, router, firewall, and other network services. 
This brings about several network challenges when we work in a data center with server virtualization, but without network virtualization. 

Why Do We Need Network Virtualization? 

Today more than ever, IT departments around the world are being pressured to reduce their costs while at the same time improving system availability and agility. This often poses some unique challenges for the organization, because cost reductions are usually at odds with system-wide improvements. 

We have organized some of these challenges into four categories: 
• Automation
VMware NSX integrates with vRealize automation and include an open REST API. This allows for out-of-the-box or customized automation solution. 

• Elasticity 
VMware NSX provides elasticity by creating logical networks that can span the entire data center. 

• Security 
VMware NSX provides security by allowing complete isolation of network segments, granular firewalling and integration with 3rd party endpoint services. 

• Management 
VMware NSX provides centralized management of virtualized network services such as routing, switching, and firewall services. 
NSX provided a platform that allows integration with a large ecosystem of partners. 


Now you'll explore some of these challenges from the perspective of a company that currently has a private cloud with server virtualization but without Network Virtualization.