So, as we begin the integration
of layer three gateways in the world of NSX,
one of the best things
we can do for ourselves is to start small.
For this set of videos,
I'd think to start off with a tier one gateway
and focus on the east-west routing.
An example of that
would be having this logical gateway route
between our segment 10,
which we created in a previous skill, and segment 20,
which we already created also in a previous skill.
So, let's go ahead and put device A right here WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So, let's go ahead and put device A right here
and device B right here,
meaning two devices connected to that segment 10.
And then, over here, let's go ahead
and put device A over here on this segment
and device B over here.
So, for IP addressing,
we're using 10.10.0.0 over here with the 24 bit mask.
And over here on segment 20,
we're using 10.20.0.0 with a 24 bit mask.
And let's say this device is at .10 and this is at .11.
And over here just for grins,
let's say this is .20, and this is .21. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
let's say this is .20, and this is .21.
So, these devices here on the 10.10.0 network,
they would have a default gateway.
Let's imagine we're using .1 here and .1 here.
They would have their default gateway set to 10.10.01.
And over here, their default gateway would be 10.20.01.
And then, this router, this gateway,
because it's directly connected to both of those segments,
in its routing table,
it's gonna know, hey, I can reach both those networks.
So, at this point, we wouldn't have
to really worry about any additional routing information
other than the two directly connected networks
that this tier one gateway is connected to,
to be able to facilitate the routing between east-west here, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to be able to facilitate the routing between east-west here,
left to right and right to left, inside the data center.
So, now that we've taken a look at east to west routing
with logical layer three routing
and also direct connectivity within a subnet,
let's also take a look at an additional challenge.
And that is this VM right here, VM-A on the 10.10.0 network
and this VM right here,
VM-A over here on the 10.20.0 network,
what if it's the same ESXi host, let's say it's ESXi-A,
that's providing the compute resources
for the VM-A over on segment 10, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
for the VM-A over on segment 10,
and it's also the compute resource for VM-A,
which is over on segment 20.
If these two devices were communicating
with each other in a physical environment,
that traffic would have to leave the hypervisor,
go to the router function.
The router would then forward it down to the destination,
and then the return path would go like this and back over,
which means if we have an ESXi host
with both of these VMs running, the traffic
(indistinct)
here and then back over here.
And here is the most fantastic news about NSX. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And here is the most fantastic news about NSX.
We are gonna use the concept of a distributed router,
or in the context of talking about NSX
and logical gateways, we could call it a DR,
not to be confused
with a designated router in the world of OSPF.
And here's what that means.
It means that the routing information
that this gateway is providing,
because it's a logical router,
not only does that routing information
exist here on this logical layer three gateway,
but this distributed router, this DR function is here.
And it's also on our hosts.
So, our host know the whole plan about routing WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So, our host know the whole plan about routing
between the 10.10.0 network and the 10.20.0 network,
because all that routing
information exists on the ESXi host.
And as a result, if this client here on host A
wanted to talk to this client here,
the actual physical routing of that traffic
wouldn't have to physically go out to the outside world
or physically be sent over
to this entity called our gateway here,
this tier one gateway.
But instead, because the ESXi
has all that routing information,
it's just gonna make a logical routing decision WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
it's just gonna make a logical routing decision
in its own brain using the information
from the distributed router
and make that routing decision locally.
So, that traffic between this VM here and this VM here
does not have to physically go out of this ESXi host.
And that traffic never needs to actually leave.
It can be routed east-west right here logically
on this ESXi host, which is hosting both of those VMs.
So, let's imagine the other two VMs
are being hosted on the compute resource called ESXi-B.
So, that'll be right here.
And it has a couple VMs that's running. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And it has a couple VMs that's running.
It's running VM-B on segment 10,
and it's also running VM-B on segment 20.
And again, the cool thing, if this is a host transport node,
it has a copy of the distributed router
logically running on this ESXi host transport node.
And so, if traffic needs to be routed
between these two devices,
it can make all the routing decisions
between the subnet 10.10 and 10.20
and make the forwarding decision between those,
and that traffic between these two VMs
never has to leave the actual ESXi-B host. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
never has to leave the actual ESXi-B host.
And in the event that traffic needs to flow
from any of the VMs that ESXi-B is hosting
to any of the VMs that ESXi-A is hosting, at that point,
these hosts, they have a complete picture
of the distributed routing table.
So, they know how to forward.
But as far as looking up the layer two address,
they would respectively realize
that that's reachable over on the other ESXi host.
And so, I'll put a little tunnel here,
and that would go between their tunnel endpoints,
so the traffic between VM-B, for example,
and either these two hosts, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and either these two hosts,
would be encapsulated and shipped over the tunnel.
And another really important consideration
with NSX is the concept of don't wait,
don't wait to make a routing decision,
because each of these ESXi hosts,
they have the distributed router component on them
if they are connected to those segments
and they have VMs that are connected,
they'll automatically get a copy
of the distributed router and the routing tables there.
So, if we had traffic, they need to go, for example,
from VM-A at 10.10.0.10
over here to VM-B on segment 20, which is at 10.20.0.21. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
over here to VM-B on segment 20, which is at 10.20.0.21.
The part about don't wait means
because ESXi is the originating host that has VM-A
and it also has the distributed router
on all the routing information right there,
locally here on ESXi-A,
it's not gonna wait to make a routing decision.
It's gonna say, you know what?
This client lives on segment 10,
which is the 10.10.0 network,
and it's trying to get to 10.20,
which is the segment 20 network.
It'll make that routing decision right here in its brain,
identify that it needs to go to segment 20.
And then, we'll go ahead
and forward that over the tunnel end points.
And so, here in this GENEVE tunnel, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And so, here in this GENEVE tunnel,
the destination would have the VLAN identifier
of this target network here
that's being supported by segment 20.
And the reverse of that is also true.
So, if that traffic
showed up at this VM-B here at 10.20.0.21,
and it's gonna respond back to VM-A
over here at 10.10.0.10,
ESXi-B, who's hosting the original VM,
would make that routing decisions.
So, the traffic is gonna start
from a VM on this segment right here.
It'll make a routing decision locally,
because it has a copy of that distributed router function,
knows all the details about the routing, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
knows all the details about the routing,
would specify that the target is on the segment
that's supporting the 10.10.0 network,
because the layer two address
of the target is on another host.
And all that information is being maintained by NSX.
ESXi-B says all that destination layer two address,
it's not on one of my local VMs, it's owned by ESXi-A.
And that's what causes it
to forward the entire original payload,
which includes the source MAC address of VM-B
and the destination MAC address of VM-A, and forward that.
So, if the original traffic was like a ping request, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So, if the original traffic was like a ping request,
then coming back would be a ICMP echo reply,
a response effectively to that ping request.