So now that we have DHCP relay services enabled for segment 10 and segment 20,
pointing to our DHCP server up here, let's verify that it works.
So one of the things I'm going to do is set up a wire-sharp capture at my
management computer,
and that way we can take a look at all the traffic regarding DHCP that's
happening on the network.
So to test this, let's bring up a couple VMs on each subnet.
So let's bring up VM1 that's running on host A, and then VM4, which is running
on host B.
And then it'll be a good test for both of our host transport nodes and both of
our segments. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
our segments.
So again, VM1 and VM4, let's power those up right now.
So there is VM1 and there is VM4.
Let me verify the host they're running on that looks great.
And let's right click and go ahead and click on power, and we'll power them
both on.
They are DHCP clients, so they should be doing the discover messages,
and the gateways on each of those respective subnets should be forwarding those
.
And we can also watch that in near real time with our packet capture right here
.
All right, so here we go.
So I've got discover, discover, uh-oh. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So I've got discover, discover, uh-oh.
I got a lot of discovers going on.
Just grab this first discover right here.
So I'm going to double click on it, and I'll give us a little more room there.
So the first four lines here are just the system, VMware,
forwarding the traffic over to my management computer at .151 right here.
So this IP header right here is coming from 11, 11, 11, which is ES6IA,
and the destination is 44, 44, 44, 44, 44, which is edge two.
So go ahead and collapse that.
And then our next row is the layer four protocol, UDP, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then our next row is the layer four protocol, UDP,
going to the well known port of 6081 that's being used by Geniv.
Then we have the Geniv header.
So there's the VNI in hex.
And if we expand that, there's the VNI in decimal 68,609.
So we'll collapse that.
So based on where I'm capturing this, as far as the payload is being carried,
this is a packet source from 10, 10, 0, 1.
And that's the IP address on the gateway A.
And it's being forwarded to 23.1.2.1, which is the IP address of the external WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And it's being forwarded to 23.1.2.1, which is the IP address of the external
DHCP server.
And that's going to the well known UDP server port for DHCP of UDP port 67.
And this is the contents of that discover message.
So there's the relay agent IP address source from the segment 10.
Here's the MAC address right there,
ending in D7 of my client who did the initial discover.
If we scroll down.
However, the problem is I see a lot of discover messages,
but I see absolutely no offers.
And because I am collecting this on the transport network, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And because I am collecting this on the transport network,
I should see the offers as well.
Because this traffic is going between our host transport nodes and the edge
nodes,
and I don't see the offers.
So what could be causing that?
So let's put on our thinking cap.
So in this case, it was VM1.
I'll cross off the IP address because it'll get whatever IP address it's given.
So VM1, did a discover message that was logically received by this gateway,
and then encapsulated and folded up.
So behind the scenes, it went from ESXIA, and it was sent over to the edge two. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So behind the scenes, it went from ESXIA, and it was sent over to the edge two.
So as far as troubleshooting, it could be, oh, I know what it is.
I know what it probably is.
We'll troubleshoot this together.
On our segments, there's a default segment profile.
We haven't covered them yet.
However, in this case, the segment profile, by default, that's assigned to our
segment
is denying any DHCP server responses that would be coming back, for example,
from a DHCP server through a segment back to our clients.
And so that very likely is causing the failure of our DHCP response to come WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And so that very likely is causing the failure of our DHCP response to come
back.
And when we set this up, it is VLAN 23 that we're using.
Let's just take a look at the segment profile that's associated with that
segment
and see whether or not it's blocking server messages from a DHCP server.
Now, by default, that's not a bad idea, actually, because if we have rogue
clients
or malicious clients who are trying to act as a DHCP server and lie to the
network
or if they just accidentally bring in a home device and it's acting as a DHCP
server,
we want to make sure we're not allowing DHCP responses from servers that are WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
we want to make sure we're not allowing DHCP responses from servers that are
not authorized.
So let's take a closer look at this segment and also the segment profile
associated with it.
So to do that, in the NSX manager, we'll go to networking under connectivity,
we'll click on segments.
And then from here, let's take a look at this segment right here.
This is our VLAN 23, 23.1.2.
That's the name of the segment.
It is VLAN backed.
If we expand it, it's showing us that we're using VLAN 23.
And if we scroll down, here's a section for segment profiles. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And if we scroll down, here's a section for segment profiles.
And there is our problem right there.
The segment security profile is using the default one,
which is not allowing DHCP server responses.
So if we minimize that and push that to the left, what we could do is we could
go ahead
and simply edit this segment.
So we'll go ahead and just click on the three dots, click on edit, and then
scroll down.
And under segment profiles, if it's collapsed, just simply expand it.
Then right here, we could go under segment security, use the dropdown.
And if they don't have one that we want to use, we could click right here on WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And if they don't have one that we want to use, we could click right here on
the three dots to create one.
So let's go ahead and create a more lax and more easygoing security profile
that will allow DHCP responses.
Also, in fact, right here, we can click and say view to view the existing one.
And right there, we can confirm that it's not allowing DHCP server type
messages to be sent.
And that's very likely why our real DHCP server who's trying to communicate
over that segment
is not getting their packets being sent into the network.
So we'll go ahead and close that and click on the three dots,
and let's create a new security segment profile. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and let's create a new security segment profile.
So we'll click on create new, and we'll call this allow DHCP server messages.
And then right here, we'll just make sure that the server block is disabled for
DHCP for IPv4.
And then we'll stick a quick peek and make sure we're not blocking anything
else too important.
Looks like we're not and we'll click on safe.
So now under segment security, we have this allow DHCP server messages.
Fantastic. And we'll click on safe.
All right. And then we'll click on close.
Also, if we wanted to take a moment and actually create that profile beforehand WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Also, if we wanted to take a moment and actually create that profile beforehand
with networking selected on the left, if we're under segments,
there's a sub tab right here for profiles.
And we could right here go ahead and create that profile.
So there's the profile that we just made that's not blocking DHCP server
messages.
This is also indicated that the segment profile is also being used over here in
the assigned two.
If we click on the assigned two and click on this hyperlink,
it's going to show us where it's currently being applied.
So it's applied to our segment called VLAN 232312.
All right. So fantastic.
So if that was causing us a problem, it should no longer be causing us a WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So if that was causing us a problem, it should no longer be causing us a
problem.
So let's go back to wire shark and let me go ahead and click on the last packet
.
And I still see nothing but discover, discover, discover.
Let me go ahead and let me kickstart a couple of our clients.
So here for VM one, let me go ahead and launch a remote console for that one.
And then we also launch a remote console for VM four.
And that way we can bring them up side by side.
Well, those consoles are coming up.
Let me bring back my wire shark.
So here's wire shark down here.
I have over 300,000 packets. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I have over 300,000 packets.
So I'm going to go ahead and stop the capture and then started again
and click on continue without saving and I'll have the same filter in place.
Looking for just GRE traffic that's coming in.
And I also have the display filter only showing DHCP related traffic.
And all I still see here are discover messages only.
So let me go ahead and reboot VM one and reboot VM four.
So that'll do a graceful shutdown and restart them.
And I just want to validate whether or not they can get an IP address and WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And I just want to validate whether or not they can get an IP address and
survey says, no.
So I have some new discover messages, but no offers in place.
Hmm curious.
What else could it be?
And now we enter the troubleshooting stage of our demonstration.
So what else could it be?
So we modified our segment profile for security.
So it's allowing DHCP server messages to come back.
We verified that this server is reachable.
We verified with the packet capture that the actual traffic is being sent.
Oh, I know what it is. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Oh, I know what it is.
In a previous skill, we took a look at the world of network address translation
.
And we currently have SNAT source NAT in place.
And the rule I think we have set up says a traffic source from 10 anything.
Go ahead and swap it out to an IP address in the 2312 address space.
Now the challenge with that is that even though the payload for the DHCP
discover
has the information about the client and their layer two address and all that
good stuff.
And also as part of that payload, it also includes the source IP address here WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And also as part of that payload, it also includes the source IP address here
of the gateway A.
The actual packet that's being sent, it's outside IP address of 10 10 0.1 is
going to be swapped out.
And when the DHCP server at least this DHCP server sees that,
it's very likely saying, hey, that doesn't match up.
This DHCP discover message came in from this relay that claims to be on the 10
10 0 network.
But the source address was something in the 23 address space.
And that may be why this DHCP server couldn't find a correct IP address because
it doesn't
have a pool in the 23 address space. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
have a pool in the 23 address space.
It only has pools for 10 10 and 10 20.
So let's do this as a temporary test.
Let's verify if we currently have net rules in place, which I believe we do.
Let's also verify if they're currently being hit. And if they are, let's just
disable our net
rule right here temporarily and then verify whether or not the gateways without
having that net done
on their source IP address to verify if that fixes the problem. Also, before we
make that change,
I just want to verify that as I scroll through here, we have no DHCP offers or
anything else.
So let me go ahead and stop the capture because I'm currently at 85,000 packets WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So let me go ahead and stop the capture because I'm currently at 85,000 packets
.
And let me start a new one with all the same details and it'll give us a nice
fresh start.
So again, as a before and after test, let me just reboot both of these little V
Ms
that should trigger the discover process.
And I just want to verify before we make the net change that we are not getting
offers.
So those should show up here in just a moment.
All right. So there's failure, failure, failure. All right, no offers.
Discover is only. All right. So let's minimize that. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Discover is only. All right. So let's minimize that.
Minimize VM1, minimize VM2, and let's go to the NSX manager.
So here at the NSX manager with the networking tab on top selected on the left
under network
services, we'll click on that. And sure enough, we have a source net rule.
I'm going to collapse the left hand side. It gives a little more room here.
And let's just click on the little icon to see whether or not we currently have
a lot of hits
on that net rule. So we'll click on the icon for statistics.
And currently it shows active session zero. If we refresh this, in fact, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And currently it shows active session zero. If we refresh this, in fact,
let me go ahead and bring back a client by a reboot of client.
So go ahead and reboot client one there. And if I do a refresh and refresh,
I just want to verify that that's triggering. And there we go. There's one
active session.
So unfortunately the DHCP relay, because it's going out the same interface that
we're using
that on, it's swapping out that source address. And that's confusing my DHCP
server.
So let me go ahead and close that. And what we'll do is simply as a test,
let me go ahead and click on the three dots for this net rule, click on edit. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
let me go ahead and click on the three dots for this net rule, click on edit.
And again, just as a test, I'm going to disable it, scroll down, click on save,
and then click here on refresh. And it is no longer enabled.
So now that we've done that, let's bring back our packet capture. Oh, look at
that. Yeah.
And here we go. Okay, fantastic. So that's the difference.
So we did two things. We actually modified the segment security profile to tell
it to allow
DHCP responses. And we also exempted the source IP address for the DHCP relay WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
DHCP responses. And we also exempted the source IP address for the DHCP relay
from being address
translated. So it's now showing up as coming from a trill address. So this is
coming from Gateway B
10, 20, 01. And this is coming from Gateway A at 10, 10, 01. And then we have
that followed up with
an offer and then a request and then the final acknowledgement. So if we look
at this offer
right here, and we expand the details, here's what we expect the client to have
. So the offer
effectively is the 10, 10, 0151 address. There's the MAC address of our client
ending in D seven.
And as far as the subnet, if we look at that, it's a 24 bit mask right there. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And as far as the subnet, if we look at that, it's a 24 bit mask right there.
If we open up the
option for the default gateway, that's 10, 10, 01. So if we look at VM one
right now, it should have
this specific information. And for the DNS server, let's see if we assign one
sure enough, there's 888.
So if we bring in VM one, and let's do an IF config for ethernet zero, press
enter. Sure enough,
10, 10, 0151 fantastic. And if we do a route dash and take a look at the
routing table,
our default gateway is 10, 10, 01. And if we try to go up to the internet, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
our default gateway is 10, 10, 01. And if we try to go up to the internet,
because we no longer have net, that's not going to be too convenient. But you
know what, let's do
this. Let's just go ahead and now that we have an IP address, let's go ahead
and enable our
net role. So I'll click on edit and enable the net role that we have an IP
address, click on save,
click on refresh there, fantastic. And let's go back to our client. So now with
our client,
if we do something like a ping to www.google.com, and that works, that's
fantastic. That verifies
a couple things for us. Number one, verifies that DNS is working. It also ver
ifies we have internet WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
ifies we have internet
access. Now, as far as a long term solution here, I would want to go ahead and
create an
exemption. A more specific rule, it says, Hey, if traffic is coming from, for
example, 10, 10,
01 going to the IP address of the DHCP server, please don't net it. And that'd
be a role of a
type no SDAP, sit up an exemption for that. Or I could just use a different
DHCP server.
That's not on that same external segment where I happen to be using network
address translation.
Either way would be great. All right, so in preparation for the next
demonstration,
where we're going to set up segment based DHCP services, I would like to remove WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
where we're going to set up segment based DHCP services, I would like to remove
all the DHCP
that we configured to this point, that'd be a good reminder of what we just
configured. So for
each of the segments, we went into the segments one by one, and we clicked on
edit, and we clicked
right here on edit DHCP config to specify the profile for the DHCP relay. I'm
going to go ahead
and delete that right here. So for segment 10, that is now gone after I click
on save and close,
and we'll do the same thing for segment 20. We'll edit it over here on the
right. We'll click on WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
right. We'll click on
delete DHCP config, delete, scroll down, click on save, close editing. And then
now on the left
hand side, if we go down to settings and networking profiles and click on DHCP,
it should now show
that this DHCP relay profile is no longer in use anywhere. So the where used
has a count of zero.
So I'm going to go ahead and delete it as well. So click on delete and delete.
And we've now
removed all of our DHCP services. So for DHCP relay, we planned it out, we
configured it,
we troubleshot it, and we verified it. So in the next video, we're going to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
we troubleshot it, and we verified it. So in the next video, we're going to
move to the next step,
and that is to create a new segment, we'll create segment 30, and we'll set up
segment based DHCP
services for a segment that has absolutely none of our gateways directly
connected to it.
So I'll see you in the next video for exactly that.
[BLANK_AUDIO]