WEBVTT

1
00:00.000 --> 00:04.920
Or our discussion regarding an NSX Federation, let's imagine we have two sites.

2
00:04.920 --> 00:09.520
Now these sites could represent, for example, two geographical locations with a

3
00:09.520 --> 00:10.120
data center

4
00:10.120 --> 00:12.520
in each or in a campus environment.

5
00:12.520 --> 00:15.480
It could represent two different buildings with two separate data centers or it

6
00:15.480 --> 00:15.640
could

7
00:15.640 --> 00:19.040
even represent two different racks in the same data center.

8
00:19.040 --> 00:21.040
And the question is, how do we go ahead and manage all that?

9
00:21.040 --> 00:25.850
Now one option is we could use a single NSX manager and have that single NSX

10
00:25.850 --> 00:26.480
manager

11
00:26.480 --> 00:29.120
manage the NSX environment at both sites.

12
00:29.120 --> 00:32.320
Now one caveat is that if we have an ESXI host over here, we'll call it ESXI
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

12
00:29.120 --> 00:32.320
Now one caveat is that if we have an ESXI host over here, we'll call it ESXI

13
00:32.320 --> 00:33.680
host A.

14
00:33.680 --> 00:35.360
That's running this VM right there.

15
00:35.360 --> 00:39.770
And we have another ESXI host, call it ESXI host Y that's supporting that VM

16
00:39.770 --> 00:41.040
right there.

17
00:41.040 --> 00:43.530
So if these two VMs needed to communicate with each other, maybe this is an

18
00:43.530 --> 00:44.040
application

19
00:44.040 --> 00:46.520
server here and it is the database server.

20
00:46.520 --> 00:50.210
If they're communicating back and forth, these two ESXI hosts in the background

21
00:50.210 --> 00:50.600
are going

22
00:50.600 --> 00:54.450
to be using Genev tunneling and saying that traffic back and forth between them

23
00:54.450 --> 00:54.520
.

24
00:54.520 --> 00:57.090
And to support that, as we've talked about previously, we're going to use a

25
00:57.090 --> 00:57.560
larger than

26
00:57.560 --> 01:01.600
normal MTU that needs to be supported between those two ESXI host.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

26
00:57.560 --> 01:01.600
normal MTU that needs to be supported between those two ESXI host.

27
01:01.600 --> 01:04.630
So if we're going to have a single NSX manager manage this entire topology here

28
01:04.630 --> 01:05.120
with both

29
01:05.120 --> 01:09.350
sites, we need to make sure that we're supporting a larger than normal MTU for

30
01:09.350 --> 01:10.040
ethernet, for

31
01:10.040 --> 01:14.720
example, 1700 bytes at least on the transport network to forward that traffic.

32
01:14.720 --> 01:18.320
We'd also make sure that our latency is less than or equal to the required

33
01:18.320 --> 01:19.120
minimums between

34
01:19.120 --> 01:23.420
the NSX manager and the transport nodes here and also the edge nodes that would

35
01:23.420 --> 01:23.720
be in

36
01:23.720 --> 01:24.720
both locations.

37
01:24.720 --> 01:28.310
And if we had really low latency, like 10 milliseconds or less, we could also

38
01:28.310 --> 01:28.720
spread

39
01:28.720 --> 01:31.000
our NSX managers across these two sites.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

39
01:28.720 --> 01:31.000
our NSX managers across these two sites.

40
01:31.000 --> 01:34.790
So in our cluster of NSX managers, maybe we have one or two here at site one

41
01:34.790 --> 01:35.280
and one

42
01:35.280 --> 01:36.600
over here at site two.

43
01:36.600 --> 01:40.790
So as long as we have the latency dialed in with what's needed for NSX between

44
01:40.790 --> 01:41.360
the NSX

45
01:41.360 --> 01:45.580
managers and a cluster and also the NSX manager and their transport and edge

46
01:45.580 --> 01:46.560
nodes, along with

47
01:46.560 --> 01:50.690
the larger than normal MTU, we could use one NSX manager to manage the entire

48
01:50.690 --> 01:51.440
environment

49
01:51.440 --> 01:53.960
here, both site one and site two.

50
01:53.960 --> 01:57.720
And in a single data center, for example, with high speed top of rack switches,

51
01:57.720 --> 01:58.440
that is absolutely

52
01:58.440 --> 01:59.440
no problem.

53
01:59.440 --> 02:03.770
However, what is a problem is if site one is in one part of the country and
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

53
01:59.440 --> 02:03.770
However, what is a problem is if site one is in one part of the country and

54
02:03.770 --> 02:04.560
site two is

55
02:04.560 --> 02:07.570
in a different part of the country or in a different country and doesn't have

56
02:07.570 --> 02:08.040
support

57
02:08.040 --> 02:11.740
for a larger MTU and as a result of being in two separate locations with maybe

58
02:11.740 --> 02:12.280
not the

59
02:12.280 --> 02:16.470
optimal connectivity, perhaps our latency doesn't meet the requirements as well

60
02:16.470 --> 02:16.560
.

61
02:16.560 --> 02:19.910
So how do we get around that if we have site one, for example, on site two in

62
02:19.910 --> 02:20.360
different

63
02:20.360 --> 02:23.880
locations where the MTU and latency requirements aren't in place?

64
02:23.880 --> 02:28.600
Well, the answer my friend is dah-da-da-da, setting up an NSX federation.

65
02:28.600 --> 02:31.340
So let's clear up the screen just a little bit and let's take a look at how NSX
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

65
02:28.600 --> 02:31.340
So let's clear up the screen just a little bit and let's take a look at how NSX

66
02:31.340 --> 02:31.920
federations

67
02:31.920 --> 02:34.040
can help us with this scenario.

68
02:34.040 --> 02:38.260
So with NSX federation, we'd implement NSX management individually or locally

69
02:38.260 --> 02:38.760
at each

70
02:38.760 --> 02:39.760
site.

71
02:39.760 --> 02:43.240
So this is the local manager, but LM for short there here at site one and at

72
02:43.240 --> 02:43.920
site two, we

73
02:43.920 --> 02:46.280
have the local manager here at site two.

74
02:46.280 --> 02:50.790
So part of the NSX federation is having local managers at each site and then on

75
02:50.790 --> 02:51.920
top of that,

76
02:51.920 --> 02:54.360
we are going to implement a global manager.

77
02:54.360 --> 02:58.100
So I'll name this global manager NSX manager dash global and we kind of think

78
02:58.100 --> 02:58.800
of the global

79
02:58.800 --> 03:00.400
manager like an org chart.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

79
02:58.800 --> 03:00.400
manager like an org chart.

80
03:00.400 --> 03:03.480
So for example, right here, if this is the global manager right here and then

81
03:03.480 --> 03:04.080
below that

82
03:04.080 --> 03:07.320
global manager, we'd have the local manager for site one.

83
03:07.320 --> 03:11.770
I'll draw that in here in blue to color code that little arrow there as well as

84
03:11.770 --> 03:12.440
the NSX

85
03:12.440 --> 03:16.160
manager over here at site two and I'll draw the little arrow there as well.

86
03:16.160 --> 03:19.960
So we can think of this global NSX manager as a manager of manager.

87
03:19.960 --> 03:24.540
So this global manager would be responsible for the local manager here at site

88
03:24.540 --> 03:25.040
one and

89
03:25.040 --> 03:27.760
also the local manager here at site two.

90
03:27.760 --> 03:30.960
Now at this point in our story, you might think, well, how does that help us
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

90
03:27.760 --> 03:30.960
Now at this point in our story, you might think, well, how does that help us

91
03:30.960 --> 03:32.040
with connectivity,

92
03:32.040 --> 03:34.840
for example, from this VM over to this VM?

93
03:34.840 --> 03:39.320
So let's say this is VM one over here and over here, we have VM 21.

94
03:39.320 --> 03:43.040
And if we want them to be on a common network segment, let's say segment 50

95
03:43.040 --> 03:43.720
here and be

96
03:43.720 --> 03:47.020
able to communicate back and forth logically on this one logical segment, how

97
03:47.020 --> 03:47.480
do we pull

98
03:47.480 --> 03:48.480
that off?

99
03:48.480 --> 03:52.660
And the answer to that is we are going to implement gateways and also segments

100
03:52.660 --> 03:52.900
that are

101
03:52.900 --> 03:57.480
stretched or common across our multiple sites that are implemented by the

102
03:57.480 --> 03:58.960
global NSX manager.

103
03:58.960 --> 04:02.090
So from the global manager, once we create a gateway and a segment, that
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

103
03:58.960 --> 04:02.090
So from the global manager, once we create a gateway and a segment, that

104
04:02.090 --> 04:02.760
segment will

105
04:02.760 --> 04:05.320
then be available to both of the sites.

106
04:05.320 --> 04:09.760
So in vSphere and the vSphere client, the administrator can add VMs to segment

107
04:09.760 --> 04:10.480
50 here

108
04:10.480 --> 04:14.580
and segment 50 over here at site two and then logically they are on the same

109
04:14.580 --> 04:15.320
segment.

110
04:15.320 --> 04:18.010
Now to pull this off, we're once again going to be used tunneling and that

111
04:18.010 --> 04:18.560
tunneling is

112
04:18.560 --> 04:21.680
going to be done from the edges at each of the sites.

113
04:21.680 --> 04:25.380
So for traffic from this VM one to VM 21 and back and forth, that tunneling

114
04:25.380 --> 04:26.360
would happen

115
04:26.360 --> 04:30.280
on the edge nodes from site one and the edge nodes here on site two.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

115
04:26.360 --> 04:30.280
on the edge nodes from site one and the edge nodes here on site two.

116
04:30.280 --> 04:33.470
And for those intersite tunnels between site one and site two, they're not

117
04:33.470 --> 04:33.960
going to use

118
04:33.960 --> 04:36.240
their normal tunnel endpoint addresses.

119
04:36.240 --> 04:39.770
They're going to go ahead and use something called R taps remote tunnel end

120
04:39.770 --> 04:40.360
points.

121
04:40.360 --> 04:44.070
So as part of our deployment of NSX Federation, we are going to add an

122
04:44.070 --> 04:45.800
additional set of addresses

123
04:45.800 --> 04:50.800
on these edge nodes for the benefit of tunneling traffic between sites.

124
04:50.800 --> 04:53.940
So that's going to apply to two sites here or we could expand this to three or

125
04:53.940 --> 04:54.240
four or

126
04:54.240 --> 04:55.240
ten sites.

127
04:55.240 --> 04:58.750
In either case, for more tunneling traffic between two sites, that's done using

128
04:58.750 --> 04:59.000
the

129
04:59.000 --> 05:01.320
R tap addresses on the edge nodes.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

129
04:59.000 --> 05:01.320
R tap addresses on the edge nodes.

130
05:01.320 --> 05:03.370
And let me clean this up just a little bit and let me show you another way of

131
05:03.370 --> 05:03.760
looking at

132
05:03.760 --> 05:04.760
this.

133
05:04.760 --> 05:07.760
So here is our local management cluster here at site one.

134
05:07.760 --> 05:10.120
Here's our local management cluster at site two.

135
05:10.120 --> 05:12.630
Here's our global manager and then from the global manager, we can deploy, for

136
05:12.630 --> 05:13.040
example,

137
05:13.040 --> 05:14.040
a gateway.

138
05:14.040 --> 05:17.700
It could be a tier zero or a tier zero and a tier one, along with segments that

139
05:17.700 --> 05:18.120
those

140
05:18.120 --> 05:19.720
gateways are connected to.

141
05:19.720 --> 05:23.480
And those are stretched or logically available across both sites.

142
05:23.480 --> 05:27.260
So if we create, for example, a tier zero gateway and specify that we want that

143
05:27.260 --> 05:27.600
to be

144
05:27.600 --> 05:31.190
available at site one and site two, those show up and are available at those
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

144
05:27.600 --> 05:31.190
available at site one and site two, those show up and are available at those

145
05:31.190 --> 05:31.640
sites in

146
05:31.640 --> 05:34.760
combination with any segments that are connected to those gateways.

147
05:34.760 --> 05:38.700
So effectively, we have gateways and segments that are stretched or available

148
05:38.700 --> 05:39.600
across multiple

149
05:39.600 --> 05:40.600
sites.

150
05:40.600 --> 05:43.690
And then the administrator with vSphere Clank can go ahead and associate VMs

151
05:43.690 --> 05:44.520
with that segment

152
05:44.520 --> 05:48.240
as their network connection and then boom, these VMs, the one over here at site

153
05:48.240 --> 05:48.680
one and

154
05:48.680 --> 05:52.160
the one over here at site two, we'll call that VM 21.

155
05:52.160 --> 05:54.440
They are now logically connected to the same segment.

156
05:54.440 --> 05:57.960
And then for traffic between them, the edges would be using their remote tunnel

157
05:57.960 --> 05:58.520
endpoints

158
05:58.520 --> 06:00.600
to tell about traffic back and forth.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

158
05:58.520 --> 06:00.600
to tell about traffic back and forth.

159
06:00.600 --> 06:04.000
And one of the big benefits of having an NSX federation set up like this is

160
06:04.000 --> 06:04.600
that we don't

161
06:04.600 --> 06:09.080
have to worry about supporting an excessively large MTU between site one and

162
06:09.080 --> 06:10.120
site two because

163
06:10.120 --> 06:14.840
with NSX federation, the actual remote tunnel endpoints can fragment the data.

164
06:14.840 --> 06:20.560
So the edges don't have to support, for example, a 1700 byte MTU between them.

165
06:20.560 --> 06:24.630
They can fragment and chop up those segments into smaller chunks and send them

166
06:24.630 --> 06:24.920
over to

167
06:24.920 --> 06:26.280
the other edge.

168
06:26.280 --> 06:29.020
Another big benefit is that because we have site one with its own local manager

169
06:29.020 --> 06:29.400
and site

170
06:29.400 --> 06:33.030
two, the zone local manager, as they interact with their own edges, they can
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

170
06:29.400 --> 06:33.030
two, the zone local manager, as they interact with their own edges, they can

171
06:33.030 --> 06:33.600
use their high

172
06:33.600 --> 06:35.040
speed connectivity.

173
06:35.040 --> 06:39.380
And we don't have that requirement of having a less than or equal to 10

174
06:39.380 --> 06:40.720
millisecond latency

175
06:40.720 --> 06:44.800
between the global manager and the edges because those edges are still being

176
06:44.800 --> 06:45.280
managed

177
06:45.280 --> 06:46.960
by their local manager.

178
06:46.960 --> 06:50.980
So at the NSX federation, we've just removed that concern because we don't have

179
06:50.980 --> 06:51.560
the 10

180
06:51.560 --> 06:55.100
millisecond requirement between the global manager and the edges because those

181
06:55.100 --> 06:55.440
edges

182
06:55.440 --> 06:58.320
are being managed locally here by their local managers.

183
06:58.320 --> 07:02.650
And we also don't need a really big MTU between the edges because of the
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

183
06:58.320 --> 07:02.650
And we also don't need a really big MTU between the edges because of the

184
07:02.650 --> 07:03.920
fragmentation that

185
07:03.920 --> 07:06.840
they're allowed to do with the remote tunnel endpoint addresses.

186
07:06.840 --> 07:09.520
So that's also been addressed here with the NSX federation.

187
07:09.520 --> 07:11.080
And I really appreciate the beauty of this.

188
07:11.080 --> 07:12.400
Here's what you and I get to do.

189
07:12.400 --> 07:17.410
In the next video, let's put a game plan in place to implement NSX federation

190
07:17.410 --> 07:17.880
with two

191
07:17.880 --> 07:20.280
sites and a global manager.

192
07:20.280 --> 07:24.550
And then with that game plan in place, we can proceed to implement and verify

193
07:24.550 --> 07:25.480
NSX federation

194
07:25.480 --> 07:26.560
in this skill.

195
07:26.560 --> 07:29.760
So I'll see you in the next video, as we put a specific game plan together.