So the NSX manager
where we created the overlay segment called Seg 10 yellow,
it knows about that segment,
but ESXi-a and ESXi-b have no need
to maintain information regarding that segment
because they don't yet have VMs connected to it.
So we are gonna solve that right now by bringing up this VM.
And let's go ahead and call it VMa,
meaning it's gonna be running on host A
and also give the name of 10.0.0.10,
just so I'll remember exactly
what IP address we plan to use on it.
And then over here, on this VM, let's call this VMb, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then over here, on this VM, let's call this VMb,
meaning it's gonna be running on host B,
and it'll be on the same common segment, segment 10,
and we'll give it the IP address of 10.0.0.11.
So let's head over to the vSphere Client.
We'll create these two new VMs
and attach them to this new segment 10.
So here at the vSphere Client,
I've got a template that we can use.
I also have a folder called NSX VMs for testing.
And let go ahead and let me remove those two VMs.
So we'll just go ahead and right click
and say delete from disk.
We'll click on yes. Let's also rename this folder. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We'll click on yes. Let's also rename this folder.
Think I'll right click on the folder.
From the dropdown, we'll click on rename,
and we'll simply call it VMs for Testing.
We'll save that. So I've got a folder for templates here.
Lemme right click on the tiny Linux template,
and we'll create a new VM from this template.
For this first one, we'll call it VM.
And then I'm also gonna put the IP address in the name.
That way when I see it,
we'll know exactly which VM we're on.
So it'll be 10.0.0.10.
And then I will put this in the folder
called VMs for Testing and click on Next.
And then as far as which host, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then as far as which host,
we want this to run on host A.
And then we'll click on Next.
I'm gonna go ahead and put on the local data store
on ESXi-a, and then click on Next.
And then, we'll customize the virtual machine hardware.
That'll give us the chance to put it
in the right segment for networking.
And we'll also have it powered
on after we're done with that, so we'll click on Next.
And this is a super tiny VM.
That's why I love it because it does support VMware tools,
which is fantastic for graceful power offs,
and it's also super tiny.
So if we need to deploy new ones or move 'em around, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So if we need to deploy new ones or move 'em around,
they're fantastic for that purpose.
So for networking, we'll go ahead and we'll click on browse.
And for network adapter one,
we'll put it right here on segment 10 yellow
and click on Okay, and then we'll click on Next and finish.
And then, we'll do it again for VMb.
So we'll right click on our template,
we'll select new VM from this template.
We'll call this VMb.
Then we'll give the name of 10.0.0.11,
and then we'll go ahead and put that here
in the VMs for Testing folder.
Click on Next and then we'll make sure WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Click on Next and then we'll make sure
that we're gonna run that on ESXi-b,
and then click on Next.
We'll use that data store, click on Next.
And then we'll customize it
to put on the right network segment,
and then we'll power it on.
So we'll click on Next, and we'll make sure we also put
this one on that same segment, 10 yellow,
which is the NSX segment,
and the little N is showing right there
as well as a reminder.
And then we'll click on Next and finish.
We could also verify they're connected to the right segment
by going to network and then selecting our Segment 10 yellow
And clicking here on VMs just WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And clicking here on VMs just
to verify that they are there
and also, that they're on the two separate hosts.
So let's go ahead and bring up consoles for each of those.
For VMb, lemme make sure it's done.
And sure enough, it's deployed.
So let's launch a web console for VMB.
So in the upper left hand corner has the name for us.
And let's also launch a console for VMA.
So we'll go to VMA, and once again,
we'll launch a web console for it as well.
So here at VMA, let's give it an IP address.
So we'll use the command ifconfig for ethernet zero
and give the IP address of 10.0.0.10. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and give the IP address of 10.0.0.10.
And the lab at this point is gonna default to a 8-bit mask,
and that's perfectly fine.
We can also verify that with an ifconfig, press enter.
So here's the IP address, here's the mask,
and then it'll work for our purposes.
Let's go over to VM 10.0.0.11,
which is running on ESXI host B,
and we'll give it the IP address of .11.
So here at VMb, we can verify that up here at the top,
we're at VMB.
Let's do an ifconfig just
to verify we have no IP address yet.
And let's configure an IP address as sudo ifconfig, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And let's configure an IP address as sudo ifconfig,
space for ethernet zero.
And here, we wanna use 10.0.0.11, and that looks good.
It says, Keith, you have a typo with ETH.
So we'll fix that, that looks better.
And let's also verify our work with an ifconfig.
And that looks great.
So now, as a spot check,
we have this VM here, VMa at 10.10.0.10,
and we have this VM over here, VMb at 10.0.0.11.
So if they wanna communicate with each other,
that traffic would go down to the host.
The host then would, based on the information it got WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
The host then would, based on the information it got
from the NSX manager, forward that over the tunnel
to the respective host where that VM exists.
Or if it's something like an ARP and it's already cached,
that information could be responded to locally
by the local ESXI host if it already has it.
So what I propose we do before we start generating traffic,
let's go back to the CLI for ESXi-a,
and also for the NSX manager.
And let's start at the manager
looking at the MAC table right here.
Effectively what this says is
that this MAC address is associated with this VNI,
that virtual network identifier, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that virtual network identifier,
effectively that layer two broadcast domain,
that segment called Segment 10.
And if we need to forward to that MAC address,
it's reachable at this VTAP address,
this virtual tunnel endpoint IP address.
And that happens to be the IP address
of the tunnel endpoint for ESXi-b.
So what that means is that this MAC address
right here is for a VM that's hosted by ESXi-a.
And that VM is connected to that segment 10
that we just created, which has this VNI.
So if we took a look at VMA to confirm its MAC address, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So if we took a look at VMA to confirm its MAC address,
we should see that exact MAC address.
Let's do that real quick.
So here at the terminal window,
here for this VM, VMA 10.0.0.10, let's do an ifconfig.
And that'll confirm for us not only the IP address,
but also the layer two address.
And there is the layer two address ending in D9:D7,
so that pans out.
And then this MAC address would be the MAC address
associated with the other VM,
the ones being hosted by ESXi-b.
And to forward to that destination layer two address,
we'd use this tunnel endpoint address of 22.22.22.22, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
we'd use this tunnel endpoint address of 22.22.22.22,
which is the tunnel endpoint address for ESXi-b.
So from the perspective here of ESXi-a,
let's say, it got a frame of data that it needed
to forward over to this MAC address.
For this MAC address,
the destination for the Geneve tunnel
is gonna be the IP address of ESXi-b
and the MAC address associated
with that destination tunnel address
is this MAC address right here.
So this MAC address ending in 70:90 would be
the layer two address associated
with the VM kernel adapter supporting WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
with the VM kernel adapter supporting
this IP address over on ESXi-b.
Let's also take just a moment
and verify that's the case as well.
So here in the vSphere Client, if we go down to ESXi-b
and we go to configure and VM kernel adapters,
and we look at the vmk10,
which has the IP address of 22.22.22, et cetera.
And we look at the properties.
Here is the MAC address, indeed ending with 70:90.
Now, the benefit of just doing that correlation is
to kinda get a better idea of how this is all glued together
with the NSX manager at the brains of the operation, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
with the NSX manager at the brains of the operation,
synchronizing all the control plane data back
and forth to those transport nodes.
In our case, it's host transport nodes
that need that information
to do proper layer two forwarding across the segment.
In addition, we could also go ahead
and take a look at the ARP caches
that are stored not only on the control plane
on the NSX manager, but also,
has been distributed down to the transport notes.
And to see that we'd use the command,
get logical-switch, the VNI number,
then the option of arp-table and press Enter. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
then the option of arp-table and press Enter.
And similar to ARP caches on an end device,
ARB cache is timeout over time.
So if there's nothing in the ARP cache, you wanna see one,
all you need to do is generate an ARP request
on one of the VMs on that segment
and that would repopulate it for you.
So that the manager, it knows that this IP address,
lemme scroll over to the right,
it knows that this IP address can be resolved
in this layer two address.
And the ESXi host, which has a local copy
of the control plane information,
believes the same information.
And if we continue scrolling to the right,
it has the transport node ID for the transport host WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
it has the transport node ID for the transport host
who effectively has reachability to that layer two address.
And that transport node was also included as part
of the output of the show MAC table as well.
So this transport node right here with this long ID,
starting with CBAF, if we look at who belongs there,
that is the transport node ID for ESXi-b
because that's where we placed the VM
that has that IP address.
So just to correlate that, if we went back to the GUI,
what we would see in the NSX manager
is that if we looked at ESXi-b,
it should have the transport node ID beginning in CBAF, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
it should have the transport node ID beginning in CBAF,
and let's confirm that as well.
So here in the NSX manager,
if we click on the system tab, over here on the left,
we'll expand the fabric section
and then we'll go down to hosts,
and we'll open up our cluster where ESXi-a and b are.
And then for ESXi-b,
we'll just simply click right here on view details.
And right here, it's showing us the ID,
which again is beginning with CBAF right there.
And as far as the NSX commands
to bring up this information at the NSX manager WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to bring up this information at the NSX manager
or at one of the transport nodes like ESXi-a,
we simply start off with the get logical switches.
Press Enter, that will show us the logical switches
that both devices know about.
And then from there, we can tack on the VNI
and the additional options,
like lemme see the MAC table or the ARP table,
and there's some additional options as well.
But that would be the starting point
for the verification about which devices know
about which logical segments and some of the MAC
and ARP tables associated with them.
Again, it's all going back WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Again, it's all going back
to the centralized control plane at the manager
and having a local control plane
of that same information being stored
on the transport nodes that need it.