VMware VCA 1V0-701 – VMware Certified Associate 6 (Retired)

16. Virtual Networking

In this video, we’ll explain some of the concepts behind virtual networking and how our virtual machines can connect to other resources, either within the same ESXi host or possibly even resources connected to our physical network. So, how do virtual machines actually handle transmitting and receiving network traffic? Well, in many ways, they work exactly the same way that a physical machine does. So, here we see a virtual machine, and it has a network interface card just like any other network connected machine. But in this case, we’re dealing with a virtual nick.

Now, our guest operating system, in this case Windows, has no idea that the virtual nick is not an actual hardware device. Windows just sees a network interface card. And from the perspective of the guest operating system, that’s really the end of the story. So, Windows sends some packet to the virtual nick, and my virtual Nic, just like a physical nick would, my virtual nick needs to connect to a switch.

So, our virtual machines will connect to a virtual machine port group on a virtual switch. And the port group is used to define settings like VLAN membership and security policies and stuff like that. And my ESXi host also has physical interfaces, but my traffic doesn’t necessarily need to flow over a physical interface. If I’ve got multiple virtual machines connected to the same port group, they can communicate without their traffic ever flowing over a physical network. And then, of course, my ESXi host itself has some physical network interfaces that connect to a physical switch. These are called VM nix.

And if my traffic needs to flow to the Internet or to some physical server, it’ll do so using these VM nix or physical adapters. So, a VM nick is basically an uplink for a virtual switch that gives a connectivity to the actual physical network. But our virtual machine port groups are really only half the story. My VM port groups are for all of my virtual machine traffic.

Everything else is going to be handled by a VM kernel port. So, the virtual machine port groups are kind of like ports on a physical switch that a PC would connect to or server would connect to. Whereas VM kernel ports are special types of ports on a virtual switch that are used for traffic like V motion or IP storage or management.

These are ports that the hosts and Venter use to talk amongst themselves for purposes other than virtual machine traffic. And then our hosts and our virtual switches also support VLANs, and they support trunk ports, as well. So, for example, let’s say I’ve got two virtual machines here. The virtual machine on top is connected to a port group with VLAN ten assigned to it.

So, my VM on the top of my diagram here is connected to a port group that has VLAN ten assigned. And my VM on the bottom is connected to a different port group with a different VLAN assigned. So as traffic flows into the virtual switch from my VM on the top of the screen, it’s going to hit a port group that’s tagged with VLAN ten. And if that VM is trying to communicate with the other VM, that traffic is actually going to have to flow out the physical network to a switch, hit a router that can route between VLANs, and eventually that traffic will flow back in. And that’s kind of how our VLAN segmentation works with a virtual switch is each VM will connect to a port group. Those port groups will have VLANs defined, and we will have a trunk port to a physical switch that is able to handle traffic across multiple VLANs on a single physical connection.

That way the physical switch can actually see a consistent set of VLANs and can see which virtual machine traffic belongs on which VLAN as that traffic arrives. So for the purposes of the VMware certified associate exam, you really want to understand that there are these things called virtual switches that exist within the ESXi host, and on them we’ve got virtual machine port groups, and each virtual machine is going to be equipped with a virtual nic. You may have heard some of the options.

There like a VMX net three virtual Network interface card. Those are going to provide connectivity to the virtual machine port groups on the virtual switches. It’s basically like having a fake switch running inside of your ESXi host that interconnects all of those VMs on that host and also applies VLAN tagging and security policies based on those port group memberships.

17. Virtual Switch Policies

In this lesson we’ll learn about Vsphere standard switches and we’re really going to focus on a lot of the policies that you can configure. This is one of the objectives of the VMware certified associate exam, is to be able to identify and explain these different virtual switch policies. So that’s what we’re going to take a look at here is the different virtual switch policies that can be created on a Vsphere standard switch. And one of the first policies covers how do we handle the failure of a physical network adapter. So VM nix are the physical adapters of the ESXi host and each VM nick can only be assigned to a single virtual switch. Virtual switches cannot share VM nicks. So in this slide, we see a virtual switch with three VM nix. And our network is currently in a healthy state. So all three of my adapters are connected. They have a nice green link light and everything is working properly. And I’ve got this virtual machine on the left and the traffic for this virtual machine is currently flowing through the first adapter.

Now, let’s say that we have some sort of problem, like maybe somebody is cleaning up some cabling for us and they cut the wrong cable and that network connection that’s currently being used by this VM is now down. So at this point, this VM neck, this physical adapter has lost connectivity. It can’t connect to the physical switch. And so my VM is going to be affected as a result because my VM was using that physical adapter. But this is actually a really easy failure for the ESXi host to detect. And when that connection fails and that link light changes from green to red, the ESXi host will simply migrate the traffic of that VM to a different physical adapter.

And so there’s a few different policies that we can configure that will control, number one, how traffic fails over from one adapter to another. And number two, how traffic is load balanced if we have multiple VM nicks available. And that’s what we’re going to take a look at now. So our first policy is called the nick teaming by originating virtual port ID. And in this scenario, what we have here, and by the way, this is the default option for a virtual switch. So what we have here is a virtual switch with 1234 VM nix, four physical adapters. And I’ve got three virtual machines. And so my three virtual machines are all going to be generating some network traffic and I want to equally distribute that traffic across these four physical adapters, these four Vmnecks.

So the way that nick teaming by originating port ID works is each virtual machine is connected to a certain port on the virtual switch. And based on the port that it’s connected to on the virtual switch, that VM will be tied to a specific physical adapter, a specific VM nick. So for VM one, all of its traffic as it flows out to the physical network is going to be handled by VM nick One for VM Two. VM Two is connected to a different port on the virtual switch. So therefore, it will use a different physical adapter. We’ll just call it VM? Nick two. And for virtual machine Three, that’s connected to yet another virtual port on the virtual switch. And so what the virtual switch is essentially doing here is it’s saying as each VM connects up to a different virtual port, we’re going to tie each VM to one specific physical adapter. And any traffic for that VM that needs to hit the physical network will flow through that one single physical adapter. So any traffic for VM One is always going to flow out of VM nick One. Now, if VM nick One were to happen to fail, then at that point the ESXi host would modify this and basically tie VM One to a different port.

Another option is nick teaming by source Mac hash. So if you don’t know what a Mac address is, every virtual machine has a unique layer to address called a Mac address. And just think of it as a unique identifier that every single virtual machine has one of these. And Macache works pretty similarly. What it basically does is, based on the Mac address, each VM is tethered to a physical adapter. So this particular VM has, we’ll call it Mac Address One, even though it would be like a large hexadecimal number. Based on that, that virtual machine will be tied to a specific physical adapter.

And as we kind of go down through the remainder of our diagram here, we can see basically the same thing is happening as happened in the previous slide, right? Each VM is being tethered to a different physical adapter. The only difference is it’s now based on the Mac address and not based on the originating virtual port. And again, if one of these physical adapters were to fail, the virtual machine would be dynamically migrated to another physical adapter, again based on the Mac address. Now, what these first two methods have in common is that basically the way it’s set up is each virtual machine is bound to one specific physical adapter, right?

So if we look at VM One, for example, VM One’s, traffic is always going to go out of adapter number one. That’s always where its traffic is going to flow. If VM One has a ton of network traffic, let’s say it’s like an FTP server or something like that, it can never use the bandwidth of VM nick Two or the bandwidth of Vmnec Three, right? We can’t distribute that virtual machine’s workload over multiple physical adapters. It doesn’t work that way with source Mac hash, and it doesn’t work that way with originating virtual port ID. IP hash is a little bit different. IP hash distributes traffic based on source and destination IP. So, for example, if this virtual machine is generating some traffic towards a destination that we will call Destination One. Destination One has its own unique IP address.

So based on the source IP and the destination IP, a physical adapter, in this case VM nick One will be chosen. Now if this virtual machine also generates some traffic to some other destination, well again the VM nic use is going to be based on the source IP and the destination IP. So because this traffic is flowing to a different destination, it’s going to be load balanced across a different physical adapter, different VM nick. And now my virtual machine is actually able to utilize the bandwidth of multiple physical connections on my virtual switch so that’s nick teeming by IP hash. Now there’s a lot of other considerations that go into this that we kind of start to get into in the Vsfair foundations course. But you need to think about things like Ether Channel and trunk ports and there’s a lot of other considerations that go into choosing the appropriate nicknaming method.

But as far as the VMware certified associate exam goes, you just want to understand these at a high level. And we’ve really gone into enough detail here for the associate level certification. Another policy that you can enable is called traffic shaping. So for example with traffic shaping, what we’re doing is we’ve got this virtual machine that’s part of a virtual machine port group. And on this port group we can identify certain traffic shaping characteristics like what is the peak bandwidth allowed per virtual machine and what is the average bandwidth allowed per virtual machine. And the goal here is essentially this. We might have a whole bunch of VMs on different port groups all connected up to this Vsphere standard switch. And if this one VM happens to be really network intensive, it could chew up a ton of bandwidth. Or if I have like a bunch of VMs that are on my development poor group and we’re testing something out, well they could potentially chew up all of the bandwidth for that particular Vsphere standard switch. And now all of the other VMs connected to that Vsphere standard switch will suffer as a result. That’s the purpose of traffic shaping. We’re implementing basically some maximums. We’re saying that if a VM is on this port group we’ve identified, hey, at any given time each VM can generate this much traffic peak and this much traffic on average over the long term. That’s what it’s got to average out to.

So that’s how traffic shaping works. It’s just a way to make sure that like a noisy neighbor type situation doesn’t occur where one small subset of virtual machines is using all of the bandwidth. Again, much more on this in the Vsphere six foundations course, or I should say the Vsphere six five foundations course. But for the purposes of the VMware certified associate, you just want to understand that traffic shaping is a way to ensure that a subset of VMs does not use all your bandwidth. And then there’s a number of security settings that you can configure as well.

They can be configured at the virtual switch level or at the individual port group level, and we can set up things like forged transmits, Mac address changes. And with forged Transmits and Mac address changes, what we’re doing is we’re allowing Mac spoofing. If we want to allow our virtual machines to use fake Mac addresses that don’t match up with their virtual Nic, we can do that. And we can also use security settings like Promiscuous mode if we want to allow a sniffer to be attached to our network.

So, again, for the VMware certified associated exam, you really want to understand the fact that these security policies can be modified to basically harden our network, make it more secure, and that they can be controlled either at the virtual switch or the port group or even at the virtual machine level. Okay, so in review, we learned that virtual switches can be protected from Nic failures using a variety of nick teaming methods, which also are utilized to load balance traffic as well.

And different nick tummy methods balance that traffic differently. So, with originating virtual port ID and source Macache, we saw that each VM was basically tied to one specific adapter based either on the original virtual port or on the source Macache. Whereas with IP hash, we saw that virtual machines could actually take advantage of the bandwidth of multiple physical adapters, and it’s based on the source and destination IP.