WEBVTT

1
00:00.000 --> 00:04.560
So now that we have DHCP relay services enabled for segment 10 and segment 20,

2
00:04.560 --> 00:09.000
pointing to our DHCP server up here, let's verify that it works.

3
00:09.000 --> 00:11.630
So one of the things I'm going to do is set up a wire-sharp capture at my

4
00:11.630 --> 00:12.560
management computer,

5
00:12.560 --> 00:16.590
and that way we can take a look at all the traffic regarding DHCP that's

6
00:16.590 --> 00:18.000
happening on the network.

7
00:18.000 --> 00:21.200
So to test this, let's bring up a couple VMs on each subnet.

8
00:21.200 --> 00:26.130
So let's bring up VM1 that's running on host A, and then VM4, which is running

9
00:26.130 --> 00:26.680
on host B.

10
00:26.680 --> 00:29.750
And then it'll be a good test for both of our host transport nodes and both of

11
00:29.750 --> 00:30.480
our segments.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

11
00:29.750 --> 00:30.480
our segments.

12
00:30.480 --> 00:34.400
So again, VM1 and VM4, let's power those up right now.

13
00:34.400 --> 00:38.200
So there is VM1 and there is VM4.

14
00:38.200 --> 00:40.280
Let me verify the host they're running on that looks great.

15
00:40.280 --> 00:44.020
And let's right click and go ahead and click on power, and we'll power them

16
00:44.020 --> 00:44.400
both on.

17
00:44.400 --> 00:48.800
They are DHCP clients, so they should be doing the discover messages,

18
00:48.800 --> 00:52.980
and the gateways on each of those respective subnets should be forwarding those

19
00:52.980 --> 00:53.240
.

20
00:53.240 --> 00:57.120
And we can also watch that in near real time with our packet capture right here

21
00:57.120 --> 00:57.400
.

22
00:57.400 --> 00:58.640
All right, so here we go.

23
00:58.640 --> 01:01.960
So I've got discover, discover, uh-oh.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

23
00:58.640 --> 01:01.960
So I've got discover, discover, uh-oh.

24
01:01.960 --> 01:03.840
I got a lot of discovers going on.

25
01:03.840 --> 01:06.320
Just grab this first discover right here.

26
01:06.320 --> 01:09.320
So I'm going to double click on it, and I'll give us a little more room there.

27
01:09.320 --> 01:13.600
So the first four lines here are just the system, VMware,

28
01:13.600 --> 01:17.200
forwarding the traffic over to my management computer at .151 right here.

29
01:17.200 --> 01:22.840
So this IP header right here is coming from 11, 11, 11, which is ES6IA,

30
01:22.840 --> 01:27.920
and the destination is 44, 44, 44, 44, 44, which is edge two.

31
01:27.920 --> 01:29.080
So go ahead and collapse that.

32
01:29.080 --> 01:32.320
And then our next row is the layer four protocol, UDP,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

32
01:29.080 --> 01:32.320
And then our next row is the layer four protocol, UDP,

33
01:32.320 --> 01:36.080
going to the well known port of 6081 that's being used by Geniv.

34
01:36.080 --> 01:37.600
Then we have the Geniv header.

35
01:37.600 --> 01:39.200
So there's the VNI in hex.

36
01:39.200 --> 01:44.840
And if we expand that, there's the VNI in decimal 68,609.

37
01:44.840 --> 01:46.160
So we'll collapse that.

38
01:46.160 --> 01:50.600
So based on where I'm capturing this, as far as the payload is being carried,

39
01:50.600 --> 01:53.560
this is a packet source from 10, 10, 0, 1.

40
01:53.560 --> 01:56.720
And that's the IP address on the gateway A.

41
01:56.720 --> 02:01.560
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

41
01:56.720 --> 02:01.560
And it's being forwarded to 23.1.2.1, which is the IP address of the external

42
02:01.560 --> 02:02.760
DHCP server.

43
02:02.760 --> 02:07.560
And that's going to the well known UDP server port for DHCP of UDP port 67.

44
02:07.560 --> 02:11.000
And this is the contents of that discover message.

45
02:11.000 --> 02:15.320
So there's the relay agent IP address source from the segment 10.

46
02:15.320 --> 02:16.920
Here's the MAC address right there,

47
02:16.920 --> 02:20.720
ending in D7 of my client who did the initial discover.

48
02:20.720 --> 02:22.200
If we scroll down.

49
02:22.200 --> 02:24.880
However, the problem is I see a lot of discover messages,

50
02:24.880 --> 02:27.640
but I see absolutely no offers.

51
02:27.640 --> 02:30.680
And because I am collecting this on the transport network,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

51
02:27.640 --> 02:30.680
And because I am collecting this on the transport network,

52
02:30.680 --> 02:32.600
I should see the offers as well.

53
02:32.600 --> 02:36.200
Because this traffic is going between our host transport nodes and the edge

54
02:36.200 --> 02:36.640
nodes,

55
02:36.640 --> 02:38.200
and I don't see the offers.

56
02:38.200 --> 02:41.040
So what could be causing that?

57
02:41.040 --> 02:42.280
So let's put on our thinking cap.

58
02:42.280 --> 02:44.680
So in this case, it was VM1.

59
02:44.680 --> 02:47.680
I'll cross off the IP address because it'll get whatever IP address it's given.

60
02:47.680 --> 02:52.800
So VM1, did a discover message that was logically received by this gateway,

61
02:52.800 --> 02:54.800
and then encapsulated and folded up.

62
02:54.800 --> 03:01.040
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

62
02:54.800 --> 03:01.040
So behind the scenes, it went from ESXIA, and it was sent over to the edge two.

63
03:01.040 --> 03:03.880
So as far as troubleshooting, it could be, oh, I know what it is.

64
03:03.880 --> 03:04.960
I know what it probably is.

65
03:04.960 --> 03:06.440
We'll troubleshoot this together.

66
03:06.440 --> 03:10.560
On our segments, there's a default segment profile.

67
03:10.560 --> 03:11.760
We haven't covered them yet.

68
03:11.760 --> 03:16.030
However, in this case, the segment profile, by default, that's assigned to our

69
03:16.030 --> 03:16.400
segment

70
03:16.400 --> 03:21.840
is denying any DHCP server responses that would be coming back, for example,

71
03:21.840 --> 03:25.040
from a DHCP server through a segment back to our clients.

72
03:25.040 --> 03:30.320
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

72
03:25.040 --> 03:30.320
And so that very likely is causing the failure of our DHCP response to come

73
03:30.320 --> 03:30.800
back.

74
03:30.800 --> 03:34.520
And when we set this up, it is VLAN 23 that we're using.

75
03:34.520 --> 03:37.920
Let's just take a look at the segment profile that's associated with that

76
03:37.920 --> 03:38.560
segment

77
03:38.560 --> 03:43.200
and see whether or not it's blocking server messages from a DHCP server.

78
03:43.200 --> 03:48.060
Now, by default, that's not a bad idea, actually, because if we have rogue

79
03:48.060 --> 03:48.600
clients

80
03:48.600 --> 03:52.730
or malicious clients who are trying to act as a DHCP server and lie to the

81
03:52.730 --> 03:53.200
network

82
03:53.200 --> 03:57.400
or if they just accidentally bring in a home device and it's acting as a DHCP

83
03:57.400 --> 03:58.000
server,

84
03:58.000 --> 04:02.320
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

84
03:58.000 --> 04:02.320
we want to make sure we're not allowing DHCP responses from servers that are

85
04:02.320 --> 04:03.120
not authorized.

86
04:03.120 --> 04:07.200
So let's take a closer look at this segment and also the segment profile

87
04:07.200 --> 04:08.280
associated with it.

88
04:08.280 --> 04:13.000
So to do that, in the NSX manager, we'll go to networking under connectivity,

89
04:13.000 --> 04:14.600
we'll click on segments.

90
04:14.600 --> 04:16.960
And then from here, let's take a look at this segment right here.

91
04:16.960 --> 04:19.800
This is our VLAN 23, 23.1.2.

92
04:19.800 --> 04:21.240
That's the name of the segment.

93
04:21.240 --> 04:22.360
It is VLAN backed.

94
04:22.360 --> 04:26.400
If we expand it, it's showing us that we're using VLAN 23.

95
04:26.400 --> 04:30.440
And if we scroll down, here's a section for segment profiles.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

95
04:26.400 --> 04:30.440
And if we scroll down, here's a section for segment profiles.

96
04:30.440 --> 04:32.920
And there is our problem right there.

97
04:32.920 --> 04:35.920
The segment security profile is using the default one,

98
04:35.920 --> 04:39.640
which is not allowing DHCP server responses.

99
04:39.640 --> 04:43.110
So if we minimize that and push that to the left, what we could do is we could

100
04:43.110 --> 04:43.360
go ahead

101
04:43.360 --> 04:45.040
and simply edit this segment.

102
04:45.040 --> 04:48.540
So we'll go ahead and just click on the three dots, click on edit, and then

103
04:48.540 --> 04:49.680
scroll down.

104
04:49.680 --> 04:53.120
And under segment profiles, if it's collapsed, just simply expand it.

105
04:53.120 --> 04:56.920
Then right here, we could go under segment security, use the dropdown.

106
04:56.920 --> 05:00.060
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

106
04:56.920 --> 05:00.060
And if they don't have one that we want to use, we could click right here on

107
05:00.060 --> 05:01.840
the three dots to create one.

108
05:01.840 --> 05:07.240
So let's go ahead and create a more lax and more easygoing security profile

109
05:07.240 --> 05:09.520
that will allow DHCP responses.

110
05:09.520 --> 05:13.520
Also, in fact, right here, we can click and say view to view the existing one.

111
05:13.520 --> 05:17.280
And right there, we can confirm that it's not allowing DHCP server type

112
05:17.280 --> 05:18.760
messages to be sent.

113
05:18.760 --> 05:22.560
And that's very likely why our real DHCP server who's trying to communicate

114
05:22.560 --> 05:23.400
over that segment

115
05:23.400 --> 05:26.240
is not getting their packets being sent into the network.

116
05:26.240 --> 05:28.960
So we'll go ahead and close that and click on the three dots,

117
05:28.960 --> 05:32.000
and let's create a new security segment profile.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

117
05:28.960 --> 05:32.000
and let's create a new security segment profile.

118
05:32.000 --> 05:36.080
So we'll click on create new, and we'll call this allow DHCP server messages.

119
05:36.080 --> 05:40.140
And then right here, we'll just make sure that the server block is disabled for

120
05:40.140 --> 05:42.000
DHCP for IPv4.

121
05:42.000 --> 05:44.480
And then we'll stick a quick peek and make sure we're not blocking anything

122
05:44.480 --> 05:45.360
else too important.

123
05:45.360 --> 05:47.240
Looks like we're not and we'll click on safe.

124
05:47.240 --> 05:51.960
So now under segment security, we have this allow DHCP server messages.

125
05:51.960 --> 05:54.600
Fantastic. And we'll click on safe.

126
05:54.600 --> 05:56.520
All right. And then we'll click on close.

127
05:56.520 --> 06:00.600
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

127
05:56.520 --> 06:00.600
Also, if we wanted to take a moment and actually create that profile beforehand

128
06:00.600 --> 06:04.120
with networking selected on the left, if we're under segments,

129
06:04.120 --> 06:06.440
there's a sub tab right here for profiles.

130
06:06.440 --> 06:09.000
And we could right here go ahead and create that profile.

131
06:09.000 --> 06:13.480
So there's the profile that we just made that's not blocking DHCP server

132
06:13.480 --> 06:14.440
messages.

133
06:14.440 --> 06:17.640
This is also indicated that the segment profile is also being used over here in

134
06:17.640 --> 06:18.280
the assigned two.

135
06:18.280 --> 06:21.200
If we click on the assigned two and click on this hyperlink,

136
06:21.200 --> 06:23.080
it's going to show us where it's currently being applied.

137
06:23.080 --> 06:27.000
So it's applied to our segment called VLAN 232312.

138
06:27.000 --> 06:28.080
All right. So fantastic.

139
06:28.080 --> 06:31.590
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

139
06:28.080 --> 06:31.590
So if that was causing us a problem, it should no longer be causing us a

140
06:31.590 --> 06:32.200
problem.

141
06:32.200 --> 06:36.640
So let's go back to wire shark and let me go ahead and click on the last packet

142
06:36.640 --> 06:36.640
.

143
06:36.640 --> 06:42.120
And I still see nothing but discover, discover, discover.

144
06:42.120 --> 06:45.080
Let me go ahead and let me kickstart a couple of our clients.

145
06:45.080 --> 06:48.520
So here for VM one, let me go ahead and launch a remote console for that one.

146
06:48.520 --> 06:51.400
And then we also launch a remote console for VM four.

147
06:51.400 --> 06:54.040
And that way we can bring them up side by side.

148
06:54.040 --> 06:55.480
Well, those consoles are coming up.

149
06:55.480 --> 06:57.320
Let me bring back my wire shark.

150
06:57.320 --> 06:59.080
So here's wire shark down here.

151
06:59.080 --> 07:01.160
I have over 300,000 packets.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

151
06:59.080 --> 07:01.160
I have over 300,000 packets.

152
07:01.160 --> 07:05.720
So I'm going to go ahead and stop the capture and then started again

153
07:05.720 --> 07:09.800
and click on continue without saving and I'll have the same filter in place.

154
07:09.800 --> 07:12.440
Looking for just GRE traffic that's coming in.

155
07:12.440 --> 07:16.440
And I also have the display filter only showing DHCP related traffic.

156
07:16.440 --> 07:19.240
And all I still see here are discover messages only.

157
07:20.120 --> 07:25.880
So let me go ahead and reboot VM one and reboot VM four.

158
07:25.880 --> 07:29.160
So that'll do a graceful shutdown and restart them.

159
07:29.160 --> 07:32.360
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

159
07:29.160 --> 07:32.360
And I just want to validate whether or not they can get an IP address and

160
07:32.360 --> 07:34.040
survey says, no.

161
07:34.040 --> 07:38.040
So I have some new discover messages, but no offers in place.

162
07:38.040 --> 07:39.960
Hmm curious.

163
07:39.960 --> 07:41.400
What else could it be?

164
07:41.400 --> 07:44.520
And now we enter the troubleshooting stage of our demonstration.

165
07:44.520 --> 07:46.120
So what else could it be?

166
07:46.120 --> 07:49.240
So we modified our segment profile for security.

167
07:49.240 --> 07:52.360
So it's allowing DHCP server messages to come back.

168
07:52.360 --> 07:54.760
We verified that this server is reachable.

169
07:54.760 --> 07:59.400
We verified with the packet capture that the actual traffic is being sent.

170
07:59.400 --> 08:01.240
Oh, I know what it is.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

170
07:59.400 --> 08:01.240
Oh, I know what it is.

171
08:01.240 --> 08:07.070
In a previous skill, we took a look at the world of network address translation

172
08:07.070 --> 08:07.080
.

173
08:07.080 --> 08:10.440
And we currently have SNAT source NAT in place.

174
08:10.440 --> 08:14.680
And the rule I think we have set up says a traffic source from 10 anything.

175
08:14.680 --> 08:18.920
Go ahead and swap it out to an IP address in the 2312 address space.

176
08:18.920 --> 08:23.880
Now the challenge with that is that even though the payload for the DHCP

177
08:23.880 --> 08:24.600
discover

178
08:24.600 --> 08:27.080
has the information about the client and their layer two address and all that

179
08:27.080 --> 08:27.800
good stuff.

180
08:27.800 --> 08:32.040
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

180
08:27.800 --> 08:32.040
And also as part of that payload, it also includes the source IP address here

181
08:32.040 --> 08:33.320
of the gateway A.

182
08:33.320 --> 08:38.920
The actual packet that's being sent, it's outside IP address of 10 10 0.1 is

183
08:38.920 --> 08:40.200
going to be swapped out.

184
08:40.200 --> 08:43.320
And when the DHCP server at least this DHCP server sees that,

185
08:43.320 --> 08:45.160
it's very likely saying, hey, that doesn't match up.

186
08:45.160 --> 08:50.800
This DHCP discover message came in from this relay that claims to be on the 10

187
08:50.800 --> 08:51.640
10 0 network.

188
08:51.640 --> 08:55.080
But the source address was something in the 23 address space.

189
08:55.080 --> 08:59.590
And that may be why this DHCP server couldn't find a correct IP address because

190
08:59.590 --> 08:59.880
it doesn't

191
08:59.880 --> 09:01.480
have a pool in the 23 address space.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

191
08:59.880 --> 09:01.480
have a pool in the 23 address space.

192
09:01.480 --> 09:03.320
It only has pools for 10 10 and 10 20.

193
09:03.320 --> 09:06.200
So let's do this as a temporary test.

194
09:06.200 --> 09:10.120
Let's verify if we currently have net rules in place, which I believe we do.

195
09:10.120 --> 09:14.040
Let's also verify if they're currently being hit. And if they are, let's just

196
09:14.040 --> 09:14.840
disable our net

197
09:14.840 --> 09:18.860
rule right here temporarily and then verify whether or not the gateways without

198
09:18.860 --> 09:19.800
having that net done

199
09:19.800 --> 09:23.840
on their source IP address to verify if that fixes the problem. Also, before we

200
09:23.840 --> 09:24.520
make that change,

201
09:24.520 --> 09:28.710
I just want to verify that as I scroll through here, we have no DHCP offers or

202
09:28.710 --> 09:29.800
anything else.

203
09:29.800 --> 09:34.600
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

203
09:29.800 --> 09:34.600
So let me go ahead and stop the capture because I'm currently at 85,000 packets

204
09:34.600 --> 09:34.600
.

205
09:34.600 --> 09:38.780
And let me start a new one with all the same details and it'll give us a nice

206
09:38.780 --> 09:39.480
fresh start.

207
09:39.480 --> 09:44.010
So again, as a before and after test, let me just reboot both of these little V

208
09:44.010 --> 09:44.600
Ms

209
09:44.600 --> 09:46.840
that should trigger the discover process.

210
09:46.840 --> 09:51.400
And I just want to verify before we make the net change that we are not getting

211
09:51.400 --> 09:51.880
offers.

212
09:51.880 --> 09:54.680
So those should show up here in just a moment.

213
09:54.680 --> 09:59.560
All right. So there's failure, failure, failure. All right, no offers.

214
09:59.560 --> 10:02.200
Discover is only. All right. So let's minimize that.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

214
09:59.560 --> 10:02.200
Discover is only. All right. So let's minimize that.

215
10:02.200 --> 10:07.240
Minimize VM1, minimize VM2, and let's go to the NSX manager.

216
10:07.240 --> 10:11.900
So here at the NSX manager with the networking tab on top selected on the left

217
10:11.900 --> 10:12.360
under network

218
10:12.360 --> 10:17.080
services, we'll click on that. And sure enough, we have a source net rule.

219
10:17.080 --> 10:19.800
I'm going to collapse the left hand side. It gives a little more room here.

220
10:19.800 --> 10:23.780
And let's just click on the little icon to see whether or not we currently have

221
10:23.780 --> 10:24.760
a lot of hits

222
10:24.760 --> 10:28.520
on that net rule. So we'll click on the icon for statistics.

223
10:28.520 --> 10:32.120
And currently it shows active session zero. If we refresh this, in fact,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

223
10:28.520 --> 10:32.120
And currently it shows active session zero. If we refresh this, in fact,

224
10:32.120 --> 10:35.080
let me go ahead and bring back a client by a reboot of client.

225
10:35.080 --> 10:39.480
So go ahead and reboot client one there. And if I do a refresh and refresh,

226
10:39.480 --> 10:43.120
I just want to verify that that's triggering. And there we go. There's one

227
10:43.120 --> 10:43.720
active session.

228
10:43.720 --> 10:49.450
So unfortunately the DHCP relay, because it's going out the same interface that

229
10:49.450 --> 10:49.800
we're using

230
10:49.800 --> 10:53.670
that on, it's swapping out that source address. And that's confusing my DHCP

231
10:53.670 --> 10:54.280
server.

232
10:54.280 --> 10:57.640
So let me go ahead and close that. And what we'll do is simply as a test,

233
10:57.640 --> 11:01.560
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

233
10:57.640 --> 11:01.560
let me go ahead and click on the three dots for this net rule, click on edit.

234
11:01.560 --> 11:06.360
And again, just as a test, I'm going to disable it, scroll down, click on save,

235
11:06.360 --> 11:10.440
and then click here on refresh. And it is no longer enabled.

236
11:10.440 --> 11:13.240
So now that we've done that, let's bring back our packet capture. Oh, look at

237
11:13.240 --> 11:13.800
that. Yeah.

238
11:13.800 --> 11:18.760
And here we go. Okay, fantastic. So that's the difference.

239
11:18.760 --> 11:24.280
So we did two things. We actually modified the segment security profile to tell

240
11:24.280 --> 11:24.760
it to allow

241
11:24.760 --> 11:31.820
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

241
11:24.760 --> 11:31.820
DHCP responses. And we also exempted the source IP address for the DHCP relay

242
11:31.820 --> 11:32.840
from being address

243
11:32.840 --> 11:35.960
translated. So it's now showing up as coming from a trill address. So this is

244
11:35.960 --> 11:37.560
coming from Gateway B

245
11:37.560 --> 11:42.210
10, 20, 01. And this is coming from Gateway A at 10, 10, 01. And then we have

246
11:42.210 --> 11:42.920
that followed up with

247
11:42.920 --> 11:46.870
an offer and then a request and then the final acknowledgement. So if we look

248
11:46.870 --> 11:47.640
at this offer

249
11:47.640 --> 11:51.700
right here, and we expand the details, here's what we expect the client to have

250
11:51.700 --> 11:52.920
. So the offer

251
11:52.920 --> 11:57.680
effectively is the 10, 10, 0151 address. There's the MAC address of our client

252
11:57.680 --> 11:59.000
ending in D seven.

253
11:59.000 --> 12:04.190
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

253
11:59.000 --> 12:04.190
And as far as the subnet, if we look at that, it's a 24 bit mask right there.

254
12:04.190 --> 12:05.000
If we open up the

255
12:05.000 --> 12:09.330
option for the default gateway, that's 10, 10, 01. So if we look at VM one

256
12:09.330 --> 12:11.000
right now, it should have

257
12:11.000 --> 12:14.160
this specific information. And for the DNS server, let's see if we assign one

258
12:14.160 --> 12:15.960
sure enough, there's 888.

259
12:15.960 --> 12:21.240
So if we bring in VM one, and let's do an IF config for ethernet zero, press

260
12:21.240 --> 12:22.360
enter. Sure enough,

261
12:22.360 --> 12:26.370
10, 10, 0151 fantastic. And if we do a route dash and take a look at the

262
12:26.370 --> 12:27.160
routing table,

263
12:27.160 --> 12:30.760
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

263
12:27.160 --> 12:30.760
our default gateway is 10, 10, 01. And if we try to go up to the internet,

264
12:30.760 --> 12:34.840
because we no longer have net, that's not going to be too convenient. But you

265
12:34.840 --> 12:35.320
know what, let's do

266
12:35.320 --> 12:39.190
this. Let's just go ahead and now that we have an IP address, let's go ahead

267
12:39.190 --> 12:40.040
and enable our

268
12:40.040 --> 12:44.060
net role. So I'll click on edit and enable the net role that we have an IP

269
12:44.060 --> 12:45.880
address, click on save,

270
12:45.880 --> 12:49.620
click on refresh there, fantastic. And let's go back to our client. So now with

271
12:49.620 --> 12:50.120
our client,

272
12:50.120 --> 12:54.590
if we do something like a ping to www.google.com, and that works, that's

273
12:54.590 --> 12:55.800
fantastic. That verifies

274
12:55.800 --> 12:59.240
a couple things for us. Number one, verifies that DNS is working. It also ver

275
12:59.240 --> 13:00.360
ifies we have internet
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

275
12:59.240 --> 13:00.360
ifies we have internet

276
13:00.360 --> 13:04.120
access. Now, as far as a long term solution here, I would want to go ahead and

277
13:04.120 --> 13:04.760
create an

278
13:04.760 --> 13:08.290
exemption. A more specific rule, it says, Hey, if traffic is coming from, for

279
13:08.290 --> 13:09.400
example, 10, 10,

280
13:09.400 --> 13:14.760
01 going to the IP address of the DHCP server, please don't net it. And that'd

281
13:14.760 --> 13:15.400
be a role of a

282
13:15.400 --> 13:20.380
type no SDAP, sit up an exemption for that. Or I could just use a different

283
13:20.380 --> 13:21.000
DHCP server.

284
13:21.000 --> 13:24.480
That's not on that same external segment where I happen to be using network

285
13:24.480 --> 13:25.400
address translation.

286
13:25.400 --> 13:29.200
Either way would be great. All right, so in preparation for the next

287
13:29.200 --> 13:29.960
demonstration,

288
13:29.960 --> 13:33.990
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

288
13:29.960 --> 13:33.990
where we're going to set up segment based DHCP services, I would like to remove

289
13:33.990 --> 13:34.680
all the DHCP

290
13:34.680 --> 13:37.820
that we configured to this point, that'd be a good reminder of what we just

291
13:37.820 --> 13:39.000
configured. So for

292
13:39.000 --> 13:43.480
each of the segments, we went into the segments one by one, and we clicked on

293
13:43.480 --> 13:44.760
edit, and we clicked

294
13:44.760 --> 13:49.550
right here on edit DHCP config to specify the profile for the DHCP relay. I'm

295
13:49.550 --> 13:49.880
going to go ahead

296
13:49.880 --> 13:54.220
and delete that right here. So for segment 10, that is now gone after I click

297
13:54.220 --> 13:55.480
on save and close,

298
13:55.480 --> 13:59.190
and we'll do the same thing for segment 20. We'll edit it over here on the

299
13:59.190 --> 14:00.440
right. We'll click on
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

299
13:59.190 --> 14:00.440
right. We'll click on

300
14:00.440 --> 14:06.440
delete DHCP config, delete, scroll down, click on save, close editing. And then

301
14:06.440 --> 14:07.160
now on the left

302
14:07.160 --> 14:12.380
hand side, if we go down to settings and networking profiles and click on DHCP,

303
14:12.380 --> 14:13.160
it should now show

304
14:13.160 --> 14:17.820
that this DHCP relay profile is no longer in use anywhere. So the where used

305
14:17.820 --> 14:19.160
has a count of zero.

306
14:19.160 --> 14:23.160
So I'm going to go ahead and delete it as well. So click on delete and delete.

307
14:23.160 --> 14:23.560
And we've now

308
14:23.560 --> 14:27.860
removed all of our DHCP services. So for DHCP relay, we planned it out, we

309
14:27.860 --> 14:28.840
configured it,

310
14:28.840 --> 14:31.870
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

310
14:28.840 --> 14:31.870
we troubleshot it, and we verified it. So in the next video, we're going to

311
14:31.870 --> 14:33.000
move to the next step,

312
14:33.000 --> 14:36.790
and that is to create a new segment, we'll create segment 30, and we'll set up

313
14:36.790 --> 14:38.040
segment based DHCP

314
14:38.040 --> 14:42.930
services for a segment that has absolutely none of our gateways directly

315
14:42.930 --> 14:44.120
connected to it.

316
14:44.120 --> 14:46.440
So I'll see you in the next video for exactly that.

317
14:46.440 --> 14:56.140
[BLANK_AUDIO]