So let's take a closer look
at what exactly is a transport node.
And again, the high level overview
is that a transport node is an ESXi host
that we know and love where we've added to it
the ability to work with NSX.
So the way that would look
is you and I would go to our NSX Manager.
The NSX Manager is working in conjunction with vCenter,
so it knows exactly about which hosts are available.
And then using NSX Manager, we reach out to a host,
let's say ESXi-A, and we specify
that we wanted to participate as part of NSX. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that we wanted to participate as part of NSX.
And once we do, the NSX software is installed
and enabled on ESXi-A and bada bing, bada boom,
it becomes a transport node.
And part of that, the ESXi host now
is gonna get a new VMkernel adapter
and is gonna use that VMkernel adapter
as one end of its tunnel called a tunnel endpoint,
so that if it needs to, it can encapsulate
and forward traffic over that tunnel to another entity.
And up to this point,
we haven't talked about other nodes
other than a transport node.
So let's imagine it sending it over
to another ESXi host like ESXi-B, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to another ESXi host like ESXi-B,
who could then deencapsulate it
and then forward it onto to its final destination.
And for every good tunnel,
there's two tunnel endpoints, one at each side.
So if we had two clients, for example,
right here on segment 20,
and this one was running on ESXi-A,
and this one was running on ESXi-B,
and they're both connected to that same segment
as they communicated back and forth,
the traffic would be encapsulated.
If this is VMA, and this is VMB
and VMA is communicating with VMB,
the traffic would be initiated by VMA,
ESXi-A would encapsulate it,
send it through the tunnel as a routed packet WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
send it through the tunnel as a routed packet
over to ESXi-B, who would deencapsulate it,
and then forwarded over to VMB,
which is one of the great reasons why
it's called a transport node.
It's able to do transport over a tunnel,
specifically a GENEVE tunnel
from itself to the other end point.
So let me clean this up a little bit
and let's chat about a few additional terms.
One of those terms is called a transport zone.
And just for fun, let me go ahead and draw a couple zones.
I'm gonna put a zone here,
and then I'll put another zone here
and let me label those.
Let's call this zone right here the production zone,
I'll call it prod zone for short.
And over here, I'll call this the dev zone, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And over here, I'll call this the dev zone,
short for development.
Let's imagine we have six ESXi hosts
that we've enabled for NSX.
So if they're enabled for NSX,
those ESXi hosts are referred to now as transport nodes
for the purposes of NSX.
So I'll put four of 'em right here.
I'll label them one through four.
Those are ESXi hosts 1, 2, 3, and 4.
And over here,
I'll specify that these other two hosts
are gonna be in the dev zone only.
So those are host 5 and 6.
So what exactly is a transport zone good for? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So what exactly is a transport zone good for?
Transport zones control the scope of a new segment.
So let's create a new segment,
and we'll create this layer two segment,
we'll call it segment 50.
So this NSX segment is a logical layer two broadcast domain.
Now, it could exist across all of our ESXi hosts.
However, if we've carved up these four hosts,
so they're only participating in the production zone,
and these two hosts are only participating in the dev zone,
when we create a new segment,
we can associate that segment with the production zone.
And that way the segment effectively would be reachable WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And that way the segment effectively would be reachable
and accessible as a port group for these four ESXi hosts.
But if segment 50 is not associated with the dev zone,
these two ESXi hosts are not gonna have that port group.
Or in the terms of NSX,
they're not gonna have that logical segment
as part of their virtual distributed switch.
And just to be fair, let's create another segment.
We'll go ahead and draw it like this,
and we'll call it segment 60.
Let's imagine we only have this segment available
for these two hosts.
So what we could do is we could go ahead
and associate the segment with the dev zone.
And because these two hosts are participating WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And because these two hosts are participating
in the dev zone, only these two hosts
would have that segment available to 'em.
Again, it would appear on the virtual distributed switch.
It simply appears like a logical port group
that is provided by NSX.
So it's referred to as a segment.
So when we think about the concept of a transport zone,
think about the concept of scope,
meaning how many ESXi hosts
and how many devices are gonna be supporting that segment.
So if a segment, again, is associated
with the production zone,
it's only being available to these four hosts.
If we have a segment associated with the dev zone, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
If we have a segment associated with the dev zone,
it would then only be available
to these two transport nodes.
Also, regarding ESXi hosts that have been enabled for NSX,
not only are they transport node,
but if we're gonna be explicit,
we could also call them a host transport node,
which is gonna help differentiate them
from another type of node
we're gonna talk about in the next video.
And while we're chatting about host transport nodes,
let's also take a look at the uplinks.
So let's imagine we have this host, let's call it Host A.
And Host A has a few vmnics connected
up to the physical world.
So here's our physical infrastructure WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So here's our physical infrastructure
with some high speed ethernet switching out here.
So I'll label this as physical.
And for the vmnics,
let's call 'em vmnic 0 and 1 and 2 and 3.
So when we go to the NSX manager,
and we specify that we want Host A to participate
and become a host transport node as part of NSX,
we are also going to be asked
and need to provide information
regarding which uplinks we want this host to use
as part of being a host transport note.
Do we wanna use vmnic 0 and 1, or 2 and 3, or 1 and 3?
And do we wanna use teaming in the form of load balancing, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And do we wanna use teaming in the form of load balancing,
or do we wanna use a failover order?
And so the details regarding which uplinks we're gonna use
are configured as part of an uplink profile.
So it'd be a great idea before we start configuring
and setting up an ESXi host as a host transport node,
we'd wanna plan out and identify beforehand
exactly which interfaces we wanna use for the uplinks
and our uplink strategy.
Again, do we wanna do load balancing with two or more nics
or do we wanna have two or more vmnics
in a specific failover order? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And we're gonna specify those as part of an uplink profile
when we're configuring our host transport node.
And what's really interesting about this
is that if we specify one uplink that we're gonna use,
it's gonna automatically create a new VMkernel adapter
with an IP address that we specify
as part of our configuration.
And the IP address that we're gonna specify
is the tunnel endpoint on this ESXi host.
Now, the key is if we did two uplinks
as part of our uplink profile,
it's not just gonna have one VMK
with an IP address for a tunnel endpoint.
Instead, it's gonna have two.
So you have two uplinks. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So you have two uplinks.
It's gonna equate to two tunnel endpoints that it can use
to communicate with other nodes in NSX.
And let me show you a quick example of that
to reinforce that concept.
So this is the NSX Manager,
and this is the section for uplink profiles right here.
And here's an uplink profile called ESXi-A, et cetera.
And it's using exactly one uplink.
So as a result, we would expect one tunnel endpoint address
on the host transport node that's using this uplink profile.
So if we go to our hosts and we go down to ESXi-A
and take a look at the details, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and take a look at the details,
and I'm gonna click on Configure
and click on Next a couple of times
and click on Next.
Right here is giving us a visual representation
that is using vmnic 2
And if we expand this,
it's showing us the uplink profile it's using,
which is the ESXi-A one.
And as a result of that, having one uplink for the NSX,
I'll go ahead and click on Cancel here.
If we look at the tunnel endpoint address,
it has one tunnel endpoint address that's 10.11.11.11
which I hard coded for that endpoint.
And again, if we had two uplinks or three uplinks,
we'd have two or three respectively WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
we'd have two or three respectively
tunnel endpoint addresses, one for each of our uplinks.
And then if we went to the vSphere Client
and took a look at the ESXi-A host.
So here's the vSphere Client,
we're in the host and clusters view,
we're looking at ESXi-A,
if we go to Configure
and then go down to VMkernel adapters.
Here is the VMkernel adapter that was created by NSX
for the benefit of that tunnel endpoint
with that IP address of 10.11.11.11.
And again, if we had two uplinks
associated with NSX for this host,
it would have two specific VMkernel adapters WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
it would have two specific VMkernel adapters
with two IP addresses, one for each of its tunnels.
And again, in this skill,
I just wanna reinforce some of the basic concepts
behind NSX.
So on our Host A, because we specified one uplink,
it has one VMkernel adapter specific
for that tunnel endpoint.
So in the interface, I think it showed us 10,
and then it had the IP address of 10.11.11.11
which is the tunnel endpoint on this ESXi host
that it can use to communicate with other devices
who are at the other end of its tunnels.
So the other end of the tunnel could be Host B. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So the other end of the tunnel could be Host B.
So if there was Host B, that would be one tunnel
and it had yet another host, let's go ahead,
but Host C here with one uplink
from that tunnel endpoint address,
we'd have another tunnel going over to Host C
to its tunnel endpoint.
And in addition to building these tunnels
for the tunnel endpoints to other ESXi hosts,
which are also host transport nodes,
there's another type of node we can also build a tunnel too,
and that's called an edge node.
So it could be called an edge node,
or it's also referred to as an edge transport node.
And that would differentiate it
from the host transport node, which is an ESXi host. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
from the host transport node, which is an ESXi host.
And the question might be, well,
why do we need this thing called an edge node
or an edge transport node?
And the answer is the edge transport nodes
are gonna take the responsibility of implementing
our logical layer three gateways and services
should we choose to use them for routing.