So in this video,
we're gonna take a look at predicting
and verifying the actual traffic flows
when traffic is being routed,
and also take a look at who
is doing the actual routing logic or the routing decision.
And when I'm talking about who,
I'm talking about like, for example, is it ESXi-A
that's making the decision
or is it ESXi-B making the decision
from the perspective of the router.
So when it comes to routing in NSX,
we are going to make that routing decision
as close to the source as possible. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
as close to the source as possible.
And here's what I mean by that
presuming that ESXi-A and ESXi-B
both have the distributed router,
which we already verified in previous video,
so they both have information on reachability
and the routing tables.
So, for example, if we want to either of these hosts
and said, regarding this distributed router,
they would both indicate they can reach the 10.10
and the 10.20 networks respectively.
So as far as making the routing decision
and being close to the source,
it depends on where the source of the traffic
is coming from.
So let's imagine for this first scenario,
it's VM-1, which is right there, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
it's VM-1, which is right there,
who's gonna talk to or send traffic to VM-2.
So from a client perspective,
it just knows that the target is on a remote network,
so it's going to use its default gateway.
So logically, the traffic would flow like this,
VM-1 would say, "Oh, the target's not my local network,"
so it's gonna send it to its default gateway
and use the layer 2 address of its default gateway
for the frame,
the router would then pick it up or receive that packet
and take a look at the destination address,
which is 10.20.0.20,
it would see from its routing table
that it's directly connected WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that it's directly connected
and then resolve that layer 2 address of the destination
if it didn't already have it in cache and then forward it.
So even though logically,
it looks like this process from the VM through Segment 10
to the router through Segment 20 down to this VM,
all that logic for the forwarding
is done here in the brains of ESXi-A.
And that's because ESXi-A is the host
that is providing the compute resources
for both VM-1 and VM-2.
So logically, it would go through this process
of, you know, traffic coming from the VM WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
of, you know, traffic coming from the VM
through the segment, through the router,
out this interface on the router down to this VM.
And that logically can all happen
because we have a copy effectively
of the distributed router right here on this host
but no traffic for that communication
ever needs to leave the uplinks
or go over the transit network
because it's all happening on the same host.
So to verify all that,
let's go ahead and use Traceflow inside of the NSX Manager
and let's just ask it,
hey, if we were gonna send a packet from this VM to that VM,
what is the logical flow that would be used WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
what is the logical flow that would be used
and which host would provide all that processing?
So back at the NSX Manager,
let's go right here to Plan & Troubleshoot.
Also, let's just take a moment
and go to Networking and Network Topology
just to make sure everything is like we think it is.
So I've got two VMs that are connected to Segment 10
and two VMs that are connected to Segment 20,
so it's VMs 1 and 3 on Segment 10
and VMs 2 and 4 on Segment 20,
and let me just do a visual check on our topology WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and let me just do a visual check on our topology
to make sure that I have it right.
So VM-1 and VM-3 are on Segment 10, perfect, in yellow
and VM-2 and VM-4 are on Segment 20 on pink,
and these two VMs are being hosted by ESXi-A
and these two VMs 3 and 4 being hosted by ESXi-B.
All right, so back to the NSX Manager,
let's go here to Plan & Troubleshoot,
and on the left, we'll go down to Traffic Analysis
and then we'll click here on getting started with Traceflow,
where it's going to actually inject packets
that we tell it to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that we tell it to
and then tell us whether or not that traffic flow
would be successful,
and if it is, it'll also tell us
the logical path it's taking.
So we'll click here to get started.
And then here, we can specify
the type of traffic we must send
and by default it's gonna simulate using ICMP,
which is protocol number one.
So later on as we set up firewalls
and we set up restrictions,
you could also further test with specific protocols
just to verify whether or not they're going through.
So for now,
we're just gonna verify basic connectivity with ICMP,
and for the source,
it's going to be VM-1 at 10.10.0.11, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
it's going to be VM-1 at 10.10.0.11,
so select that,
and if we scroll down a little bit,
it'll also show us the actual MAC address
associated with that client at 10.10.0.11.
And then for the destination, based on this initial test,
we wanna select the virtual machine from the dropdown,
we're gonna select VM-2,
which is on a different segment, it's on segment 20,
but being hosted still by ESXi-A.
So there's the details for VM-2
and we'll scroll down a little bit more
and we'll click on TRACE.
So this literally injects traffic on the network. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So this literally injects traffic on the network.
I put a packet capture on the transport network
for stuff that would have to go between ESXi-A and B
and sure enough, the packet captures off the wire
showed literal traffic as a result
of this traceflow being run.
So here's a visual representation of what just happened.
Let me make that full screen.
So this is showing us that the traffic from VM-1,
which is on the network 10.10.0,
was forwarded through the yellow segment,
it was received by the gateway,
effectively the layer 3 router here, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
effectively the layer 3 router here,
and that layer three router made a routing decision,
forwarded it down at the interface,
going to the pink segment,
and then forwarding and finally to the client at 10.20.0.20.
And then off to the left
is showing us the resource that was being used.
So a resource in NSX could be an actual host transport node
in the case of ESXi-A or ESXi-B,
or it could be an edge node
in the event we had to forward traffic over to an edge node
for some service that required the edge node,
like active/active or active/standby
or doing NAT services or other services WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
or doing NAT services or other services
that may require sending it over to the edge nodes.
However, for this topology,
especially for this traceflow,
because VM-1 and VM-2 are the same host,
we just click over here on the host icon,
it was ESXi-A,
and then we click here on Segment 10 on the host,
it's ESXi-A.
If we click on the logical router, the distributed router,
it was ESXi-A.
And then as that traffic was logically routed
down through Segment 20, if we click here,
it's still ESXi-A.
And then as it got delivered to the final client,
which is also hosted on ESXi-A,
ESXi-A was responsible for that. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
ESXi-A was responsible for that.
So this traffic flow was all happening right at ESXi-A
and doing the logical routing between 10.10.0 and 10.20.0.
All right, let's go ahead and close that,
and then it's showing us also the details right here.
So that traffic was sent in
as if it was coming in from that VM.
It was received at ESXi-A.
Logically, there was a distributed firewall
with a distributed firewall rule
that by default is permitting all traffic,
so it's showing that logically, it had to go through that
but the distributed firewall was permitting it. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
but the distributed firewall was permitting it.
Later on, we'll talk about implementing security
with a distributed firewall.
And once it passed the rule,
it then went through Segment 10
and then it went to the logical layer 3 interface
on Segment 10 for our Tier-1 gateway.
Now again, it's all ESXi-A doing it
using the distributed router.
The traffic never had to leave ESXi-A.
So once that traffic was received on one interface
of the logical router,
it was then forwarded out the other interface right here
down through Segment 20,
and then before it was delivered to the client, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and then before it was delivered to the client,
there's also a distributed firewall and a rule
that by default are permitting the traffic,
and it was delivered successfully to VM-2,
who lives on Segment 20.
All right, so that is one example of routing
using a single ESXi host to do it.
So up here, we'll make a little note,
it was all ESXi-A leveraging the distributed router
that it has.