So now this logical layer 3 router
exists locally as a distributed router here and here.
And the benefit of that is
that ESXi-A can now make routing decisions
between those two segments.
And then when needed it can go ahead
and transport data over the tunnel over
to a host like ESXi-B if the traffic was going,
for example, from one of these two VMs
over to one of these two VMs.
So before we get to that verification of
where the routing is done and how it's done,
let's take a look at the actual distributed router function WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
let's take a look at the actual distributed router function
on each of these ESXi hosts,
just to confirm that they both
have exactly the same information
about this logical layer 3 router.
So I'm using SecureCRT as a terminal emulator.
I just started two SSH sessions, one here on the left
to ESXi-A and the other on the right to ESXi-B.
So on each of them I'm gonna type in nsxcli
to go into the NSX CLI for each one
and then to give the same commands
to both devices at the same time,
I'm gonna use this command window down here. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I'm gonna use this command window down here.
I'm gonna right click and say, please send commands
to all sessions.
And that way they'll both get the same commands.
So if we did a get logical routers,
that's gonna show us the logical routers
that exist on these two host transport notes.
And you'll notice that the VDR,
the virtual distributed router has the exact same UUID
on both of 'em, same number of logical interfaces, 2,
and that's the two logical interfaces, one connected
to segment 10, the other connected to segment 20.
And if we scroll to the right a little bit, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And if we scroll to the right a little bit,
they also have the same number of routes.
They have the route for the 10.10 network
and the 10.20 network.
And going forward, more
and more of the commands in the world
of NSX are being migrated over to the get gateways command
as opposed to get logical routers.
So lemme show you what that looks like as well
with a get gateways and press enter.
And you might say, well Keith, it's the same output.
And yes it is.
So if you're ever working with the NSX CLI, a lot
of the older commands still work
and they're migrating towards the newer options.
So instead of saying, for example, logical switches, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So instead of saying, for example, logical switches,
we can go ahead and say segments.
Instead of saying logical routers, we can say gateways.
So if we wanna find more information on this gateway,
for example, hey, what are those interfaces
that are connected or what routes do you have,
we could use the command get and then gateway singular.
And then we'll go ahead and specify the actual UUID
and plug that in.
And for contact sensitive help, I'm just gonna go
to one window right here real quick and do a get
and put in gateway.
And then I'll put in the UUID space
and a question mark just WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and a question mark just
for context sensitive help about what the next options are.
So we could collectively say we wanna look
at the forwarding information
that would include IPv4 and IPv6,
or we could ask for forwarding information
for a specific network.
So let's do this.
Let's go ahead and ask for forwarding information
just for IPv4 routes.
So right here we'll do get gateway, the UUID for
that gateway, the keyword forwarding for that option.
And then we'll follow it up with IPv4
and press enter.
And boom, here it's showing us the IPv4 routing table WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And boom, here it's showing us the IPv4 routing table
for that distributed router.
And it's the same on ESXi-A and ESXi-B.
And if we scroll to the right, in fact,
let me put these horizontal so I can see 'em side
by side a little bit easier.
So because the distributed router is the same
and they both have a copy of it,
it's showing us the two routes,
the gateway associated with those networks.
and the zeros here represents it's myself.
This means that ESXi-A and ESXi-B
because they both have clients VMs that are connected
to those respective segments.
They know how to reach those two logical networks. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
They know how to reach those two logical networks.
10.10.0 and 10.20.0 network.
And then it has the interface ID for each
of those interfaces on the distributed router
to reach those networks.
So if we did a get gateway, and I'm gonna go ahead
and use that same UUID for the gateway
and then we followed up with interfaces
and press enter, it's gonna show us the interfaces
associated with that logical distributed router.
So I'm gonna go ahead and sort these side by side again
to make it a little bit easier to read and compare.
And let's scroll up.
So there's the get gateway command
and we're asking for the interfaces. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and we're asking for the interfaces.
So here's the first interface, that's the LIF stands
for logical interface.
And there's the UUID for that specific interface.
Here's the overlay of VNI
and based on the IP address, this is for segment 20,
and here's the default gateway.
And you notice on both sides it's the same information
because we're looking at the same distributed router.
So if a client anywhere either ESXi-A
or ESXi-B if they're on the 10.20.0 subnet,
which is segment 20,
and they do an ARP request for their default gateway,
they're gonna get this information as their default gateway. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
they're gonna get this information as their default gateway.
So it doesn't matter where the client is,
this virtualized Mac address that's being presented for them
to use to reach their default gateway is gonna be the same
on ESXi-A and ESXi-B.
So if we brought up a client
that was on the 10.20.0 network, that segment 20, just
to verify for what it got as a result when
for its default gateway layer two address, we could verify
that it ends in 44:52, whether
that VM is sitting on host A or host B.
So here on VM-2 which is at 10.0.20, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So here on VM-2 which is at 10.0.20,
if we do an ARP and take a look at the ARP cache,
it currently does not have the layer 2 address
of its default gateway.
But let's send some traffic off the local network.
Let's ping 10.10.0.10,
that'll force traffic off the local network
and as a result, it'll lead its default gateway.
And now if we do a ARP
and press enter, now we're showing the layer 2 address
of the default gateway.
And notice that that layer two address ends in 44:52.
And if we were to do the same thing over on VM-4
which is also on the 10.20 network, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
which is also on the 10.20 network,
it would also have the same layer 2 address associated
with the default gateway at 10.20.0.1.
So to verify that here we are at 10.20.21,
we'll do an ARP press enter.
It has nothing in its cache.
So let's do a confirmation of it's IP address
with an IF config, and let's go ahead
and ping something off network.
So we're at 10.20.0.21, let's ping 10.10.0.10.
And that's great.
So we would've used our default gateway for that.
So now if we do an ARP and press enter,
now we have the layer
to address associated with our default gateway. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to address associated with our default gateway.
And once again, it's the same exact layer to address
for that same exact default gateway address.
And that's because this distributed router on ESXi-A
and ESXi-B, it exists on both.
So if we go back to the output here,
this is the first logical interface for
that virtual router showing.
And then the next one is right here.
I'll line those up to make 'em really easy to see there.
And that's the interface for the 10.10.0 network,
which is the 10 segment.
There's the VNI number for it.
There's the default gateway address, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
There's the default gateway address,
and the corresponding layer 2 address
that clients on those segments are gonna believe is
associated with their default gateway.
And that's what they'll use to forward frames
to their default gateway.
At which point the ESXi host
who are hosting those VMs will be responding on behalf
of those layer 2 addresses.
And if we scroll up a little bit, notice that
that Mac address is the same for both subnets.
So it's using that Mac address for the layer two address
of the default gateway on segment 20.
It's also the same layer two Mac address associated WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
It's also the same layer two Mac address associated
with the default gateway here on segment 10.
So at this point in the game, what do we know?
Well, we know that this logical distributed router
exists on this host transport node.
It exists on this host transport node,
and it's not necessarily gonna show up
as a distributor router
on every possible host transport node
because we may have hosts
that are supporting the same transport zones
or the same segments.
However, maybe we have a host out there
that has zero VMs on any of those segments.
And as a result, if we don't have any VMs on any segments, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And as a result, if we don't have any VMs on any segments,
there's no need to have a distributed router
on that respective host.
But in our case, we have hosts on those segments
on these two ESXi hosts, which are host transport nodes.
And as a result, both of them
have a real-time copy of that distributed router.