So let's put a game plan together
for the addition of ESXi-A and ESXi-B
as host transport nodes in NSX.
So we've identified the two hosts
that we're going to include, ESXi-A and ESXi-B.
We're gonna make them host transport nodes.
And in addition to knowing which ESXi host
we want to include as transport nodes,
let's also identify which uplinks we want
those ESXi hosts to use as part of NSX.
And currently I have a few unused physical uplinks. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And currently I have a few unused physical uplinks.
The VMNICs on the actual ESXi host,
including VMNIC2 right here and three right there.
So those are both available to be used as uplinks.
And I propose we use those as uplinks as part of NSX.
And this red horizontal line here
represents the transport network.
So between ESXi-A and ESXi-B,
we could have routers and additional switches
that are able to forward traffic back and forth,
but it doesn't necessarily mean
that they're in the same layer two broadcast domain.
So on the physical network, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So on the physical network,
I've got the ports connected to VMNIC2 and three
on both of these ESXi hosts.
They are configured as trunks.
And the transport network represents routers and switches.
They're able to forward packets back and forth
between ESXi-A and ESXi-B.
So although it could be a single layer two VLAN,
it doesn't have to be.
As long as we have IP routing
and reachability between the two ESXi hosts,
that's all that's needed.
So for our game plans, here's what I propose we do.
Let's use a single uplink as the primary uplink,
and that'll be VMNIC2 as the active uplink, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and that'll be VMNIC2 as the active uplink,
both ESXi hosts that are acting as transport nodes.
And we'll set up VMNIC3 as passive as a backup.
So we'll set that up on both of these,
what are gonna be transport nodes, ESXi-A and ESXi-B.
Now, as part of the configuration
to specify which uplinks we're gonna use,
we're gonna create an uplink profile.
And as part of that, we're also gonna specify
which VLANs we wanna use.
Now, because my infrastructure supports trunking here,
and I have routing capabilities
between these two ESXi hosts, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
between these two ESXi hosts,
for the benefit of education,
I would like to use two different VLANs,
one on ESXi-A, and one on ESXi-B.
And that way from a learning perspective,
when we see the IP addresses and the subnets involved,
it'll be very clear about which ESXi host
is at which end of the Geneve tunnel.
So for our game plan, for ESXi-A,
let's use for the transport network,
let's go ahead and use VLAN 101.
And for ESXi-B, let's use VLAN 102.
And then associated with that in the VLAN 101, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then associated with that in the VLAN 101,
I'm using the IP address base of 10.11.11.
And on the VLAN 102, I'm using the address base of 10.22.22.
And everything we implement here is gonna be
with a slash 24, 24 bit mask.
So visually, what this will look like
when they start building their tunnels between each other,
we're gonna have this logical tunnel,
this Geneve tunnel between ESXi-A and ESXi-B.
And at this end of the tunnel,
which is called a tunnel endpoint, or TEP for short,
they'll be using address base of 10.11.11.something. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
they'll be using address base of 10.11.11.something.
In fact, we can hard code it as well, like .11.
And then over here at ESXi-B is tunnel endpoint address.
It'll be in VLAN 102.
So we can go ahead and use something like 10.22.22,
and just for simplicity, we can just hard code it as 22
for the host address.
And then later on we create a segment in the world of NSX,
specifically an overlay segment,
and we connect a couple of VMs to it,
for example, connect this VM to it and this VM to it.
So because they're in this common overlay segment,
it looks to the VMs, it just looks like a common giant WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
it looks to the VMs, it just looks like a common giant
layer two broadcast domain.
So this VM could be at 10.10.0.10,
and over here this VM could be at 10.10.0.11.
And logically they would be on the same
layer two broadcast domain with IP addresses
and the same IP subnet.
But behind the scenes,
when that traffic needs to go back and forth
between this VM, we'll call it VM-A,
and this VM, we'll call it VM-B,
that traffic is actually gonna be received by the ESXi host.
It'll be encapsulated inside of the Geneve tunnel, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
It'll be encapsulated inside of the Geneve tunnel,
sent over to the pier who will deencapsulate it,
and then forwarded on to the final destination.
And by using separate VLANs here
and separate IP addressing spaces respectively,
it'll be a lot easier from a learning perspective
for you to see exactly the IP address
being significantly different in different subnets.
It also makes it super easy to identify the source
and destination of the tunnel
based on the significantly different IP address.
And when we do create NSX overlay segments,
like this one right here in yellow,
those are gonna be associated with a transport zone.
And a transport zone simply controls WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And a transport zone simply controls
how far a segment is gonna go.
And as a quick reminder of that,
if we had a whole bunch of ESXi hosts,
for example, one, two, three, four, five, and six,
and these two ESXi hosts right here were in Dev
and these four ESXi hosts for participating
as part of production,
what we could do is create a transport zone.
And then we could take these four ESXi hosts,
which are enabled for NSX,
and associate them and have them support this transport zone
called PROD.
And then the network segment WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then the network segment
that's included in that transport zone called PROD
will only exist or be available across those four hosts.
While these two ESXi hosts over here,
if they're supporting a transport zone called Dev,
and then we create a new segment
that's associated with transport dev,
then that NSX segment will only show up
and be available on these two hosts.
So the transport zone, we can think of it like
a way to contain or limit how far
a segment in NSX is going to go.
Because a segment associated
with a transport zone called PROD
will only show up on ESXi hosts, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
will only show up on ESXi hosts,
which again, with NSX enabled,
they're referred to as host transport nodes
that are supporting that zone.
So as part of our game plan,
we could use some existing transport zones
that come by default with NSX,
or we could create our own.
And I propose we create our own.
Let's create a brand new transport zone,
and let's call this new transport zone
that we're gonna create Our A-B
because we're gonna have both ESXi host A and B
support this transport zone we're gonna create.
And for transport zones, you can have two types. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And for transport zones, you can have two types.
One is gonna be for NSX overlay segments,
and the other is gonna be for VLAN-based segments.
So we'll go ahead and call this overlay,
so that way when we see the name of our transport zone,
we'll remember the type it is,
and then we'll go ahead and call it TZ.
And here's the play by play.
When we create a new network segment in NSX,
is it a overlay segment,
or is it gonna be a VLAN-backed or VLAN-based segment?
And for an overlay segment,
we'll get to specify which overlay transport zone
we want it to belong to. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
we want it to belong to.
So if e ESXi-A and ESXi-B,
both configured as host transport nodes,
are both supporting this zone
called Our A-B overlay transport zone.
Then any new segments that we add to that zone
will also be supported by these two hosts.
Now, over the years, NSX has been evolving,
and currently with NSX version 4.1X,
we are gonna be using a vSphere distributed switch.
And as the vSphere distributed switch,
which we're gonna use as part of NSX
as we start adding overlay segments. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
as we start adding overlay segments.
So if we add overlay segments,
they're gonna show up on our vSphere distributed switch.
So let's go ahead and create a new distributed switch
in vSphere that NSX can then start to use.
So for our distributed switch,
let's create a new distributed switch called DS for NSX.
And that way when we see it, we'll know exactly what it is.
Now, when we create this distributed switch,
we'll create logical segments like an overlay segment
that is then gonna be associated
with the distributed switch.
And from the vSphere perspective,
it simply looks like a port group with a big N, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
it simply looks like a port group with a big N,
as in Nancy, on it,
which represents that this is a segment
which looks like a port group on that distributed switch
that NSX has created.
So we'll create a new distributed switch
for NSX to go ahead and use.
And also on that distributed switch,
we wanna make sure that we have a large enough MTU.
So I'm gonna set the MTU to 9,000.
That'll be more than enough.
So with the Geneve tunneling,
because it does add some overhead,
they'd like you to have support for at least 1,700 bytes.
So if we set up our ESXi distributed switch
to support 9,000, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to support 9,000,
and our underlying infrastructure also supports that,
we'll be good to go.
And with all that in place, we then take the final step,
and that is to actually add the NSX software to these hosts,
ESXi-A and ESXi-B, which once it's done,
besides an ESXi host,
it also makes them a host transport node
in the world of NSX.
And again, think of a transport node as the device
or the entity that's able to build Geneve tunnels
and forward user traffic across those tunnels. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and forward user traffic across those tunnels.
And in the case where we have a couple of VMs,
let's put VMC right here, that are on the same ESXi host,
even if there's layered three routing in NSX
that's been set up, the local ESXi host,
if it's the host at both these VMs,
it can do that logical forwarding
directly on his back plane.
So that traffic wouldn't even have to go out
to the transport network.
If it had two VMs that were both connected to NSX segments,
ESXi-A as a host transport node could do that movement
of the traffic between them
without ever having to send it up to the physical network. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
without ever having to send it up to the physical network.
So again, our last step here is to go ahead and deploy
slash configure NSX on the ESXi hosts.