All right, so for our game plan,
I know there's a lot on the screen right here,
but I wanted to go ahead and just reinforce
what we've already put in place up to this point
and just carry that forward.
So as part of our game plan, let's do a validation
of our current implementation.
'Cause in the previous video we created a couple segments,
segment 10, segment 20,
we have a couple of VMs on each segment, on each host.
And currently, because we don't have any layer three routing
between those two segments
and the subnets associated with those segments,
the devices here on segment 10 don't have a default gateway WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
the devices here on segment 10 don't have a default gateway
they can use to communicate with devices over here
on Segment 20.
So the first thing I'd like to do is simply validate our
current infrastructure with these two segments
to verify they exist and also to make sure we have
these four VMs set up and ready to go.
And now, as part of that in the background,
we're gonna have a separate skill on DHCP services,
but for this skill, just for a little sanity,
for my own benefit, I'm gonna set up in the background DHCP
services so that when we bring up these VMs on segment 10, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
services so that when we bring up these VMs on segment 10,
they'll automatically get an IP address in the
10, 10, 0 subnet,
and over here on Segment 20, when they boot up,
they'll automatically get an IP address in the
10, 20, 0 subnet.
And then later we'll have more time
to focus our attention on a whole variety and range
of DHCP services as part of NSX.
So for now, I just wanna make you aware
that I don't plan on manually statically configuring all
these IP addresses on these four VMs as we bring them up.
And that'll give us an opportunity
to focus our attention here on the logical layer three
routing inside of NSX. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
routing inside of NSX.
Also, to start off, we are gonna start off
with our tier one gateway
that'll provide the east-west routing.
And then as we progress together,
we'll have a separate skill on integrating
and adding on top of that a tier zero router,
which connects as a gateway to the outside world.
So as part of our game plan,
segment 10 is gonna have addressing space of 10.10.0.0
with a slash 24,
and segment 20 is gonna have the
IP addressing space of 10.20.0.0
with a slash 24.
And then for this logical layer three router, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then for this logical layer three router,
which we are gonna implement as a gateway in NSX,
let's go ahead and use dot one right here
on the 10, 10, 0 network for that connection,
for that interface.
And then we'll use dot two right here
for the connection from this gateway to this segment.
And that way this logical layer three router,
which is gonna be a distributed router to begin with,
it can do the logical routing between those two segments.
Now, behind the scenes,
what's gonna happen when we implement this is
that over here on ESXI-A, NSX,
the NSX manager is gonna replicate WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
the NSX manager is gonna replicate
that information about this logical layer three router,
and it's gonna replicate that to ESXI transport nodes,
which in this case would be ESXI-A as a host transport node,
and also ESXI-B as a host transport node,
ESXI-A has a VM on both segments
and ESXI-B has a VM on both segments.
And as a result, each of those transport nodes,
these Host Transport Nodes, are gonna have effectively a
copy or an instance of that distributed router.
So either one of them can make routing decisions WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So either one of them can make routing decisions
between segment 10 and segment 20.
And then after the layer three routing decision is made,
then regarding the destination layer two address,
if it's not local, for example, we have this machine here,
Host-A VM on segment 10 needs to communicate
with this VM over here, Host-B VM segment 20,
Host-A would make their routing decision first
between segment 10 and segment 20.
And then when it looks for the destination
layer two address, it would identify, oh,
that layer two address is reachable on a VM
that's over on ESXI-B,
at which point Host-A would then use the Geneve tunnel WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
at which point Host-A would then use the Geneve tunnel
to go ahead and encapsulate
and forward the traffic to the destination
of the Host-B VM right here.
And as part of that tunnel on the Geneve header,
it's gonna indicate that the destination segment,
that this frame of data that's being encapsulated
belongs to, is associated with segment 20.
So the ESXI-B can de-encapsulate
and then make the forwarding decision over here
to this VM at that MAC address.
So once we validate our existing infrastructure,
which currently just has two segments
and no logical layer three routing between them,
then our next step would be to go ahead WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
then our next step would be to go ahead
and create the tier one gateway.
Now, when we create that gateway
that can do our east-west routing between our,
in our example, segment 10 and segment 20,
there are a couple options when we deploy this.
And one of those options is when we create that gateway
to say that we want it to be a distributed router only.
Now, if we say that, that just simply means
that the ESXI hosts that have VMs that are connected
to the segments, they're gonna have a copy of
that logical layer three router locally on them,
so they can make the routing decisions
and then forward to the other host where WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and then forward to the other host where
that host has the VM that's the final destination
of the traffic.
Now, we also mentioned that the reason
that we deploy the Edge Transport Nodes,
as I have listed up here, is to provide additional logical
functions and services.
However, I wanna also point out
that these Edge Nodes are not absolutely required
for every possible option.
So, if we simply wanna have our host transport nodes working
in this topology right here,
with a logical layer three router routing between segment 10
and segment 20, which effectively is routing WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and segment 20, which effectively is routing
between the 10, 10, 0 network,
and the 10, 20, 0 network, when we deploy the gateway,
if we specify distributed router only, it's not going
to involve the Edge Transport Nodes, which acting
as a cluster edge.
So even though they are there,
if we say we want this T-one logical gateway
as a distributed router only, there's no need
to actually include Edge one and Edge two in that equation,
because these two hosts will have a copy of
that distributed router WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that distributed router
and they can make the routing decisions
and forward traffic back and forth.
However, if we wanna use additional services, for example,
if we want to include services like NAT,
network address translation, or have a DHCP server,
or set up VPNs,
or have some Stateful firewall functionality at a gateway,
at that point, we are gonna be using the actual services
of the Edge Nodes that are providing those functions.
And when we start using these types of network services,
there's another instance of routing that's implemented, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
there's another instance of routing that's implemented,
and that is called a services router,
which we're gonna cover more in a separate skill.
So for now, just realize
that a distributed router, like the basic nuts
and bolts of routing packets,
and a distributed router can exist on host transport nodes,
it can also exist on Edge Nodes when it's needed,
meaning these Edge Nodes are involved in
the routing process.
And when we begin to incorporate additional services such
as network address translation or VPNs,
or if we want some fault tolerance,
maybe we wanna implement these Edge Transport Nodes
and provide active standby services so that WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and provide active standby services so that
with the cluster, with these two Edge Nodes running, if one
of them fails, the other one can pick up the slack.
So we do set up additional services
that do require the services of these Edge Nodes,
at that point, NSX behind the scenes will
automatically effectively turn on
the services router function on those Edge Nodes.
So at that point, our Edge Nodes
if they're involved in the party as well,
they would also have a copy of the distributed router,
but they would also have a copy when needed
of a services router.
And that is what allows them to do the services
of things like NAT and VPN WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
of things like NAT and VPN
and connectivity to outside resources like the outside world
or to a service provider and so forth.
And because it's gonna be super helpful in seeing this all
grow step-by-step, I'm going
to intentionally not engage those services up here on the
Edge Nodes,
like NAT
or VPNs
or Active Standby Services for the logical routing
that would require these guys to get involved
and actually do that work.
Because if we do the setup of the gateway
as just a distributed router and no additional services, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
as just a distributed router and no additional services,
we can still do the routing here
between these two segments,
but it's all just in the minds of these ESXI hosts
and their willingness to use the Geneve tunnel
to forward traffic back and forth, for the benefit
of one VM being able to talk to the other.
So as part of our game plan, as we create
that tier one gateway, I'm gonna set it up
as a distributed router only,
and we can focus on the traffic flows, the logic,
and the routing with a distributed router.
And then as we continue our journey together
and we incorporate additional services like NAT WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and we incorporate additional services like NAT
and connectivity to the outside world,
and as a result, we'll then engage these Edge VMs
who are in our Edge cluster to provide those services.
And as a result on those Edge devices will then have a
distributed router, just like the host transport nodes
that have VMs on those segments.
But in addition, the Edge Transport Nodes will also have a
Services Router, we'll call it SR for short,
which is just the logical entity on those edge nodes
that are providing those additional network services.
Alright, so to conclude with our game plan,
we are gonna validate our topology. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
we are gonna validate our topology.
We're gonna create this tier one level gateway, right here,
we'll call it tier one gateway A.
And then we'll connect segment 10
and segment 22, that logical router, we'll give each
of those segments of appropriate IP address on the gateway,
and then we'll verify that it works
and we'll also walk through the logical
routing that happens.
And then we'll verify our connectivity both
for VMs in the same segment on different hosts,
and also for two VMs on two different segments,
but happen to be hosted by the same host transport node
where this host transport node can do that routing WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
where this host transport node can do that routing
between those two VMs on those two segments in its brain,
inside of the hypervisor itself.
It's also important to point out
that if we do set up the DHCP services, which I'm going
to do here for these segments,
because the DHCP is a network service that's
provided by our Edge Nodes, we are gonna have a little bit
of services router functionality at the Edge Nodes,
but it's just gonna be to support the DHCP services.
And when we set up this gateway function by itself,
we'll tell it we just want a distributed router
and we don't want active standby. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and we don't want active standby.
So for the DHCP services,
I'm gonna set up a logical DHCP server at 99.99.99
so that way when you see that,
you'll know exactly what it is.
"Oh, that's the DHCP server that Keith set up".
And then for some implementations, it's gonna ask us
for an IP address on each of the subnets
for the DHCP services.
So when that happens, I'm gonna use dot two.
So over here it'd be 10, 10, 02 for the DHCP server.
Over here, it's 10, 20, 02.
And again, there's a few options
for implementing DHCP services.
And the reason I just mentioned that is WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And the reason I just mentioned that is
because when you see either 10, 10, 02
or you see 99, 99, et cetera, just be aware that that's
for the DHCP services that I've got set up
in the background.
And again, we'll have a whole separate skill on the details
and the flow and setup of DHCP.
But for now, I just want the DHCP functionality
and I don't want you to have any surprises about the dot 2
address or the 99 address space there.
Just realize it's all related to DHCP services
for our topology.