So in the previous video, we configured this segment, segment 30.
We enabled DHCP services for that specific segment.
And in this video, we're going to test and verify that it works.
So I propose that we put a couple of VMs right here on that segment.
We'll tell them to be DHCP clients.
We'll verify they get an IP address for the 1030 address space.
And we'll also verify they can connect to each other.
It'll also be fun to capture the traffic on the transport network,
just to verify all the devices that are involved with those DHCP services. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
just to verify all the devices that are involved with those DHCP services.
So just to confirm in the NSX manager here,
we created the NSX segment 30 and we have DHCP services enabled for it.
So let's create a couple VMs, plug them into this segment,
and verify that our segment-based DHCP services are working.
So here we are on the vSphere client, and let me just take a couple VMs
and let me just clone them to new VM.
So right click on this VM1.
From the menu, we'll click on clone and we'll clone to virtual machine.
And let's call this VM-30-A.
And we'll put that on host A.
So let me put that in a folder called VMs for testing, click on next, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So let me put that in a folder called VMs for testing, click on next,
and then we'll put it on the ESXIA, fantastic, click on next.
And then we'll use the local data store there, click on next.
And then I'll customize it to put it on the right segment,
and then we'll power it on the background after that happens and click on next.
So the part we want to change here is I want to make sure it's on the right
segment.
So for the network adapter, we'll click on browse,
and we went on segment 30, no gateway, click on OK, everything else looks great
,
and click on next and finish. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and click on next and finish.
All right, so that's being deployed, and while that's being deployed,
let's go ahead and create one more.
So I'll right click on VM1 again, click on clone, clone to virtual machine,
and we'll call this VM-30-B.
I'll store it in the folder called VMs for testing, click on next.
And then for the compute resource, I want to put this one on ESXIA-B
and click on next, and we'll put that in the local data store there and click
on next.
And then customize the VM before powering it on, click on next.
And then we also want to place this one on that same segment, which is segment WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then we also want to place this one on that same segment, which is segment
30.
So we'll grab segment 30, click on OK, everything else looks good,
click on next and finish.
And we click on recent tasks here, and it looks like that second VM deployment
is almost done, and it says it is.
So let me close the recent tasks there.
So there's VM-30A and VM-30B, we go to the networks view here
and go to that segment right there and click on VMs just to verify
that we have the first one, VM-38 running on host A
and VM-30B running on host B, and they're both connected to this segment 30. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and VM-30B running on host B, and they're both connected to this segment 30.
So if everything worked out well, they both got IP addresses on the 1030 subnet
,
courtesy of our segment-based DHCP server.
Precise-wise, let me go ahead and just bring up a web console for VM-30.
And here for VM-30A, we'll do an IF config for Ethernet 0,
and that's it, 1030-0-1-51, that's looking pretty good.
And let's open up a console for VM-30B by clicking here on launch web console.
So from the top left, we're on VM-30B, we'll do an IF config for Ethernet 0, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So from the top left, we're on VM-30B, we'll do an IF config for Ethernet 0,
and that's at 10.30.0.152.
So we did a ping over to 10.30.0.151, that's VM-30A's address and press enter.
Boom, that works, no problem, fantastic.
I also think it would be fun just to confirm what's really going on behind the
scenes
to go ahead and do a trace flow.
So back at the NSX manager, for a trace flow, we can go to plan and troublesh
oot.
And then the left, under troubleshooting tools, we'll click right here on WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then the left, under troubleshooting tools, we'll click right here on
traffic analysis.
And here in the tile for trace flow, we'll click right here and get started.
And what we want to do is we want to do a test from these two virtual machines.
So let's go ahead and test traffic between VM-30A on the left.
So there's this IP address and this MAC address.
And we want to test that connectivity over to VM-30B.
And there's its IP address and MAC address.
That's also a really great confirmation that we are dealing with the IP
addresses that we believe we are.
So VM-30A is running on host A, VM-30B is running on host B, and let's click on WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So VM-30A is running on host A, VM-30B is running on host B, and let's click on
trace.
And we'll give that a moment to process that.
And here are the results. Let me go ahead and collapse the left-hand side.
Give us a little more room.
And if we look at the play-by-play right here, the traffic starts on ESXIA,
goes to a logical distributed firewall.
ESXIA sends it over the tunnel to ESXIB, who receives it.
It goes to a logical distributed firewall, which permits the traffic.
And then that traffic is delivered to VM-30B.
So that's for the VM to VM traffic. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So that's for the VM to VM traffic.
But another interesting note is that I also have that packet capture still
running in the background.
So I thought it'd be interesting to take a look at that packet capture.
If we reboot one of those VMs, then it goes through the discover offer request
acknowledgement process again.
So I just reset the packet capture, so it's backed down to a reasonable number
of packets.
I also have a display filter just showing DHCP related traffic.
And here on VM-30A, let me go ahead and do a then control alt delete,
which will cause it to go ahead and do a reboot.
And let's do the same thing for VM-30B. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And let's do the same thing for VM-30B.
So here's VM-30B. Let me do a control alt delete, which will cause it to shut
down and a reboot.
And initiate the discover offer request process again.
All right, that's looking good.
And let's go to the packet capture and take a look at the results.
So here's that captured traffic.
So we look at the discovers, check it out.
There's four of them.
You might think, well, why in the world are there for?
Well, let's take a look at the details.
So for this first one that I'm highlighting here, we look at the tunnel end
points here.
It's from ES6IA going to ES6IB.
And the reason it's sent it over was because it's a broadcast. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And the reason it's sent it over was because it's a broadcast.
If you look at the next one, it's going from ES6IA over to that IP address is
edge one.
Now, notice here for the offer, it's coming from the IP address, the tunnel end
point of edge one.
That's the tunnel end point address of edge one coming back to ES6IA.
And here we have the Geneve header.
So if we open up the Geneve header, here is the VNI number right there.
So it claps that and then here's the original payload.
So from the client's perspective, it looks like this is traffic coming from 10
30 to that's the virtual IP address WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
30 to that's the virtual IP address
that we set up for the DHCP services on the 1030 network
and is destined to 1030 0.151, which is the IP address being offered to the
client.
So if we expand the details for the payload and the DHCP offer right here,
that's the IP address that's being offered to the client.
So as part of the DHCP offer, it includes the IP address, the mask,
and we didn't supply the information.
We're going to default gateway or DNS.
Otherwise, it would be included here as well.
So let me go ahead and collapse that.
So here for the offer, the offer is unicast back. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So here for the offer, the offer is unicast back.
So it's unicasting it to the IP address that's being used in the offer
as well as the layer two address of that VM.
And then for the request, the client is broadcasting that back.
And as a result, it's being sent to host B, it's being sent to edge one.
It's also being sent to edge tube based on those tunnel endpoint addresses.
And then we have the final acknowledgement from the server.
So this is coming from edge one based on this one endpoint address going over
to ESXIA
who de encapsulates it and then forwards effectively that acknowledgement back WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
who de encapsulates it and then forwards effectively that acknowledgement back
to the client
back to the VM.
So in the acknowledgement, it acknowledges that the client is going to be using
this IP address
with this mask right here.
And again, any other options that we had offered like a default gateway or DNS
server
and so forth, if they were offered, those would be part of the acknowledgement
as well.
And then for the next series of discover messages, these are for VM 30 dash B.
And again, we can confirm that just based on where these are coming from and
going to.
So the source is the 22 address base.
That's the tunnel endpoint for ESXIA B and it's being sent over to ESXIA. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
That's the tunnel endpoint for ESXIA B and it's being sent over to ESXIA.
And it's also being sent.
Let me clap that.
It's also being sent to edge one and also edge to based on those tunnel
endpoint addresses.
And then there's an offer made.
And if we collapse that this offer is coming from edge one based on that tunnel
endpoint address going back to ESXIA
B and then based on that offer, the client then does a broadcast to say,
Yep, I'll take it.
That's part of the request followed by an acknowledgement.
This is the acknowledgement from edge to going back to ESXIA B.
Now, not every single client handles DHCP the same way. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now, not every single client handles DHCP the same way.
In fact, there's a bit in the DHCP discover.
So if we go up to one of our discovers, go ahead and grab this one right here
and we open up the details for this discover.
In the discover coming from the client, there's some boot P flags.
Boot P is like the predecessor way of saying DHCP.
And so based on the boot flags of unicast, that means the server is going to
respond back with unicast responses.
So as far as the offer and the acknowledgement, they are going to be unicast
back.
If the client had said this bit to on instead of off, that would mean it's WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
If the client had said this bit to on instead of off, that would mean it's
going to be broadcast and that would cause the DHCP server to respond with the
offer and the acknowledgments in a layer to broadcast fashion as opposed to
unicast back to the IP address associated with the offer.
So again, so the behavior coming back from the server is based on what the
client in their initial discover was asking for.
So now that we have configured and verified segment based DHCP services for
segment 30 in the next video, let's follow up with our third implementation of WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
segment 30 in the next video, let's follow up with our third implementation of
DHCP services and that is to implement gateway based DHCP services and that's
going to benefit segments that are directly connected to gateways.
As is the case for segment 10 and segment 20.
So we'll do that third piece in our next video.
So I'll see you there in just a moment.
[BLANK_AUDIO]