So now that this is all in place,
and all of our devices,
including these two ESXi host transport nodes
and these edge transport nodes,
they all know about the logical Layer 3 routing,
they have copies of, effectively,
each of the logical routers, tier-0 gateway-0,
tier-1 gateway-A, and tier-2 gateway-B.
We should, as long as the clients
have a correct IP address on the subnets
and they have a correct default gateway
using .1 on their local subnets
for the default gateway function
which is associated with our tier-1 gateways,
the traffic should be able to be routed WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
the traffic should be able to be routed
between these two segments,
whether it's done logically in the mind of an ESXi host
that has both VMs or whether or not
we're making a routing decision
before forwarding that traffic across the network.
So just as a quick test,
let's go ahead and verify basic connectivity
between VM-1 here and VM-2,
and that'd be routed locally here on ESXi-A,
let's also test connectivity from VM-1 one over to VM-4,
which, once again, the routing decision
would be made here on ESXi-A
and then forwarded over the Geneve tunnel WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and then forwarded over the Geneve tunnel
over to ESXi-B which has responsibility for VM-4
and its Layer 2 mac address.
Let's do an ifconfig real quick, to verify our IP address.
So my IP address here is 10.10.0.10,
and again, this is on VM-1.
And let's do a test with a ping to 10.20.0.20,
press Enter, and that is working, fantastic.
So we'll do a CTRL-C to stop that,
and let's also do a ping from VM-1,
and let's go over to VM-4.
So just as a confirmation,
VM-4 is right here at 10.20.0.21. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
VM-4 is right here at 10.20.0.21.
So for that ping test, let me go ahead
and bring back in my command lane interface,
and it's a little bit small,
but I'm sitting here at VM-1 still
and we're gonna do a ping over to 10.20.0.21.
So we'll do a ping over to 10.20.0.21, press Enter,
and sure enough, that is working great too.
So we'll do a CTRL-C, and let me move that CLI
outta the way, just for a moment, for that little VM.
So if we were going to predict the traffic flows here,
here's what we would predict for the traffic
from VM-1 to VM-2,
and that traffic would be sourced from VM-1. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and that traffic would be sourced from VM-1.
And we could also confirm the traffic flow
and the logical routing decisions
that are being made by going to Traceflow in NSX Manager.
So what we'd expect here on VM-1
if it was trying to ping, for example, VM-2,
is that traffic would be entering via this logical segment,
called segment 10,
and then host A with the distributed router
would make the routing decision on the gateway
to forward that to the next top,
in this case would be tier-0,
and then tier-0, because we're sharing these routes
and advertising them up, tier-0 would say,
oh, to get to the 10.20 address base, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
oh, to get to the 10.20 address base,
I'm gonna forward it down to gateway-B,
and because VM-1 and VM-2 are both hosted on ESXi-A,
all that logical routing is gonna happen in the brains here,
or in the memory if you will,
of ESXi transport host number A.
And if we are sending traffic from VM-1 over to VM-4,
the local routing decision from gateway-A, to tier-0,
to gateway-B, would also be done in the brains here
of ESXi-A.
So after making the routing decision
locally here at ESXi-A, it would forward the traffic
over the tunnel to host B WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
over the tunnel to host B
where the Layer 2 address lives for VM-4,
at which point ESXi-B would deencapsulate
and then forward the traffic up to VM-4.
And we can verify all those decisions
and that traffic pattern simply by going to Traceflow
inside of the NSX Manager, so let's do that right now,
just to confirm.
So here in the NSX Manager,
let's go ahead and exit out of this topology view
and let's make a road trip over to Plan and Troubleshoot,
and that's where we're gonna find, under Traffic Analysis,
that's where we're gonna find Traceflow. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that's where we're gonna find Traceflow.
So let's click on get started with Traceflow
and then, for the first test,
we'll do it from VM-1,
and it's showing us the details about VM-1
with its IP address, and Layer 2 address, and so forth,
and the first test is gonna be over to VM-2,
which is also hosted by ESXi-A.
So we'll select VM-2,
and we'll confirm its IP address as well, that looks great.
So traffic is coming from 10.10.0.10,
going over to 10.20.0.20,
that's VM-1 and VM-2's addresses respectively,
and we'll click on Trace.
And what we're expecting to see is a full routing decision, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And what we're expecting to see is a full routing decision,
routing flow, that starts here at VM-1, goes to gateway-A,
then tier-0, then gateway-B, then down to segment 20,
then to VM-2.
And even though it's being hosted by one ESXi host,
we're still expecting to see all that logic happening,
and because these two VMs are on the same ESXi host,
it's gonna be ESXi-A,
with its three distributed routers that it has,
that's gonna be making all those routing decisions,
effectively, in its brain.
So to verify that, let me go ahead
and bring this full screen and make it a little bit bigger, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and bring this full screen and make it a little bit bigger,
and here we go.
So the traffic starting here at VM-1
went in through the yellow segment,
it went through the gateway-A,
got routed through gateway-0, then through gateway-B,
then down through the pink segment here
where it was finally delivered to the final destination.
And if we clicked on the host icon on the left or right
for any of these steps,
it's all gonna reflect its ESXi-A.
So, right here it shows that's ESXi-A doing the work,
and if we go over here to the far right, for example,
down to our tier-1 gateway-B, and click on the host, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
down to our tier-1 gateway-B, and click on the host,
it's gonna show, once again, it's ESXi-A,
and the final VM, because it also is hosted on ESXi-A,
that's gonna be on ESXi-A as well.
So all of this logical Layer 3 routing of the packets
were all done in the brains of ESXi-A,
and if we collapse that and make it a little smaller,
it also shows us the details right here,
how it came into the network,
the logical firewalls that it went through,
the segments it went through, the gateway-A it went through,
the logical routing through the transit network
from gateway-A to gateway-0, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
from gateway-A to gateway-0,
where gateway-0 received it,
logically sent it through the transit network
between it and gateway-B, where gateway-B received it,
and then it went through the segment 20,
went through a logical distributed firewall,
which, by default, was permitting everything,
and then finally being delivered to VM-2,
who is also being hosted on ESXi-A.
So across the board, the transport node mold was all ESXi-A.
So if we did a new trace,
and I'll click on Proceed for new trace,
and we went from VM-1 to VM-4,
in this case the closest transport node WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
in this case the closest transport node
to make those routing decisions for VM-1 is ESXi-A.
So, if we're sending traffic from VM-1 over to VM-4,
the logical flow would be from the VM, to gateway-A,
to tier-0, to gateway-B,
and then being delivered down to VM-4.
However, the routing decisions for gateway-A, and tier-0,
and gateway-B, all that routing is done
closest to the source, in this case VM-1,
so ESXi-A is gonna make all those routing decisions.
And then once it figures out it's on segment 20,
and also then further figures out
that the Layer 2 address for VM-4 is over a tunnel WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that the Layer 2 address for VM-4 is over a tunnel
over to ESXi-B, it'll then encapsulate,
send it over the Geneve tunnel to ESXi-B,
who will then deencapsulate
and forward it to the final destination.
And again, a Traceflow can verify that for us as well.
So here, back in our Traceflow,
we're gonna select the source as VM-1,
confirm its IP address, fantastic,
and the destination is gonna be VM-4,
so we'll confirm that IP address as well.
That all looks good, and we'll click on Trace,
and we'll give that a minute to cook.
So let's take a look at the full screen view here,
and there's our traffic flow from VM-1, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and there's our traffic flow from VM-1,
up to the segment, through three routers,
down through segment 20,
and down to the final target VM-4.
And so if we clicked on the host information here,
for example, the logical gateway-A routing function,
if we click here on the host, that's gonna be ESXi-A.
And if we looked at the gateway-0 routing decision
and clicked on the host there, also gateway-A.
If we clicked on the host
associated with this router right here, gateway-B,
so we'll click on the host icon, once again ESXi-A.
And then once more, for the connection to the pink segment,
if we click here, once again ESXi-A. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
if we click here, once again ESXi-A.
But, at this point right here,
between the logical segment 20
and where the actual VM lives,
it was sent through the tunnel,
so if we click on this last device here,
it's gonna be ESXi-B, which is the host supporting VM-4.
So to see the actual play by play,
let's go ahead and exit full screen
and I'll scroll up a little bit here
so we can see the details,
and this logically shows us the flow.
So let's get down to the interesting part.
So everything up to this point,
everything above it was done, all the logical routing,
was done by ESXi-A. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
was done by ESXi-A.
And at this point,
we're sending the traffic encapsulated over the tunnel
from our tunnel endpoint address at ESXi-A
over the tunnel endpoint at ESXi-B,
and the next entry here shows ESXi-B receiving that
at its local endpoint of 22 et cetera,
from the tunnel endpoint address of ESXi-A,
and then we scroll down,
it's logically going through a distributed firewall,
which is permitting that traffic by default,
and then delivering it to VM-4.
And the key takeaways here,
is that each of these transport nodes
with a full complement of all the information
for all three logical gateways, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
for all three logical gateways,
can make the routing decisions.
And then, based on NSX and the control plane
educating the transport nodes
regarding Layer 2 addresses and how to reach them,
once the routing decision is done close to the source,
then that traffic can be forwarded to the appropriate node
who can deliver the traffic to the final destination.