Now, the actual edge transport node
could be one of two flavors.
We could deploy the edge transport node as a VM,
that's the most easy and popular option.
Or if we actually have a ton of throughput
that needs to be routed,
we may choose to use a dedicated piece of hardware
for an edge transport node,
and that's where we use a physical server.
And that implementation is also known
as implementing our edge transport node on bare metal.
And for our demonstration of our implementation here,
let's implement the edge transport node as a VM. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
let's implement the edge transport node as a VM.
So let me go ahead and remove the physical bare metal option
as far as an edge transport node goes,
and let's plan on using a VM.
It's also a good idea to have some fault tolerance as well.
So if we're implementing, for example,
an active standby or active-active scenario
for a specific gateway,
we're gonna wanna have more than just one VM.
So in that case, we could deploy two VMs,
two edge transport nodes,
and then we could place them together
inside of an edge node cluster
and that would be a more reliable pool to pull from.
So that way if we lose one of the VMs, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So that way if we lose one of the VMs,
the other one can still provide the functions
for the layer three gateway services.
And again, for our purposes,
we're gonna be implementing the edge as VMs.
So here's what I propose we do.
Using the NSX manager,
let's deploy two edge node VMs,
and VMware makes it super easy
to do right from the gooey interface on the NSX Manager.
So as far as the VMs,
let's go ahead and call them Edge-1 and Edge-2.
It'd also be a great idea to make sure
that whatever names you use are resolvable in DNS, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that whatever names you use are resolvable in DNS,
and that goes for everything else here as well
as far as your ESXi hosts and your vCenter server
and your NSX Manager,
we wanna make sure everything is resolvable via DNS.
We'd also wanna make sure we have accurate time
with network time protocol
to make sure everything's in sync.
So again, for the VMs, we'll call one Edge-1 and one Edge-2.
For the domain, we'll put 'em in ogit.local
for the purposes of DNS resolution.
And for the management address,
here's my management network right here,
it's on the 192.168.1 network. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
it's on the 192.168.1 network.
So the vCenter server is at .185.
On the management network, the NSX Manager,
the virtual IP address is at .10.
ESXi host A is on the management network at .181
and ESXi-B is on the management network at .182.
So for these two edge VMs that we're gonna deploy
for the management network for Edge-1,
let's use 192.168.1.191 with a 24-bit mask.
And then for Edge-2,
we'll give it the IP address on the management network
of 192.168.1.192. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
of 192.168.1.192.
And I have a default gateway off that management network,
and that's a little router down here, it's at .1.
Now, the next question we're gonna answer together
in our planning step here is where should we run these VMs?
Now, we could run them pretty much on any ESXi host
that has the bandwidth to support it.
So I've got a management cluster with ESXi-C and D.
I've also got two ESXi hosts that are enabled for NSX,
meaning they're NSX host transport nodes.
So if we needed to, although it's not required, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So if we needed to, although it's not required,
we could also go ahead and put these edge VMs
and have the ESXi host A and B support those as well.
And as I consider the load
that we currently have on our four ESXi hosts,
I currently have the NSX Manager right here.
It's running on ESXi-C
And the vCenter is currently running as a VM on ESXi-D.
So I think just for capacity purposes,
we should go ahead and run one of these edge VMs
on the competing resource, known and loved as ESXi-A. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
on the competing resource, known and loved as ESXi-A.
And this VM will go ahead and run over here on ESXi-B.
But I do wanna make it clear that these two hosts
where we're running these VMs,
they do not have to be NSX specific transport nodes.
They can just be regular ESXi host
providing the compute resources
as long as we're giving the VMs access
to the network connections they need.
So currently, each of these ESXi hosts
has a port group that leads out to my management network.
So as we deploy the VMs,
we'll specify which interface we're gonna be using
and how to connect that to the port group. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and how to connect that to the port group.
That leads up to the management network.
And the next element we get to plan for
is the tunnel endpoint address base,
including what VLANs we're gonna use
for that transport network
and also which physical uplink on the ESXi hosts.
So here's what I propose we do.
Let's go ahead and use ESXi-A and ESXi-B
as the homes for Edge-1 and Edge-2 respectively.
And for the tunnel endpoint on these VMs,
let's use the IP dressing space of 33, et cetera.
And on Edge-2, we'll use the addressing space of 44. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And on Edge-2, we'll use the addressing space of 44.
Now, we could put all the TEPs in the same exact subnet.
In fact, now with the current flavor of NSX version 4.x.
you can also go ahead and put the TEPs for the edge nodes
and also the TEPs for the host transport nodes.
We could put all of them in the same exact VLAN,
assuming that VLAN and that subnet
was available across the board.
However, for the purpose of learning,
if we create separate subnets
and have very distinct IP addresses,
that way as these tunnels are being built WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that way as these tunnels are being built
between host transport nodes and edge transport nodes,
it'll be very, very clear
who they're coming from and where they're going to.
So ESXi-A has a TEP of 11.11.11.11.
And ESXi-B has a TEP of 22.22.22.22.
And that way if we make Edge-1, 33.33.33.33,
and Edge-2, a whole bunch of fours there,
it'll be super easy to identify the tunnel source
and destination and also identify which edge node
or host transport node it happens to be.
So for Edge-1, let's go ahead and use vmnic three, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So for Edge-1, let's go ahead and use vmnic three,
uplink number three,
and allow it exclusive use by this Edge VM.
And then on that link, let's also go ahead
and use VLAN 103,
that in my network corresponds to the 33.33 address base.
And then for Edge-2,
which is gonna be running over here on ESXi-B,
let's allocate it Uplink #3
over here on this host ESXi-B.
And over here, let's go ahead and use VLAN 104,
which corresponds to my 44.44.44.44 address space
on the transport network.
And as a result of our final configuration, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And as a result of our final configuration,
which is going to include in a future set of videos,
setting up the actual layer three gateways themselves,
we could have tunnels from the VTEP on Edge-2
that go to the host transport node on ESXi-A.
We could set up a tunnel from Edge-1 from this TEP,
going over to the host transport node functionality.
And the TEP here on ESXi-B
or from Edge-1 down to ESXi-A
or from Edge-2 down to ESXi-B
And of course, we've already seen this in a previous skill,
we have a tunnel that can be set up
between ESXi-A and ESXi-B WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
between ESXi-A and ESXi-B
in the event they have VMs that need traffic moved
that are on a common segment.
In our example, in the previous skill,
it was segment 10 and segment 20.
And I also think I left off one here.
We also possibly could have a tunnel segment
between Edge-1 and Edge-2 because they're separate VMs.
So in any of these NSX nodes,
whether they're edge nodes or host transport nodes
need to communicate with each other.
They're gonna be using their respective uplinks
and the respective VLANs
for the transport network
as they send packets back and forth over the tunnels. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
as they send packets back and forth over the tunnels.
And you might ask,
"Well, how in the world is ESXi ever gonna need
to send a tunnel over to Edge-1 or to Edge-2?"
And here's a quick example of that.
Let's imagine we have ESXi-A here
and it has a little VM here,
and that VM is connected to an NSX overlay segment.
Let's call it segment 20.
And the addressing space there is 20.0.0,
I mean the host has the IP address of .20.
And let's also imagine that we have our gateways
fully configured, and we have connectivity out
to the external networks, including the internet. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to the external networks, including the internet.
So I'll go ahead and put the internet right here,
and I'll have this red line right here
reflect our transport network,
which could include many switches and routers,
but effectively allowing communications
between the tunnel endpoint here on ESXi-A
and the tunnel endpoint on one of our edges.
So let's imagine our customers sitting here,
and they wanna go out to some internet resource,
like a Google DNS server
or a public internet website, et cetera,
and let's also imagine we've already set up
the north south routing here inside of NSX.
When that client sends its traffic, ESXi-A, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
When that client sends its traffic, ESXi-A,
'cause it came in on an overlay segment,
is gonna go ahead and forward that through the tunnel
to one of the two edges.
So I'll go ahead and just write edge here
as the end point for this tunnel.
And then the edge will deencapsulate that,
and it can continue forwarding that packet
in the direction it needs to go to.
And so for just for clarity, let's imagine,
it's Edge-1 that's supporting the gateway services
and maybe Edge-2 is acting as the standby.
So then ESXi-A with its tunnel here,
we'd have a tunnel that goes up to Edge-1.
So the customer's traffic would again, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So the customer's traffic would again,
encapsulated go over the GENEVE tunnel.
And then Edge-1 when it receives that traffic,
would deencapsulate it,
logically process it as it needs to regarding routing,
and then forward it out to the next top
out on the physical network.
And based on this plan, on this topology,
let's implement Edge-1 and Edge-2.
And just as a reminder, we're gonna place Edge-1
as a VM using the compute resources of ESXi-A
and we'll have Edge-2 running on ESXi host B.