Understand VMware NSX Fundamentals

0:00Hello, and welcome. My name is Keith Barker. And one of the things that I really enjoy working on are the nuts and bolts of IP networking, whether it's IP version four, or IP version six. I love IP networking. And so when CBT Nuggets came to me and said, "Hey, Keith, we're gonna create this VMware NSX course. Do you wanna be part of it?" I said, "You betcha. Two thumbs way, way up. I love networking and I love VMware." And NSX brings those both together. Now, one of the things that I've discovered is that those individuals who are just starting off with NSX, because there are quite a few moving parts and pieces and terms and new vocabulary, that sometimes at the beginning it's a little bit overwhelming.

0:37So here's what you and I get to do in this skill. We are going to walk through logically the big picture of how NSX works, including a lot of the vocabulary and terms and logic. And our objective together in this skill is simple. We wanna have a solid foundation on which we can build upon, so that as we proceed forward, if we hear the terms of "transport nodes," or "edge nodes," or "TEPs," or "tier-0," or "tier-1 gateways," they won't be foreign to us. We'll have good kinda a feeling for where those fit in and what those are in the infrastructure. And one of the important aspects to be aware of is that the NSX and a VMware vSphere environment is built upon the software-defined data center infrastructure that vSphere presents.

1:17So here's our roadmap for this set of videos in this skill. We're gonna first take a look at a quick overview of software-defined data centers, just the basic nuts and bolts regarding vSphere and vCenter and ESXi host and how that all fits together. And then with that in mind, we'll take the next logical step and we'll add onto it the components that NSX brings to the table, including the features it brings, and also the terms and the vocabulary, and some of the core elements that make it possible. So if you, my friend, are ready for a big picture look at the world of NSX, you are in the right place. And I'll see you, my friend, in the next video.

0:00So starting off, I'd like to make sure that you and I are on the same sheet of music regarding the basic infrastructure for the software-defined data center, or SDDC for short from VMware. And one of the core components of that infrastructure is the hypervisor called ESXi. So ESXi runs on top of hardware, usually, it's a pretty hefty server that has lots of CPU, and memory, and network access through network interface cards. These days, a lot of those network interface cards are 10 gigs each.

0:30And that ESXi host also has some storage, and that storage could be local or the ESXi host may have access to network-based storage as well. So the hypervisor, think of it like an operating system that's running on top of the hardware, in the case of ESXi, it's a specialized, dedicated operating system for host hardware, that could then provide a home for one or more VMs. And also with the right licensing, some containers as well. So the hypervisor's responsible for doling out and providing the resources regarding CPU, and memory, and network access, and storage, for each of the VMs or containers that are running on that hypervisor.

1:05So an individual virtual machine believes it has access to storage, and RAM, and CPU, and everything else, but behind the scenes, it's all being provided logically via the hypervisor. And most environments that are running ESXi are gonna have more than just one ESXi host. So here's an example of three ESXi hosts, each of them with network access, and with CPU, and RAM, and either storage or network-attached storage, and each of them supporting several VMs that are running on those respective ESXi hosts. And to manage multiple ESXi hosts, we're often gonna use a vCenter server, which is implemented as a virtual machine.

1:39And then vCenter is interacting with and managing all the ESXi hosts, then you and I, we interact with vCenter to get information regarding what's going on, so this is us right here at our management PC. So we interact with vCenter and vCenter interacts with each of the ESXi hosts. And when working with multiple ESXi hosts, generally, we'll put two or more into a cluster, and then leverage some really cool features that we can get from that cluster of ESXi hosts, that are being managed by vCenter, including cool things like DRS, distributed resource scheduler, or being able to move a virtual machine from this ESXi host to another one, whether it's powered on or off.

2:13And when implementing the switching on these ESXi hosts, it's often a pain to go into each one, and configure a virtual switch here, another one here, another one here, and then if we wanna do vMotion, or migrate VMs back and forth, we need to make sure we have the same port groups on each of the switches, so oftentimes, we'll use a virtual distributed switch, and that way, we can have a configuration for a virtual switch be replicated across multiple hosts. So that way if we want a port group called port group 10, and we want it on all three switches, we create a virtual distributed switch, we create a distributed port group called, "PG-10."

2:44And then, poof! Once these three hosts are all part of that distributed switch, they will all have that port group. And then behind the scenes, that port group will lead to one or more of the physical NICs, which are called VMNICs for access out to the physical world. So that's all well and good, However, I would like to point out a few challenges that we are going to fix and address with NSX. Let me label some VMs, I'm gonna go ahead and let's name them VM A here, and then VM B right here, and VM C.

3:14So VM A is being hosted on ESXi-one, and ESXi-two is hosting VM B and VM C. Let's also imagine that each of those VMs are connected logically to a port group, and I'll go ahead and put that port group in the same color here, that's part of a distributed switch. And let's imagine each of those port groups are associated with VLAN 10. And let's also imagine that this VMNIC right here with the green cable, is associated with this switch, and that this port group is using that uplink. So this represents VLAN 10. Now under the covers, all of this connectivity right here is gonna be provided by our physical network.

3:48So we may have some top-of-rack switches and we have VLAN 10 that's accessible by both ESXi-one and ESXi-two. And if that's the case, no problem. So as far as the IP addresses, VM A could be 10.10.0.11, and VM B could be 10.10.0.12, and VM C could be 10.10.0.13. And they could all communicate with each other because they're on the same port group, And that port group is associated with VLAN 10, and VLAN 10 is accessible on the physical network between ESXi-one and ESXi-two.

4:18So with that in mind, let me ask a couple of questions and these are gonna lead to a couple problems as well. And one of those is security. How do we implement controls between what can be done between VM A, for example, and VM B? Back and forth between each other, or VM A to VM C? Now all three of those VMs are in the same VLAN, so in the physical world, we could perhaps do some layer two security if we knew what the MAC addresses were, and so forth. And also if we had the expertise and time to do that in the physical world. However, it's a hassle, because we're bringing up and down various VMs all the time, and if we want security involved, it'd be a pain to have to go to the physical environment and identify what the MAC addresses are, and then try to implement some layer two security for traffic going back and forth to control what's allowed.

5:00And it even gets worse if we wanna start controlling what services are allowed. For example, if we wanna allow SSH between VM A and VM B, and HTTPS between VM A and VM C, and maybe ICMP between VM B and VM C, once again, this can be very tough to implement it here at the physical network to control the traffic between those VMs. So I'll leave a question mark there, saying there should be a better way of implementing security between our VMs in the infrastructure. Another challenge could be this, let's imagine that ESXi-one and ESXi-two, behind the scenes on the physical network, do not have connectivity to that same VLAN 10.

5:36So let's imagine down here, instead of just having trunking with layer two, we have a router. And if that's the case, ESXi-one and ESXi-two no longer have access to that same layer two broadcast domain. So even though the clients are using the 10.10.0 address space, assuming a 24-bit mask up here, if we don't have a contiguous VLAN between ESXi-one and two, VM A cannot be on the same broadcast domain here as VM B and VM C. So over here, if we have a VLAN 10, and maybe over here, it's VLAN 20, or even if the numbers are the same on both sides, VLAN 10 over here, and VLAN 10 over here on another switch, because we have a logical layer three router in the middle of that, we're gonna have two different broadcast domains, and as a result, we cannot have VM A on the same layer two broadcast domain with a traditional distributed switch as VM B and VM C.

6:24And that's because the infrastructure behind the scenes has a router between ESXi-one and ESXi-two. So our next challenge is an extended layer two broadcast domain when we have a router between the two ESXi hosts. Because if this is our topology of the physical world of the router between ESXi-one and ESXi-two, we are not going to have an extended layer two broadcast domain across these two ESXi hosts. Another challenge that comes up is routing. So for example, let's take VM B and VM C, and let's put VM B in the 20 subnet, 10.20.0, dot, let's use 20, and let's put VM C in the 30 subnet, 10.30, with a host address of 30 also.

7:03And so if these devices are in different subnets, how can we route between them? So one way of doing that, we could go ahead and put VM A on one port group, and put VM B on a different port group here, and VM C on yet a different port group. Maybe this is VLAN 40, and VLAN 50, and VLAN 60. And let me remove my router down here. So if these three VMs are now on three different port groups, and effectively on three different VLANs, in the physical world, we could set up our routing between the subnets 10.10.0, 10.20.0, and 10.30.0, but once again, that is gonna require us to do that in the physical environment with logical layer three interfaces on whatever gear we're using, from Cisco, or HP, or Juniper, et cetera.

7:45And although that can be done in the physical environment, it'd be much more convenient if we could set up that routing logically inside of the virtualized environment. And while we're talking about traditional network services, let's also put a question mark regarding how do we implement features like network address translation, and DHCP services, and VPNs, and load balancing, and the list goes on. And once again, the answer to that in the physical environment would be to use the tools that we have. Either from Cisco, or Juniper, or HP, et cetera, and we'd set up those features.

8:15However, it would be a lot more convenient if we could set up those features virtually inside of our vSphere environment. And now is time for the great news. All these features, which, with traditional vSphere might be a problem, can now be solved and done with software once we implement NSX, and add that to our vSphere environment.

0:00So to really appreciate some of the benefits of NSX, let's draw a simplified topology. And let's start off with a rack that would be in a data center. So this is gonna represent rack number one. And then over here, let's go ahead and put in another rack. And I'm gonna go ahead and name this one rack number nine. And I'm labeling this one rack number nine, just to give us an idea that these don't have to be like right next to each other. Now each of the racks is very likely gonna have a couple switches. They're called top of rack switches. So I'll put a couple switches at the top of each one.

0:30I'll label it TOR for top of rack switch. We'll call this one switch A and switch B. And over here the top of rack switches, got switch A and switch B. And then those would connect up into a spine layer for a spine-leaf architecture. So we'd have some fault tolerance there. So there's one of our switches apart of the spine and it's very likely in a fault-tolerant environment. We'd have multiple spines and if we had multiple spine switches, we'd have additional connections from each of the top of rack switches to the additional spines. So for our drawing, I'll just represent one spine right here. And so the idea also I wanna point out here with the spine-leaf architecture is that we are routing.

1:05So we're routing between our racks. We don't have one contiguous Layer 2 broadcast domain. We have routed networks. So in each of our racks, let's go ahead and put it in ESXi host. So let's call this one ESXi-A. And over here this will be ESXi-B. And each of those ESXi hosts are gonna have their physical connections go to our top of rack switches. I'll just draw one to each of the switches. Even though an ESXi host is likely to have multiple physical network interface cards, also known as vmnics.

1:35So I'll draw a couple over here as well as a representation of the physical connectivity. And over here, lemme go ahead and put VM-A. And over here I'll put VM-B to represent a virtual machine that's being hosted by those respective ESXi hosts. And here's the magic, hold onto your hats, instead of connecting these virtual machines to a traditional distributed port group that would allow them to be, for example, on the same VLAN but instead we are gonna have a new segment, this new Layer 2 segment. And specifically this will be a Layer 2 NSX segment.

2:07And even more specifically, we could call this a Layer 2 NSX overlay segment. So from an administration perspective, it just looks like a port group that's representing that segment and we simply connect the respective PCs to it. So even though these two hosts, ESXi-A and ESXi-B, do not have the same connectivity to the same Layer 2 VLAN if we implement a Layer 2 NSX overlay segment, again, think of it like a VLAN because what it really is is a Layer 2 broadcast domain, that segment will show up like a port group on each of our distributed switches.

2:40We connect VM-A to it, we connect VM-B to it, and boom, those two VMs are logically connected to the same Layer 2 broadcast domain. So lemme give some IP addresses here. I'll give this one 10.10.0.10. And we'll give this one the IP address of 10.10.0.11. Now on the backend we have a little problem to solve, and that is we don't have the same Layer 2 VLAN connectivity from rack one over here all the way over here to rack nine because we have routing at the spine layer between both of those. So how in the world if VM-A tries to communicate with VM-B, how is that communication actually possible?

3:15And here is the magic. We are gonna create a tunnel between ESXi-A and ESXi-B. So there are the two ends of the tunnel. I'll go ahead and make a nice macaroni shape there to represent the tunnel. I'm even gonna label it. And this tunnel between ESXi-A and ESXi-B that was created by NSX are gonna be terminated at VMkernel adapters on each of the hosts. Over here, perhaps we're using VMK 10 and over here we could use VMK 10 as well. And in association with these VMkernel adapters, we're also gonna have an IP address for each end of the tunnel.

3:47So maybe over here at ESXi-A, VMK 10 is using 10.11.11.11 with the 24-bit mask. And over here at ESXi-B for its VMkernel 10 adapter, which is acting as the tunnel endpoint on this side, maybe it's using 10.22.22.22. So TEP is an acronym for tunnel endpoint. So think of it like a VMkernel adapter with an IP address representing the end of the tunnel here on ESXi-A and the other end over here at ESXi-B. And I intentionally used different subnets for each of the tunnel endpoints to reinforce the concept that we're routing between the two devices, between the two ends of the tunnel.

4:25So although in some typologies we could place both tunnel endpoints in the same exact subnet, I intentionally put these tunnel endpoints in two separate subnets, just to reinforce the concept that we're not just bridging the traffic here, we are with our tunnel, we're routing the traffic between two reachable IP addresses. So over here at VM-A, if it did a ping to 10.10.0.11 that traffic would be forwarded out the VM into this port group, ESXi would see it and see that it came in on this Layer 2 NSX overlay segment.

4:58And then take that entire frame, we're talking about Layer 2 and everything higher than that, that this client was sending it will encapsulate that and then it will route it through the tunnel over to ESXi-B. So if the original message here is in pink, I'll go ahead and put that into the tunnel, it gets encapsulated. So the original content is effectively now the payload and the tunnel traffic will look like it's coming from 10.11.11.11 being routed to 10.22.22.22. And at this end it would de-encapsulate it and then forward it down to the intended recipient.

5:29So from the client's perspective, it just looks and feels like a common Layer 2 broadcast domain that VM-A and VM-B are in, but behind the scenes, these two ESXi hosts, which are enabled for NSX, have set up tunnel endpoints and they are encapsulating and routing the traffic over that tunnel back and forth on behalf of VMs that are connected to that Layer 2 segment. And you know what, it would only take a couple of moments to demonstrate this in action. And before I take you to the interface, let me reinforce the concept here that my goal isn't to have us memorize all the details on how to configure this.

6:03That's coming up in later skills. But my intention right now is just to get a comfort level that that encapsulation is happening by simply connecting these two VMs to an NSX Layer 2 segment. So as a demonstration, here is the vSphere Client that we know and love. And here I'm on the networking tab and I'm looking at a distributed switch called DS for NSX. And a few of these segments here, notice that if we click on this what looks like a port group, it has a big N there. And what that big N represents is that this is not just a normal distributed port group as part of a distributed switch, but instead this is an NSX segment and it has a virtual network identifier, this number right there.

6:41But the case in point is I just wanna point out that these are how they look from the vSphere Client. They simply look like port groups. So this is the NSX manager will have lots of time in playing here later. But for now, I just wanna go ahead and create a brand new segment. Again, this segment's just gonna show up on the distributed switch. It's gonna look a lot like a port group. So I'm gonna create a new segment by going to segments here and clicking on add segment. And I'll call it Fun Demo for fundamentals demo. And I'm gonna go ahead and associate with a transport zone called Our Overlay Transport Zone.

7:13We'll talk about that also here in just a moment. And we'll scroll down and click on save. So all we did here in this tool called NSX Manager, we just created this new segment called Fun Demo. We hop over to the vSphere Client, check it out, there it is, looks just like a port group. So to demonstrate this segment being used, lemme go ahead and deploy a couple VMs and I'll put 'em on separate ESXi hosts. So if I go back to my VM and templates view, I've got a folder called templates here, and lemme create a new VM or tube from this template. So I'll right click on this template and from the menu, I'll click on new VM from this template and I'll call this VM on host A.

7:47And lemme go ahead and lemme just put it here for Discovered virtual machine. Click on next. And then lemme go ahead and place this on EXSi-A right there. Click on next. I'll choose the data store. Click on next. And I'll customize to make sure I put it on the right segment. And then we'll go ahead and power it on. Click on next. And I wanna put this VM on that new segment we just made, which is this one right here, the Fun Demo. So that's the NSX overlay network segment that we just made. Again, it just looks like a port group on the distributed switch. So we'll connect it there and click on okay. And click on next and finish.

8:19All right, one down, one to go. We'll right click on our template again. New VM from this template, we'll call this VM on host B. I'll put it in Discovered virtual machines, in that folder. Click on next. And then I'll go ahead and choose the right host for this, which is gonna be ESXi-B. Click on next. Choose the data store. Click on next and customize and power it on. So I wanna customize it because I wanna place it on that same port group, or in this case the same NSX segment, which is right here called Fun Demo. And we'll click on, okay and click on next.

8:50And we'll click on finish. And now both those VMs are powering up. So let's go ahead and let's bring a console to them. So lemme go to VM on host B and launch a web console there. Great, that's booting up. And let's go to VM on host A and open a web console there. And let's also configure IP addresses. So here in the top left hand corner showing us which VM we're on, this is VM on host A. So let's give it an IP address, the pseudo I have config ethernet zero. And the address we want on VM-A is 10.10.0.10. And we'll put a 24-bit mask on there as well.

9:20We'll do an ifconfig for ethernet zero, just to confirm. All right, that looks great, let's go over to the VM on host B. So here's the VM on host B. So we'll configure its IP address as 10.10.0.11 with a 24-bit mask. And we'll confirm that with an ifconfig for ethernet zero. And that looks good. So before we do a ping test, let's just go verify real quick that they are both on the same segment. So if we click on network here and then we go down to our distributed switch, then click on that Fun Demo, let's click on VMs. And sure enough, we have both VMs that are on that segment.

9:52They're both connected there. And the first VM is running on ESXi-A. And the second VM is running on ESXi-B. Let's verify connectivity with the ping from the VM on host A, which is at 10.10.0.10 and let's ping 10.10.0.11, press enter and that seems to be working no problem. But behind the scenes, the ESXi hosts are taking that traffic, tunneling it and forwarding it to each other. So from an end user's perspective, it looks totally normal, like "Hey, we're just on the same Layer 2 broadcast domain." But behind the scenes, the two ESXi hosts are tunneling that traffic back and forth.

10:27And the visual representation of that is right here. So VM-A and VM-B, they're both connected to the same Layer 2 overlay segment as part of NSX, the same Layer 2 broadcast domain. And for the traffic, it's actually being sent over the tunnel between ESXi-A and ESXi-B. And sometimes it's a good idea just to verify that what we think is happening is really happening. So through the magic of some packet captures, let me go ahead and put a packet capture on this. We'll send some traffic over again and then take a close look at capturing the traffic right here as it crosses the network.

10:58All right, so in the background I've got a packet capture running this to that same exact ping again from the VM on host A to the IP address of the VM over on host B. We'll let that go a few times. We'll do a control C to stop it. And let's take a look at that packet capture. All right, and here we go. So lemme also explain this part right here. The first four lines here represent the encapsulation and the forwarding of the data from my ESXi host over to my management computer, and that was using GRE, so the actual traffic that was generated and then forwarded from ESXi-A over to ESXi-B starts right here.

11:33So the source address was 10.11.11.11, and that's the tunnel endpoint on ESXi-A. And the destination address is 10.22.22.22, which is the tunnel endpoint over on ESXi-B. So to forward to those destinations, we used a local Layer 2 address here MAC address. And then this second MAC address for the destination is the MAC address of the default gateway that was being used to reach and forward in the direction of 10.22.22.22. So this packet sent from ESXi-A to ESXi-B had a payload that was UDP.

12:03So the UDP payload is tested to the well-known port of 6081 that's being used for the encapsulation, used for the tunnel. So ESXi one shows a high currently unused port and then sent it to the well known port of 6081. And because ESXi-B was listening on port 6081 for UDP, it continued to open up and de-encapsulate. And as ESXi-B continued to de-encapsulate, it saw generic network virtualization encapsulation, which the acronym for that is G-E-N-E-V-E or GENEVE for generic network virtualization encapsulation.

12:37And that's what NSX uses for the encapsulation of the traffic between in this example ESXi-A and ESXi-B. So after the GENEVE header, then we have the original payload, the original frame and packet that was sent by VM-A that was being sent over to VM-B. So we looked at the source MAC address here of 0050, et cetera, et cetera, ending in 2C1A. That is the MAC address associated with VM-A. And to confirm that here on VM host A, we could do an ifconfig, press enter, and here we can verify its MAC address right there.

13:10Also, while we're right here looking at the VMs, let's also take a look at the Layer 2 MAC address on the VM that's running on host B. So here is host B and there's its MAC address right here ending in 0A1B. And that's what we should have seen inside the trace as the destination in the payload. So let's verify that as well. So if we go back to our packet capture, there's the destination address right there ending in 0A1B. So the traffic was sourced from 10.10.0.10 that's the VM on host A going to the IP address of the VM on host B.

13:42And again, just as a reminder, everything from this line going up was just the traffic in delivering this packet capture over to my management computer and my management computer's right here at .151. And then everything from right here below is all of our traffic related to NSX with the original payload being right here. And the traffic rigor on the tunnel is everything from here to here. So I'll label that part as the tunnel. Again, that's the GENEVE tunnel. And then the payload of that is the original traffic that was going from the VM on host A going over to the VM on host B.

14:17And again, we'll also have more opportunities to both configure and verify this, but I just wanna reinforce the concept that it is really happening and it is really that easy once NSX is set up and configured. So one of the benefits is extended Layer 2 broadcast domains, even when we have ESXi hosts that are not attached to the same common Layer 2 broadcast domains. And again, the way that NSX pulls this off is using the GENEVE tunnels and tunneling the traffic from one EXSi host to another. Another benefit that NSX brings to the table is security.

14:49So for any VMs that are part of our infrastructure where NSX is involved, we have several security features, including what's known as a distributed firewall. And think of a distributed firewall as a firewall that just hovers everywhere. So we could be very granular in what we want to permit or allow or deny between any two VMs, even two VMs that are on the same exact broadcast domain. So if we want to allow SSH or HTTPs or ICMP or anything else using the security services, we can control what is or is not allowed between the two VMs.

15:20And that also would apply to two VMs that are sitting on the same ESXi host. So over here at ESXi-B, if we had VM-B and VM-C who's also connected to that same segment, we can also control what's allowed back and forth between those two VMs as well. Another big benefit of NSX is the ability to do Layer 3 routing. And with NSX, instead of having to do that on our physical environment with our physical routers and switches and doing the routing there, we can do the routing logically in software. So lemme give you a quick diagram of what that could look like. Let's say imagine we have a router here, this router one, and let's imagine we have router two and router three, and then this guy goes up to the internet.

15:58We have some connections here. Then down here, let's imagine we have a few network segments, the 10.10 network and the 10.20 network and the 10.30 network and the 10.40 network. Let's go ahead and put some connectivity there. So we'll have this router router two connect to those two network segments and over here are three connected there. Let's put some VMs there on those segments as well. So we'll put one VM there, I'll put 'em in blue, this guy be in yellow, and this VM will be in pink. And I'll put this VM here in green. So for the routing, we can do routing east-west, that'd be routing within our infrastructure. We can also do routing for north-south traffic as well.

16:29So let's imagine this VM represents customer one, and this yellow represents a VM that's a web server. And the pink represents an app server and the green represents a database server. So for east-west traffic, we can route the traffic between those VMs. And for our traffic that needs to go out of our enterprise, out to the internet, for example, we could also implement the north-south routing. And in conjunction with these routers, which in a NSX environment, they refer to them as gateways, we could also implement network services, such as network address translation and DHCP and load balancing and VPNs and stable firewall services and many, many more.

17:06And to help reinforce what that might look like inside of an NSX environment, let me give you a sneak peek. So here's an example of what that would look like. We have a router here. We have another router here and here. Then we've got four network segments. So I've got one here, that I'm using the 10.10.0 address base on. I've got another Layer 2 broadcast domain here for segment 20 where I'm using the 10.20.0 address base. I've got a third one right here where we're using the 10.30.0 address base. And then I've got another segment over here, another Layer 2 broadcast domain where I'm using the 10.40.0 address base. And the way these segments are represented is they simply show up and look like port groups on our distributed switch.

17:41So we simply connect our VMs to the segments, which again look like port groups that we want them to be a part of. And then the logical routing services inside of NSX are providing the IP addresses and the routing to do the east-west routing as well as the north-south routing for those clients.

0:00For the deployment, configuration, and management of our NSX environments, we are going to use an entity called the NSX Manager and think of the NSX Manager, very similar to the function of a vCenter Server Appliance. So we're using vCenter to manage our ESXI hosts. We're gonna use the NSX Manager to manage all of our NSX components. What we're gonna first do is deploy the NSX Manager as a VM. So we'll choose one of our ESXI hosts to deploy that on and then once we deploy it, it's gonna encourage us to go ahead and create a cluster.

0:32And a cluster is three VMs, specifically three NSX Manager VMs that we can use to help manage our entire NSX environment. So let's say we have three VMs that we've deployed. Now the first one we're gonna deploy as an OVF. So you deploy it, install it, you let it get up and initialized and then once it's running, it encourages you to add additional managers. So right from the interface of the NSX one, for example, you can go ahead and deploy NSX two and NSX three. It'd also be wise to have each of those on a separate ESXI host. So this could be on host X, and this could be on host Y, and this could be on host Z.

1:06So we may wanna set up some affinity rules to make sure that if we're using DRS that our NSX VMs are being deployed and not on the same exact host. That way we can share the love and the resources that each of those NSX appliances is gonna get. So let's imagine this is our management network right here, and I'm gonna use 192, 168.1.0 with a 24 bit mask. So maybe this guy's at .11, and we put the second one in at .12, and we put the third one in at .13. And what we can also do is set up a virtual address, a virtual IP, to manage them as a cluster.

1:40So let's go ahead and pick, for example, .10 as the virtual IP so you and I, we connect to the IP address of .10 with https, and this is gonna associate that with one of our NSX managers, and that's where we can go ahead and start working. Now, behind the scenes, let's say we have 50 objects inside of NSX, including hosts and other VMs that we'll be talking about here in just a moment. Even though when we connect to the virtual IP address, we're only connected to one of the NSX appliances or one of the NSX managers, behind the scenes, it's gonna divvy up some of the loads. So perhaps this NSX Manager is gonna be managing 15 of our objects, and this device is gonna be managing 15 of our objects, and this one may be 20, so hopefully that adds up to 50.

2:19So that division on the backend is done automatically. Also, in addition to using a virtual IP address, we could also set up a load balancing service on the front end and if we did implement a load balancer, we would connect them to the load balancer virtual IP address, and then it could spin us off to the least busy or based on the load balancer rules, the NSX Manager that it believed was the least busy, but even without a load balancer, we can set up a virtual IP address, have multiple NSX managers, and behind the scenes, they'll divvy up the responsibility of interacting with and working with our NSX devices.

2:51And these NSX managers working together are referred to as an NSX Cluster. So to give you a visual idea of what that looks like, this is the interface for the NSX manager. So I've gone here to the appliances section, and I currently have one NSX manager in place. So it's begging me, please add more. So I simply click here and I could go through the process of yet adding a second, and then repeat that to add a third NSX manager that would become part of this cluster. So on this first NSX Manager, there's its management address right there of 192 168, 1.11 and then here's the version of NSX that I'm currently running.

3:25So the NSX Manager is the brains of the operation. So let's imagine this is our NSX Manager right here. As part of the deployment, once we deploy it, we'll also tell it where our vCenter is. Let's mention we also have here on our management network, the vCenter Server Appliance and the reason the NSX manager needs to know about the vCenter Server is because the vCenter Server is in charge of the distributed switch, which in the current flavor of NSX, we're gonna be leveraging the virtual distributed switch and adding our logical segments from NSX to our VDS. So as part of that integration, in addition to identifying the virtual distributed switch in vSphere that we're gonna use and enhance, we're also gonna leverage that relationship with the vCenter to identify the ESXI host that we are going to include as part of NSX.

4:08So that way right here from the NSX manager, we can specify, oh, for this host or that host, we want to add the NSX software to those hosts so they can participate as part of NSX. And the NSX Manager is gonna become the centralized control plane for the NSX environment. So any of the details regarding segments or routers, virtual routers in the NSX environment, or which segments should be included on which hosts, that's all controlled by the NSX Manager, and it's gonna be the Centralized Control Plane.

4:38And then on each of the ESXI hosts and other objects that we'll soon talk about here in a moment, they'll receive a copy of what they're supposed to do and that's called the Local Control Plane. So the Centralized Control Plane is managed by the NSX Manager cluster. And for individual hosts that are participating in NSX, they'll have a Local Control Plane. Effectively what they need to know to do their jobs as part of NSX. Let's imagine that you and I are sitting here at this management PC, we've logged onto the NSX Manager and we've identified these two hosts, we'll call it host A and B, that we want them to participate as part of NSX.

5:12So from the NSX Manager, we install and add the software to those hosts. And the moment that we add that NSX software and they're up and running and happy, happy, those are now referred to as transport nodes. And think of a transport node as an ESXI host with the additional software regarding NSX that allows it to do the tunneling that we took a look at a couple videos ago where traffic coming in, for example, from one VM on a segment is encapsulated and tunneled and shipped off to a remote destination where the receiving site is de-encapsulated.

5:43Effectively, that's the function of a transport node in the world of NSX.

0:00So let's take a closer look at what exactly is a transport node. And again, the high level overview is that a transport node is an ESXi host that we know and love where we've added to it the ability to work with NSX. So the way that would look is you and I would go to our NSX Manager. The NSX Manager is working in conjunction with vCenter, so it knows exactly about which hosts are available. And then using NSX Manager, we reach out to a host, let's say ESXi-A, and we specify that we wanted to participate as part of NSX.

0:31And once we do, the NSX software is installed and enabled on ESXi-A and bada bing, bada boom, it becomes a transport node. And part of that, the ESXi host now is gonna get a new VMkernel adapter and is gonna use that VMkernel adapter as one end of its tunnel called a tunnel endpoint, so that if it needs to, it can encapsulate and forward traffic over that tunnel to another entity. And up to this point, we haven't talked about other nodes other than a transport node. So let's imagine it sending it over to another ESXi host like ESXi-B, who could then deencapsulate it and then forward it onto to its final destination.

1:03And for every good tunnel, there's two tunnel endpoints, one at each side. So if we had two clients, for example, right here on segment 20, and this one was running on ESXi-A, and this one was running on ESXi-B, and they're both connected to that same segment as they communicated back and forth, the traffic would be encapsulated. If this is VMA, and this is VMB and VMA is communicating with VMB, the traffic would be initiated by VMA, ESXi-A would encapsulate it, send it through the tunnel as a routed packet over to ESXi-B, who would deencapsulate it, and then forwarded over to VMB, which is one of the great reasons why it's called a transport node.

1:37It's able to do transport over a tunnel, specifically a GENEVE tunnel from itself to the other end point. So let me clean this up a little bit and let's chat about a few additional terms. One of those terms is called a transport zone. And just for fun, let me go ahead and draw a couple zones. I'm gonna put a zone here, and then I'll put another zone here and let me label those. Let's call this zone right here the production zone, I'll call it prod zone for short. And over here, I'll call this the dev zone, short for development. Let's imagine we have six ESXi hosts that we've enabled for NSX.

2:08So if they're enabled for NSX, those ESXi hosts are referred to now as transport nodes for the purposes of NSX. So I'll put four of 'em right here. I'll label them one through four. Those are ESXi hosts 1, 2, 3, and 4. And over here, I'll specify that these other two hosts are gonna be in the dev zone only. So those are host 5 and 6. So what exactly is a transport zone good for? Transport zones control the scope of a new segment. So let's create a new segment, and we'll create this layer two segment, we'll call it segment 50.

2:40So this NSX segment is a logical layer two broadcast domain. Now, it could exist across all of our ESXi hosts. However, if we've carved up these four hosts, so they're only participating in the production zone, and these two hosts are only participating in the dev zone, when we create a new segment, we can associate that segment with the production zone. And that way the segment effectively would be reachable and accessible as a port group for these four ESXi hosts. But if segment 50 is not associated with the dev zone, these two ESXi hosts are not gonna have that port group.

3:12Or in the terms of NSX, they're not gonna have that logical segment as part of their virtual distributed switch. And just to be fair, let's create another segment. We'll go ahead and draw it like this, and we'll call it segment 60. Let's imagine we only have this segment available for these two hosts. So what we could do is we could go ahead and associate the segment with the dev zone. And because these two hosts are participating in the dev zone, only these two hosts would have that segment available to 'em. Again, it would appear on the virtual distributed switch. It simply appears like a logical port group that is provided by NSX.

3:42So it's referred to as a segment. So when we think about the concept of a transport zone, think about the concept of scope, meaning how many ESXi hosts and how many devices are gonna be supporting that segment. So if a segment, again, is associated with the production zone, it's only being available to these four hosts. If we have a segment associated with the dev zone, it would then only be available to these two transport nodes. Also, regarding ESXi hosts that have been enabled for NSX, not only are they transport node, but if we're gonna be explicit, we could also call them a host transport node, which is gonna help differentiate them from another type of node we're gonna talk about in the next video.

4:17And while we're chatting about host transport nodes, let's also take a look at the uplinks. So let's imagine we have this host, let's call it Host A. And Host A has a few vmnics connected up to the physical world. So here's our physical infrastructure with some high speed ethernet switching out here. So I'll label this as physical. And for the vmnics, let's call 'em vmnic 0 and 1 and 2 and 3. So when we go to the NSX manager, and we specify that we want Host A to participate and become a host transport node as part of NSX, we are also going to be asked and need to provide information regarding which uplinks we want this host to use as part of being a host transport note.

4:53Do we wanna use vmnic 0 and 1, or 2 and 3, or 1 and 3? And do we wanna use teaming in the form of load balancing, or do we wanna use a failover order? And so the details regarding which uplinks we're gonna use are configured as part of an uplink profile. So it'd be a great idea before we start configuring and setting up an ESXi host as a host transport node, we'd wanna plan out and identify beforehand exactly which interfaces we wanna use for the uplinks and our uplink strategy. Again, do we wanna do load balancing with two or more nics or do we wanna have two or more vmnics in a specific failover order?

5:30And we're gonna specify those as part of an uplink profile when we're configuring our host transport node. And what's really interesting about this is that if we specify one uplink that we're gonna use, it's gonna automatically create a new VMkernel adapter with an IP address that we specify as part of our configuration. And the IP address that we're gonna specify is the tunnel endpoint on this ESXi host. Now, the key is if we did two uplinks as part of our uplink profile, it's not just gonna have one VMK with an IP address for a tunnel endpoint. Instead, it's gonna have two. So you have two uplinks.

6:00It's gonna equate to two tunnel endpoints that it can use to communicate with other nodes in NSX. And let me show you a quick example of that to reinforce that concept. So this is the NSX Manager, and this is the section for uplink profiles right here. And here's an uplink profile called ESXi-A, et cetera. And it's using exactly one uplink. So as a result, we would expect one tunnel endpoint address on the host transport node that's using this uplink profile. So if we go to our hosts and we go down to ESXi-A and take a look at the details, and I'm gonna click on Configure and click on Next a couple of times and click on Next.

6:34Right here is giving us a visual representation that is using vmnic 2 And if we expand this, it's showing us the uplink profile it's using, which is the ESXi-A one. And as a result of that, having one uplink for the NSX, I'll go ahead and click on Cancel here. If we look at the tunnel endpoint address, it has one tunnel endpoint address that's 10.11.11.11 which I hard coded for that endpoint. And again, if we had two uplinks or three uplinks, we'd have two or three respectively tunnel endpoint addresses, one for each of our uplinks.

7:05And then if we went to the vSphere Client and took a look at the ESXi-A host. So here's the vSphere Client, we're in the host and clusters view, we're looking at ESXi-A, if we go to Configure and then go down to VMkernel adapters. Here is the VMkernel adapter that was created by NSX for the benefit of that tunnel endpoint with that IP address of 10.11.11.11. And again, if we had two uplinks associated with NSX for this host, it would have two specific VMkernel adapters with two IP addresses, one for each of its tunnels. And again, in this skill, I just wanna reinforce some of the basic concepts behind NSX.

7:38So on our Host A, because we specified one uplink, it has one VMkernel adapter specific for that tunnel endpoint. So in the interface, I think it showed us 10, and then it had the IP address of 10.11.11.11 which is the tunnel endpoint on this ESXi host that it can use to communicate with other devices who are at the other end of its tunnels. So the other end of the tunnel could be Host B. So if there was Host B, that would be one tunnel and it had yet another host, let's go ahead, but Host C here with one uplink from that tunnel endpoint address, we'd have another tunnel going over to Host C to its tunnel endpoint.

8:11And in addition to building these tunnels for the tunnel endpoints to other ESXi hosts, which are also host transport nodes, there's another type of node we can also build a tunnel too, and that's called an edge node. So it could be called an edge node, or it's also referred to as an edge transport node. And that would differentiate it from the host transport node, which is an ESXi host. And the question might be, well, why do we need this thing called an edge node or an edge transport node? And the answer is the edge transport nodes are gonna take the responsibility of implementing our logical layer three gateways and services should we choose to use them for routing.

0:00If we wanna implement routing, for example, having these three routers to do logical routing of our traffic for north-south traffic and east-west traffic. To implement that functionality, we're gonna configure it all from the NSX Manager, so you and I interface with the NSX Manager and then we specify that we want to have, for example, gateway zero, and gateway A, and gateway B, and connect them logically to those various NSX segments. And when we create this logical routing inside of NSX, the actual ESXi host transport nodes, they can actually do the logical routing themselves, and then if they need to forward traffic to another ESXi host, they can go ahead and tunnel it over.

0:40And that's known as a distributed router, where the logical routers are implemented on the actual host transport nodes. However, sometimes we may need to integrate additional services, including things like network address translation, or VPNs, or connecting our NSX routed environment out to the outside world, and for those specific functions that can't be done by the host transport nodes themselves, we have a separate entity, and that, my friend, is an edge transport node. Now we have a couple of options for implementing an edge transport node, the easiest option in my opinion, is to implement a little VM.

1:16So this little VM is running on a host somewhere, and this little VM is implemented, and it's an edge node. So we can have an edge node VM, or we could also do a bare-metal edge node. And that's where, instead of running the edge node as a VM, we'd take a physical computer and install the appropriate software there. And so one of the questions might be why would we ever, you know, wanna have a dedicated piece of hardware as an edge node when we can implement the functionality of these gateways as a VM? And the answer is throughput. If you wanna crank out 20, or 40, or 100 gigabits per second, you may need some dedicated hardware to do that, and that's why there's the option of a bare-metal edge node.

1:52So let's imagine we wanna implement the routing infrastructure and we decide to deploy a VM. So to deploy that VM for the edge node, as I mentioned, it's done right through the NSX Manager and you simply specify what host you wanna run that VM on, we're gonna specify which uplinks on that host should be used by the edge node, and let's go ahead and visualize that with an ESXi host. Let's say this is an ESXi host here, and here's our edge node VM running on that host, and of course the host has some physical connectivity out, and as part of our configuration of the edge node, we're also gonna specify which uplinks we want the edge node to use.

2:28So let's say I have VM NIC zero, and one, and two, and three, and four. And very similar to the uplink profile that we specified for an ESXi host when it's acting as a host transport node, we're also, when we deploy the edge node, gonna specify which uplinks we want it to use on the host that it's currently running on. So, maybe we want this edge node to go ahead and use VM NIC three as the active and then VM NIC four as the standby, I'll put a A there and S there. And as a result, that edge node is also going to get a tunnel endpoint. So that tunnel endpoint, we'll go ahead and call this one, let's say it's 10.33.33.33.

3:04And another question might be, well, what would this need to tunnel to? And the answer is it could tunnel to any other transport node, so we could tunnel over here to ESXi, let's say ESXi-A, which is acting as a host transport node with this tunnel endpoint address of 10.11.11.11. We can add this edge node with a tunnel going to ESXi-B, and perhaps this tunnel endpoint address is 10.22.22.22. And the cool thing is that there is a function called a distributed router, we'll call it a DR for short, not to be confused with an OSPF designated router, so I'll spell it out, that's a distributed router.

3:39And that distributed router exists here on the edge node on the local control plane, it also exists here on ESXi-B and the ESXi-A, and the entity that's coordinating all that is the NSX Manager, and up here we have the centralized control plane. So the benefit of having a centralized control plane and then a local control plane that's been coordinated between the NSX Manager and that cluster, and each of our nodes, which includes the ESXi host, and also now the edge node implemented as a VM, the benefit is if we have a VM list, call this VM-C, and let's say that VM is over here on segment 30, and that VM is sending traffic into the network, and that VM is connected to this logical segment 30, ESXi-B knows exactly how to forward it.

4:21Is it gonna make the forwarding decision locally because it has all the information that needs to do that or is the destination reachable through one of our routers, AKA an NSX gateway? And if it is, ESXi-B can take it, encapsulate it into the tunnel, send it to the other side where it needs to go, where it can be deencapsulated and processed. Most of the time we're not just gonna have one edge node, we'll have an edge node cluster. So let's say this is ESXi-10, and let's also draw a really thin ESXi host over here, (laughs) because of the space, so. So, here's ESXi-11, and it also has an edge node VM, and we can implement those as a cluster that work together.

4:59Now here's the great news, in this skill, I wanted to present a big picture look at the concept of NSX and the key players inside that architecture. So with this warmup to the world of NSX, what we're gonna do is we'll take a look at implementing and verifying each of the components in one nice little step at a time.

0:00I have a friend who is a juggler, and he told me that over the years he's gotten better and better at juggling, and now he's a professional juggler. He said, "You know what? When we practice one day, what we're really doing is we're reinforcing what we practiced the previous day. So it's important to pause from time to time and reinforce our concept." So here's what I'd like you to do right now. I'd like you to imagine that a customer has come to us and said, "Hmm, I've heard about this NSX thing and this Software-Defined Networking. How exactly can VMware's NSX help me?"

0:31And what I would love you to do is based on these intro videos that we just went through, I'd like you to either verbally say it or write them out, or think in your mind, what exactly are some of the benefits of NSX? And again, I'm not expecting you to be an expert yet on NSX, but based on the videos that we've just gone through, I'd like you to be able to list just a few of the benefits. So before we walk through the next video and we confirm some of those benefits together, pause right now, think it through, what are some of the benefits? And when you're ready, join me in the next video and we'll reconvene.

0:00So, list together, now that we had a moment to think about it, let's list out a few of the benefits of VMware's software to find networking with their product called NSX. One of the benefits is the ability to have a common layer two segment. And if we told that to the customer and they said, "Well, we have layer two segments already. We have, you know, distribute a switch, we have four or five VMs, all the same port group, and they're in the same segment." But that's if, on our transport or underlay networks, we have those two ESXI hosts that are hosting the VMs, able to reach that same layer two broadcast domains.

0:33So with NSX, even if we have two ESXI hosts, we have one over here at this end of the data center in a rack, we have one over here in a different rack, and we have lots of routing between them. So here's a router, there's a router. We can still have a common layer two segment, an overlay segment that those VMs can go ahead and connect to. And then behind the scenes, these two ESXI hosts can tunnel that traffic back and forth. So we have a tunnel endpoint over on the host on the left, and a tunnel endpoint over on the host on the right. So this is host A and this is host B.

1:03And even though they're not on the transport network directly connected to the same layer two broadcast demand or the same vlan, the little VMs who are connected to the overlay segment can look and feel like they're on the same layer two broadcast domain. So this could be 10.10.0.10 over here, and we have 10.10.0.11 here on the same IP subnet because they're also on the same layer two broadcast domain courtesy of this logical segment provided by NSX. So I would say that would be one of the benefits.

1:35We can have logical layer two segments across the entire data center wherever we need them to be, without having to have the actual underlay network. And the ESXI hosts connected to that underlay network in the same exact VLAN. So I'll make a little note up here. Layer two segments across routed networks. Another big benefit that NSX can bring to the table is regarding security. So if we wanted to control what is or isn't allowed between, for example, this VM, we'll call it VM1 and this VM, VM2, even though they're on the same layer two broadcast domain and the same subnet, with NSX, we can now control very, very granularly what is allowed between those two VMs.

2:13For example, we wanna allow TCP traffic if it's HTTPS, or do we wanna allow ICMP, or if this is an application server, and this is a database server, we can specifically permit or deny certain types of traffic flows between those two VMs. Another big benefit is routing. Now, in the case of routing, if we want to implement routing within our NSX environment, we can do exactly that. We can have a router here and here and here, and then a network segment here, another network segment here, and a third network segment there, and then route everywhere between them.

2:45And this is all without having to touch a physical piece of hardware for routing. So all this routing, especially the east west traffic, can all be done inside of NSX in software. And in addition to routing, we can also provide other IP services, including things like DHCP services and VPN, and we can set up gateway firewall services, and other services like network address translation. And all of that can be implemented right here inside of NSX in software. So the way that would play out is that you and I would log into the NSX manager.

3:18We would configure what we wanna go ahead and have implemented in NSX. And also there's various options for working with NSX manager. So here is our NSX manager, it's very likely we're gonna have a cluster of those so that we have some fault tolerance. So this would be NSX Manager, one and two, and three, all configured as an NSX management cluster, as a virtual IP address. So you and I can connect to that virtual IP address, for example, that's reachable on the management network. So here's the computer that we're sitting at, we connect to that IP address to the browser, and then it's gonna associate that with one of our NSX managers, so we can go ahead and get the graphical user interface.

3:53So that's one of our options for working with and managing NSX. And now, another option also is we could get a plugin for vCenter. So we have our vCenter server appliance, and within vCenter we could have a NSX plugin. And then that way we could just log into the vSphere client. And then within vSphere client, there's additional controls that we can use to implement control and set up our NSX world as well. And for most of the configuration and demonstrations that we're gonna use together in this course, we're gonna be managing the NSX GUI interface directly on the NSX manager as opposed to using the plugin inside of vCenter.

4:25Although at the end of the day, the functionality is the same whether we're configuring security, or DHCP services, or routing. And those are all functions and features that a customer can use by leveraging NSX in their environment. So thanks for taking an extra moment in this set of videos to pause and help reconfirm our understanding. And when you're ready, my friend, I'll see you in the very next skill. Until then, I hope this has been informative and I'd like to thank you for viewing.