So to really appreciate some of the benefits
of NSX, let's draw a simplified topology.
And let's start off with a rack
that would be in a data center.
So this is gonna represent rack number one.
And then over here, let's go ahead and put in another rack.
And I'm gonna go ahead and name this one rack number nine.
And I'm labeling this one rack number nine,
just to give us an idea that these don't have
to be like right next to each other.
Now each of the racks is very likely gonna
have a couple switches.
They're called top of rack switches.
So I'll put a couple switches at the top of each one. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So I'll put a couple switches at the top of each one.
I'll label it TOR for top of rack switch.
We'll call this one switch A and switch B.
And over here the top of rack switches,
got switch A and switch B.
And then those would connect up into a spine layer
for a spine-leaf architecture.
So we'd have some fault tolerance there.
So there's one of our switches apart of the spine
and it's very likely in a fault-tolerant environment.
We'd have multiple spines
and if we had multiple spine switches,
we'd have additional connections from each of
the top of rack switches to the additional spines.
So for our drawing, I'll just represent
one spine right here. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
one spine right here.
And so the idea also I wanna point out here
with the spine-leaf architecture is that we are routing.
So we're routing between our racks.
We don't have one contiguous Layer 2 broadcast domain.
We have routed networks.
So in each of our racks, let's go ahead
and put it in ESXi host.
So let's call this one ESXi-A.
And over here this will be ESXi-B.
And each of those ESXi hosts are gonna have
their physical connections go to our top of rack switches.
I'll just draw one to each of the switches.
Even though an ESXi host is likely WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Even though an ESXi host is likely
to have multiple physical network interface cards,
also known as vmnics.
So I'll draw a couple over here as well as a representation
of the physical connectivity.
And over here, lemme go ahead and put VM-A.
And over here I'll put VM-B to represent a virtual machine
that's being hosted by those respective ESXi hosts.
And here's the magic, hold onto your hats,
instead of connecting these virtual machines
to a traditional distributed port group
that would allow them to be, for example, on the same VLAN
but instead we are gonna have a new segment, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
but instead we are gonna have a new segment,
this new Layer 2 segment.
And specifically this will be a Layer 2 NSX segment.
And even more specifically,
we could call this a Layer 2 NSX overlay segment.
So from an administration perspective,
it just looks like a port group that's representing
that segment and we simply connect the respective PCs to it.
So even though these two hosts, ESXi-A
and ESXi-B, do not have the same connectivity
to the same Layer 2 VLAN
if we implement a Layer 2 NSX overlay segment, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
if we implement a Layer 2 NSX overlay segment,
again, think of it like a VLAN
because what it really is is a Layer 2 broadcast domain,
that segment will show up like a port group on each
of our distributed switches.
We connect VM-A to it, we connect VM-B to it,
and boom, those two VMs are logically connected
to the same Layer 2 broadcast domain.
So lemme give some IP addresses here.
I'll give this one 10.10.0.10.
And we'll give this one the IP address of 10.10.0.11.
Now on the backend we have a little problem to solve,
and that is we don't have the same WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and that is we don't have the same
Layer 2 VLAN connectivity from rack one
over here all the way over here to rack nine
because we have routing at the spine layer
between both of those.
So how in the world if VM-A tries to communicate with VM-B,
how is that communication actually possible?
And here is the magic.
We are gonna create a tunnel between ESXi-A and ESXi-B.
So there are the two ends of the tunnel.
I'll go ahead and make a nice macaroni shape
there to represent the tunnel.
I'm even gonna label it.
And this tunnel between ESXi-A and ESXi-B that was created WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And this tunnel between ESXi-A and ESXi-B that was created
by NSX are gonna be terminated at VMkernel
adapters on each of the hosts.
Over here, perhaps we're using VMK 10
and over here we could use VMK 10 as well.
And in association with these VMkernel adapters,
we're also gonna have an IP address
for each end of the tunnel.
So maybe over here at ESXi-A,
VMK 10 is using 10.11.11.11
with the 24-bit mask.
And over here at ESXi-B for its VMkernel 10 adapter,
which is acting as the tunnel endpoint on this side, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
which is acting as the tunnel endpoint on this side,
maybe it's using 10.22.22.22.
So TEP is an acronym for tunnel endpoint.
So think of it like a VMkernel adapter
with an IP address representing the end
of the tunnel here on ESXi-A
and the other end over here at ESXi-B.
And I intentionally used different subnets for each
of the tunnel endpoints to reinforce the concept
that we're routing between the two devices,
between the two ends of the tunnel.
So although in some typologies we could place both tunnel
endpoints in the same exact subnet, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
endpoints in the same exact subnet,
I intentionally put these tunnel endpoints in two separate
subnets, just to reinforce the concept
that we're not just bridging the traffic here,
we are with our tunnel, we're routing the traffic
between two reachable IP addresses.
So over here at VM-A, if it did a ping to 10.10.0.11
that traffic would be forwarded out the VM
into this port group, ESXi would see it and see
that it came in on this Layer 2 NSX overlay segment.
And then take that entire frame,
we're talking about Layer 2 and everything higher than WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
we're talking about Layer 2 and everything higher than
that, that this client was sending it will encapsulate that
and then it will route it
through the tunnel over to ESXi-B.
So if the original message here is in pink, I'll go ahead
and put that into the tunnel, it gets encapsulated.
So the original content is effectively now the payload
and the tunnel traffic will look like it's coming from
10.11.11.11 being routed to 10.22.22.22.
And at this end it would de-encapsulate it
and then forward it down to the intended recipient.
So from the client's perspective, it just looks WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So from the client's perspective, it just looks
and feels like a common Layer 2 broadcast domain that
VM-A and VM-B are in, but behind the scenes,
these two ESXi hosts, which are enabled for NSX,
have set up tunnel endpoints and they are encapsulating
and routing the traffic over that tunnel back
and forth on behalf of VMs that are connected to
that Layer 2 segment.
And you know what, it would only take a couple of moments
to demonstrate this in action.
And before I take you to the interface, let me reinforce
the concept here that my goal isn't to have us memorize all WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
the concept here that my goal isn't to have us memorize all
the details on how to configure this.
That's coming up in later skills.
But my intention right now is just to get a comfort level
that that encapsulation is happening
by simply connecting these two VMs
to an NSX Layer 2 segment.
So as a demonstration, here is the vSphere Client
that we know and love.
And here I'm on the networking tab
and I'm looking at a distributed switch called DS for NSX.
And a few of these segments here,
notice that if we click on this
what looks like a port group, it has a big N there.
And what that big N represents is WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And what that big N represents is
that this is not just a normal distributed port group
as part of a distributed switch,
but instead this is an NSX segment
and it has a virtual network identifier,
this number right there.
But the case in point is I just wanna point out
that these are how they look from the vSphere Client.
They simply look like port groups.
So this is the NSX manager will have lots
of time in playing here later.
But for now, I just wanna go ahead
and create a brand new segment.
Again, this segment's just gonna show up on
the distributed switch.
It's gonna look a lot like a port group. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
It's gonna look a lot like a port group.
So I'm gonna create a new segment by going to segments here
and clicking on add segment.
And I'll call it Fun Demo for fundamentals demo.
And I'm gonna go ahead
and associate with a transport zone called
Our Overlay Transport Zone.
We'll talk about that also here in just a moment.
And we'll scroll down and click on save.
So all we did here in this tool called NSX Manager,
we just created this new segment called Fun Demo.
We hop over to the vSphere Client, check it out,
there it is, looks just like a port group.
So to demonstrate this segment being used, lemme go ahead WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So to demonstrate this segment being used, lemme go ahead
and deploy a couple VMs
and I'll put 'em on separate ESXi hosts.
So if I go back to my VM and templates view,
I've got a folder called templates here,
and lemme create a new VM or tube from this template.
So I'll right click on this template
and from the menu, I'll click on new VM from this template
and I'll call this VM on host A.
And lemme go ahead and lemme just put it here
for Discovered virtual machine.
Click on next.
And then lemme go ahead and place this
on EXSi-A right there.
Click on next.
I'll choose the data store.
Click on next.
And I'll customize to make sure
I put it on the right segment. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I put it on the right segment.
And then we'll go ahead and power it on.
Click on next.
And I wanna put this VM on that new segment we just made,
which is this one right here, the Fun Demo.
So that's the NSX overlay network segment that we just made.
Again, it just looks like a port group
on the distributed switch.
So we'll connect it there and click on okay.
And click on next and finish.
All right, one down, one to go.
We'll right click on our template again.
New VM from this template, we'll call this VM on host B.
I'll put it in Discovered virtual machines, in that folder.
Click on next.
And then I'll go ahead and choose the right host for this, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then I'll go ahead and choose the right host for this,
which is gonna be ESXi-B.
Click on next.
Choose the data store.
Click on next and customize and power it on.
So I wanna customize it because I wanna place it on
that same port group,
or in this case the same NSX segment,
which is right here called Fun Demo.
And we'll click on, okay and click on next.
And we'll click on finish.
And now both those VMs are powering up.
So let's go ahead and let's bring a console to them.
So lemme go to VM on host B and launch a web console there.
Great, that's booting up. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Great, that's booting up.
And let's go to VM on host A
and open a web console there.
And let's also configure IP addresses.
So here in the top left hand corner showing us which VM
we're on, this is VM on host A.
So let's give it an IP address, the pseudo I have
config ethernet zero.
And the address we want on VM-A is 10.10.0.10.
And we'll put a 24-bit mask on there as well.
We'll do an ifconfig for ethernet zero, just to confirm.
All right, that looks great,
let's go over to the VM on host B.
So here's the VM on host B.
So we'll configure its IP address as 10.10.0.11 WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So we'll configure its IP address as 10.10.0.11
with a 24-bit mask.
And we'll confirm that with an ifconfig for ethernet zero.
And that looks good.
So before we do a ping test,
let's just go verify real quick that
they are both on the same segment.
So if we click on network here
and then we go down to our distributed switch, then click on
that Fun Demo, let's click on VMs.
And sure enough, we have both VMs that are on that segment.
They're both connected there.
And the first VM is running on ESXi-A.
And the second VM is running on ESXi-B.
Let's verify connectivity
with the ping from the VM on host A, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
with the ping from the VM on host A,
which is at 10.10.0.10
and let's ping 10.10.0.11,
press enter and that seems to be working no problem.
But behind the scenes, the ESXi hosts are taking
that traffic, tunneling it and forwarding it to each other.
So from an end user's perspective, it looks totally normal,
like "Hey, we're just on the same Layer 2 broadcast domain."
But behind the scenes, the two ESXi hosts are tunneling
that traffic back and forth.
And the visual representation of that is right here.
So VM-A and VM-B, they're both connected WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So VM-A and VM-B, they're both connected
to the same Layer 2 overlay segment as part of NSX,
the same Layer 2 broadcast domain.
And for the traffic,
it's actually being sent over the tunnel
between ESXi-A and ESXi-B.
And sometimes it's a good idea just to verify that
what we think is happening is really happening.
So through the magic of some packet captures,
let me go ahead and put a packet capture on this.
We'll send some traffic over again
and then take a close look at capturing the traffic right
here as it crosses the network.
All right, so in the background I've got a packet capture WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
All right, so in the background I've got a packet capture
running this to that same exact ping again
from the VM on host A
to the IP address of the VM over on host B.
We'll let that go a few times.
We'll do a control C to stop it.
And let's take a look at that packet capture.
All right, and here we go.
So lemme also explain this part right here.
The first four lines here represent the encapsulation
and the forwarding of the data from my ESXi host over
to my management computer,
and that was using GRE, so the actual traffic
that was generated and then forwarded from ESXi-A WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that was generated and then forwarded from ESXi-A
over to ESXi-B starts right here.
So the source address was 10.11.11.11,
and that's the tunnel endpoint on ESXi-A.
And the destination address is 10.22.22.22,
which is the tunnel endpoint over on ESXi-B.
So to forward to those destinations,
we used a local Layer 2 address here MAC address.
And then this second MAC address
for the destination is the MAC address
of the default gateway that was being used to reach
and forward in the direction of 10.22.22.22.
So this packet sent from ESXi-A WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So this packet sent from ESXi-A
to ESXi-B had a payload that was UDP.
So the UDP payload is tested to the well-known port
of 6081 that's being used
for the encapsulation, used for the tunnel.
So ESXi one shows a high currently unused port
and then sent it to the well known port of 6081.
And because ESXi-B was listening on port 6081
for UDP, it continued to open up and de-encapsulate.
And as ESXi-B continued to de-encapsulate,
it saw generic network virtualization encapsulation, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
it saw generic network virtualization encapsulation,
which the acronym for that is G-E-N-E-V-E
or GENEVE for generic network virtualization encapsulation.
And that's what NSX uses for the encapsulation
of the traffic between in this example ESXi-A
and ESXi-B.
So after the GENEVE header,
then we have the original payload,
the original frame and packet that was sent by VM-A
that was being sent over to VM-B.
So we looked at the source MAC address here of 0050,
et cetera, et cetera, ending in 2C1A.
That is the MAC address associated with VM-A. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
That is the MAC address associated with VM-A.
And to confirm that here on VM host A,
we could do an ifconfig, press enter,
and here we can verify its MAC address right there.
Also, while we're right here looking at the VMs,
let's also take a look at the Layer 2 MAC address
on the VM that's running on host B.
So here is host B
and there's its MAC address right here ending in 0A1B.
And that's what we should have seen inside the trace
as the destination in the payload.
So let's verify that as well.
So if we go back to our packet capture, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So if we go back to our packet capture,
there's the destination address right there
ending in 0A1B.
So the traffic was sourced from 10.10.0.10
that's the VM on host A going to the IP address
of the VM on host B.
And again, just as a reminder,
everything from this line going up was
just the traffic in delivering this packet capture over
to my management computer
and my management computer's right here at .151.
And then everything from right here below is all
of our traffic related to NSX WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
of our traffic related to NSX
with the original payload being right here.
And the traffic rigor on the tunnel is everything from
here to here.
So I'll label that part as the tunnel.
Again, that's the GENEVE tunnel.
And then the payload of that is the original traffic
that was going from the VM on host A going over
to the VM on host B.
And again, we'll also have more opportunities
to both configure and verify this,
but I just wanna reinforce the concept
that it is really happening
and it is really that easy once NSX
is set up and configured.
So one of the benefits is extended Layer 2 broadcast WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So one of the benefits is extended Layer 2 broadcast
domains, even when we have ESXi hosts that are not attached
to the same common Layer 2 broadcast domains.
And again, the way that NSX pulls this off is using
the GENEVE tunnels and tunneling the traffic
from one EXSi host to another.
Another benefit that NSX brings
to the table is security.
So for any VMs that are part of our infrastructure
where NSX is involved, we have several security features,
including what's known as a distributed firewall.
And think of a distributed firewall
as a firewall that just hovers everywhere. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
as a firewall that just hovers everywhere.
So we could be very granular in what we want to permit
or allow or deny between any two VMs,
even two VMs that are on the same exact broadcast domain.
So if we want to allow SSH or HTTPs or ICMP
or anything else using the security services,
we can control what is or is not allowed
between the two VMs.
And that also would apply to two VMs
that are sitting on the same ESXi host.
So over here at ESXi-B, if we had VM-B
and VM-C who's also connected to that same segment, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and VM-C who's also connected to that same segment,
we can also control what's allowed back
and forth between those two VMs as well.
Another big benefit of NSX is the ability
to do Layer 3 routing.
And with NSX, instead of having to do
that on our physical environment with our physical routers
and switches and doing the routing there,
we can do the routing logically in software.
So lemme give you a quick
diagram of what that could look like.
Let's say imagine we have a router here, this router one,
and let's imagine we have router two and router three,
and then this guy goes up to the internet.
We have some connections here.
Then down here, let's imagine we have a few network WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Then down here, let's imagine we have a few network
segments, the 10.10 network and the 10.20 network
and the 10.30 network and the 10.40 network.
Let's go ahead and put some connectivity there.
So we'll have this router router two connect
to those two network segments
and over here are three connected there.
Let's put some VMs there on those segments as well.
So we'll put one VM there, I'll put 'em in blue,
this guy be in yellow, and this VM will be in pink.
And I'll put this VM here in green.
So for the routing, we can do routing east-west,
that'd be routing within our infrastructure.
We can also do routing for north-south traffic as well.
So let's imagine this VM represents customer one, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So let's imagine this VM represents customer one,
and this yellow represents a VM that's a web server.
And the pink represents an app server
and the green represents a database server.
So for east-west traffic, we can route the traffic
between those VMs.
And for our traffic that needs to go out
of our enterprise, out to the internet,
for example, we could also implement
the north-south routing.
And in conjunction with these routers,
which in a NSX environment, they refer to them as gateways,
we could also implement network services, such as
network address translation and DHCP and load balancing WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
network address translation and DHCP and load balancing
and VPNs and stable firewall services and many, many more.
And to help reinforce what that might look like inside
of an NSX environment, let me give you a sneak peek.
So here's an example of what that would look like.
We have a router here.
We have another router here and here.
Then we've got four network segments.
So I've got one here,
that I'm using the 10.10.0 address base on.
I've got another Layer 2 broadcast domain here
for segment 20 where I'm using the 10.20.0 address base.
I've got a third one right here
where we're using the 10.30.0 address base. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
where we're using the 10.30.0 address base.
And then I've got another segment over here,
another Layer 2 broadcast domain
where I'm using the 10.40.0 address base.
And the way these segments are represented is they simply
show up and look like port groups on our distributed switch.
So we simply connect our VMs to the segments,
which again look like port groups
that we want them to be a part of.
And then the logical routing services inside
of NSX are providing the IP addresses
and the routing to do the east-west routing as well
as the north-south routing for those clients.