WEBVTT

1
00:00.000 --> 00:04.000
So in the previous video, we configured this segment, segment 30.

2
00:04.000 --> 00:07.700
We enabled DHCP services for that specific segment.

3
00:07.700 --> 00:10.700
And in this video, we're going to test and verify that it works.

4
00:10.700 --> 00:14.800
So I propose that we put a couple of VMs right here on that segment.

5
00:14.800 --> 00:17.000
We'll tell them to be DHCP clients.

6
00:17.000 --> 00:20.000
We'll verify they get an IP address for the 1030 address space.

7
00:20.000 --> 00:22.200
And we'll also verify they can connect to each other.

8
00:22.200 --> 00:25.500
It'll also be fun to capture the traffic on the transport network,

9
00:25.500 --> 00:30.500
just to verify all the devices that are involved with those DHCP services.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

9
00:25.500 --> 00:30.500
just to verify all the devices that are involved with those DHCP services.

10
00:30.500 --> 00:33.000
So just to confirm in the NSX manager here,

11
00:33.000 --> 00:38.000
we created the NSX segment 30 and we have DHCP services enabled for it.

12
00:38.000 --> 00:41.300
So let's create a couple VMs, plug them into this segment,

13
00:41.300 --> 00:44.700
and verify that our segment-based DHCP services are working.

14
00:44.700 --> 00:48.000
So here we are on the vSphere client, and let me just take a couple VMs

15
00:48.000 --> 00:49.500
and let me just clone them to new VM.

16
00:49.500 --> 00:51.300
So right click on this VM1.

17
00:51.300 --> 00:55.000
From the menu, we'll click on clone and we'll clone to virtual machine.

18
00:55.000 --> 00:57.200
And let's call this VM-30-A.

19
00:57.200 --> 00:58.400
And we'll put that on host A.

20
00:58.400 --> 01:02.400
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

20
00:58.400 --> 01:02.400
So let me put that in a folder called VMs for testing, click on next,

21
01:02.400 --> 01:07.200
and then we'll put it on the ESXIA, fantastic, click on next.

22
01:07.200 --> 01:11.100
And then we'll use the local data store there, click on next.

23
01:11.100 --> 01:13.800
And then I'll customize it to put it on the right segment,

24
01:13.800 --> 01:17.300
and then we'll power it on the background after that happens and click on next.

25
01:17.300 --> 01:19.960
So the part we want to change here is I want to make sure it's on the right

26
01:19.960 --> 01:20.300
segment.

27
01:20.300 --> 01:22.700
So for the network adapter, we'll click on browse,

28
01:22.700 --> 01:27.900
and we went on segment 30, no gateway, click on OK, everything else looks great

29
01:27.900 --> 01:27.900
,

30
01:27.900 --> 01:30.300
and click on next and finish.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

30
01:27.900 --> 01:30.300
and click on next and finish.

31
01:30.300 --> 01:33.800
All right, so that's being deployed, and while that's being deployed,

32
01:33.800 --> 01:35.500
let's go ahead and create one more.

33
01:35.500 --> 01:40.800
So I'll right click on VM1 again, click on clone, clone to virtual machine,

34
01:40.800 --> 01:44.500
and we'll call this VM-30-B.

35
01:44.500 --> 01:48.000
I'll store it in the folder called VMs for testing, click on next.

36
01:48.000 --> 01:51.200
And then for the compute resource, I want to put this one on ESXIA-B

37
01:51.200 --> 01:55.200
and click on next, and we'll put that in the local data store there and click

38
01:55.200 --> 01:56.000
on next.

39
01:56.000 --> 01:59.400
And then customize the VM before powering it on, click on next.

40
01:59.400 --> 02:02.510
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

40
01:59.400 --> 02:02.510
And then we also want to place this one on that same segment, which is segment

41
02:02.510 --> 02:02.900
30.

42
02:02.900 --> 02:06.700
So we'll grab segment 30, click on OK, everything else looks good,

43
02:06.700 --> 02:08.700
click on next and finish.

44
02:08.700 --> 02:13.900
And we click on recent tasks here, and it looks like that second VM deployment

45
02:13.900 --> 02:16.300
is almost done, and it says it is.

46
02:16.300 --> 02:18.100
So let me close the recent tasks there.

47
02:18.100 --> 02:22.000
So there's VM-30A and VM-30B, we go to the networks view here

48
02:22.000 --> 02:26.600
and go to that segment right there and click on VMs just to verify

49
02:26.600 --> 02:29.700
that we have the first one, VM-38 running on host A

50
02:29.700 --> 02:33.400
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

50
02:29.700 --> 02:33.400
and VM-30B running on host B, and they're both connected to this segment 30.

51
02:33.400 --> 02:38.600
So if everything worked out well, they both got IP addresses on the 1030 subnet

52
02:38.600 --> 02:38.600
,

53
02:38.600 --> 02:41.300
courtesy of our segment-based DHCP server.

54
02:41.300 --> 02:45.100
Precise-wise, let me go ahead and just bring up a web console for VM-30.

55
02:45.100 --> 02:49.500
And here for VM-30A, we'll do an IF config for Ethernet 0,

56
02:49.500 --> 02:53.100
and that's it, 1030-0-1-51, that's looking pretty good.

57
02:53.100 --> 02:58.400
And let's open up a console for VM-30B by clicking here on launch web console.

58
02:58.400 --> 03:03.600
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

58
02:58.400 --> 03:03.600
So from the top left, we're on VM-30B, we'll do an IF config for Ethernet 0,

59
03:03.600 --> 03:06.600
and that's at 10.30.0.152.

60
03:06.600 --> 03:14.400
So we did a ping over to 10.30.0.151, that's VM-30A's address and press enter.

61
03:14.400 --> 03:16.900
Boom, that works, no problem, fantastic.

62
03:16.900 --> 03:20.860
I also think it would be fun just to confirm what's really going on behind the

63
03:20.860 --> 03:21.400
scenes

64
03:21.400 --> 03:23.900
to go ahead and do a trace flow.

65
03:23.900 --> 03:27.870
So back at the NSX manager, for a trace flow, we can go to plan and troublesh

66
03:27.870 --> 03:27.900
oot.

67
03:27.900 --> 03:31.170
And then the left, under troubleshooting tools, we'll click right here on
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

67
03:27.900 --> 03:31.170
And then the left, under troubleshooting tools, we'll click right here on

68
03:31.170 --> 03:32.500
traffic analysis.

69
03:32.500 --> 03:35.900
And here in the tile for trace flow, we'll click right here and get started.

70
03:35.900 --> 03:39.600
And what we want to do is we want to do a test from these two virtual machines.

71
03:39.600 --> 03:45.500
So let's go ahead and test traffic between VM-30A on the left.

72
03:45.500 --> 03:47.900
So there's this IP address and this MAC address.

73
03:47.900 --> 03:52.000
And we want to test that connectivity over to VM-30B.

74
03:52.000 --> 03:54.500
And there's its IP address and MAC address.

75
03:54.500 --> 03:58.180
That's also a really great confirmation that we are dealing with the IP

76
03:58.180 --> 03:59.800
addresses that we believe we are.

77
03:59.800 --> 04:05.230
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

77
03:59.800 --> 04:05.230
So VM-30A is running on host A, VM-30B is running on host B, and let's click on

78
04:05.230 --> 04:05.600
trace.

79
04:05.600 --> 04:07.900
And we'll give that a moment to process that.

80
04:07.900 --> 04:10.400
And here are the results. Let me go ahead and collapse the left-hand side.

81
04:10.400 --> 04:11.700
Give us a little more room.

82
04:11.700 --> 04:16.700
And if we look at the play-by-play right here, the traffic starts on ESXIA,

83
04:16.700 --> 04:19.000
goes to a logical distributed firewall.

84
04:19.000 --> 04:23.400
ESXIA sends it over the tunnel to ESXIB, who receives it.

85
04:23.400 --> 04:26.500
It goes to a logical distributed firewall, which permits the traffic.

86
04:26.500 --> 04:29.100
And then that traffic is delivered to VM-30B.

87
04:29.100 --> 04:31.300
So that's for the VM to VM traffic.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

87
04:29.100 --> 04:31.300
So that's for the VM to VM traffic.

88
04:31.300 --> 04:34.750
But another interesting note is that I also have that packet capture still

89
04:34.750 --> 04:36.400
running in the background.

90
04:36.400 --> 04:39.200
So I thought it'd be interesting to take a look at that packet capture.

91
04:39.200 --> 04:43.060
If we reboot one of those VMs, then it goes through the discover offer request

92
04:43.060 --> 04:44.700
acknowledgement process again.

93
04:44.700 --> 04:48.050
So I just reset the packet capture, so it's backed down to a reasonable number

94
04:48.050 --> 04:48.700
of packets.

95
04:48.700 --> 04:51.900
I also have a display filter just showing DHCP related traffic.

96
04:51.900 --> 04:55.800
And here on VM-30A, let me go ahead and do a then control alt delete,

97
04:55.800 --> 04:57.900
which will cause it to go ahead and do a reboot.

98
04:57.900 --> 05:00.200
And let's do the same thing for VM-30B.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

98
04:57.900 --> 05:00.200
And let's do the same thing for VM-30B.

99
05:00.200 --> 05:04.610
So here's VM-30B. Let me do a control alt delete, which will cause it to shut

100
05:04.610 --> 05:05.700
down and a reboot.

101
05:05.700 --> 05:09.100
And initiate the discover offer request process again.

102
05:09.100 --> 05:10.700
All right, that's looking good.

103
05:10.700 --> 05:13.700
And let's go to the packet capture and take a look at the results.

104
05:13.700 --> 05:15.300
So here's that captured traffic.

105
05:15.300 --> 05:16.900
So we look at the discovers, check it out.

106
05:16.900 --> 05:17.600
There's four of them.

107
05:17.600 --> 05:20.400
You might think, well, why in the world are there for?

108
05:20.400 --> 05:21.900
Well, let's take a look at the details.

109
05:21.900 --> 05:25.640
So for this first one that I'm highlighting here, we look at the tunnel end

110
05:25.640 --> 05:26.300
points here.

111
05:26.300 --> 05:29.200
It's from ES6IA going to ES6IB.

112
05:29.200 --> 05:31.900
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

112
05:29.200 --> 05:31.900
And the reason it's sent it over was because it's a broadcast.

113
05:31.900 --> 05:37.030
If you look at the next one, it's going from ES6IA over to that IP address is

114
05:37.030 --> 05:37.700
edge one.

115
05:37.700 --> 05:42.350
Now, notice here for the offer, it's coming from the IP address, the tunnel end

116
05:42.350 --> 05:43.600
point of edge one.

117
05:43.600 --> 05:47.700
That's the tunnel end point address of edge one coming back to ES6IA.

118
05:47.700 --> 05:49.400
And here we have the Geneve header.

119
05:49.400 --> 05:52.800
So if we open up the Geneve header, here is the VNI number right there.

120
05:52.800 --> 05:55.500
So it claps that and then here's the original payload.

121
05:55.500 --> 05:58.920
So from the client's perspective, it looks like this is traffic coming from 10

122
05:58.920 --> 06:01.600
30 to that's the virtual IP address
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

122
05:58.920 --> 06:01.600
30 to that's the virtual IP address

123
06:01.600 --> 06:04.900
that we set up for the DHCP services on the 1030 network

124
06:04.900 --> 06:10.520
and is destined to 1030 0.151, which is the IP address being offered to the

125
06:10.520 --> 06:10.900
client.

126
06:10.900 --> 06:15.400
So if we expand the details for the payload and the DHCP offer right here,

127
06:15.400 --> 06:17.400
that's the IP address that's being offered to the client.

128
06:17.400 --> 06:21.900
So as part of the DHCP offer, it includes the IP address, the mask,

129
06:21.900 --> 06:23.300
and we didn't supply the information.

130
06:23.300 --> 06:24.900
We're going to default gateway or DNS.

131
06:24.900 --> 06:27.000
Otherwise, it would be included here as well.

132
06:27.000 --> 06:28.500
So let me go ahead and collapse that.

133
06:28.500 --> 06:31.400
So here for the offer, the offer is unicast back.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

133
06:28.500 --> 06:31.400
So here for the offer, the offer is unicast back.

134
06:31.400 --> 06:34.700
So it's unicasting it to the IP address that's being used in the offer

135
06:34.700 --> 06:37.200
as well as the layer two address of that VM.

136
06:37.200 --> 06:40.300
And then for the request, the client is broadcasting that back.

137
06:40.300 --> 06:45.200
And as a result, it's being sent to host B, it's being sent to edge one.

138
06:45.200 --> 06:48.800
It's also being sent to edge tube based on those tunnel endpoint addresses.

139
06:48.800 --> 06:51.100
And then we have the final acknowledgement from the server.

140
06:51.100 --> 06:55.500
So this is coming from edge one based on this one endpoint address going over

141
06:55.500 --> 06:56.600
to ESXIA

142
06:56.600 --> 07:00.400
who de encapsulates it and then forwards effectively that acknowledgement back
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

142
06:56.600 --> 07:00.400
who de encapsulates it and then forwards effectively that acknowledgement back

143
07:00.400 --> 07:00.900
to the client

144
07:00.900 --> 07:01.900
back to the VM.

145
07:01.900 --> 07:04.400
So in the acknowledgement, it acknowledges that the client is going to be using

146
07:04.400 --> 07:05.700
this IP address

147
07:05.700 --> 07:07.400
with this mask right here.

148
07:07.400 --> 07:11.400
And again, any other options that we had offered like a default gateway or DNS

149
07:11.400 --> 07:11.700
server

150
07:11.700 --> 07:14.720
and so forth, if they were offered, those would be part of the acknowledgement

151
07:14.720 --> 07:15.400
as well.

152
07:15.400 --> 07:20.500
And then for the next series of discover messages, these are for VM 30 dash B.

153
07:20.500 --> 07:24.170
And again, we can confirm that just based on where these are coming from and

154
07:24.170 --> 07:24.800
going to.

155
07:24.800 --> 07:27.000
So the source is the 22 address base.

156
07:27.000 --> 07:32.400
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

156
07:27.000 --> 07:32.400
That's the tunnel endpoint for ESXIA B and it's being sent over to ESXIA.

157
07:32.400 --> 07:33.700
And it's also being sent.

158
07:33.700 --> 07:34.400
Let me clap that.

159
07:34.400 --> 07:38.600
It's also being sent to edge one and also edge to based on those tunnel

160
07:38.600 --> 07:39.700
endpoint addresses.

161
07:39.700 --> 07:41.200
And then there's an offer made.

162
07:41.200 --> 07:45.530
And if we collapse that this offer is coming from edge one based on that tunnel

163
07:45.530 --> 07:47.600
endpoint address going back to ESXIA

164
07:47.600 --> 07:51.800
B and then based on that offer, the client then does a broadcast to say,

165
07:51.800 --> 07:52.700
Yep, I'll take it.

166
07:52.700 --> 07:54.900
That's part of the request followed by an acknowledgement.

167
07:54.900 --> 07:58.400
This is the acknowledgement from edge to going back to ESXIA B.

168
07:58.400 --> 08:02.900
Now, not every single client handles DHCP the same way.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

168
07:58.400 --> 08:02.900
Now, not every single client handles DHCP the same way.

169
08:02.900 --> 08:05.100
In fact, there's a bit in the DHCP discover.

170
08:05.100 --> 08:09.000
So if we go up to one of our discovers, go ahead and grab this one right here

171
08:09.000 --> 08:11.000
and we open up the details for this discover.

172
08:11.000 --> 08:13.900
In the discover coming from the client, there's some boot P flags.

173
08:13.900 --> 08:17.000
Boot P is like the predecessor way of saying DHCP.

174
08:17.000 --> 08:20.940
And so based on the boot flags of unicast, that means the server is going to

175
08:20.940 --> 08:23.500
respond back with unicast responses.

176
08:23.700 --> 08:27.530
So as far as the offer and the acknowledgement, they are going to be unicast

177
08:27.530 --> 08:27.900
back.

178
08:27.900 --> 08:32.160
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

178
08:27.900 --> 08:32.160
If the client had said this bit to on instead of off, that would mean it's

179
08:32.160 --> 08:36.560
going to be broadcast and that would cause the DHCP server to respond with the

180
08:36.560 --> 08:41.340
offer and the acknowledgments in a layer to broadcast fashion as opposed to

181
08:41.340 --> 08:44.900
unicast back to the IP address associated with the offer.

182
08:44.900 --> 08:48.710
So again, so the behavior coming back from the server is based on what the

183
08:48.710 --> 08:51.400
client in their initial discover was asking for.

184
08:51.500 --> 08:56.270
So now that we have configured and verified segment based DHCP services for

185
08:56.270 --> 09:01.360
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

185
08:56.270 --> 09:01.360
segment 30 in the next video, let's follow up with our third implementation of

186
09:01.360 --> 09:05.900
DHCP services and that is to implement gateway based DHCP services and that's

187
09:05.900 --> 09:09.900
going to benefit segments that are directly connected to gateways.

188
09:09.900 --> 09:13.200
As is the case for segment 10 and segment 20.

189
09:13.200 --> 09:15.700
So we'll do that third piece in our next video.

190
09:15.700 --> 09:17.900
So I'll see you there in just a moment.

191
09:17.900 --> 09:27.580
[BLANK_AUDIO]