Pass Your VMware 2V0-41.20 Exam Easy!

VMware 2V0-41.20 Professional VMware NSX-T Data Center exam dumps vce, practice test questions, study guide & video training course to study and pass quickly and easily. VMware 2V0-41.20 Professional VMware NSX-T Data Center exam dumps & practice test questions and answers. You need avanset vce exam simulator in order to study the VMware 2V0-41.20 certification exam dumps & VMware 2V0-41.20 practice test questions in vce format.

Networking Basics

7. IP Network Basics

In this video we'll cover some IP network basics. And when I say basics, I really mean just the very basics. We're not going to give a full CCNA-level class on routing and protocol and all of that sort of stuff. But I just want to give you some of the most basic concepts, and that way, as we kind of work our way into more advanced topics and other videos like NSX and the distributed logical router, you'll be able to understand those concepts because you'll have a basic understanding of IP networking. So let's take a look at our diagram here. And in the diagram, we can see we have two different networks. And on top of that, we've got the network, which I'm calling the "ten one 100:24 network," and that is our IP network. So that means on this network we have a 24-subnet mask. That means that the first 24 bits are part of the network address and the remaining eight bits, or myzero, are part of the host range of IPS. So based on that, we can kind of ascertain here that the range of IP addresses available is from 10.1 through ten 1255.We typically do not use this first address. Ten one 10—that's the address of our network. And we don't use 10/1/1255 unless we have to do broadcasts. So our actual usable range of iPad addresses will be ten to one. And I've got these machines connected to the same switch. It could be a physical switch or a virtual switch. Regardless, I've got these machines on this network connected to the same switch. And here's a layer-two domain; here's a layer-two network interconnecting devices that are on the same IP address range. Well, what happens when my machines that are on this network want to talk to devices that are on some other network? We're going to have to use something called our default gateway. And in that case, that's the route that we have pictured here. So the router is going to act as our default gateway for our machines. And again, this is true if you have physical machines or virtual machines; it doesn't matter. You'll go into the guest operating system. Let's assume it's Windows. You'll go into Windows, and you'll configure a default gateway for your machine. And what that default gateway means is that basically anything that's on some other network, anything that falls outside of this IP address range, needs to be sent to the default gateway so that it can be routed to another network. We can't have machines from different networks on the same Layer 2 domain. We can't have virtual machines or physical machines on the same switching segment if they're on different layer-three networks. So that's what we're going to use that default gateway for. So when you think of that default gateway and that configuration that you do in Windows, basically all you're saying is that for any traffic that is on some network other than this network, send that traffic to my default gateway. And the default gateway is a router. The router works at layer three of the OSI model. So let's say, for example, we have a machine here at ten one two. And it goes, and it sends some traffic toward 192-1681-2, some machines on the 192-16810 network. Well, that traffic is going to be directed towards the default gateway, and the default gateway will receive that packet. And here's what that packet looks like. When the packet arrives at the router, it'll have a source and destination IP address, and the router will open up that packet and essentially analyse the contents of that packet, and it'll say, "Okay, the source IP is coming from ten one one two." The destination IP is 192 168, one two.And at this point, the router will realise I have an interface on that network; I have an interface on the 192.168.1.2 network. And so it'll forward that packet towards that network, where it can eventually reach the destination virtual machine. So what the router is essentially doing in our network here is interconnecting multiple layer 2 networks. It knows how to get to each of those networks by using its routing table. And it's going to receive traffic from one network and forward it to the appropriate network. And so what the router will have is something called a routing table, which I just mentioned. And in this scenario, we've got this router, and it's connected directly to these two switches. So let's assume it has a direct connection to these two Ethernet switches. The router is always going to be aware of those directly connected networks. We'll configure IP addresses on those router interfaces, and it will automatically be aware of those directly connected networks, and it will build entries in its routing table to reflect those networks. So here's what our routing table will look like. It'll look something like this. We'll have interfaces on the router, and we'll have networks associated with those interfaces. As a result, any packets bound for the ten-dot, one-dot, one-dot-zero network will be routed through interface 1. And if those packets are bound for the 192-16810 network, those packets will be forwarded out through interface 2. Now this is really the most basic iteration of the routing table. There are a lot of other ways that our routing table entries can be populated and updated. We can use static routes or we can use dynamic routing protocols. But that's not really what I want to get into here. I just want to show you the basic concept of a router, what its job is, and what a routing table looks like. We're not going to get into how to build a dynamic routing table or anything like that just yet. One final item of review is just some kind of talk about our OSI model. Let's bring it back to the OSI Model. Let's look at our layers here. So I have a machine that is physically connected to the switch, not through physical cable, that is layer one, the physical cable between the switch and the router and the other switch and this other router interface, those are all my layer one connections, my physical media and the actual physical switch itself and the router itself, those interfaces, those are all my layer one components. At layer two, I have Mac addresses on an Ethernet network. So when this machine ten, dot one, dot one, dot two sent that packet towards its default gateway, the IP addresses weren't the only ones on there. A source and destination Mac address were also provided. That is my addressing scheme layer. So if we take a deeper look at that packet, let's drill down into the source and destination Mac and the source and destination IP addresses to understand how our layer two and layer three addresses differ. Here's a more detailed look at that same packet that we looked at before. So in this scenario, again, this virtual machine up here, the 10 1 2, is trying to communicate with 192 dot 168, dot one, dot two. And so because that destination is on a different network, what that source machine will do is send the frame to the default gateway. And so in this case, the source Mac address is the Mac address of this machine. Let's call it Mac A. The destination Mac is the Mac address of the router. Let's call it MACR One. So when that Ethernet frame gets sent out, the router will receive it. It'll analyse the source and destination Macs, and it will determine at a layer-two level whether this frame is down for me. I'm the destination Mac address. At that point, those source and destination Mac headers are gone. They're discarded. We don't need the match headers anymore because, at this point, the communication across each layer to the network is complete. So let's dispose of these. And then at that point, the router will analyse the layer three headers. It'll dig one layer deeper; it will see that the source IP is ten dot one, dot one, dot two, and that the destination IP is 192, 168, one two. And the router will realise that's not me, I'm not the destination IP, and this package is not bound for me. It's down for some other device on that 192 dot 168, dot one, and dot two network. so that it will analyse its routing table and determine whether I've got an interface connected to that network. So what does this packet look like as it leaves the router and heads towards that destination machine? Well, the first thing that we notice is that the source and destination IP don't change. That part is not going to change at all. We still have the same source IP, which is this machine up here, and we still have the same destination IP, which is this machine down here. So the layer three addresses don't change at all. But from a layer two perspective, the source Mac as it leaves this router is now this interface on the router. And now the destination Mac is the Mac address of our receiving machine. So what I want to illustrate here is that these layer-two Mac addresses are unique to their layer-two segment. That's the only place that those addresses are significant. When we saw frames flowing within this layer to the domain up here, those sources and destination Mac addresses were relevant. As soon as that frame gets routed by a router to some other layer in the network, those source and destination Mac addresses from up here lose their significance, and new source and destination Mac addresses are appended. So what we see here is two Ethernet domains, right? We have one Ethernet domain up here, one Ethernet main down here, and they are interconnected by a layer 3 device, a router.

8. Address Resolution Protocol (ARP)

In this video, I'll explain the concept of our requests, and we'll look at how an ARP request is handled by an Ethernet switch. So here we see a pretty simple diagram of two devices connected to an Ethernet switch. This could be virtual machines or physical machines, but there's some sort of device that's connected to an Ethernet switch. For the sake of this example, let's assume that they're Windows machines. And let's assume that the machine on the left with Macaddress A and IP address 10 dot one, dot one, dot two) wants to communicate with the machine on the right. Let's say it wants to send a ping to it. Now, within the source virtual machine, there's going to be an ARP table. And what an ARP table is, essentially, is a list of mappings that map IP addresses to Mac addresses. Because if my source VM wants to communicate with this destination VM, that's going to happen over a layer-two network. This traffic is not being sent to the default gateway; it's not being sent to a router. It's going to be direct communication over that switch between these virtual machines. So in order to accomplish that, the source VM needs to know the Macaddress of the destination virtual machine. So let's say I go into my Windows operating system on my source VM and I type in the command ping ten one one three. And my arc table in the guest operating system of the source virtual machine does not currently have an ARP table entry for that IP address. That means at this point, the sending VM doesn't know the Mac address of the receiving VM. What will happen at this point is that the source virtual machine will generate an ARP request, and an ARP request is a layer to broadcast. So the source VM will send out this broadcast basically saying, "Who has IP address ten, one, three?" It'll send that broadcast to the physical or virtual switch. And at that point, the switch will flood out every single port that the switch is connected to. Every port on that layer-two domain And a bunch of machines are going to see this request that don't need to see it, right? It's a broadcast. So it's going to hit everything until it eventually hits the appropriate machine. And this machine is going to say, "Yeah, ten one-one-three, that's me, let me generate an arc response." And it will then send an arc response to the source machine to provide it with that IP-to-MAC address mapping. So then in the future, if the source machine generates some traffic destined for 10 1 1 3, that can be unicast traffic that goes directly to that destination virtual machine. So it's in our best interests to minimise this ARP traffic as much as we possibly can because it's broadcast traffic and it generates a lot of overhead on our network. When we get into NSX, we'll take a look at how NSX suppresses these requests and kind of minimises the number of broadcasts that are required on a layer for the network. So, in summary, an ARP request is simply a request by a virtual machine to discover the destination Mac; it already knows the destination IP. It's trying to communicate with something that's on that same network, that same layer-two network. So it issues an ARP request to discover the destination Mac.

vSphere Networking Fundamentals

1. About this Section

Spend some time discussing Vise for standard and Vise for distributed switches as well. If you're already very comfortable with these concepts, please feel free to skip the next three lessons. But if you're not familiar with these concepts, I definitely recommend watching the next three lessons as they will be very informative as you start learning about NSX. So if you already have a strong background with VSphere Virtual Networking and you don't feel you need those lessons, go ahead and move on to the next section.

2. Virtual Networking Basics

In this video, I will 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. Our guest operating system, in this case Windows, is completely unaware that the virtual nick is not a physical 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 packets to the virtual nick, and 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 VMs on NX. And if my traffic needs to flow to the Internet or to some physical server, it'll do so using these VM nicks or physical adapters. So a VM nick is basically an uplink for a virtual switch that gives 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 our server would connect to. 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 V centre used 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 at the bottom is connected to a different port group with a different VLAN assigned. So as traffic flows into the virtual switch from myVM 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 of 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: 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 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 pork groups. And each virtual machine is going to be equipped with a virtual neck. You may have heard some of the options. There are, like a VMX net, three virtual network interface cards. 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. Then we've also got these special ports on the virtual switches called VM kernel ports. And this is another important concept for the exam. VM kernel ports are used for managed traffic, storage traffic, and V motion traffic.

3. vSphere Standard Switches

In this video, I'll explain certain attributes of the VSphere standard switch. Specifically, we'll talk about how Nic timing is performed and how we can configure our VM decks or physical adapters to tolerate failures. So our VM necks are actually the physical adapters of the ESXi host itself. And each VM neck can only be assigned to a single virtual switch. Our virtual switches can't share VM necks. So in this slide, we see a virtual switch with three physical adapters, or Vmix. And our network is in a healthy state. So all three of my adapters are connected and have a nice green link light. At this moment, traffic for this virtual machine is currently flowing through the first physical adapter. And let's say that something happens. Like, for example, let's say we have a new intern, and we send them into the data center, where we say, "Go ahead and clean up the cables." And he goes in with his scissors, starts cutting cables, and just so happens to cut the wrong cable. Well, now, in this situation, our nice green link light on that VM isn't green anymore. Now the connection has been physically broken. And this is something that's very easy for the ESXi host to detect, and it will simply redirect that traffic to another port that's still functional. Now, let's talk about a more complicated failure. Let's assume that cable that justgot caught, we fixed it. So now all of my network adapters are connected. And again, we have a nice green linklight on all of those physical VM nicks. And in this case, our virtual machine traffic is flowing through this third adapter. And again, we go ahead and we send the intern into the data center, and we say, "Okay, careful this time, but go ahead and keep on cleaning up those cables." And this time, he cuts a cable that interconnects our two physical switches. Now, this is a little bit different because in this scenario, the link state of the VM NIC doesn't change. That nice green link light is going to remain green. But if we look at our diagram here, traffic from this virtual machine is now flowing into a physical switch that's essentially isolated. It doesn't have any connectivity to the other physical switch, and therefore, it doesn't have any connectivity to the Internet. So at this moment, adapter Three is flowing into a dead end. This is where beacon probing can be helpful. Beacon probes are little packets that myVmix sends out to each other to just validate that they're still operating well. So here we see the two VM nicks at the top of our screen being able to pass these beacon probes and successfully communicate with each other. However, our third adapter is flowing into a dead end. So although those two adapters on the top can communicate, the adapter on the bottom is sending these beacon probes into a physical switch that the other VM necks can't see right now due to this upstream network failure. When the host realises it isn't seeing those beacon probes from the third adapter, it will disable that adapter and redirect virtual machine traffic to another VM neck. Now, let's talk about some of our nick-teaming options. What we're trying to accomplish here is to have multiple VM nicks or multiple physical adapters that are connected to a virtual switch. And we want to ensure that our virtual machine traffic is able to utilise all of these physical adapters. So we're going to have to configure some sort of nick timing method to allow those adapters to load and balance that traffic. And the first option is a method called "nick timing" by originating virtual port ID. Now, how this works is that each virtual machine will be connected to a virtual port on our virtual switch. And based on the virtual port ID that the VM connects to, all of its traffic will flow out of one specific VM nick. And if our second VM connects to a different virtual port ID, its traffic will be routed through a different VM nick. same thing with our third virtual machine. Now, in this scenario, each VM is essentially tethered to a specific physical adapter, and all of that virtual machine's traffic will flow through that one physical adapter. And this is how nick timing by originating port ID spreads that workload out across all of these physical nicks. Now, in this scenario, it's important to understand that what we want to do is configure the physical switch without port channels, without LACP. We don't want any of that nick teaming to occur on the physical switch side. The physical switch has to see these four physical connections as completely independent. And that's the same situation when we go to source match hashes. So with Source Match, it's actually very similar to the method that we just looked at, maybe for a virtual machine One has a unique Mac address called Mac One. And based on that unique Mac address, that VM is going to be associated with a specific VM neck. The same is true for VMs two and three. Based on their Mac addresses, they will be tethered to one specific physical adapter, and we'll use that for all traffic that needs to leave the ESXi host. Again, we don't want to configure LACP ethernet and port channels. We don't want to configure any of that stuff on the actual physical switch in this case. Now, the final nick teaming method that's supported by the standard virtual switch is one called IP hash. And here's how IP hashing works. Here you can see that we have a virtual machine with IP address 1. When that virtual machine goes to send some traffic to a particular destination with a unique IP address, that traffic can flow over a physical adapter. And the physical adapter is selected based not only on the source IP but on the destination IP as well. So now if the same virtual machine happens to be sending traffic to some other destination with a different destination IP, that traffic can actually flow out of a different physical adapter. And this is different than the prior nicktiming methods that we saw because now my virtual machine can actually utilise multiple VM nicks. So in this scenario, it's important that the physical switch is appropriately configured. We want to set up port channel, or LACP, on the physical switch to bind these physical adapters together. Another feature that's supported on the VsfairStandard switch is something called traffic shaping. What traffic shaping does is apply settings such as peak bandwidth, average bandwidth, and burst size to a port group. So, for example, let's say that we have a group of virtual machines connected to a port group on a Visa standard switch, and sometimes we test new applications on these VMs or do something else that's resource intensive. And as a result, these VMs tend to dominate the bandwidth of that virtual switch, and other VMs on other port groups sometimes can't get the bandwidth they need. Well, what we can do is apply traffic shaping to a port group so that, essentially, on this particular port group, each VM will have a peak bandwidth of 100 megabits per second. Each VM on this port group will have an average bandwidth of 50 megabits per second. And over time, that's what the virtual machines must average out to at a maximum of 50 megabits per second. So because this particular virtual machine is connected to a port group that has this traffic shaping policy assigned, this policy will be enforced on this particular VM. So under normal circumstances, this VM should be averaging 50 megabits per second or less in bandwidth usage. However, let's say there's some large file that we need to upload. Well, for a short period, this VM can actually utilise 100 megabits per second, or its peak bandwidth rate, until it completely uses up what we call burst size. So for this VM, maybe we'll say our burst size is 100 megabytes. And again, that's defined as a port group level, not an individual virtual machine level. So let's say at the port group level, our traffic shaping policy specifies a 100 megabyte burst size. This VM will be able to transmit at 100 megabits per second until it uses up that 100 megabyte burst size maximum. And then the virtual machine will be forced back down to the average bandwidth of 50 megabits per second. And it will not be able to exceed that until it builds that burst-size backup. Now, how does it build the burst size back up? By staying below that 50 megabits per second average for enough time to essentially save up 100 megabytes worth of birth size again, And so in that way, traffic shaping can really help us to ensure that one particular port group doesn't completely overwhelm the physical adapters of an ESXi host. There may be many port groups with different types of traffic connected to this Visa standard Switching and traffic shaping just give us the ability to place limits on how much bandwidth each VM within a port group can actually consume. We can also configure some security settings on a VSfair standard switch. These can be configured at either the virtual switch or the port group level. If we configure these settings at the virtual switchlevel, they will be similar to our global settings. So maybe we want to enable forging on a virtual switch. If we do so at the virtual switch level, what this means is that that setting will apply to all port groups on that virtual switch. Now, if we go to an individual portgroup and modify that setting, the settings that are created at the group level will override those global virtual switch ride configurations. So one of the settings that we can modify is called "Forged Transmits." Let's say you have a virtual machine and, for some reason, you need to modify the Mac address of that virtual machine. Maybe it has been converted from a physical machine to a virtual machine, and you have some software that is licenced based on Mac addresses. So we need to keep the same Mac address that we had in the physical environment. That's a good use case for Mac spoofing. And so in that case, when that virtual machinegenerates traffic, it's going to be using the Macaddress that we've specified in the guest operating system. Now, the virtual switch isn't going to like that. The virtual switch expects traffic to come on that port from the Mac address of the virtual nick of that VM. So if it sees traffic coming in on some otherMac address, that's called a Forged Transmit and we canchoose to either accept or reject that traffic by default,the virtual switch is configured to accept it. And by setting this to accept, we're going to allow Max-Boofing for outbound traffic. Another security setting is Mac address changes. And Mac address changes are basically the exact same setting for inbound traffic. So now let's say some traffic is coming towards a virtual machine, and the destination Mac is some Mac address that we've configured in the guest operating system that is inconsistent with the actual Mac of the virtual Nic. To allow this traffic through, Mac address changes must be set to accept, which is the default setting in a virtual switch. Mac address changes and Forge Transmit are both set to accept Now, if you don't need this MaxSpoofing capability, I recommend you go into those virtual switches and change those settings to reject because that'll be more secure. Finally, the third security setting is something called promiscuous mode. And promiscuous mode allows sniffing of all the traffic on a virtual switch. This is not a secure option to leave enabled all the time. Maybe you need to install sniffer software on a virtual machine and monitor all of the traffic on a virtual switch. for some reason. That's a good reason to enable Promiscuous Mode, but you're essentially opening up your network and allowing it to be sniffed. So of course, promiscuous mode isn't something that we want on all the time because it presents a pretty serious security risk. So the recommendation is to turn promiscuous mode on when you need it, and when you're done, turn it back off. Vs. Fare. Six supports multiple TCP IP stacks. So what is a TCP IP stack? Well, it provides DNS and a default gateway. For example, the default gateway is used when traffic is bound for some other network. Let's say you go into Windows on your machine and you type in www.trainertests.com. Well, that traffic is bound for some address on the Internet, and so therefore, that traffic needs to hit something in your network that's capable of performing routing to that other network. That's your default gateway. And you may have different machines in your network that need to use different networks for different things. And in that case, you might need multiple default gateways. That's part of the TCP IP stack. So built right into your ESXi host is the default TCP IP stack, and that's used for management traffic and all other types of traffic by default. But if you want to, you can utilise a separate TCP/IP stack for V-Motion traffic. And this is useful if you need to send V-Motion traffic to some other network. Let's say, for example, you plan to do a lot of long-distance V motions. You might have another network that you want to send that V motion traffic over. So by giving V Motion its own dedicated TCP IPstack, you can direct that V Motion traffic to a different default gateway or a different DNS server. And we can do something similar for provisioning and for cold migrations, for example, cloning snapshots. We can send that traffic through its own dedicated TCP IP stack, and we can create custom TCP IP stacks as well. Okay, so in this lesson, we learned about the following topics. We learned about virtual switches and how we can protect them from a network interface card failure by using either link state or beacon probing. We learned about the different nick timing methods and how they can be utilised to loadbalance across our VMX or physical adapters. We learned about originating virtual port IDs, which essentially tie each virtual machine to one VMNIC based on the virtual switch port. Very similar to that was Source Match, which ties its virtual machine to a physical adapter based on the Mac address. And the third method was a little bit different, right? The IP hash was based on not only the source IP, but the destination IP as well. And with that method, we saw that virtual machines had the ability to utilise multiple physical adapters. We talked about traffic shaping and how it can provide bandwidth control on a per-virtual-machine basis, and that traffic shaping is going to be configured on a port group. And then finally, we talked a little bit about the multiple TCP/IP stacks that are included with VSFare Six so that we can use different default gateways for different types of traffic.

Go to testing centre with ease on our mind when you use VMware 2V0-41.20 vce exam dumps, practice test questions and answers. VMware 2V0-41.20 Professional VMware NSX-T Data Center certification practice test questions and answers, study guide, exam dumps and video training course in vce format to help you study with ease. Prepare with confidence and study using VMware 2V0-41.20 exam dumps & practice test questions and answers vce from ExamCollection.