I also think it'd be super effective
and useful at this point to take a look
at some of the details here at the NSX manager,
which is acting as the centralized control plane
for the entire operation of NSX.
So the NSX manager is acting
as the centralized control plane,
it's also acting as the management plane.
So you and I log in, we connect to the NSX manager,
we specify what we want to have happen,
and then the NSX manager communicates
with the transport nodes to make it happen and vice versa.
The transport nodes are also communicating information
back to the NSX manager as well. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
back to the NSX manager as well.
And you might think, well, what does the NSX manager
need to know about an ESXi host that set up
as a host transport node?
Well, if we launched a VM on ESXi-A, for example,
we connect it to a segment, there's all kinds of activity
that this VM is gonna be doing.
Things like ARPing, looking for other layer two addresses,
maybe this VM, we'll call it VMA,
is looking for the layer two address
of this VM, VMC and stuff that ARP request comes in.
Initially, that ARP request is gonna have to be sent
over the tunnel to ESXi-B, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
over the tunnel to ESXi-B,
and then this VM can go ahead and respond to it.
But how does ESXi know that it should send that traffic
over the tunnel for flooding of that initial ARP request?
The answer is the NSX manager has information
about exactly which ESXi hosts are participating
and also which VMs are connected to which segments,
and the cool thing is if we have lots of clients,
we probably don't want all that traffic
to have to go across the tunnel.
So if we have ARP tables that are being built
and the control plane knows about it,
it can actually share that information with other ESXi hosts WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
it can actually share that information with other ESXi hosts
so that in the future, for example,
another VM right here that's also connected,
if it's doing an ARP request
and ESXi-A already knows about the information
on that same segment about what that address is,
the actual ESXi host can respond back
and that traffic won't have to go across the network.
So the NSX manager has the responsibility
of a centralized control plane for NSX.
It's also the management plane and then the data plane,
the actual forwarding of traffic
is being done by our transport nodes.
In this example, we have two ESXi host transport nodes WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
In this example, we have two ESXi host transport nodes
and those are responsible for the data plane.
For example, moving the traffic between VMA,
who's trying to communicate with VMC.
Another element that's committed back and forth
are MAC address tables.
So that way, if we have like six computers over here
on ESXi-A all connected to segment 10,
I'll put that here in yellow,
and let's also imagine we have two or three VMs
also connected to this segment that are being hosted here
on ESXi-B, so I'll draw that connectivity in as well.
In a switch environment, the switch would be responsible,
or the combination of switches if there's trunking involved, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
or the combination of switches if there's trunking involved,
or connectivity between the VLANs here on these switches,
they would maintain MAC address tables
of which ports are associated with which MAC addresses.
So in NSX, if we have six over here
and three over here all connected
to the same overlay segment,
all that information about the MAC addresses
and how they're reachable is maintained by the NSX manager,
and the NSX manager can also make sure
that each of the ESXi hosts connected to that segment,
that they also have that information,
and that's an example of the local control plane
on our ESXi host transport nodes, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
on our ESXi host transport nodes,
so they have that information.
So the benefit is if we're doing forwarding here
between VMs on segment 10, ESXi-A has all the information
it needs to know to make that forwarding decision locally,
and if it needs to forward traffic over to ESXi-B,
it can go ahead and forward that
through the tunnel over to ESXi-B.
So let me clean that up just a little bit.
So I think it'd be super valuable to take a peek
at the information about this segment.
Currently we have no VMs that are connected
to any of the segments, and let's take a peek
at this initial state at the information WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
at this initial state at the information
about that segment that ESXi-A has
and compare that to the centralized control plane down here,
the NSX manager, to compare and contrast
what they both know about this segment.
And to do that, I'm gonna go ahead
and open up a terminal emulator
and let's log in with SSH over to ESXi,
which is our host transport node,
and we'll have a separate screen opened up
over to our NSX manager.
All right, so here's our connection over to the NSX manager
and let's go over to ESXi-A,
and it says the remote system refused the connection WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and it says the remote system refused the connection
and that's because SSH isn't enabled.
Let's fix that real quick.
So here in the vSphere client,
let's go to the host and clusters view.
Let's go to ESXi-A.
We'll click on configure,
and we'll go down to services.
Click on services, and then make sure that we're allowing,
at least for now, SSH access.
So I'll click on start and it is now running.
Fantastic.
Let's go back to our terminal emulator.
So here in our terminal emulator,
I'll go ahead and press enter.
So for the logins, I logged into the NSX manager as admin, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So for the logins, I logged into the NSX manager as admin,
and over here at the ESXi host, I've logged in as root,
and I'm also in this terminal emulator called secure CRT.
I'm gonna open up a little window at the bottom,
so if I need to do similar commands on both
at the same time, I can.
So to do that, I'm gonna click here on view
and the menu for secure CRT,
and I'm gonna ask it to show me the command window,
which is right here at the bottom.
So down here in the command window,
if I right click and then hover
where it says send commands to, I'm gonna say all sessions.
So now if I effectively is pressing enter
on both console windows simultaneously. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
on both console windows simultaneously.
So over here on the left, on the ESX host side,
lemme go ahead and move into NSXCLI
by typing in NSXCLI,
which gives us effectively the command line interface
for the NSX stuff.
Now press enter a few times,
and there is context sensitive help
on both of these interfaces.
So if we did, for example, a get space
and then press question mark,
it's gonna show us a list of the next possible options,
and one of those options is logical switches.
So over here on this side, if we did a get space
and a question mark, you'll notice over here, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and a question mark, you'll notice over here,
even though the commands are not all identical,
we also here have the option if we scroll up
of the option of getting a list of the logical switches.
So at the command line at the very bottom,
I'm gonna do a get logical switches and press enter.
So this is interesting, on the ESXi host,
this is prior to connecting any VMs to that segment,
the ESXi host A, it's saying, you know what?
As far as logical switches within NSX, I got nothing.
Now, why is that?
If we scroll to the right, nothing's there.
So why is that?
It's because this ESXi host, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
It's because this ESXi host,
even though it could have VMs that are connected
to that logical segment, it doesn't and as a result,
its control plane doesn't have to worry about
knowing about or working with that logical segment.
So think of a segment
like a logical layer two broadcast domain,
here it's being referred to as a logical switch.
But over here at the manager on the right hand side,
it does know about one logical switch,
and that's this VNI, this virtual network identifier,
of 68608 with a very, very long UUID, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
of 68608 with a very, very long UUID,
and if we scroll to the right a little bit more,
it's also showing us the name of that segment.
And again, host A doesn't really need to know about that yet
or have anything regarding the control plane for it yet
because it has nothing connected to it.
So over here on the right,
let's go ahead and do a get logical switch,
and I'm gonna scroll up and grab that VNI.
So we can either put in the VNI number
or we could put this really, really long UUID,
either way is great.
So I'm gonna go ahead and just copy and paste the VNI,
the virtual network identifier space WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
the virtual network identifier space
and then I'll do a question mark,
and now we could ask for information
regarding the ARP table associated with that virtual network
or the MAC table associated
with that virtual network segment
or the transport node table, which if we had ESXi-A
and ESXi-B, that both had VMs connected to that segment,
they should show up.
So let's do a few examples of this
prior to bringing on any VMs.
So let's go ahead and do an ARP table.
Press enter and currently the command worked,
but there's nothing there.
There's nothing in the ARP table
for that logical layer two segment because we have no VMs. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
for that logical layer two segment because we have no VMs.
So we hit the up arrow key and we swapped out ARP table
with mac table, same thing.
Nothing's gonna be there because we have no VMs
connected to that layer two segment.
And if we use the command get logical-switch
and the same VNI number again,
and let's use this option here, transport node table.
So I'll copy paste that, press enter,
and that's also coming back empty.
And the reason that there's no host transport nodes
associated with that segment is because neither
of our ESXi hosts, A or B, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
of our ESXi hosts, A or B,
which are both host transport nodes,
neither of them have any need for that information.
Neither of them have VMs that are connected
to that logical segment called Segment 10.
So if you're ready for something cool, here it is.
In the next video, we'll go ahead
and bring up a couple of VMs,
one on ESXi-A, one on ESXi-B, we'll power 'em up.
So I'll see you in the next video in just a moment.