Understand VMware NSX Fundamentals

0:00<v ->Hello, and welcome.</v>

0:01My name is Keith Barker.

0:03And one of the things that I really enjoy working on

0:06are the nuts and bolts of IP networking,

0:08whether it's IP version four, or IP version six.

0:11I love IP networking.

0:13And so when CBT Nuggets came to me and said,

0:16"Hey, Keith, we're gonna create this VMware NSX course.

0:18Do you wanna be part of it?"

0:20I said, "You betcha.

0:21Two thumbs way, way up.

0:22I love networking and I love VMware."

0:24And NSX brings those both together.

0:26Now, one of the things that I've discovered

0:27is that those individuals

0:28who are just starting off with NSX,

0:30because there are quite a few moving parts

0:32and pieces and terms and new vocabulary,

0:34that sometimes at the beginning

0:36it's a little bit overwhelming.

0:37So here's what you and I get to do in this skill.

0:40We are going to walk through logically the big picture

0:43of how NSX works, including a lot of the vocabulary

0:46and terms and logic.

0:48And our objective together in this skill is simple.

0:50We wanna have a solid foundation on which we can build upon,

0:54so that as we proceed forward, if we hear the terms

0:56of "transport nodes," or "edge nodes," or "TEPs,"

0:59or "tier-0," or "tier-1 gateways,"

1:02they won't be foreign to us.

1:03We'll have good kinda a feeling for where those fit in

1:05and what those are in the infrastructure.

1:07And one of the important aspects to be aware of

1:09is that the NSX and a VMware vSphere environment

1:11is built upon the software-defined

1:14data center infrastructure that vSphere presents.

1:17So here's our roadmap for this set of videos in this skill.

1:20We're gonna first take a look at a quick overview

1:22of software-defined data centers,

1:24just the basic nuts and bolts regarding vSphere and vCenter

1:28and ESXi host and how that all fits together.

1:30And then with that in mind, we'll take the next logical step

1:32and we'll add onto it the components

1:34that NSX brings to the table,

1:36including the features it brings,

1:37and also the terms and the vocabulary,

1:39and some of the core elements that make it possible.

1:42So if you, my friend, are ready for a big picture look

1:45at the world of NSX, you are in the right place.

1:47And I'll see you, my friend, in the next video.

0:00<v Instructor>So starting off,</v>

0:01I'd like to make sure that you and I

0:02are on the same sheet of music

0:03regarding the basic infrastructure

0:05for the software-defined data center,

0:08or SDDC for short from VMware.

0:10And one of the core components

0:12of that infrastructure is the hypervisor called ESXi.

0:17So ESXi runs on top of hardware,

0:20usually, it's a pretty hefty server

0:21that has lots of CPU, and memory,

0:24and network access through network interface cards.

0:26These days, a lot of those network interface cards

0:28are 10 gigs each.

0:30And that ESXi host also has some storage,

0:32and that storage could be local

0:33or the ESXi host may have access

0:35to network-based storage as well.

0:37So the hypervisor,

0:38think of it like an operating system

0:39that's running on top of the hardware,

0:41in the case of ESXi,

0:43it's a specialized, dedicated operating system

0:45for host hardware,

0:46that could then provide a home for one or more VMs.

0:50And also with the right licensing,

0:51some containers as well.

0:53So the hypervisor's responsible for doling out

0:56and providing the resources

0:57regarding CPU, and memory,

0:59and network access, and storage,

1:01for each of the VMs or containers

1:03that are running on that hypervisor.

1:05So an individual virtual machine

1:06believes it has access to storage,

1:09and RAM, and CPU, and everything else,

1:11but behind the scenes,

1:12it's all being provided logically

1:13via the hypervisor.

1:15And most environments that are running ESXi

1:16are gonna have more than just one ESXi host.

1:19So here's an example of three ESXi hosts,

1:22each of them with network access,

1:24and with CPU, and RAM,

1:25and either storage or network-attached storage,

1:27and each of them supporting several VMs

1:29that are running on those respective ESXi hosts.

1:32And to manage multiple ESXi hosts,

1:34we're often gonna use a vCenter server,

1:36which is implemented as a virtual machine.

1:39And then vCenter is interacting with

1:41and managing all the ESXi hosts,

1:43then you and I,

1:44we interact with vCenter to get information

1:46regarding what's going on,

1:47so this is us right here at our management PC.

1:49So we interact with vCenter

1:50and vCenter interacts with each of the ESXi hosts.

1:53And when working with multiple ESXi hosts,

1:55generally, we'll put two or more into a cluster,

1:58and then leverage some really cool features

2:00that we can get from that cluster of ESXi hosts,

2:02that are being managed by vCenter,

2:04including cool things like DRS,

2:05distributed resource scheduler,

2:07or being able to move a virtual machine

2:08from this ESXi host to another one,

2:11whether it's powered on or off.

2:13And when implementing the switching

2:14on these ESXi hosts,

2:15it's often a pain to go into each one,

2:17and configure a virtual switch here,

2:19another one here, another one here,

2:21and then if we wanna do vMotion,

2:22or migrate VMs back and forth,

2:25we need to make sure we have the same port groups

2:26on each of the switches,

2:27so oftentimes, we'll use a virtual distributed switch,

2:31and that way, we can have

2:31a configuration for a virtual switch

2:33be replicated across multiple hosts.

2:35So that way if we want a port group

2:37called port group 10,

2:38and we want it on all three switches,

2:39we create a virtual distributed switch,

2:41we create a distributed port group called, "PG-10."

2:44And then, poof!

2:45Once these three hosts

2:46are all part of that distributed switch,

2:47they will all have that port group.

2:49And then behind the scenes,

2:50that port group will lead

2:51to one or more of the physical NICs,

2:53which are called VMNICs

2:55for access out to the physical world.

2:56So that's all well and good,

2:58However, I would like to point out a few challenges

3:01that we are going to fix and address with NSX.

3:04Let me label some VMs,

3:05I'm gonna go ahead and let's name them VM A here,

3:10and then VM B right here,

3:12and VM C.

3:14So VM A is being hosted on ESXi-one,

3:16and ESXi-two is hosting VM B and VM C.

3:19Let's also imagine that each of those VMs

3:21are connected logically to a port group,

3:24and I'll go ahead and put that port group

3:25in the same color here,

3:26that's part of a distributed switch.

3:29And let's imagine each of those port groups

3:30are associated with VLAN 10.

3:32And let's also imagine that this VMNIC right here

3:34with the green cable,

3:36is associated with this switch,

3:38and that this port group is using that uplink.

3:41So this represents VLAN 10.

3:43Now under the covers,

3:44all of this connectivity right here

3:46is gonna be provided by our physical network.

3:48So we may have some top-of-rack switches

3:50and we have VLAN 10 that's accessible

3:51by both ESXi-one and ESXi-two.

3:54And if that's the case, no problem.

3:56So as far as the IP addresses,

3:57VM A could be 10.10.0.11,

4:01and VM B could be 10.10.0.12,

4:05and VM C could be 10.10.0.13.

4:08And they could all communicate with each other

4:10because they're on the same port group,

4:11And that port group is associated with VLAN 10,

4:14and VLAN 10 is accessible on the physical network

4:16between ESXi-one and ESXi-two.

4:18So with that in mind,

4:19let me ask a couple of questions

4:21and these are gonna lead to a couple problems as well.

4:23And one of those is security.

4:25How do we implement controls

4:26between what can be done between VM A,

4:28for example, and VM B?

4:29Back and forth between each other,

4:31or VM A to VM C?

4:33Now all three of those VMs are in the same VLAN,

4:35so in the physical world,

4:36we could perhaps do some layer two security

4:38if we knew what the MAC addresses were,

4:41and so forth.

4:41And also if we had the expertise

4:43and time to do that in the physical world.

4:45However, it's a hassle,

4:46because we're bringing up and down

4:48various VMs all the time,

4:49and if we want security involved,

4:50it'd be a pain to have to go

4:52to the physical environment

4:53and identify what the MAC addresses are,

4:55and then try to implement some layer two security

4:57for traffic going back and forth

4:58to control what's allowed.

5:00And it even gets worse

5:01if we wanna start controlling

5:02what services are allowed.

5:03For example, if we wanna allow SSH

5:05between VM A and VM B,

5:06and HTTPS between VM A and VM C,

5:11and maybe ICMP between VM B and VM C,

5:14once again, this can be very tough

5:15to implement it here at the physical network

5:18to control the traffic between those VMs.

5:20So I'll leave a question mark there,

5:21saying there should be a better way

5:22of implementing security between our VMs

5:25in the infrastructure.

5:26Another challenge could be this,

5:27let's imagine that ESXi-one and ESXi-two,

5:30behind the scenes on the physical network,

5:32do not have connectivity to that same VLAN 10.

5:36So let's imagine down here,

5:36instead of just having trunking with layer two,

5:39we have a router.

5:41And if that's the case,

5:42ESXi-one and ESXi-two

5:44no longer have access to that same

5:46layer two broadcast domain.

5:48So even though the clients

5:49are using the 10.10.0 address space,

5:51assuming a 24-bit mask up here,

5:53if we don't have a contiguous VLAN

5:55between ESXi-one and two,

5:57VM A cannot be on the same broadcast domain here

5:59as VM B and VM C.

6:01So over here, if we have a VLAN 10,

6:03and maybe over here, it's VLAN 20,

6:06or even if the numbers are the same on both sides,

6:08VLAN 10 over here,

6:08and VLAN 10 over here on another switch,

6:10because we have a logical layer three router

6:12in the middle of that,

6:13we're gonna have two different broadcast domains,

6:15and as a result,

6:15we cannot have VM A

6:17on the same layer two broadcast domain

6:19with a traditional distributed switch

6:21as VM B and VM C.

6:24And that's because the infrastructure

6:25behind the scenes has a router

6:27between ESXi-one and ESXi-two.

6:29So our next challenge

6:30is an extended layer two broadcast domain

6:34when we have a router between the two ESXi hosts.

6:37Because if this is our topology

6:38of the physical world

6:39of the router between ESXi-one and ESXi-two,

6:41we are not going to have an extended

6:44layer two broadcast domain

6:45across these two ESXi hosts.

6:47Another challenge that comes up is routing.

6:49So for example, let's take VM B and VM C,

6:53and let's put VM B in the 20 subnet,

6:5410.20.0, dot, let's use 20,

6:57and let's put VM C in the 30 subnet,

6:5910.30, with a host address of 30 also.

7:03And so if these devices are in different subnets,

7:05how can we route between them?

7:07So one way of doing that,

7:08we could go ahead and put VM A on one port group,

7:11and put VM B on a different port group here,

7:13and VM C on yet a different port group.

7:16Maybe this is VLAN 40,

7:17and VLAN 50, and VLAN 60.

7:20And let me remove my router down here.

7:23So if these three VMs

7:24are now on three different port groups,

7:25and effectively on three different VLANs,

7:27in the physical world,

7:28we could set up our routing

7:30between the subnets

7:3210.10.0, 10.20.0, and 10.30.0,

7:35but once again, that is gonna require us

7:36to do that in the physical environment

7:38with logical layer three interfaces

7:40on whatever gear we're using,

7:41from Cisco, or HP,

7:44or Juniper, et cetera.

7:45And although that can be done

7:46in the physical environment,

7:47it'd be much more convenient

7:49if we could set up that routing logically

7:51inside of the virtualized environment.

7:54And while we're talking about

7:54traditional network services,

7:56let's also put a question mark

7:57regarding how do we implement features

7:59like network address translation,

8:00and DHCP services, and VPNs,

8:04and load balancing, and the list goes on.

8:07And once again, the answer to that

8:08in the physical environment

8:09would be to use the tools that we have.

8:11Either from Cisco,

8:12or Juniper, or HP, et cetera,

8:14and we'd set up those features.

8:15However, it would be a lot more convenient

8:17if we could set up those features

8:19virtually inside of our vSphere environment.

8:22And now is time for the great news.

8:24All these features,

8:25which, with traditional vSphere might be a problem,

8:29can now be solved and done with software

8:32once we implement NSX,

8:34and add that to our vSphere environment.

0:00<v Instructor>So to really appreciate some of the benefits</v>

0:02of NSX, let's draw a simplified topology.

0:05And let's start off with a rack

0:07that would be in a data center.

0:09So this is gonna represent rack number one.

0:12And then over here, let's go ahead and put in another rack.

0:14And I'm gonna go ahead and name this one rack number nine.

0:18And I'm labeling this one rack number nine,

0:19just to give us an idea that these don't have

0:21to be like right next to each other.

0:23Now each of the racks is very likely gonna

0:24have a couple switches.

0:26They're called top of rack switches.

0:28So I'll put a couple switches at the top of each one.

0:30I'll label it TOR for top of rack switch.

0:33We'll call this one switch A and switch B.

0:36And over here the top of rack switches,

0:38got switch A and switch B.

0:40And then those would connect up into a spine layer

0:43for a spine-leaf architecture.

0:44So we'd have some fault tolerance there.

0:46So there's one of our switches apart of the spine

0:48and it's very likely in a fault-tolerant environment.

0:50We'd have multiple spines

0:51and if we had multiple spine switches,

0:53we'd have additional connections from each of

0:54the top of rack switches to the additional spines.

0:57So for our drawing, I'll just represent

0:58one spine right here.

1:00And so the idea also I wanna point out here

1:02with the spine-leaf architecture is that we are routing.

1:05So we're routing between our racks.

1:07We don't have one contiguous Layer 2 broadcast domain.

1:10We have routed networks.

1:13So in each of our racks, let's go ahead

1:14and put it in ESXi host.

1:16So let's call this one ESXi-A.

1:19And over here this will be ESXi-B.

1:22And each of those ESXi hosts are gonna have

1:24their physical connections go to our top of rack switches.

1:27I'll just draw one to each of the switches.

1:29Even though an ESXi host is likely

1:31to have multiple physical network interface cards,

1:33also known as vmnics.

1:35So I'll draw a couple over here as well as a representation

1:38of the physical connectivity.

1:40And over here, lemme go ahead and put VM-A.

1:43And over here I'll put VM-B to represent a virtual machine

1:47that's being hosted by those respective ESXi hosts.

1:49And here's the magic, hold onto your hats,

1:52instead of connecting these virtual machines

1:54to a traditional distributed port group

1:56that would allow them to be, for example, on the same VLAN

1:59but instead we are gonna have a new segment,

2:02this new Layer 2 segment.

2:04And specifically this will be a Layer 2 NSX segment.

2:07And even more specifically,

2:08we could call this a Layer 2 NSX overlay segment.

2:13So from an administration perspective,

2:14it just looks like a port group that's representing

2:17that segment and we simply connect the respective PCs to it.

2:20So even though these two hosts, ESXi-A

2:23and ESXi-B, do not have the same connectivity

2:26to the same Layer 2 VLAN

2:28if we implement a Layer 2 NSX overlay segment,

2:32again, think of it like a VLAN

2:33because what it really is is a Layer 2 broadcast domain,

2:36that segment will show up like a port group on each

2:39of our distributed switches.

2:40We connect VM-A to it, we connect VM-B to it,

2:42and boom, those two VMs are logically connected

2:45to the same Layer 2 broadcast domain.

2:47So lemme give some IP addresses here.

2:48I'll give this one 10.10.0.10.

2:51And we'll give this one the IP address of 10.10.0.11.

2:55Now on the backend we have a little problem to solve,

2:57and that is we don't have the same

3:00Layer 2 VLAN connectivity from rack one

3:03over here all the way over here to rack nine

3:06because we have routing at the spine layer

3:07between both of those.

3:09So how in the world if VM-A tries to communicate with VM-B,

3:12how is that communication actually possible?

3:15And here is the magic.

3:16We are gonna create a tunnel between ESXi-A and ESXi-B.

3:20So there are the two ends of the tunnel.

3:22I'll go ahead and make a nice macaroni shape

3:25there to represent the tunnel.

3:26I'm even gonna label it.

3:28And this tunnel between ESXi-A and ESXi-B that was created

3:31by NSX are gonna be terminated at VMkernel

3:34adapters on each of the hosts.

3:36Over here, perhaps we're using VMK 10

3:39and over here we could use VMK 10 as well.

3:42And in association with these VMkernel adapters,

3:45we're also gonna have an IP address

3:46for each end of the tunnel.

3:47So maybe over here at ESXi-A,

3:49VMK 10 is using 10.11.11.11

3:53with the 24-bit mask.

3:54And over here at ESXi-B for its VMkernel 10 adapter,

3:58which is acting as the tunnel endpoint on this side,

4:00maybe it's using 10.22.22.22.

4:04So TEP is an acronym for tunnel endpoint.

4:07So think of it like a VMkernel adapter

4:09with an IP address representing the end

4:11of the tunnel here on ESXi-A

4:13and the other end over here at ESXi-B.

4:15And I intentionally used different subnets for each

4:18of the tunnel endpoints to reinforce the concept

4:20that we're routing between the two devices,

4:23between the two ends of the tunnel.

4:25So although in some typologies we could place both tunnel

4:28endpoints in the same exact subnet,

4:30I intentionally put these tunnel endpoints in two separate

4:33subnets, just to reinforce the concept

4:35that we're not just bridging the traffic here,

4:37we are with our tunnel, we're routing the traffic

4:40between two reachable IP addresses.

4:43So over here at VM-A, if it did a ping to 10.10.0.11

4:49that traffic would be forwarded out the VM

4:51into this port group, ESXi would see it and see

4:55that it came in on this Layer 2 NSX overlay segment.

4:58And then take that entire frame,

4:59we're talking about Layer 2 and everything higher than

5:01that, that this client was sending it will encapsulate that

5:05and then it will route it

5:06through the tunnel over to ESXi-B.

5:08So if the original message here is in pink, I'll go ahead

5:11and put that into the tunnel, it gets encapsulated.

5:14So the original content is effectively now the payload

5:16and the tunnel traffic will look like it's coming from

5:2010.11.11.11 being routed to 10.22.22.22.

5:24And at this end it would de-encapsulate it

5:26and then forward it down to the intended recipient.

5:29So from the client's perspective, it just looks

5:31and feels like a common Layer 2 broadcast domain that

5:34VM-A and VM-B are in, but behind the scenes,

5:37these two ESXi hosts, which are enabled for NSX,

5:41have set up tunnel endpoints and they are encapsulating

5:44and routing the traffic over that tunnel back

5:47and forth on behalf of VMs that are connected to

5:49that Layer 2 segment.

5:51And you know what, it would only take a couple of moments

5:52to demonstrate this in action.

5:54And before I take you to the interface, let me reinforce

5:57the concept here that my goal isn't to have us memorize all

6:01the details on how to configure this.

6:03That's coming up in later skills.

6:05But my intention right now is just to get a comfort level

6:07that that encapsulation is happening

6:10by simply connecting these two VMs

6:12to an NSX Layer 2 segment.

6:14So as a demonstration, here is the vSphere Client

6:17that we know and love.

6:18And here I'm on the networking tab

6:20and I'm looking at a distributed switch called DS for NSX.

6:23And a few of these segments here,

6:25notice that if we click on this

6:27what looks like a port group, it has a big N there.

6:29And what that big N represents is

6:30that this is not just a normal distributed port group

6:33as part of a distributed switch,

6:35but instead this is an NSX segment

6:38and it has a virtual network identifier,

6:40this number right there.

6:41But the case in point is I just wanna point out

6:43that these are how they look from the vSphere Client.

6:47They simply look like port groups.

6:48So this is the NSX manager will have lots

6:51of time in playing here later.

6:53But for now, I just wanna go ahead

6:54and create a brand new segment.

6:56Again, this segment's just gonna show up on

6:57the distributed switch.

6:59It's gonna look a lot like a port group.

7:01So I'm gonna create a new segment by going to segments here

7:04and clicking on add segment.

7:06And I'll call it Fun Demo for fundamentals demo.

7:09And I'm gonna go ahead

7:10and associate with a transport zone called

7:12Our Overlay Transport Zone.

7:13We'll talk about that also here in just a moment.

7:15And we'll scroll down and click on save.

7:17So all we did here in this tool called NSX Manager,

7:20we just created this new segment called Fun Demo.

7:22We hop over to the vSphere Client, check it out,

7:25there it is, looks just like a port group.

7:27So to demonstrate this segment being used, lemme go ahead

7:30and deploy a couple VMs

7:31and I'll put 'em on separate ESXi hosts.

7:34So if I go back to my VM and templates view,

7:36I've got a folder called templates here,

7:38and lemme create a new VM or tube from this template.

7:40So I'll right click on this template

7:42and from the menu, I'll click on new VM from this template

7:45and I'll call this VM on host A.

7:47And lemme go ahead and lemme just put it here

7:49for Discovered virtual machine.

7:50Click on next.

7:51And then lemme go ahead and place this

7:53on EXSi-A right there.

7:54Click on next.

7:56I'll choose the data store.

7:57Click on next.

7:58And I'll customize to make sure

7:59I put it on the right segment.

8:01And then we'll go ahead and power it on.

8:02Click on next.

8:03And I wanna put this VM on that new segment we just made,

8:06which is this one right here, the Fun Demo.

8:08So that's the NSX overlay network segment that we just made.

8:12Again, it just looks like a port group

8:13on the distributed switch.

8:15So we'll connect it there and click on okay.

8:17And click on next and finish.

8:19All right, one down, one to go.

8:20We'll right click on our template again.

8:22New VM from this template, we'll call this VM on host B.

8:26I'll put it in Discovered virtual machines, in that folder.

8:28Click on next.

8:29And then I'll go ahead and choose the right host for this,

8:31which is gonna be ESXi-B.

8:33Click on next.

8:34Choose the data store.

8:35Click on next and customize and power it on.

8:38So I wanna customize it because I wanna place it on

8:41that same port group,

8:42or in this case the same NSX segment,

8:45which is right here called Fun Demo.

8:47And we'll click on, okay and click on next.

8:50And we'll click on finish.

8:51And now both those VMs are powering up.

8:53So let's go ahead and let's bring a console to them.

8:56So lemme go to VM on host B and launch a web console there.

8:59Great, that's booting up.

9:00And let's go to VM on host A

9:02and open a web console there.

9:04And let's also configure IP addresses.

9:06So here in the top left hand corner showing us which VM

9:08we're on, this is VM on host A.

9:10So let's give it an IP address, the pseudo I have

9:11config ethernet zero.

9:13And the address we want on VM-A is 10.10.0.10.

9:17And we'll put a 24-bit mask on there as well.

9:20We'll do an ifconfig for ethernet zero, just to confirm.

9:23All right, that looks great,

9:24let's go over to the VM on host B.

9:26So here's the VM on host B.

9:27So we'll configure its IP address as 10.10.0.11

9:31with a 24-bit mask.

9:33And we'll confirm that with an ifconfig for ethernet zero.

9:36And that looks good.

9:37So before we do a ping test,

9:39let's just go verify real quick that

9:41they are both on the same segment.

9:43So if we click on network here

9:44and then we go down to our distributed switch, then click on

9:46that Fun Demo, let's click on VMs.

9:48And sure enough, we have both VMs that are on that segment.

9:52They're both connected there.

9:53And the first VM is running on ESXi-A.

9:55And the second VM is running on ESXi-B.

9:58Let's verify connectivity

9:59with the ping from the VM on host A,

10:02which is at 10.10.0.10

10:04and let's ping 10.10.0.11,

10:06press enter and that seems to be working no problem.

10:09But behind the scenes, the ESXi hosts are taking

10:12that traffic, tunneling it and forwarding it to each other.

10:16So from an end user's perspective, it looks totally normal,

10:19like "Hey, we're just on the same Layer 2 broadcast domain."

10:22But behind the scenes, the two ESXi hosts are tunneling

10:25that traffic back and forth.

10:27And the visual representation of that is right here.

10:29So VM-A and VM-B, they're both connected

10:31to the same Layer 2 overlay segment as part of NSX,

10:35the same Layer 2 broadcast domain.

10:37And for the traffic,

10:38it's actually being sent over the tunnel

10:39between ESXi-A and ESXi-B.

10:42And sometimes it's a good idea just to verify that

10:44what we think is happening is really happening.

10:47So through the magic of some packet captures,

10:49let me go ahead and put a packet capture on this.

10:52We'll send some traffic over again

10:53and then take a close look at capturing the traffic right

10:56here as it crosses the network.

10:58All right, so in the background I've got a packet capture

11:00running this to that same exact ping again

11:02from the VM on host A

11:04to the IP address of the VM over on host B.

11:06We'll let that go a few times.

11:07We'll do a control C to stop it.

11:09And let's take a look at that packet capture.

11:11All right, and here we go.

11:13So lemme also explain this part right here.

11:15The first four lines here represent the encapsulation

11:18and the forwarding of the data from my ESXi host over

11:22to my management computer,

11:24and that was using GRE, so the actual traffic

11:27that was generated and then forwarded from ESXi-A

11:30over to ESXi-B starts right here.

11:33So the source address was 10.11.11.11,

11:36and that's the tunnel endpoint on ESXi-A.

11:38And the destination address is 10.22.22.22,

11:42which is the tunnel endpoint over on ESXi-B.

11:45So to forward to those destinations,

11:46we used a local Layer 2 address here MAC address.

11:49And then this second MAC address

11:51for the destination is the MAC address

11:52of the default gateway that was being used to reach

11:55and forward in the direction of 10.22.22.22.

11:58So this packet sent from ESXi-A

12:00to ESXi-B had a payload that was UDP.

12:03So the UDP payload is tested to the well-known port

12:06of 6081 that's being used

12:08for the encapsulation, used for the tunnel.

12:11So ESXi one shows a high currently unused port

12:14and then sent it to the well known port of 6081.

12:17And because ESXi-B was listening on port 6081

12:20for UDP, it continued to open up and de-encapsulate.

12:23And as ESXi-B continued to de-encapsulate,

12:26it saw generic network virtualization encapsulation,

12:30which the acronym for that is G-E-N-E-V-E

12:34or GENEVE for generic network virtualization encapsulation.

12:37And that's what NSX uses for the encapsulation

12:40of the traffic between in this example ESXi-A

12:43and ESXi-B.

12:45So after the GENEVE header,

12:46then we have the original payload,

12:48the original frame and packet that was sent by VM-A

12:51that was being sent over to VM-B.

12:53So we looked at the source MAC address here of 0050,

12:56et cetera, et cetera, ending in 2C1A.

12:59That is the MAC address associated with VM-A.

13:03And to confirm that here on VM host A,

13:05we could do an ifconfig, press enter,

13:07and here we can verify its MAC address right there.

13:10Also, while we're right here looking at the VMs,

13:12let's also take a look at the Layer 2 MAC address

13:15on the VM that's running on host B.

13:17So here is host B

13:18and there's its MAC address right here ending in 0A1B.

13:23And that's what we should have seen inside the trace

13:26as the destination in the payload.

13:28So let's verify that as well.

13:29So if we go back to our packet capture,

13:31there's the destination address right there

13:33ending in 0A1B.

13:35So the traffic was sourced from 10.10.0.10

13:37that's the VM on host A going to the IP address

13:40of the VM on host B.

13:42And again, just as a reminder,

13:43everything from this line going up was

13:48just the traffic in delivering this packet capture over

13:51to my management computer

13:53and my management computer's right here at .151.

13:56And then everything from right here below is all

13:59of our traffic related to NSX

14:01with the original payload being right here.

14:03And the traffic rigor on the tunnel is everything from

14:05here to here.

14:07So I'll label that part as the tunnel.

14:09Again, that's the GENEVE tunnel.

14:10And then the payload of that is the original traffic

14:13that was going from the VM on host A going over

14:16to the VM on host B.

14:17And again, we'll also have more opportunities

14:19to both configure and verify this,

14:20but I just wanna reinforce the concept

14:22that it is really happening

14:23and it is really that easy once NSX

14:27is set up and configured.

14:28So one of the benefits is extended Layer 2 broadcast

14:32domains, even when we have ESXi hosts that are not attached

14:35to the same common Layer 2 broadcast domains.

14:38And again, the way that NSX pulls this off is using

14:40the GENEVE tunnels and tunneling the traffic

14:43from one EXSi host to another.

14:46Another benefit that NSX brings

14:47to the table is security.

14:49So for any VMs that are part of our infrastructure

14:52where NSX is involved, we have several security features,

14:55including what's known as a distributed firewall.

14:57And think of a distributed firewall

14:59as a firewall that just hovers everywhere.

15:01So we could be very granular in what we want to permit

15:04or allow or deny between any two VMs,

15:08even two VMs that are on the same exact broadcast domain.

15:11So if we want to allow SSH or HTTPs or ICMP

15:15or anything else using the security services,

15:17we can control what is or is not allowed

15:19between the two VMs.

15:20And that also would apply to two VMs

15:22that are sitting on the same ESXi host.

15:24So over here at ESXi-B, if we had VM-B

15:27and VM-C who's also connected to that same segment,

15:30we can also control what's allowed back

15:32and forth between those two VMs as well.

15:34Another big benefit of NSX is the ability

15:37to do Layer 3 routing.

15:38And with NSX, instead of having to do

15:40that on our physical environment with our physical routers

15:43and switches and doing the routing there,

15:45we can do the routing logically in software.

15:47So lemme give you a quick

15:48diagram of what that could look like.

15:50Let's say imagine we have a router here, this router one,

15:53and let's imagine we have router two and router three,

15:56and then this guy goes up to the internet.

15:58We have some connections here.

15:59Then down here, let's imagine we have a few network

16:01segments, the 10.10 network and the 10.20 network

16:04and the 10.30 network and the 10.40 network.

16:07Let's go ahead and put some connectivity there.

16:09So we'll have this router router two connect

16:10to those two network segments

16:12and over here are three connected there.

16:14Let's put some VMs there on those segments as well.

16:16So we'll put one VM there, I'll put 'em in blue,

16:18this guy be in yellow, and this VM will be in pink.

16:20And I'll put this VM here in green.

16:22So for the routing, we can do routing east-west,

16:25that'd be routing within our infrastructure.

16:27We can also do routing for north-south traffic as well.

16:29So let's imagine this VM represents customer one,

16:32and this yellow represents a VM that's a web server.

16:35And the pink represents an app server

16:37and the green represents a database server.

16:40So for east-west traffic, we can route the traffic

16:42between those VMs.

16:43And for our traffic that needs to go out

16:44of our enterprise, out to the internet,

16:46for example, we could also implement

16:48the north-south routing.

16:49And in conjunction with these routers,

16:51which in a NSX environment, they refer to them as gateways,

16:54we could also implement network services, such as

16:56network address translation and DHCP and load balancing

17:01and VPNs and stable firewall services and many, many more.

17:06And to help reinforce what that might look like inside

17:08of an NSX environment, let me give you a sneak peek.

17:10So here's an example of what that would look like.

17:12We have a router here.

17:13We have another router here and here.

17:15Then we've got four network segments.

17:17So I've got one here,

17:18that I'm using the 10.10.0 address base on.

17:21I've got another Layer 2 broadcast domain here

17:23for segment 20 where I'm using the 10.20.0 address base.

17:26I've got a third one right here

17:27where we're using the 10.30.0 address base.

17:30And then I've got another segment over here,

17:31another Layer 2 broadcast domain

17:33where I'm using the 10.40.0 address base.

17:35And the way these segments are represented is they simply

17:37show up and look like port groups on our distributed switch.

17:41So we simply connect our VMs to the segments,

17:43which again look like port groups

17:44that we want them to be a part of.

17:46And then the logical routing services inside

17:48of NSX are providing the IP addresses

17:50and the routing to do the east-west routing as well

17:53as the north-south routing for those clients.

0:00<v Instructor>For the deployment, configuration,</v>

0:02and management of our NSX environments, we are going

0:05to use an entity called the NSX Manager

0:08and think of the NSX Manager, very similar to the function

0:10of a vCenter Server Appliance.

0:12So we're using vCenter to manage our ESXI hosts.

0:15We're gonna use the NSX Manager to manage all

0:18of our NSX components.

0:20What we're gonna first do is deploy the NSX Manager as a VM.

0:24So we'll choose one of our ESXI hosts to deploy that on

0:27and then once we deploy it, it's gonna encourage us

0:30to go ahead and create a cluster.

0:32And a cluster is three VMs,

0:35specifically three NSX Manager VMs that we can use

0:38to help manage our entire NSX environment.

0:40So let's say we have three VMs that we've deployed.

0:43Now the first one we're gonna deploy as an OVF.

0:46So you deploy it, install it,

0:47you let it get up and initialized

0:48and then once it's running, it encourages you

0:50to add additional managers.

0:52So right from the interface of the NSX one, for example,

0:55you can go ahead and deploy NSX two and NSX three.

0:58It'd also be wise to have each of those

1:00on a separate ESXI host.

1:01So this could be on host X, and this could be on host Y,

1:05and this could be on host Z.

1:06So we may wanna set up some affinity rules to make sure

1:09that if we're using DRS that our NSX VMs are being deployed

1:14and not on the same exact host.

1:16That way we can share the love and the resources that each

1:19of those NSX appliances is gonna get.

1:21So let's imagine this is our management network right here,

1:24and I'm gonna use 192, 168.1.0 with a 24 bit mask.

1:29So maybe this guy's at .11,

1:31and we put the second one in at .12,

1:32and we put the third one in at .13.

1:34And what we can also do is set up a virtual address,

1:37a virtual IP, to manage them as a cluster.

1:40So let's go ahead and pick, for example, .10

1:42as the virtual IP so you and I, we connect to the IP address

1:45of .10 with https, and this is gonna associate that with one

1:48of our NSX managers, and that's where we can go ahead

1:51and start working.

1:52Now, behind the scenes, let's say we have 50 objects

1:55inside of NSX, including hosts and other VMs

1:59that we'll be talking about here in just a moment.

2:01Even though when we connect to the virtual IP address,

2:03we're only connected to one of the NSX appliances

2:05or one of the NSX managers, behind the scenes,

2:08it's gonna divvy up some of the loads.

2:09So perhaps this NSX Manager is gonna be managing

2:1115 of our objects, and this device is gonna be managing

2:1515 of our objects, and this one may be 20,

2:17so hopefully that adds up to 50.

2:19So that division on the backend is done automatically.

2:22Also, in addition to using a virtual IP address,

2:25we could also set up a load balancing service

2:27on the front end and if we did implement a load balancer,

2:30we would connect them to the load balancer virtual

2:32IP address, and then it could spin us off to the least busy

2:35or based on the load balancer rules, the NSX Manager

2:38that it believed was the least busy,

2:40but even without a load balancer,

2:41we can set up a virtual IP address,

2:43have multiple NSX managers,

2:45and behind the scenes, they'll divvy up the responsibility

2:47of interacting with and working with our NSX devices.

2:51And these NSX managers working together are referred to

2:54as an NSX Cluster.

2:56So to give you a visual idea of what that looks like,

2:58this is the interface for the NSX manager.

3:01So I've gone here to the appliances section,

3:03and I currently have one NSX manager in place.

3:06So it's begging me, please add more.

3:08So I simply click here and I could go through the process

3:11of yet adding a second, and then repeat that

3:13to add a third NSX manager that would become

3:16part of this cluster.

3:17So on this first NSX Manager, there's its management address

3:20right there of 192 168, 1.11 and then here's the version

3:23of NSX that I'm currently running.

3:25So the NSX Manager is the brains of the operation.

3:28So let's imagine this is our NSX Manager right here.

3:30As part of the deployment, once we deploy it,

3:32we'll also tell it where our vCenter is.

3:34Let's mention we also have here on our management network,

3:36the vCenter Server Appliance

3:38and the reason the NSX manager needs to know

3:40about the vCenter Server is because the vCenter Server

3:42is in charge of the distributed switch,

3:44which in the current flavor of NSX,

3:47we're gonna be leveraging the virtual distributed switch

3:49and adding our logical segments from NSX to our VDS.

3:54So as part of that integration, in addition

3:55to identifying the virtual distributed switch in vSphere

3:58that we're gonna use and enhance, we're also gonna leverage

4:01that relationship with the vCenter to identify the ESXI host

4:05that we are going to include as part of NSX.

4:08So that way right here from the NSX manager, we can specify,

4:11oh, for this host or that host, we want

4:13to add the NSX software to those hosts

4:17so they can participate as part of NSX.

4:19And the NSX Manager is gonna become the centralized control

4:22plane for the NSX environment.

4:24So any of the details regarding segments or routers,

4:29virtual routers in the NSX environment,

4:31or which segments should be included on which hosts,

4:34that's all controlled by the NSX Manager,

4:36and it's gonna be the Centralized Control Plane.

4:38And then on each of the ESXI hosts

4:40and other objects that we'll soon talk about here

4:42in a moment, they'll receive a copy of what they're supposed

4:45to do and that's called the Local Control Plane.

4:48So the Centralized Control Plane is managed

4:50by the NSX Manager cluster.

4:51And for individual hosts that are participating in NSX,

4:54they'll have a Local Control Plane.

4:57Effectively what they need to know to do their jobs

4:59as part of NSX.

5:01Let's imagine that you and I are sitting here

5:03at this management PC, we've logged onto the NSX Manager

5:06and we've identified these two hosts, we'll call it host A

5:08and B, that we want them to participate as part of NSX.

5:12So from the NSX Manager, we install and add the software

5:15to those hosts.

5:16And the moment that we add that NSX software

5:19and they're up and running and happy, happy,

5:21those are now referred to as transport nodes.

5:24And think of a transport node as an ESXI host

5:26with the additional software regarding NSX that allows it

5:30to do the tunneling that we took a look at

5:32a couple videos ago where traffic coming in, for example,

5:35from one VM on a segment is encapsulated and tunneled

5:38and shipped off to a remote destination

5:41where the receiving site is de-encapsulated.

5:43Effectively, that's the function of a transport node

5:46in the world of NSX.

0:00<v Lecturer>So let's take a closer look</v>

0:01at what exactly is a transport node.

0:03And again, the high level overview

0:04is that a transport node is an ESXi host

0:07that we know and love where we've added to it

0:11the ability to work with NSX.

0:13So the way that would look

0:14is you and I would go to our NSX Manager.

0:17The NSX Manager is working in conjunction with vCenter,

0:20so it knows exactly about which hosts are available.

0:23And then using NSX Manager, we reach out to a host,

0:25let's say ESXi-A, and we specify

0:28that we wanted to participate as part of NSX.

0:31And once we do, the NSX software is installed

0:33and enabled on ESXi-A and bada bing, bada boom,

0:36it becomes a transport node.

0:38And part of that, the ESXi host now

0:40is gonna get a new VMkernel adapter

0:42and is gonna use that VMkernel adapter

0:44as one end of its tunnel called a tunnel endpoint,

0:47so that if it needs to, it can encapsulate

0:49and forward traffic over that tunnel to another entity.

0:53And up to this point,

0:53we haven't talked about other nodes

0:55other than a transport node.

0:55So let's imagine it sending it over

0:57to another ESXi host like ESXi-B,

1:01who could then deencapsulate it

1:02and then forward it onto to its final destination.

1:03And for every good tunnel,

1:04there's two tunnel endpoints, one at each side.

1:07So if we had two clients, for example,

1:08right here on segment 20,

1:10and this one was running on ESXi-A,

1:13and this one was running on ESXi-B,

1:15and they're both connected to that same segment

1:17as they communicated back and forth,

1:18the traffic would be encapsulated.

1:20If this is VMA, and this is VMB

1:22and VMA is communicating with VMB,

1:24the traffic would be initiated by VMA,

1:27ESXi-A would encapsulate it,

1:28send it through the tunnel as a routed packet

1:30over to ESXi-B, who would deencapsulate it,

1:32and then forwarded over to VMB,

1:34which is one of the great reasons why

1:36it's called a transport node.

1:37It's able to do transport over a tunnel,

1:40specifically a GENEVE tunnel

1:41from itself to the other end point.

1:43So let me clean this up a little bit

1:44and let's chat about a few additional terms.

1:47One of those terms is called a transport zone.

1:49And just for fun, let me go ahead and draw a couple zones.

1:52I'm gonna put a zone here,

1:53and then I'll put another zone here

1:54and let me label those.

1:55Let's call this zone right here the production zone,

1:57I'll call it prod zone for short.

1:59And over here, I'll call this the dev zone,

2:01short for development.

2:03Let's imagine we have six ESXi hosts

2:05that we've enabled for NSX.

2:08So if they're enabled for NSX,

2:09those ESXi hosts are referred to now as transport nodes

2:12for the purposes of NSX.

2:14So I'll put four of 'em right here.

2:16I'll label them one through four.

2:18Those are ESXi hosts 1, 2, 3, and 4.

2:21And over here,

2:22I'll specify that these other two hosts

2:24are gonna be in the dev zone only.

2:26So those are host 5 and 6.

2:28So what exactly is a transport zone good for?

2:31Transport zones control the scope of a new segment.

2:35So let's create a new segment,

2:36and we'll create this layer two segment,

2:38we'll call it segment 50.

2:40So this NSX segment is a logical layer two broadcast domain.

2:45Now, it could exist across all of our ESXi hosts.

2:48However, if we've carved up these four hosts,

2:50so they're only participating in the production zone,

2:52and these two hosts are only participating in the dev zone,

2:55when we create a new segment,

2:56we can associate that segment with the production zone.

2:59And that way the segment effectively would be reachable

3:01and accessible as a port group for these four ESXi hosts.

3:05But if segment 50 is not associated with the dev zone,

3:08these two ESXi hosts are not gonna have that port group.

3:12Or in the terms of NSX,

3:13they're not gonna have that logical segment

3:15as part of their virtual distributed switch.

3:18And just to be fair, let's create another segment.

3:20We'll go ahead and draw it like this,

3:21and we'll call it segment 60.

3:23Let's imagine we only have this segment available

3:25for these two hosts.

3:26So what we could do is we could go ahead

3:27and associate the segment with the dev zone.

3:29And because these two hosts are participating

3:31in the dev zone, only these two hosts

3:34would have that segment available to 'em.

3:35Again, it would appear on the virtual distributed switch.

3:38It simply appears like a logical port group

3:41that is provided by NSX.

3:42So it's referred to as a segment.

3:43So when we think about the concept of a transport zone,

3:46think about the concept of scope,

3:48meaning how many ESXi hosts

3:50and how many devices are gonna be supporting that segment.

3:53So if a segment, again, is associated

3:55with the production zone,

3:56it's only being available to these four hosts.

3:58If we have a segment associated with the dev zone,

4:00it would then only be available

4:02to these two transport nodes.

4:03Also, regarding ESXi hosts that have been enabled for NSX,

4:07not only are they transport node,

4:08but if we're gonna be explicit,

4:10we could also call them a host transport node,

4:13which is gonna help differentiate them

4:14from another type of node

4:16we're gonna talk about in the next video.

4:17And while we're chatting about host transport nodes,

4:19let's also take a look at the uplinks.

4:21So let's imagine we have this host, let's call it Host A.

4:24And Host A has a few vmnics connected

4:27up to the physical world.

4:28So here's our physical infrastructure

4:30with some high speed ethernet switching out here.

4:32So I'll label this as physical.

4:34And for the vmnics,

4:35let's call 'em vmnic 0 and 1 and 2 and 3.

4:38So when we go to the NSX manager,

4:40and we specify that we want Host A to participate

4:42and become a host transport node as part of NSX,

4:45we are also going to be asked

4:46and need to provide information

4:48regarding which uplinks we want this host to use

4:51as part of being a host transport note.

4:53Do we wanna use vmnic 0 and 1, or 2 and 3, or 1 and 3?

4:57And do we wanna use teaming in the form of load balancing,

5:01or do we wanna use a failover order?

5:03And so the details regarding which uplinks we're gonna use

5:06are configured as part of an uplink profile.

5:09So it'd be a great idea before we start configuring

5:12and setting up an ESXi host as a host transport node,

5:15we'd wanna plan out and identify beforehand

5:17exactly which interfaces we wanna use for the uplinks

5:21and our uplink strategy.

5:23Again, do we wanna do load balancing with two or more nics

5:26or do we wanna have two or more vmnics

5:28in a specific failover order?

5:30And we're gonna specify those as part of an uplink profile

5:32when we're configuring our host transport node.

5:35And what's really interesting about this

5:36is that if we specify one uplink that we're gonna use,

5:39it's gonna automatically create a new VMkernel adapter

5:42with an IP address that we specify

5:44as part of our configuration.

5:45And the IP address that we're gonna specify

5:47is the tunnel endpoint on this ESXi host.

5:50Now, the key is if we did two uplinks

5:52as part of our uplink profile,

5:53it's not just gonna have one VMK

5:55with an IP address for a tunnel endpoint.

5:57Instead, it's gonna have two.

5:58So you have two uplinks.

6:00It's gonna equate to two tunnel endpoints that it can use

6:03to communicate with other nodes in NSX.

6:05And let me show you a quick example of that

6:07to reinforce that concept.

6:08So this is the NSX Manager,

6:10and this is the section for uplink profiles right here.

6:12And here's an uplink profile called ESXi-A, et cetera.

6:16And it's using exactly one uplink.

6:18So as a result, we would expect one tunnel endpoint address

6:22on the host transport node that's using this uplink profile.

6:25So if we go to our hosts and we go down to ESXi-A

6:28and take a look at the details,

6:30and I'm gonna click on Configure

6:31and click on Next a couple of times

6:33and click on Next.

6:34Right here is giving us a visual representation

6:37that is using vmnic 2

6:38And if we expand this,

6:40it's showing us the uplink profile it's using,

6:41which is the ESXi-A one.

6:43And as a result of that, having one uplink for the NSX,

6:46I'll go ahead and click on Cancel here.

6:48If we look at the tunnel endpoint address,

6:50it has one tunnel endpoint address that's 10.11.11.11

6:54which I hard coded for that endpoint.

6:56And again, if we had two uplinks or three uplinks,

6:59we'd have two or three respectively

7:01tunnel endpoint addresses, one for each of our uplinks.

7:05And then if we went to the vSphere Client

7:06and took a look at the ESXi-A host.

7:08So here's the vSphere Client,

7:10we're in the host and clusters view,

7:11we're looking at ESXi-A,

7:13if we go to Configure

7:14and then go down to VMkernel adapters.

7:16Here is the VMkernel adapter that was created by NSX

7:19for the benefit of that tunnel endpoint

7:21with that IP address of 10.11.11.11.

7:24And again, if we had two uplinks

7:26associated with NSX for this host,

7:28it would have two specific VMkernel adapters

7:31with two IP addresses, one for each of its tunnels.

7:34And again, in this skill,

7:35I just wanna reinforce some of the basic concepts

7:37behind NSX.

7:38So on our Host A, because we specified one uplink,

7:41it has one VMkernel adapter specific

7:44for that tunnel endpoint.

7:45So in the interface, I think it showed us 10,

7:47and then it had the IP address of 10.11.11.11

7:51which is the tunnel endpoint on this ESXi host

7:54that it can use to communicate with other devices

7:56who are at the other end of its tunnels.

7:58So the other end of the tunnel could be Host B.

8:01So if there was Host B, that would be one tunnel

8:03and it had yet another host, let's go ahead,

8:04but Host C here with one uplink

8:07from that tunnel endpoint address,

8:08we'd have another tunnel going over to Host C

8:09to its tunnel endpoint.

8:11And in addition to building these tunnels

8:13for the tunnel endpoints to other ESXi hosts,

8:15which are also host transport nodes,

8:17there's another type of node we can also build a tunnel too,

8:20and that's called an edge node.

8:22So it could be called an edge node,

8:23or it's also referred to as an edge transport node.

8:27And that would differentiate it

8:28from the host transport node, which is an ESXi host.

8:31And the question might be, well,

8:32why do we need this thing called an edge node

8:35or an edge transport node?

8:36And the answer is the edge transport nodes

8:38are gonna take the responsibility of implementing

8:40our logical layer three gateways and services

8:44should we choose to use them for routing.

0:00<v ->If we wanna implement routing,</v>

0:02for example, having these three routers

0:04to do logical routing of our traffic

0:06for north-south traffic and east-west traffic.

0:09To implement that functionality,

0:10we're gonna configure it all from the NSX Manager,

0:13so you and I interface with the NSX Manager

0:15and then we specify that we want to have, for example,

0:17gateway zero, and gateway A, and gateway B,

0:20and connect them logically to those various NSX segments.

0:24And when we create this logical routing inside of NSX,

0:29the actual ESXi host transport nodes,

0:32they can actually do the logical routing themselves,

0:35and then if they need to forward traffic

0:36to another ESXi host, they can go ahead and tunnel it over.

0:40And that's known as a distributed router,

0:42where the logical routers are implemented

0:45on the actual host transport nodes.

0:47However, sometimes

0:48we may need to integrate additional services,

0:50including things like network address translation, or VPNs,

0:54or connecting our NSX routed environment

0:57out to the outside world, and for those specific functions

1:00that can't be done by the host transport nodes themselves,

1:03we have a separate entity,

1:05and that, my friend, is an edge transport node.

1:09Now we have a couple of options

1:10for implementing an edge transport node,

1:12the easiest option in my opinion,

1:14is to implement a little VM.

1:16So this little VM is running on a host somewhere,

1:18and this little VM is implemented, and it's an edge node.

1:22So we can have an edge node VM,

1:23or we could also do a bare-metal edge node.

1:26And that's where, instead of running the edge node as a VM,

1:29we'd take a physical computer

1:31and install the appropriate software there.

1:33And so one of the questions might be why would we ever,

1:35you know, wanna have a dedicated piece of hardware

1:37as an edge node when we can implement

1:39the functionality of these gateways as a VM?

1:41And the answer is throughput.

1:43If you wanna crank out

1:4420, or 40, or 100 gigabits per second,

1:47you may need some dedicated hardware to do that,

1:49and that's why there's the option of a bare-metal edge node.

1:52So let's imagine we wanna implement

1:54the routing infrastructure and we decide to deploy a VM.

1:58So to deploy that VM for the edge node,

2:00as I mentioned, it's done right through the NSX Manager

2:03and you simply specify what host you wanna run that VM on,

2:07we're gonna specify which uplinks

2:09on that host should be used by the edge node,

2:11and let's go ahead and visualize that with an ESXi host.

2:15Let's say this is an ESXi host here,

2:17and here's our edge node VM running on that host,

2:20and of course the host has some physical connectivity out,

2:23and as part of our configuration of the edge node,

2:25we're also gonna specify which uplinks

2:27we want the edge node to use.

2:28So let's say I have VM NIC zero, and one, and two,

2:30and three, and four.

2:31And very similar to the uplink profile

2:34that we specified for an ESXi host

2:36when it's acting as a host transport node,

2:38we're also, when we deploy the edge node,

2:40gonna specify which uplinks we want it to use

2:43on the host that it's currently running on.

2:45So, maybe we want this edge node to go ahead

2:47and use VM NIC three as the active

2:50and then VM NIC four as the standby,

2:52I'll put a A there and S there.

2:54And as a result, that edge node

2:55is also going to get a tunnel endpoint.

2:57So that tunnel endpoint, we'll go ahead and call this one,

3:00let's say it's 10.33.33.33.

3:04And another question might be, well,

3:06what would this need to tunnel to?

3:07And the answer is

3:08it could tunnel to any other transport node,

3:10so we could tunnel over here to ESXi, let's say ESXi-A,

3:14which is acting as a host transport node

3:16with this tunnel endpoint address of 10.11.11.11.

3:20We can add this edge node with a tunnel going to ESXi-B,

3:23and perhaps this tunnel endpoint address is 10.22.22.22.

3:29And the cool thing is

3:30that there is a function called a distributed router,

3:32we'll call it a DR for short,

3:33not to be confused with an OSPF designated router,

3:36so I'll spell it out, that's a distributed router.

3:39And that distributed router exists here

3:41on the edge node on the local control plane,

3:43it also exists here on ESXi-B and the ESXi-A,

3:47and the entity that's coordinating all that

3:49is the NSX Manager,

3:51and up here we have the centralized control plane.

3:53So the benefit of having a centralized control plane

3:55and then a local control plane that's been coordinated

3:58between the NSX Manager and that cluster,

4:00and each of our nodes, which includes the ESXi host,

4:04and also now the edge node implemented as a VM,

4:07the benefit is if we have a VM list, call this VM-C,

4:10and let's say that VM is over here on segment 30,

4:12and that VM is sending traffic into the network,

4:16and that VM is connected to this logical segment 30,

4:18ESXi-B knows exactly how to forward it.

4:21Is it gonna make the forwarding decision locally

4:23because it has all the information that needs to do that

4:25or is the destination reachable through one of our routers,

4:28AKA an NSX gateway?

4:30And if it is, ESXi-B can take it,

4:33encapsulate it into the tunnel,

4:34send it to the other side where it needs to go,

4:36where it can be deencapsulated and processed.

4:38Most of the time we're not just gonna have one edge node,

4:41we'll have an edge node cluster.

4:43So let's say this is ESXi-10,

4:46and let's also draw a really thin ESXi host over here,

4:49(laughs) because of the space, so.

4:50So, here's ESXi-11,

4:53and it also has an edge node VM,

4:56and we can implement those as a cluster that work together.

4:59Now here's the great news, in this skill,

5:01I wanted to present a big picture look at the concept of NSX

5:06and the key players inside that architecture.

5:09So with this warmup to the world of NSX,

5:12what we're gonna do is we'll take a look

5:13at implementing and verifying each of the components

5:16in one nice little step at a time.

0:00<v Presenter>I have a friend who is a juggler,</v>

0:01and he told me that over the years

0:03he's gotten better and better at juggling,

0:05and now he's a professional juggler.

0:06He said, "You know what? When we practice one day,

0:09what we're really doing is we're reinforcing

0:11what we practiced the previous day.

0:13So it's important to pause from time to time

0:15and reinforce our concept."

0:17So here's what I'd like you to do right now.

0:19I'd like you to imagine that a customer has come to us

0:22and said, "Hmm, I've heard about this NSX thing

0:25and this Software-Defined Networking.

0:27How exactly can VMware's NSX help me?"

0:31And what I would love you to do

0:32is based on these intro videos that we just went through,

0:34I'd like you to either verbally say it or write them out,

0:38or think in your mind,

0:39what exactly are some of the benefits of NSX?

0:43And again, I'm not expecting you to be an expert yet on NSX,

0:46but based on the videos that we've just gone through,

0:49I'd like you to be able to list just a few of the benefits.

0:52So before we walk through the next video

0:54and we confirm some of those benefits together,

0:56pause right now, think it through,

0:58what are some of the benefits?

0:59And when you're ready,

1:00join me in the next video and we'll reconvene.

0:00<v Instructor>So, list together,</v>

0:01now that we had a moment to think about it,

0:03let's list out a few of the benefits of VMware's software

0:06to find networking with their product called NSX.

0:09One of the benefits is the ability

0:11to have a common layer two segment.

0:15And if we told that to the customer

0:16and they said, "Well, we have layer two segments already.

0:18We have, you know, distribute a switch,

0:19we have four or five VMs, all the same port group,

0:22and they're in the same segment."

0:23But that's if, on our transport

0:25or underlay networks, we have those two ESXI hosts

0:28that are hosting the VMs, able to reach

0:30that same layer two broadcast domains.

0:33So with NSX, even if we have two ESXI hosts,

0:35we have one over here at this end of the data center

0:38in a rack, we have one over here in a different rack,

0:41and we have lots of routing between them.

0:43So here's a router, there's a router.

0:45We can still have a common layer two segment,

0:48an overlay segment

0:49that those VMs can go ahead and connect to.

0:51And then behind the scenes, these two ESXI hosts can tunnel

0:54that traffic back and forth.

0:56So we have a tunnel endpoint over on the host on the left,

0:58and a tunnel endpoint over on the host on the right.

1:01So this is host A and this is host B.

1:03And even though they're not on the transport network

1:06directly connected to the same layer two broadcast demand

1:09or the same vlan, the little VMs who are connected

1:11to the overlay segment can look and feel

1:13like they're on the same layer two broadcast domain.

1:16So this could be 10.10.0.10 over here,

1:20and we have 10.10.0.11 here on the same IP subnet

1:24because they're also on the same layer two broadcast domain

1:28courtesy of this logical segment provided by NSX.

1:32So I would say that would be one of the benefits.

1:35We can have logical layer two segments

1:37across the entire data center wherever we need them to be,

1:40without having to have the actual underlay network.

1:42And the ESXI hosts

1:43connected to that underlay network in the same exact VLAN.

1:46So I'll make a little note up here.

1:48Layer two segments across routed networks.

1:51Another big benefit that NSX can bring to the table

1:54is regarding security.

1:55So if we wanted to control what is or isn't allowed between,

1:59for example, this VM, we'll call it VM1

2:02and this VM, VM2,

2:04even though they're on the same layer two broadcast domain

2:06and the same subnet, with NSX, we can now control very,

2:09very granularly what is allowed between those two VMs.

2:13For example, we wanna allow TCP traffic if it's HTTPS,

2:17or do we wanna allow ICMP,

2:19or if this is an application server,

2:21and this is a database server, we can specifically permit

2:24or deny certain types of traffic flows

2:26between those two VMs.

2:27Another big benefit is routing.

2:29Now, in the case of routing, if we want to implement routing

2:32within our NSX environment,

2:34we can do exactly that.

2:35We can have a router here and here and here,

2:38and then a network segment here,

2:41another network segment here,

2:42and a third network segment there,

2:44and then route everywhere between them.

2:45And this is all without having to touch

2:48a physical piece of hardware for routing.

2:51So all this routing, especially the east west traffic,

2:54can all be done inside of NSX in software.

2:57And in addition to routing,

2:59we can also provide other IP services,

3:01including things like DHCP services and VPN,

3:05and we can set up gateway firewall services,

3:07and other services like network address translation.

3:10And all of that can be implemented right here

3:12inside of NSX in software.

3:14So the way that would play out is that you and I

3:16would log into the NSX manager.

3:18We would configure what we wanna go ahead

3:20and have implemented in NSX.

3:22And also there's various options

3:23for working with NSX manager.

3:25So here is our NSX manager,

3:27it's very likely we're gonna have a cluster of those

3:30so that we have some fault tolerance.

3:32So this would be NSX Manager, one and two, and three,

3:35all configured as an NSX management cluster,

3:38as a virtual IP address.

3:39So you and I can connect to that virtual IP address,

3:41for example, that's reachable on the management network.

3:43So here's the computer that we're sitting at,

3:45we connect to that IP address to the browser,

3:47and then it's gonna associate that

3:48with one of our NSX managers, so we can go ahead

3:51and get the graphical user interface.

3:53So that's one of our options for working with

3:55and managing NSX.

3:56And now, another option also is we could get

3:58a plugin for vCenter.

4:00So we have our vCenter server appliance,

4:02and within vCenter we could have a NSX plugin.

4:05And then that way we could just log into the vSphere client.

4:08And then within vSphere client,

4:09there's additional controls

4:11that we can use to implement control

4:12and set up our NSX world as well.

4:14And for most of the configuration and demonstrations

4:17that we're gonna use together in this course,

4:19we're gonna be managing the NSX GUI interface

4:21directly on the NSX manager

4:23as opposed to using the plugin inside of vCenter.

4:25Although at the end of the day,

4:27the functionality is the same whether we're configuring

4:30security, or DHCP services, or routing.

4:33And those are all functions

4:34and features that a customer can use

4:36by leveraging NSX in their environment.

4:39So thanks for taking an extra moment in this set of videos

4:42to pause and help reconfirm our understanding.

4:45And when you're ready, my friend,

4:46I'll see you in the very next skill.

4:48Until then, I hope this has been informative

4:50and I'd like to thank you for viewing.