Faddom Raises $12M for Our Agentless IT Infrastructure Mapping Platform
Search
Close this search box.

VMware Networking Basics

Read Time: 4 minutes

Standard ethernet networks allow devices to communicate with one another. This is done through physical devices such as switches, routers and firewalls. Much of these same concepts also apply to virtual networks. In this post, we will take a look at the basics of networking on VMware and see how they compare to and interact with the physical network. (For more information, see our Guide to Microsegmentation.)

Switches

First, let’s take a look at switches. One of the core components of any network is the network switch. Physical switches contain multiple ports to which devices can be connected to. The switch then learns which device is connected to which port, and then allows for the sending of data between those devices. In VMware, we have the virtual switch which does the same thing, only for virtual machines.

VMware supports different types of switches, the most common of them being standard switches and distributed switches. While there are some differences between the switch types, their basic functionality is the same. Then main differences between these switch types are in terms of how they need to be managed. Standard switches are defined and managed separately on each host, while distributed switches are defined at the vCenter level and then can be assigned to multiple hosts. Distributed switches also have some additional features such as Netflow support. Using distributed switches also requires an Enterprise Plus license for vCenter.

For traffic between VMs on the same host and in the same network subnet, this traffic doesn’t even need to leave the virtual environment and remains entirely on the host. If the communication is between network subnets or between VMs on different hosts, the virtual switches must be connected to the physical network. The connection to the physical network is done using uplinks, where each switch can be assigned one or more network adapters that it can use to communicate with the physical network.

After the switches are configured on a host, VMs can be connected to those switches to allow them to communicate with each other. The connection between the VM and the switch is done through a Port Group.

Port Groups

The concept of port groups is unique to virtual networks and it provides some control over how a VM is connected to a virtual switch. Just as with virtual switches, there is more than one type of port group. There are standard port groups which connect to standard switches, and distributed port groups that connect to distributed switches. Their functionality is almost identical, as in the switches, except for the central management available through vCenter for the distributed port groups.

The port group defines which VLAN to connect to (if at all) and can also define some security features such as if promiscuous mode is allowed. It can also set bandwidth limitations. You can define multiple port groups on a switch and then assign VMs to the port groups.

In order to connect a VM to the network, you assign it a port group. For each network adapter that is added to a VM, you select which port group it connects to, which then defines which switch it connects to.

VMkernel Networking

The last concept we will go over is VMkernel networking. This is a special type of adapter which defines how a physical host will connect to the network for management purposes. VMware uses these adapters internally to facilitate the communication between the VMware hosts and vCenter for all of the internal tasks required to manage the hosts.

The VMkernel adapter is attached to a virtual switch and then uses the uplink ports on the virtual switch to communicate with the rest of the network.

Best Practices for VMware Networking

According to VMware, there are a number of best practices that you can use when setting up your networking. Here are a few that can help you to get started.

  1. Don’t set timeouts or connection limits between products:

    This can impact the packet flow and cause interruption to services, impacting the stable connection between products such as vCenter Server and your ESXi host.

  2. Be smart about isolation:

    Isolate networks for host management, vSphere FT, vSphere vMotion and more. This will have a positive impact on security and performance. You can also use I/O control and traffic shaping procedures to make sure that a guaranteed level of bandwidth goes to your VMs to handle traffic.

  3. Separate network services:

    Either use a separate standard or distributed switch for each network service, or use different VLAN IDs to separate network services within a single switch, attached to port groups. This will ensure your networks and network traffic are isolated from the rest of the environment. Physical network adapters that are connected to the same standard or distributed switch should be connected to the same physical network, too.

  4. Always leave one network adapter available:

    Add and remove network adapters from either the vSphere standard switch or the vSphere distributed switch without worrying about impacting the network service and the VMs. In fact, as long as one network adapter is left intact, all your VMs will be able to connect with the network.

  5. Use firewalls:

    If you’re running sensitive data or information on your VMs, deploy firewalls on any VMs that route traffic from virtual networks with uplinks to physical networks or pure virtual networks.

  6. Think about the MTU:

    Your maximum transmission unit on all of your VMKernel network adapters should be the same within a single distributed switch. If not, you may find that you have some problems with your connectivity.

In Summary

Networking concepts in VMware are very similar to those on the physical network, only they are done in software instead of having to physically connect cables to servers. Virtual networking allows for a lot of flexibility when configuring and managing your networks, especially if you start with best practices in mind.

Map All Your Servers, Applications, and Dependencies in 60 Minutes

Document your IT infrastructure both on premises and in the cloud.
No agents. No open firewalls. Can work offline.
FREE for 14 days. No credit card needed.

Share this article

Map Your Infrastructure Now

Simulate and plan ahead. Leave firewalls alone. See a current blueprint of your topology.

Try Faddom Now!

Map all your on-prem servers and cloud instances, applications, and dependencies
in under 60 minutes.

Get a 14-day FREE trial license.
No credit card required.

Try Faddom Now!

Map all your servers, applications, and dependencies both on premises and in the cloud in as little as one hour.

Get a FREE, immediate 14-day trial license
without talking to a salesperson.
No credit card required.
Support is always just a Faddom away.