So for the validation,
we're focusing on traffic sourced
by this VM right here, VM number three,
which is at 10.10.0.11,
if it's sending traffic over to this VM right here,
which is VM-2 at 10.20.0.20.
And let's take a look at the questions
we were asked to consider.
So for question number one,
it asked us, "On a host transport node such as ESXi-A
or ESXi-B what command is used
to see a distributed routing table?
And there's a couple of different options
because we could actually use get logical dash router WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
because we could actually use get logical dash router
and then the UUID and then ask for the routing table,
or we could do a get gateway.
So as a test of that, let's go to the command line interface
with NSX CLI on both ESXi-A as a transport node and ESXi-B.
Because ESXi-A and ESXi-B,
if they both have VMs that are running
and attached to those segments, they should both have a copy
of that distributed router locally.
So I have a SSH session opened up
to ESXi-A here on the left hand, on the right, ESXi-B. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to ESXi-A here on the left hand, on the right, ESXi-B.
I've also taken the next step of typing in NSX CLI
to go to the NSX CLI on both of these hosts.
And in my command window right here down below,
I can type it in command and that's gonna
be sent simultaneously
to the NSX CLI interface here on ESXi-A
as well as on B at the same time.
So to see which gateways we have to, start off with,
we could use one of two commands.
We could use, get logical-routers, and press enter,
and that's one way of doing it.
So we've got this gateway with this UUID right here.
In fact, lemme go ahead and put these horizontally WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
In fact, lemme go ahead and put these horizontally
so we can see more of the output.
Alright, so here's the output where we can see more
of it because it's wider.
So here's the command, get logical-routers,
that we've issued on both of these host transport nodes.
Here's the UUID for the virtual router in our topology
and here's the number of logical interfaces.
That's what LIF stands for.
They each have two IPv4 routes, and see, the routing table,
we can type and get logical-router, space,
then put in the UUID.
So we'll go ahead and do that on both
of 'em at the same time by pasting it down below,
and then space, and typing in, forwarding, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and then space, and typing in, forwarding,
and then pressing enter.
And that's gonna show us the forwarding table
for that specific gateway.
And it's identical on both of our ESXi hosts
because they both have a copy of this distributed router.
Now another option that gives the same output
is get gateways, and press enter.
Again, that's very similar to the get logical-routers.
Either way is great.
They're migrating towards the use of gateway,
the keyword, gateway, as opposed to logical-router.
And furthermore, if we said get gateway
and then we plugged in that UUID once again,
which again is identical on both of these transport nodes WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
which again is identical on both of these transport nodes
and pasted it in and then did a space
and typed in, forwarding, once again it shows
the routing table for that gateway, for that logical router.
So for the question, what command is used
to see the distributed routers routing table,
it'd be get, and then we could use logical-router
or gateway, either way, followed by the UUID,
and then followed by the keyword, forwarding,
and that will show us the routing table.
Alright, so that addresses the first question.
Let's take a look at the next one.
The second question says, "On a host transport node
"such as ESXi-A or B,
"one command is used to see the MAC address table WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
"one command is used to see the MAC address table
"for an overlay segment."
So that is courtesy of the NSX Manager
and the control plane there populating the information
regarding all the MAC addresses that exist, for example,
on segment 10 and a separate table,
with all the MAC addresses that live on segment 20.
So this goes back to our logical switching.
And so to see that information we'd use the command,
get logical-switch, or segment.
They both do the same thing.
And let's go ahead and do a demonstration of that right now
for both segment 10 and segment 20. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
for both segment 10 and segment 20.
So here in our two ESXI hosts of the NSX CLI
to see the existing segments
that are relevant here on these two hosts,
we can type in the command, get segments.
And here in the output of get segments,
it's showing us we have two segments.
There's the VNI numbers, there's the UUIDs,
and there's their names and they're again identical here
on both ESXi-A and ESXi-B.
Now another option to see the same information
would be the command, get logical-switches.
So we'll type in, get logical-switches, press enter,
and that'll give us the same output. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and that'll give us the same output.
And then furthermore, if we wanna see the MAC address table
associated with either of these segments,
we can type in, get segment,
and let's take a look at the MAC address table
for Segment 20 Pink.
So I'm gonna go ahead and just copy that VNI,
paste it down here below
and then follow it up with mac-table,
and that will show us the MAC address table
for all the VMs associated and active now
on that logical broadcast domain,
in our case it's segment 20, which has the VNI of 73728.
So we'll press enter, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and here's the MAC address table information,
and lemme go ahead and put this side by side.
So here's the command we just issued regarding
that specific segment, 73728, which is our pink segment.
So here in the output of get segment,
and this is the VNI number,
our virtual network identifier,
for the pink segment followed by mac-table,
is showing us MAC addresses, layer two addresses
and how they're reachable.
So in the case of ESXi-A, if it needed to reach
this MAC address right here ending in C9 D3,
it knows that MAC address
for this segment is reachable
through this tunnel endpoint, 22.22.22.22. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
through this tunnel endpoint, 22.22.22.22.
So if we needed to forward frame to that, specifically,
to the address, ESXi-B would say, you know what,
I'm gonna encapsulate the data and ship it over
through the tunnel to 22.22.22.22,
which is the tunnel endpoint for ESXi-B.
And over here on ESXi-B it knows that if it needs
to forward traffic to this MAC address ending in 5D AC,
that it would go ahead and forward it
to the tunnel endpoint 11.11.11.11, et cetera,
and that address is the tunnel endpoint
over here for ESXi-A.
So that's all courtesy of the control plane
that's being managed and maintained by our NSX Manager WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that's being managed and maintained by our NSX Manager
and being kept up to date on these two transport nodes.
So that answers question number two here.
We can use the command, get,
either get segment, the VNI number and mac-table,
or we can use the command, get logical-switch,
with the UUID number followed by the option MAC table
to see the MAC address table for a given overlay segment.
So then we move on to question number three,
and that's asking us which device would make
the routing decisions for packets from VM-3 over here
that are being sent over to VM-2 over here? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that are being sent over to VM-2 over here?
So these two VMs are on two different hosts
and they're on two different subnets.
So who would make the routing decision for that?
And a great way to verify that packet flow is to go
to Traceflow and take a look.
So let's go to the graphical user interface
on the NSX Manager and we'll ask it,
Hey, can you tell us about reachability,
first of all, from VM-3 to VM-2,
and as a result of that output, it'll also confirm
who is making the routing decisions
and what we'd expect to have happen.
Because ESXi-A is closest to the source for VM-3,
it should be making all the routing decisions logically WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
it should be making all the routing decisions logically
through the gateway between subnet 1010
and subnet 1020,
which are being used on segment 10 and segment 20.
So let's head over to the NSX Manager and verify that.
So here in the NSX Manager,
we'll go to the Plan & Troubleshoot tab right there,
and on the left we'll click on traffic analysis.
And then here in the window for Traceflow,
we'll click on Get Started.
And if we wanna trace the traffic from VM-3 as a source,
we'll simply go ahead and select VM-3 right there.
And for the target, we want the target to be VM-2, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And for the target, we want the target to be VM-2,
so we'll select VM-2.
We're also gonna scroll down a little bit
and just confirm the actual IP addresses involved
and also make a note of the layer two address
for the target, which is VM-2.
So VM-2 is at 10.20.0.20,
and there's this MAC address ending in 5D AC.
So we'll go ahead and click on Trace
and that'll actually inject the traffic for this test,
and it also give us the results
of did it make it or did it not,
and it also gives us the logical path it took.
So I'm gonna go ahead and collapse the left side here
to give us a little bit more room. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to give us a little bit more room.
And just for a moment, lemme go ahead and take this topology
and make it full screen.
Let me rearrange a little bit
to make it a little bit bigger.
Fantastic.
So here's where the traffic started.
It went through the yellow segment,
went through the logical router,
went down through the pink segment,
and then finally it was delivered here to VM-2.
So if we click right here on this icon for the host,
it'll show us which host is involved initially.
So this is ESXi-B,
which is the compute resource for that VM.
Fantastic.
And as the traffic went through the segment 10 yellow,
it was also ESXi-B logically moving
the traffic through that segment. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
the traffic through that segment.
And then if we click here on the host icon that's associated
with the gateway function, it's once again ESXi-B
that's now making the routing decision
between the 1010 network over here
and the 1020 network over here.
And then we go down further down through the pink subnet.
This is also still the job of ESXi-B.
So that's its complete routing decision.
And at this point, ESXi-B said, you know what,
I need to forward this over to the tunnel endpoint
which has ownership or responsibility
for the MAC address I'm trying to reach, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
for the MAC address I'm trying to reach,
at which point ESXi-B encapsulated the traffic,
sent it through the tunnel over to ESXi-A
who de-encapsulated it
and then forwarded on to the final VM.
We can verify that last piece here by clicking on the icon
of the host next to VM-2, which shows this is ESXi-A
who did the final delivery.
So the routing was all done logically by the device closest
to the source, which is ESXi-B, and then the final traffic
was delivered to host A who then delivered that to the VM.
If we press escape, we can also verify that WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
If we press escape, we can also verify that
in the output right here,
which logically shows the traffic going
through ESXi-B, being logically routed,
and then right here showing that traffic being sent
through the tunnel from ESXi-B over to ESXi-A,
and then ESXi-A received it and then forward it to the VM.
So for question number three,
which device would make the routing decisions
for the packets from VM-3 to VM-2,
it's gonna be the transport node closest to the source,
and in our topology that is our host transport node
we know and love as ESXi-B
that made those routing decisions. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that made those routing decisions.
And then the fourth question we've already answered,
but let's review it as well.
And that is how does the device performing the IP routing,
which is in our topology here for this traffic flow,
ESXi-B, how does it have access to the routing table
for the logical router?
And the answer to that is these ESXi transport nodes
have a living, breathing copy, if you will,
of that distributed router.
So ESXi-A has it, it knows all the routing
for that logical router, and ESXi-A also has a copy
and that's how it knows about how to route. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and that's how it knows about how to route.
And that's all controlled and managed via the NSX Manager
as it interacts and keeps these two ESXi-A hosts up to date.
So if we add a new gateway
or we connect a new segment to a gateway,
we're doing that on the NSX Manager
via the management plane,
and then the NSX Manager is educating
and updating all of our transport nodes that need
that information so they can have
that updated distributed router information as well.
So for question number five then, after routing,
and we're talking about ESXi-B here
for this traffic flow, after it made the routing decision
that the traffic sourced on segment 10 needs to be routed WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that the traffic sourced on segment 10 needs to be routed
to the segment 20 before it can be delivered to this client,
after that routing decision's done, how does ESXi-B know
that the destination layer to address associated
with that target is reachable, for example, over here?
And we looked at that also earlier
in the command line interface for NSX on each of our hosts,
and that was looking at the actual segment.
So for this segment right here, the NSX control plane
provided by the NSX Manager is updating the MAC addresses
associated with that segment. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
associated with that segment.
So once ESXi-B said, oh, I need to forward this
to this layer two MAC address based on the MAC address table
for that segment, ESXi-B knew it had to encapsulate that
and ship it over to its good buddy, ESXi-A,
at the tunnel endpoint of 11.11.11.11,
at which point when ESXi-A receives that,
it de-encapsulated it and then forwarded it directly
to the VM-2 which owns that MAC address.
So when it comes to forwarding traffic on an IP network,
the first consideration is layer three, for example,
what network do we need to forward this to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
what network do we need to forward this to
from a routing perspective
and then it's gonna be layer two.
Now that layer two question could be, okay,
for the next hop in this path,
what is the layer two address for the next router,
or in the case of our segment, segment 20,
where ESXi-B is already connected to that,
the layer two question is, okay, how do I reach
that layer two address on that segment?
So in this case, ESXi-B, knowing from the control plane
that the MAC address for VM-2 is reachable via ESXi-A,
that would cause ESXi-B to encapsulate the traffic,
ship it over to ESXi-A who de-encapsulates WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
ship it over to ESXi-A who de-encapsulates
and then forward it to VM-2.
So thanks for joining me in this video
and in the skill regarding setting up
a single virtual router as a gateway within NSX.
And we'll have more opportunities to practice and play
and understand IP routing in the world of NSX
as we take a look at the next skill
where we'll add a couple additional routers
to do the routing and forwarding
for not only east-west traffic,
but also eventually for north-south traffic,
for VMs like these guys right here
that may need to communicate
with external networks such as the internet WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
with external networks such as the internet
or other data centers.
So I look forward to seeing you in those skills as well.
Until then, I hope this has been informative
and I'd like to thank you for viewing.