So for our discussion regarding segment profiles,
let's talk for a moment about where we can apply a segment profile.
There's a bunch of segment profiles that are in place by default,
and their primary location is on a segment.
By default, we're going to have a set of segment profiles applied
to the segments 10 and 20 here off the blue tier 1 gateway.
We're going to have segment profiles by default applied to this segment right
here,
off of our tier 1 gateway off the primary tier 0.
And we're also going to have a set of default segment profiles applied right WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And we're also going to have a set of default segment profiles applied right
here to segment green.
And the way that a segment profile works is sort of like a waterfall.
So if you imagine a waterfall starting here and then it goes down,
that's how it works with our segments.
If we have a segment profile applied right here to segment 10
and the same default 1's to segment 20,
any VMs connected to those segments are going to inherit those properties.
And the same thing right here for this segment,
whatever segment profiles are applied here,
these VMs, because they're directly connected to the segments via their logical WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
these VMs, because they're directly connected to the segments via their logical
network interface
cards and the logical ports on those segments, they are going to inherit those
settings.
Now, what if we have 200 VMs on a segment and we all of a sudden decide,
oh no, we have two or three VMs of those hundreds that need specific or
different settings.
What we can also do is take a segment profile that's different
and we can apply that directly to a VM should we choose to do that.
So if at the segment level, we have one segment profile.
We'll go ahead and call it A.
And then at the individual VM that's connected to that segment,
we've directly applied a different segment profile of B WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
we've directly applied a different segment profile of B
to the port where that VM is connected.
For those settings there in profile B, they're applied directly to the VMs port
.
Those are going to take precedence and override any conflicting settings
that might be the segment profile applied to the segment itself.
So again, the segment level applies to all VMs by default,
unless there's a more specific segment profile applied directly to a VM.
The next thing I'd love to chat about is the types of segment profiles
that we can use on our segment.
And the first one is a quality of service segment profile. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And the first one is a quality of service segment profile.
When you think of quality of service, think about applications like voice over
IP
or real-time voice applications that need to have priority treatment.
If push comes to shove, there's not enough bandwidth in the network,
we may want to give some traffic like voice traffic,
higher preference to be forwarded through the network
compared to some other application that can survive a few hundred milliseconds
of latency
or delay or jitter, like email or transferring a file
or some other application like that that we wouldn't even notice the difference
if there's slight latency in the delivery of those packets. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
if there's slight latency in the delivery of those packets.
So as an example, let's imagine that we have a computer right here.
I'll call that PC and that is daisy-chain from an IP phone right here.
And then that goes into a switch.
We'll call that a layer two switch, which then goes down at some point to a
logical router,
which leads off to other points of the network.
And let's go ahead and draw another router in there.
And then I'll draw a cloud to represent the rest.
And let's imagine that this PC is communicating with a server right here.
And let's also imagine that there's a phone call being made over the IP network WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And let's also imagine that there's a phone call being made over the IP network
.
And this phone could be either a physical phone or software that's being run
for the voice over IP.
And let's imagine the other phone is right here that's being called.
So this will be phone number one up here and it'll be phone number two.
And ideally, if everything's moving nice and smoothly,
everything gets delivered, the voice of IP calls going great.
There's not excessive latency there.
However, if there's congestion in the network where there isn't enough
bandwidth or throughput
sent all the traffic in a timely manner, the network can be trained to pay
attention
to QoS quality of service markings inside the packets and the layer two headers WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to QoS quality of service markings inside the packets and the layer two headers
.
And then based on that, they can give preferential treatment to that.
Think of it like having a grocery store with several checkout lanes.
So these are checkout lanes one, two, and three.
And let's imagine it's a slow day and there's not a whole bunch of people in
line
every checking out fairly quickly.
But as it gets busy, which is a network world we could refer to as congestion,
perhaps at these checkouts at the grocery store, we have this right here as a
priority lane
for people who are wearing blue hats. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
for people who are wearing blue hats.
So if you're wearing a blue hat, you can go to this priority lane and check out
fairly quickly.
And if you don't have a blue hat, you have to get into one of these other lanes
.
And so you get better service if you're in this lane right here.
So let's imagine our router for a traffic.
Let's imagine we have a little backup there.
We have lots of packets that need to be sent.
If we're implementing QoS, it's a lot like having a special lane that's looking
for
people with blue hats.
Except this time we're looking for packets that have certain markings.
Let's imagine that this packet right here and this packet right here have been
given effectively
a blue hat. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
a blue hat.
And when the router sees that traffic, it's going to go ahead and forward those
first.
And then all the other packets and frames that don't have a blue hat,
they're going to be forwarded normally, which may include some additional
latency.
But at least we've identified our blue hat packets and have been able to
forward them more quickly.
And that's an example of using QoS.
Now, instead of using hats, as we have over here in our checkout lines with IP
packets
and with layer two frames, we're going to do markings.
So layer two that marking is referred to as COS class of service.
And then at layer three, we have DSCP, which stands for differentiated services WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then at layer three, we have DSCP, which stands for differentiated services
code point.
Think of it like just some special markings like a blue hat in the IP header.
And all by themselves, those DSCP markings, for example, if we mark the packets
as EAF,
which in decimal is number 46.
These routers, by default, don't care about looking at the IP header and
looking for whatever markings
might be there inside of the IP header representing expedited forwarding.
So in addition to getting the correct markings on our traffic, for example,
we can mark all of our voice traffic with EAF. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
we can mark all of our voice traffic with EAF.
And to actually give that traffic preferential treatment as it gets routed
through the network,
each of these layer three router devices need to be trained that when there is
congestion,
they need to look at that layer three header information regarding DSCP.
And then based on that information and how they've been programmed to go ahead
and give
preferential treatment to that.
So how does this QoS that we've talked about in a network environment,
how does that relate to segment profiles?
And the answer is we can create a QoS segment profile.
And with that segment profile applied, for example, right here to segment 10, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And with that segment profile applied, for example, right here to segment 10,
which then would be inherited and applied here to the port that this VM is
connected to segment 10
with, we could then implement QoS.
For example, if we wanted to go ahead and do certain markings at the layer
three header for the
benefit of the rest of the network to do expedited forwarding for that traffic,
we could actually have our QoS profile on the segment inject that marking.
So that way, if we have traffic that's entering the segment from a VM,
we can with a QoS profile modify the markings.
So as that traffic makes it out to the rest of the world and cross other WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So as that traffic makes it out to the rest of the world and cross other
routers,
if those other routers, if they've been trained to look at that IP header
information
and then do preferential forwarding based on that, they can go ahead and do
that.
Another cool thing we can do with a QoS segment profile is we can do bandwidth
throttling.
So even if we have, for example, one gig or maybe even 10 gig here on the
segment,
we could based on our QoS segment profile, we could limit the ingress or egress
,
which are fancy ways of saying inbound or outbound traffic for any of the VMs
on that segment.
So if we wanted to limit, for example, the maximum bandwidth that any single VM WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So if we wanted to limit, for example, the maximum bandwidth that any single VM
would use,
we could include that in a QoS segment profile, apply that to the segment, and
boom, we've just
limited HVM connected to that segment, and they're going to be constrained as
far as how fast they
can forward traffic based on the settings in our QoS segment profile. All right
, so with that
cleaned up, let me go ahead and do a little quick note there that QoS is one of
our segment profile
types. Another type is a segment profile called IP Discovery. And unlike a QoS
segment profile,
which is not applied to our segment's by default, there is a default IP WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
which is not applied to our segment's by default, there is a default IP
Discovery
segment profile applied to all of our segments. And the reason that's important
is because NSX is
using a lot of information based on that IP Discovery profile that NSX can use
for making the
network work better. For example, an IP Discovery segment profile is going to
be doing DHCP snooping.
Think of it like eavesdropping, looking at all the DHCP traffic going back and
forth between
clients and their DHCP server, or in the case of a DHCP relay between the VM
and the relay.
And it's using that to learn the layer three and layer two address mappings of WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And it's using that to learn the layer three and layer two address mappings of
each of the VMs.
It's also doing ARP snooping as well, paying attention to the ARP messages
being sent back and
forth from the VMs and building that into a table. And if you're running IP
version six,
it's also building tables based on neighbor discovery, which is used by IPV six
, including
things like router advertisements and neighbor advertisements and so forth. And
also as part of
an IP Discovery segment profile, including the default one that's applied to
our segments, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
our segments,
it's also leveraging VMware tools that's running on the VMs to report
information about that specific
VM. Now the benefit of NSX having all this information, it can do things like
ARP suppression. So if
this little VM here is running on ESXIA, and this little VM here is running on
ESXIB, two different
hosts. Let's imagine it's the 10 network here. So this is 10 dot 10 dot 0 dot
150. And this is
dot 151. If this client needs to communicate with that second host on the same
subnet,
when it does an ARP request, instead of that ARP request actually being WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
when it does an ARP request, instead of that ARP request actually being
forwarded as a broadcast
over to ESXIB, NSX, who knows, due to the IP Discovery segment profile that's
in place,
it knows the layer two addresses and the IP addresses. And as a result, ESXIA,
which is a transport
node, can actually respond back to that VM saying, Oh, here's your response to
that ARP request or
IPV six, it can respond back with the information that the client was
requesting without sending that
traffic over the tunnel over the network. So we're able to suppress a lot of WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
traffic over the tunnel over the network. So we're able to suppress a lot of
that ARP and neighbor
discovery traffic from ever leaving the host, because that information gleaned
via an IP Discovery
segment profile has collected all that information. And as a result, we don't
have to actually send
those broadcast other types of requests across the network. We can feed it
directly back from NSX
without ever bothering the remote host. All right, let's clean that up a little
bit. So that's two
of our segment profiles. Let's go ahead and talk about a third for our third
segment profile.
It's called spoof guard. So behind the scenes, NSX, it knows about VMS IP WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
It's called spoof guard. So behind the scenes, NSX, it knows about VMS IP
addresses, there are
layer two addresses got a lot of that information from the IP Discovery,
including the use of VMware
tools to report that. And in the event that this VM right here, which is at 10.
10.0.150,
let's imagine someone at this VM attempts to at that VM with the guest OS,
change its IP address.
So instead of being 10 10 0 150, which was all learned via IP Discovery, now
the user changes it
to 10.10.0.151. Well, if the user does that, what spoof guard is going to do, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to 10.10.0.151. Well, if the user does that, what spoof guard is going to do,
if it's enabled,
it's going to say, you know what, you're not allowed to go ahead and change
your IP address.
I already know says NSX what that IP address slash Mac combination is for the V
land that you're in.
So if the user tries to change their address with spoof guard, because NSX
knows the IP address
is involved because of the snooping and the Mac address is involved, it's going
to say,
you know what, you can't change that IP address. Or maybe you can try to change
your IP address to
the guest OS, maybe they'll let you. But as a function of spoof guard, I'm not
going to let you
send any packets into the network. If you're trying to come from an IP address WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
send any packets into the network. If you're trying to come from an IP address
that's not the one
that I believe you have. All right, let me clean that up just a little bit. And
let's talk about
yet another type of segment profile. And the next type of segment profile like
to chat about is
called a segment security profile, or the full name would be a segment security
segment profile.
In either case, with a segment security profile, we can protect against several
things in our network,
and some are related to spanning tree protocol. So for example, this VM right
here has absolutely
no need to receive any type of bridge protocol data units. We can simply do WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
no need to receive any type of bridge protocol data units. We can simply do
filtering as part
of the segment security segment profile and specify that we want to filter and
not send BPDs
down to our VMs. So we'll save a little bit of bandwidth in doing that. Also,
if we have an attacker
on one of our segments, we probably don't want to be sending in STP information
, including bridge
protocol data units to a hacker who may want to use that information to try to
compromise our
network at layer two. Another element as part of a segment security segment
profile is regarding
dynamic host configuration protocol. So let's imagine we have this VM right WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
dynamic host configuration protocol. So let's imagine we have this VM right
here that one day,
either somebody either accidentally or intentionally is using some tools,
trying to become or act as
a DHCP server. So when this client, if it's got the as a DHCP client, it sends
a discover message
to the network. If this device right here, if it's acting as a DHCP server,
could send an offer.
And if we trick this VM into taking the offer from this VM right here from the
attacker machine,
or if it's accidental from the accidental user here, we could totally give the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
or if it's accidental from the accidental user here, we could totally give the
wrong information
regarding IP address, default gateway, DNS, etc. And if it's an attacker and
that attacker is
malicious, the attacker could intentionally give this VM incorrect information
saying,
Hey, if they're DNS server, use me or for your default gateway, use me. And at
that point,
all the traffic can be going through this attacker VM before 40 out to the rest
of the network.
And that would create a man in the middle attack. So if we want to prevent that
, if we want to
prevent DHCP server messages, we can do that as part of a segment security
segment profile.
And by default, filtering DHCP server messages are already included in the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And by default, filtering DHCP server messages are already included in the
default segment security
segment profile that's applied to all of our segments. Now, one thing that that
does not apply
to is if we have DHCP relay setup, where we have our gateway, for example, that
's taking our DHCP
request and forwarding that to the real DHCP server, even if we're filtering
DHCP server messages,
the actual relay function is still going to work fine right here on this
segment.
So the default behavior of stopping any DHCP server type messages that weren't
sourced from WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
sourced from
NSX itself, or weren't going through an appropriate relay, those server decline
messages are going
to be blocked to protect against devices like this one becoming a rogue or
unauthorized DHCP server.
And another component of a segment security profile would be router
advertisement information.
So just like we don't want this VM right here to start advertising itself as a
DHCP server and
giving out DHCP offers, we also don't want this device right here to try to
trick the network with
router advertisements for IPv6 to try to trick the network that this device WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
router advertisements for IPv6 to try to trick the network that this device
right here in its IP
address is a valid router on that segment. And the fifth segment profile I'd
love to chat with you
about is Mac Discovery. So let's imagine this VM right here. And let's also
just realize that
there's IP Discovery involved with an IP Discovery segment applied to this
segment by default. And so
NSX knows all about the layer two address of this VM and as the layer three
address of this VM.
However, what if this VM needs to go ahead and change their layer two address?
Well, as part of
a Mac Discovery profile, if we configure one that allows the user to change WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
a Mac Discovery profile, if we configure one that allows the user to change
their Mac address,
then that user in the guest OS can change their layer two address and the NSX
segment will continue
to allow frames from that new layer two address, even though it wasn't the one
originally configured
on that VM. Another function of a Mac Discovery segment profile is the learning
of Mac addresses.
And I'm putting that in plural right there because perhaps on this VM, we have
not only this VM's
network interface card with its own layer two address, but also maybe we're
running some function
or proxy service inside that VM, which includes yet a second or a third or more WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
or proxy service inside that VM, which includes yet a second or a third or more
layer two addresses
that are going to be coming into the segment via this VM's network interface
card. Well, if we
want to allow that to happen and allow those additional sources for the layer
two addresses to be sent
into the segment, we can use a Mac Discovery segment profile either applied to
the segment itself or
applied directly to the VM as an override to allow multiple layer two addresses
to be coming in
from that single VM NIC. Also, while we're right here talking about profiles,
let's also talk about
one other profile that's not specifically a segment profile, but it's pretty
important to be aware WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
important to be aware
and it's called an edge bridge profile. And an edge bridge profile can come in
super handy if
we need to merge or bridge, for example, a overlay segment like this network 10
10 zero,
which is on this non VRF segment right here off of this T1 gateway. And let's
say we need to have
these VMs right here, we'll call them VM number one and VM number two. And let
's also imagine we
have a VLAN over here. And we have a couple more computers over here on the
physical network.
So this could be computer three and computer four. And let's say we want to
have these two devices WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
have these two devices
also logically be on that same network segment. So this is VLAN based on our
physical network.
And this is our overlay segment. So how do we bridge those two together? And
the answer is,
I'm going to color code this, we're going to use an edge bridge profile that
basically says,
you know what, for this segment right here, and for this VLAN, let's go ahead
and call this say,
say, let's say, for example, VLAN 25, we can use an edge bridge profile and
logically bridge those
together. Now behind the scenes, it's our edge transport nodes that are doing
the actual bridging
of that traffic from this network segment, the 1010 zero up here on this WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
of that traffic from this network segment, the 1010 zero up here on this
overlay segment
down to this VLAN. So if we want these computers to talk, we need to use IP
addresses over here
in that same address space of 10 dot 10. So if we had D should be services
right here,
being provided by tier one gateway A for the segment, and we set up the bridge,
we could
actually have these clients act as D should be clients. And they could actually
get IP addresses
from the D should be services over here, because logically, it's like one giant
layer two broadcast
domain, which includes this segment here and this VLAN here. And again, that's WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
domain, which includes this segment here and this VLAN here. And again, that's
pulled off by using an
edge bridge profile.