So now that we have a couple of edge nodes
that are both deployed, they're running
and they're set up as a cluster.
Let's talk just for a moment at a high level about when
those edge nodes would actually be used.
So let's imagine within NSX, we wanna set up some routing.
So we wanna do some routing.
We'll put a little R there for router.
And let's imagine we wanna route
between segment 10, which is right here.
I'll put that in yellow
and segment 20, we'll put that right here in pink.
Let's also imagine we have a few VMs that are running
and connected to those segments WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and connected to those segments
and we wanna be able to do routing between those two.
Now we're gonna have a separate whole skill on routing
and setting up routing services.
However, for right now I just wanna give you a big insight
as to when an edge transport node is needed or not needed.
So if we have ESXI-A and ESXI-B,
and they both have access to segment 10
and they both have access to segment 20, lemme go ahead
and put a couple VMs there,
A couple here running on ESXI-A couple here on ESXI-B.
And let's also connect into the respective segment.
So this one on the left will connect to segment 10, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So this one on the left will connect to segment 10,
and the one here on the right will connect
to segment 20, just like that.
Fantastic. Then over here I need a ESXI-B.
For this VM we'll connect it to segment 10.
And for the VM here on the right,
we'll connect to segment 20.
So if we're gonna set up logical routing
between these two segments, ESXI-A has the ability to do
that routing for VMs on either segment
because it's connected to both of them.
And we can have our routing function here on ESXI-A
that can logically do that routing.
And that router could also be located here on ESXI-B, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And that router could also be located here on ESXI-B,
and it could do the logical routing between these two VMs.
And in the event that VM number one here needs
to communicate with VM number four,
so VM one's on the segment 10 on the 10.10. 0 network
and VM four is over here on ESXI-B on
the segment 20 network.
And it has an IP address in the 10.20.0 subnet range.
If they wanted to communicate with each other, let's imagine
that this VM right here wants to communicate with
that VM over there based on their IP addressing, this ESXI
host could go ahead and take that incoming packet, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
host could go ahead and take that incoming packet,
make a routing decision
because it has a copy effectively of that distributed router
as a function of NSX.
And then after making a routing decision, can also identify
that, hey, that destination layer to address
for this VM is not reachable locally,
but it's reachable over the tunnel over here to ESXI-B.
So after having made the routing decision in its mind,
if you will, with this distributed router,
it would then encapsulate the traffic, forward it
through the tunnel, ESXI-B would de-encapsulate it
and then forward on to the final destination here, VM 4.
So even though we're gonna have a whole separate skill WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So even though we're gonna have a whole separate skill
and details, we're regard setting up these routers
and doing routing inside of NSX, I wanted to point out
that these ESXI host on their own ESXI-A
and B with this topology right here.
They can do all the routing on their own without ever having
to call upon the services of one
of these edge transport nodes
because each of these ESXI nodes can do all the routing
between these two subnets and they can send the traffic back
and forth between ESXI-A
and ESXI-B over the tunnel.
So at this point, with that distributed
router function existing on both WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
router function existing on both
of our host transport nodes, we really don't
yet have any need for these edge VMs
as edge transport nodes.
So the question might come up, okay, Keith,
please give us a heads up.
Why then would we even want to deploy
or need to deploy an edge transport node?
And here's the answer, anytime that we need
to provide some type of a service.
And examples of a service would include things such
as active standby support.
For example, a single E ES XI host on its own cannot provide
fault tolerance for this routing function. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
fault tolerance for this routing function.
So if we wanted to leverage active standby,
that would be a network service that would be
provided courtesy of the edge transport nodes, for example,
Edge one and Edge two as part of a edge cluster.
Another example of a service that would require the services
of an Edge transport node would be a network service such
as network address translation or setting up a VPN
or setting up some centralized DHCP services
or setting up some gateway specific firewall rules.
And the list goes on.
So anytime that we have a network service WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So anytime that we have a network service
where an ESXI host can't do it on its own, it's at
that time when we're gonna start tunneling our traffic based
on routing decisions to our edge nodes
who are gonna provide those types of services.
And also to help reinforce a couple of concepts in NSX
regarding providing these services,
there's a concept called a DR, which stands
for a distributed router.
Think of it like a logical router
that everybody knows about.
So the edge nodes would be aware of this logical router
and how to route between these two segments
and ESXI-A with a copy of
that distributed router would know how to route locally WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that distributed router would know how to route locally
between those two segments and ESXI-B
with a copy of that router.
We know how to route.
So in that sense, we could say
that the edge nodes
and each of our transport nodes all have a effectively a
copy of the distributed router.
I'll point to it right here.
And when we start adding on additional services
that require these services of an edge node, we are going
to also be implementing a Logical services router.
The acronym for that is SR.
And again, we'll have a further discussion on how
to implement that and set that up.
However, it's critical at this stage in the game WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
However, it's critical at this stage in the game
that you're aware that anytime we're adding on some type
of a network service where the ESXI host can't do it
on their own, we're also be including an SR
and that SR function, that services router function,
is gonna be included on the edge nodes.
So for the full picture, the distributed router would be,
and here and here and here.
And then we start adding on services
that the ESXI host can't do on their own like active standby
or NAT and so forth.
Then on the edge nodes,
we're also gonna be including an instance
of an SRA services router.
So think of a services router WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So think of a services router
as a additional function in addition to the normal routing
that a edge node can do to provide some type
of network service.
Another great example of when this is needed is if we're
going to be connecting, for example, this router
to the outside world.
So at that point we'd be using an edge node which would have
a services router function on it for
that connectivity from our VMs inside of NSX
to the outside world.
So I was thinking to myself, what would be a great way
for you I to reinforce this concept
that sometimes an edge node may not be needed, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that sometimes an edge node may not be needed,
but sometimes it is.
So I thought a simple example of that would be to go ahead
and set up a simple distributed router just
as a demonstration that the host transport nodes
and the edge nodes, once we set up a distributed router, all
of them are gonna have a copy of
that information about the routing in this case
between segment 10 and segment 20.
And then the moment we start adding an additional network
service like Active standby or NAT
or some other feature that requires an edge node,
we would then see that additional service WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
we would then see that additional service
that services router function on our edge nodes while the
ESXI hosts who can't provide that service,
they wouldn't have that additional service router there.
So to reinforce the concept that the distributed router,
for example, the logical router
that can do the logical routing
between a couple different segments here,
that distributed router can exist on our
host transport nodes.
It'll also exist on our edge nodes.
And when we start to include additional services like Active
Standby or NAT
and so forth, that additional service
that services router function will appear here on our edge WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that services router function will appear here on our edge
nodes while the ESXI hosts, who are not gonna be providing
that specific service, will still just have a
copy of the distributed router.
And to reinforce that, let's do two things.
Number one, I'd like to give you a foreshadowing of how
to create a logical router.
And again, this video is just for the demonstration
that distributed router is going
to exist on all our transport nodes that need access to it.
And then secondly, we'll modify the configuration
so this router isn't just a distributed router,
but we also want active standby services, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
but we also want active standby services,
which will cause the SR component
to show up here on our edges.
So to demonstrate that I have here edge one at the top,
and I've got ESXI-A at the bottom,
both are in NSX CLI mode.
So if we issue the command, for example, get gateways,
that's gonna show us our existing gateways
that we currently have inside of NSX.
So our edge transport nodes are gonna have a logical gateway
and that gateway is set up for their transport network.
So for example, here on edge one, if we said, Hey,
let's get the gateway information and I'll just copy WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
let's get the gateway information and I'll just copy
and paste this UUID and paste it in
and then say forwarding, press enter.
This is gonna show us the routing table
for the transport network that this edge node uses.
So its IP address is 33.33, et cetera.
That's shown right here. It's connected logically
to the 24 bit network, 33, et cetera.
And there's this default gateway on the transport network.
So that's the refer to as VRF 0.
Think of it like the default routing
table for our edge node.
So if you're gonna look at Edge two, it has the IP address WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So if you're gonna look at Edge two, it has the IP address
of 44.44, et cetera.
So it's routing table for its logical gateway
that it's using for the transport network,
would show that information.
So to start off, this command here
of get gateways is just gonna show us the gateways
that exist on our devices.
And again, here on the edge, it's the gateway that's used
for the transport network by Edge One.
And down here, ESXI-A
and NSX CLI mode is showing no logical gateways.
So just as a reinforcement of the concept
that a distributed router when we create one,
it's gonna show up everywhere it's needed, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
it's gonna show up everywhere it's needed,
let's create a simple distributed router.
And our goal here is just to reinforce the concept
that if we create this logical distributed router,
this logical gateway, it's gonna show up everywhere
that it's needed, including our host and transport nodes.
So if we go to networking
and we click here on network topology,
currently we have two segments with two VMs connected
to each of those segments, and we have no logical routers.
So if we wanna create a gateway here in NSX,
we go here under networking, under connectivity, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
we go here under networking, under connectivity,
go to tier one gateways.
And again, don't worry about the actual tier
one versus tier zero.
We'll cover all of that in an upcoming video.
For now, we're just gonna create a simple tier one gateway
by clicking on add tier one gateway,
and I'm gonna name it Demo gateway.
And then for the HA mode here,
I'm gonna specify, to start with, that
I don't want active standby
'cause that would require an edge node.
I don't want Active Active
'cause that would require the special services router
function on an edge node,
but I wanna do a distributed router only.
So with only that selected, I'll go ahead and click on save. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So with only that selected, I'll go ahead and click on save.
And now we have this new gateway.
If we go look at the topology
by clicking here on network topology is showing us
that da da da da, we have this demo gateway.
And if we wanna link it to these two network segments like
connecting an interface to segment 10, another interface
to segment 20, we do that in NSX by going to each
of the segments and saying, Hey,
please connect this to this gateway.
So again, as a demonstration,
let's go ahead and do that right now.
We'll go to segments, we'll edit segment 10
by clicking on the three dots,
clicking on edit, and they'll say, you know what?
We want this segment to be connected to our demo gateway WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We want this segment to be connected to our demo gateway
and boom, we're done.
And we click on save and then click on close editing.
And then we'll repeat that over here for segment 20.
So we'll click on the three dots for segment 20,
click on edit and say we simply wanna connect that
to our demo gateway.
Again, it's like connecting a interface on a physical router
over to a subnet or connecting it to a specific VLAN.
So scroll down, we'll click on save
and click on close editing.
Alright, fantabulous.
So now if we wanna see the network topology
by clicking on network topology, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
by clicking on network topology,
it's now showing us we have our demo gateway
and it's connected to the 10 network and the 20 network.
So we could go ahead
and tell these VMs over here that their default gateway is
for example, 10.10.0 dot
and whatever IP address we signed here on this interface.
And then over here, these VMs we could say, Hey,
your default gateway is 10.20.0 dot
and whatever IP address we signed here.
And in the background I also set up two IP
addresses, do one on each subnet.
Again, we'll cover more details on how to set that up
and how to confirm that in a separate skill.
But for now we have this new gateway
and this new gateway logically lives on all WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and this new gateway logically lives on all
of our transport noes, including edge one and Edge two
and ESXI-A and ESXI-B.
And to verify that,
let's go take a look at the command line.
And I also wanna point out that I've got VMs running on
ESXI-A and ESXI-B that are currently connected
to those relevant segments of segment 10 and segment 20.
So a moment ago when we said get gateways
and an older way of saying
that is get logical dash routers either way is great,
that's gonna show us the logical layer three routers in NSX. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that's gonna show us the logical layer three routers in NSX.
So previously on Edge one, we just had the default router
for the transport network on the edge one device.
And here in ESXI-A, it had nothing.
But now if we do that same command again
of get gateways on both devices, check this out.
In addition to the default route on Edge one,
it now has logical router with this UUID starting
with 24 ending with af.
And we have that same identical distributed router
configured here on ESXI-A
because it's the same exact logical router. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
because it's the same exact logical router.
The IP addresses are the same,
the layer two addresses are the same.
And up here in the output
of the edge one showing us the actual name of
that gateway itself, Dr dash demo Space Gateway,
that's the name we gave it and we scroll to the right.
So here at the edge it's also showing us
that it's a distributed router,
specifically a tier one distributed router.
So long story short edge one
and the ESXI host transport node called ESXI-A.
They both have a copy of that same exact distributed router. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
They both have a copy of that same exact distributed router.
So if we did a command like get gateway, I'm gonna plug in
that UUID here just by pasting it in.
And then we said forwarding,
that's gonna show us effectively the routing table on
that distributed router.
So if you notice, they both have a route
for the 10.10.0.24 network.
So appears Edge one down here is ESXI-A.
They both have a route for the 10.20.0.24 bit network.
And again, on the top it's edge one reflecting
that here at the bottom it's ESXI-A reflecting that.
So effectively they both have the same information.
However, if we were to add some type of network service WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
However, if we were to add some type of network service
that required a services router instance,
the edges would receive that services router function,
for example, like setting up active standby
or setting up nat, something that requires
the edge services to be used.
And the ESXI host wouldn't bother getting a copy of
that services router because they can't provide
that functionality again, such
as active standby or active active.
So back at our NSX manager,
if we double clicked on this gateway, our demo gateway,
it's gonna show us what they call the fabric view, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
it's gonna show us what they call the fabric view,
which is what's making up
or providing the resources for the gateway.
So here it says DR distributed router,
which means this distributed router function can exist on
any of our transport nodes that need it.
ESXI-A, ESXI-B, edge one and edge two.
So if we did a trace, for example, from VM one over
to VM two, and both those two VMs are being hosted
by ESXI-A, ESXI-A could do all the routing
logically on its own between those two segments
and to verify that if we went to plan WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and to verify that if we went to plan
and troubleshoot over here on the left, if we go
to traffic analysis and go to trace flow
and click here to get started,
here we can say we wanna do a test from, for example,
VM one at 10.10.0.10, which is being hosted by ESXI-A.
And for the target we can specify VM two at 10.20.0.20.
Also, let's just verify real quick that VM one
and VM two are both being by ESXI-A.
So to do that we'll head over here to the vSphere client.
And here we have VM one and VM two
and I've got the column for host
and the first one's being hosted by ESXI-A WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and the first one's being hosted by ESXI-A
and the second one's being hosted also by ESXI-A.
So if we go back and we run this trace by clicking on trace,
it's gonna show us that all of that logical routing
between segment 10
and segment 20, all of that was done by ESXI-A
because they has a copy of the distributed router.
All that work is being done by ESXI-A.
So if we clicked over here on the left, it's gonna show us
that's ESXI-A where VM one is.
If we click here for the demo gateway,
if we click on the host involved,
it's gonna show us it was ESXI-A
and for the final delivery as well. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and for the final delivery as well.
If we click over here, once again, it was ESXI-A
because it has a copy of the distributed router.
Now if we modify this demo gateway
and we said, you know what, we wanna provide some kind
of network service that an ESXI
host transport node can't do on its own like active standby
or active active at that point,
it's then gonna require the use
and services of an edge node.
So to demonstrate that, we'll go back to networking.
Let's go to our tier one gateways by clicking on it
and then we'll edit our demo gateway
and say, you know what, you're not just gonna be WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and say, you know what, you're not just gonna be
distributed only.
I wanna go ahead and use some additional services.
And for the demo we're gonna say, let's use active standby.
So we'll click on the three dots
for our demo gateway, click on edit.
And then for the HA mode we'll use the dropdown
and say we want active standby.
Now that's going to require our edge services.
And as a result, it's also asking, Hey,
which edge cluster do you wanna use?
We only have one. And in
that cluster it's Edge one and Edge two.
Fantastic. And now we'll click on save.
So it says it was successfully updated. Fantastic.
We'll click here on close editing. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We'll click here on close editing.
This is a quick recap before we create any gateways.
The edge knew about its transport network.
The ESXI host knew about no virtual gateways,
no logical layer three routers.
And then as we added the first router, then
that additional router showed up on our edge,
which is the top here.
It also showed up on our ESXI host
and notice again the same UUID, so that's the UUID
for the distributed router that exists on the edge node here
and also on the transport node.
And then when we just made that final change
and we said, Hey, we wanna go ahead WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and we said, Hey, we wanna go ahead
and do active standby, if we now do the command
of get gateways, check this out.
We still have the same distributed router on ESXI-A.
That's the same as the one right here on our edge
node, edge one.
But look at this, the edge node now has an
additional logical gateway.
Think of it like an additional routing function
or service that exists on edge node to provide some service
where the ESXI host can't do it on their own.
And the example I'm using here is the function
of active standby for the gateway services, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
of active standby for the gateway services,
which is gonna require the edge nodes working as a cluster.
So for Edge one, there's the UUID,
there's the name we gave it,
and if we scroll to the right, in fact I'll highlight
that entire row and we'll scroll to the right.
It's also indicating that is a service router.
Again, think of it like providing some additional service.
In this case, active standby services,
which an ESXI host can't do on its own.
And so here on ESXI-A, if we did a get gateway
and I'll plug in the UUID of our distributed router
and I'll go ahead and type in forwarding and press enter.
Here's showing us the routing for IPV4 and IPV6. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Here's showing us the routing for IPV4 and IPV6.
And for a default route is pointing to this IP address,
169.254.0.2.
Now let me share with you whose IP address that is.
That is an IP address that's owned by the services router.
So here on the edge if we did a get gateway
and then I'm gonna go ahead and copy
and paste the UUID for our services router function, here.
I'll do a space, I'm gonna type in interface.
I'm gonna a space and I'm gonna do a pipe symbol
and then find, space.
And then I'm gonna plug in this IP address again,
the purpose here is just to help reinforce the concept WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
the purpose here is just to help reinforce the concept
that a services router function is added
and that's implemented when there's no option to do
that on the actual host transport node.
That's where we're leveraging the edge nodes.
So in this output, all I'm saying is that
for the services router function, show me the interfaces
and show me only interface information in the output
where we have this string, which is 169.254.0.2.
And this is just confirming that
that IP address is associated with this services router.
So from a routing perspective, the transport node says, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So from a routing perspective, the transport node says,
well, from a routing perspective, if I need
to forward traffic and I don't have a better route in my
routing table, I'm gonna forward it
to this next top address, which
that next top address belongs to the services router.
And we'll take a closer look at that
as we implement multi-tiered routing inside of NSX.
So the key takeaway is this.
If we do a get gateways,
the services router function will show up on our edge nodes
when we need specific services that are not able
to be implemented on a standalone ESXI host transport node. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to be implemented on a standalone ESXI host transport node.
And this is an example of doing that right here.
Again, they both have a copy of the distributed router,
which in our case is our DR dash demo gateway.
But only the edge nodes are gonna have a copy
of the services router.
And from a routing perspective,
if the ESXI host ever need to forward traffic to
that services router function in their routing tables,
they know the IP address they need to send it to.