WEBVTT

1
00:00.000 --> 00:08.240
So let's begin by looking at the centralized internet gateway model, which

2
00:08.240 --> 00:09.820
honestly is

3
00:09.820 --> 00:14.440
essentially a new name on an old design.

4
00:14.440 --> 00:19.350
This is sort of the way that we have been running WANs in the IT field for

5
00:19.350 --> 00:20.280
decades, which

6
00:20.280 --> 00:24.610
is basically we have some form of a central location, be that maybe

7
00:24.610 --> 00:26.320
headquarters or a data

8
00:26.320 --> 00:31.040
center of some sort, and then all of our branch offices connect back to that
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

8
00:26.320 --> 00:31.040
center of some sort, and then all of our branch offices connect back to that

9
00:31.040 --> 00:33.040
central location,

10
00:33.040 --> 00:37.760
and then through that central location, that's where we go out to the internet.

11
00:37.760 --> 00:42.600
Now of course, like most things, there are pros and cons to every design.

12
00:42.600 --> 00:46.680
So let's jump in and take a look at some of the details of this design, as well

13
00:46.680 --> 00:47.120
as some

14
00:47.120 --> 00:51.640
of its advantages and disadvantages to some more modern designs.

15
00:51.640 --> 00:56.000
So let's go ahead and take a closer look.

16
00:56.000 --> 01:03.700
So as we mentioned during the introduction, the centralized internet gateway or
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

16
00:56.000 --> 01:03.700
So as we mentioned during the introduction, the centralized internet gateway or

17
01:03.700 --> 01:04.200
CIG is

18
01:04.200 --> 01:07.400
the proven sort of traditional design.

19
01:07.400 --> 01:13.480
Again, the basic idea here is of course we have the internet out there, we have

20
01:13.480 --> 01:13.720
our

21
01:13.720 --> 01:19.970
internet connection going out to some form of a central location, maybe this is

22
01:19.970 --> 01:20.840
something

23
01:20.840 --> 01:26.940
like headquarters, then we have our remote sites out there, and those remote

24
01:26.940 --> 01:27.640
sites all

25
01:27.640 --> 01:33.240
connect in with some form of a WAN circuit.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

25
01:27.640 --> 01:33.240
connect in with some form of a WAN circuit.

26
01:33.240 --> 01:38.380
So essentially what that means is that for a branch office to connect out to

27
01:38.380 --> 01:39.160
anything

28
01:39.160 --> 01:44.670
on the internet, it's going to go across this WAN circuit to headquarters and

29
01:44.670 --> 01:46.200
then headquarters

30
01:46.200 --> 01:48.120
out to the cloud.

31
01:48.120 --> 01:51.720
So overall, this is the design we're talking about.

32
01:51.720 --> 01:54.800
And again, this is a very traditional design.

33
01:54.800 --> 02:00.080
This is how we've sort of been running our networks for a very, very long time.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

33
01:54.800 --> 02:00.080
This is how we've sort of been running our networks for a very, very long time.

34
02:00.080 --> 02:05.270
So again, as we said, this was all about those remote or branch office sites

35
02:05.270 --> 02:05.640
connecting

36
02:05.640 --> 02:08.560
into some form of a central site.

37
02:08.560 --> 02:10.920
Now of course, that central site's going to vary.

38
02:10.920 --> 02:13.320
It's going to depend on the size of the company.

39
02:13.320 --> 02:16.550
But generally speaking, it's going to be something like a headquarters site,

40
02:16.550 --> 02:17.080
like where

41
02:17.080 --> 02:21.770
the corporate headquarters is located, or if you have one, and not of course,

42
02:21.770 --> 02:22.800
all enterprises

43
02:22.800 --> 02:28.000
do, but if there is like a primary data center, that might also be the central

44
02:28.000 --> 02:29.880
point of connectivity.

45
02:29.880 --> 02:34.420
What you really want to do is look at the traffic flow on your network and sort
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

45
02:29.880 --> 02:34.420
What you really want to do is look at the traffic flow on your network and sort

46
02:34.420 --> 02:34.920
of figure

47
02:34.920 --> 02:40.590
out where most of the internal traffic is going anyway, and then use that as

48
02:40.590 --> 02:41.440
the branch

49
02:41.440 --> 02:43.360
off for the internet.

50
02:43.360 --> 02:48.760
And quite commonly, that's going to be wherever most of those WAN circuits

51
02:48.760 --> 02:49.880
already go.

52
02:49.880 --> 02:53.040
So again, you're already going to have these existing WAN circuits.

53
02:53.040 --> 02:54.760
That's sort of the idea.

54
02:54.760 --> 02:56.560
Well, where do they go?

55
02:56.560 --> 03:00.300
They're going to go probably to one of these two locations, whichever one the
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

55
02:56.560 --> 03:00.300
They're going to go probably to one of these two locations, whichever one the

56
03:00.300 --> 03:01.000
majority of

57
03:01.000 --> 03:06.500
those go to would be the one that would make sense to be this central site that

58
03:06.500 --> 03:07.280
's going

59
03:07.280 --> 03:10.000
to act as our internet gateway.

60
03:10.000 --> 03:13.830
Now of course, we haven't really talked too much about those WAN circuits, but

61
03:13.830 --> 03:14.200
this is

62
03:14.200 --> 03:17.920
going to be some form of a private WAN connection.

63
03:17.920 --> 03:22.600
And of course, we have had a bunch of different options over the years, but it

64
03:22.600 --> 03:23.440
could be really

65
03:23.440 --> 03:24.560
anything.

66
03:24.560 --> 03:27.520
We could have something like an IPsec tunnel.

67
03:27.520 --> 03:30.920
We could have just a traditional VPN.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

67
03:27.520 --> 03:30.920
We could have just a traditional VPN.

68
03:30.920 --> 03:34.520
And in case you're wondering, why is IPsec and VPN separate?

69
03:34.520 --> 03:41.000
Well, this VPN could be something as simple as say, for example, a GRE tunnel.

70
03:41.000 --> 03:43.160
So that would not be encrypted.

71
03:43.160 --> 03:48.880
IPsec, of course, can offer protection to say a GRE VPN, but they are

72
03:48.880 --> 03:50.920
technically two separate

73
03:50.920 --> 03:52.320
things.

74
03:52.320 --> 03:58.360
This could even be something such as DM VPN, which is a hub and spoke multip

75
03:58.360 --> 04:00.360
oint VPN design.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

75
03:58.360 --> 04:00.360
oint VPN design.

76
04:00.360 --> 04:03.960
This again may or may not use IPsec as part of it.

77
04:03.960 --> 04:07.980
These are all options or it could be a completely private offering from the

78
04:07.980 --> 04:09.200
service provider,

79
04:09.200 --> 04:11.840
such as something like MPLS.

80
04:11.840 --> 04:15.650
At the end of the day, MPLS is sort of like a VPN as well, because it does

81
04:15.650 --> 04:16.600
encapsulation

82
04:16.600 --> 04:18.040
with labels.

83
04:18.040 --> 04:21.140
But either way, we're just giving some options here of what these private

84
04:21.140 --> 04:21.960
connections could

85
04:21.960 --> 04:22.960
be.

86
04:22.960 --> 04:26.080
It could even be something like dark fiber.

87
04:26.080 --> 04:30.010
This is a service that's offered in a lot of areas where maybe the service
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

87
04:26.080 --> 04:30.010
This is a service that's offered in a lot of areas where maybe the service

88
04:30.010 --> 04:31.120
provider has

89
04:31.120 --> 04:35.100
some fiber they're not using some available bandwidth, and you can lease that

90
04:35.100 --> 04:35.600
from the

91
04:35.600 --> 04:38.360
provider to connect to sites.

92
04:38.360 --> 04:41.360
This is usually limited a bit geographically.

93
04:41.360 --> 04:43.960
However, it's also an option.

94
04:43.960 --> 04:46.280
This could even be something like Metro Ethernet.

95
04:46.280 --> 04:49.520
Again, there's a lot of different choices.

96
04:49.520 --> 04:52.520
You could have a 5G connection going over cellular.

97
04:52.520 --> 04:57.500
This is getting, of course, more popular as cellular speeds get faster.

98
04:57.500 --> 05:02.610
This is going to have an advantage of if maybe not today, at least very soon,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

98
04:57.500 --> 05:02.610
This is going to have an advantage of if maybe not today, at least very soon,

99
05:02.610 --> 05:03.340
being available

100
05:03.340 --> 05:07.340
pretty much everywhere that cellular service is available.

101
05:07.340 --> 05:12.220
Now, again, not everyone has 5G with the higher speeds.

102
05:12.220 --> 05:17.550
Interestingly enough, be aware that you can have 5G service, but not

103
05:17.550 --> 05:18.860
necessarily the high

104
05:18.860 --> 05:21.060
speed 5G service.

105
05:21.060 --> 05:25.940
So a couple of little caveats there, but nonetheless, it's a good option.

106
05:25.940 --> 05:29.180
This can even be something as simple as point-to-point wireless.

107
05:29.180 --> 05:33.000
Now, that's, of course, going to require the locations to be a little bit
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

107
05:29.180 --> 05:33.000
Now, that's, of course, going to require the locations to be a little bit

108
05:33.000 --> 05:34.140
closer together,

109
05:34.140 --> 05:39.780
maybe outbuildings on the same campus or maybe two offices across town.

110
05:39.780 --> 05:42.620
This is going to be, of course, a much closer proximity.

111
05:42.620 --> 05:46.530
We're not talking about going between, say, two cities with something like

112
05:46.530 --> 05:47.460
point-to-point

113
05:47.460 --> 05:52.390
wireless, but the point is these are all different ways that branch offices

114
05:52.390 --> 05:53.660
could connect back

115
05:53.660 --> 05:54.660
in.

116
05:54.660 --> 05:57.780
Of course, we've had plenty of other ones over the years.

117
05:57.780 --> 06:01.020
We've had things like frame relay, ATM.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

117
05:57.780 --> 06:01.020
We've had things like frame relay, ATM.

118
06:01.020 --> 06:04.580
We've even had frame relay and ATM combined.

119
06:04.580 --> 06:08.680
If you're not familiar with that, one of the enterprises that I worked for, of

120
06:08.680 --> 06:09.420
course,

121
06:09.420 --> 06:14.500
many years ago now because this is all legacy technology, but they were running

122
06:14.500 --> 06:15.340
frame relay

123
06:15.340 --> 06:20.420
out at the remote offices, and then we had an ATM connection coming in at

124
06:20.420 --> 06:21.820
headquarters.

125
06:21.820 --> 06:26.350
And the service provider would take all of those frame relay connections, cond

126
06:26.350 --> 06:26.820
ense them

127
06:26.820 --> 06:31.660
together, and deliver them to us over that single ATM connection.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

127
06:26.820 --> 06:31.660
together, and deliver them to us over that single ATM connection.

128
06:31.660 --> 06:34.980
So we were essentially running frame relay over ATM.

129
06:34.980 --> 06:39.030
The framing is very similar, so it's actually a very easy translation for the

130
06:39.030 --> 06:39.820
provider.

131
06:39.820 --> 06:43.540
But nonetheless, there have been many options over the years.

132
06:43.540 --> 06:45.820
We're certainly not going to list them all here.

133
06:45.820 --> 06:48.220
Theoretically, you could still have dial-up.

134
06:48.220 --> 06:52.140
But the point is we need some sort of private WAN connection to get these

135
06:52.140 --> 06:53.500
remote sites connected

136
06:53.500 --> 06:56.940
in to this central internet gateway.

137
06:56.940 --> 07:00.380
And just one last little point here on the WAN connections.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

137
06:56.940 --> 07:00.380
And just one last little point here on the WAN connections.

138
07:00.380 --> 07:05.980
Don't forget that literally any of these options can be combined for redundancy

139
07:05.980 --> 07:05.980
.

140
07:05.980 --> 07:11.760
Now, obviously, you wouldn't want to use two choices that sort of use the same

141
07:11.760 --> 07:12.980
transport.

142
07:12.980 --> 07:20.580
So for example, you probably don't want to use DMVPN with GRE backing it up,

143
07:20.580 --> 07:20.740
because

144
07:20.740 --> 07:24.350
there's a pretty good chance that both of those are going to go over some form

145
07:24.350 --> 07:24.700
of an

146
07:24.700 --> 07:26.180
internet connection.

147
07:26.180 --> 07:28.820
They're probably going to use the same transport.

148
07:28.820 --> 07:34.790
So what would be far more common would be to use something like DMVPN with IP
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

148
07:28.820 --> 07:34.790
So what would be far more common would be to use something like DMVPN with IP

149
07:34.790 --> 07:35.460
sec over

150
07:35.460 --> 07:41.170
some form of an internet connection and use that to actually back up something

151
07:41.170 --> 07:41.820
like an

152
07:41.820 --> 07:46.580
actual MPLS connection, which would be your primary connection.

153
07:46.580 --> 07:50.810
So if our goal here is to provide redundancy, we do have to make sure that

154
07:50.810 --> 07:51.700
ultimately our

155
07:51.700 --> 07:57.520
two choices or possibly more that we're combining aren't ultimately using the

156
07:57.520 --> 07:59.060
same transport.

157
07:59.060 --> 08:03.900
So ultimately, the way this design works is all of the traffic.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

157
07:59.060 --> 08:03.900
So ultimately, the way this design works is all of the traffic.

158
08:03.900 --> 08:08.690
And what we mean by all is going to be internal traffic, going to our own

159
08:08.690 --> 08:10.020
servers, as well

160
08:10.020 --> 08:15.060
as traffic headed for the internet, it's all going to be sent again from the

161
08:15.060 --> 08:16.540
branch office

162
08:16.540 --> 08:22.060
to that central site, be that headquarters or a data center.

163
08:22.060 --> 08:27.020
Once that traffic actually arrives at the central site, that central site is

164
08:27.020 --> 08:27.620
going to

165
08:27.620 --> 08:29.820
route that accordingly.

166
08:29.820 --> 08:34.630
Any internet bound traffic is going to be sent out through this central
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

166
08:29.820 --> 08:34.630
Any internet bound traffic is going to be sent out through this central

167
08:34.630 --> 08:36.460
internet connection,

168
08:36.460 --> 08:41.450
internal traffic on the other hand, which could be things like maybe internal

169
08:41.450 --> 08:42.260
web traffic

170
08:42.260 --> 08:48.030
going to an internal server, maybe to an internal email server or local DNS

171
08:48.030 --> 08:48.940
server.

172
08:48.940 --> 08:54.080
These things will all be routed to the internal servers, which would possibly

173
08:54.080 --> 08:55.060
be somewhere

174
08:55.060 --> 08:59.260
like a DMZ or a demilitarized zone.

175
08:59.260 --> 09:06.700
Now remembering that the main topic for this skill is software as a service.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

175
08:59.260 --> 09:06.700
Now remembering that the main topic for this skill is software as a service.

176
09:06.700 --> 09:11.580
That software as a service traffic, of course, still goes out through the

177
09:11.580 --> 09:12.840
central internet

178
09:12.840 --> 09:17.930
connection because at the end of the day, from the perspective of this model,

179
09:17.930 --> 09:18.380
this is

180
09:18.380 --> 09:20.740
just internet traffic.

181
09:20.740 --> 09:26.590
It may be a specific type of internet traffic, but we're still going to an SaaS

182
09:26.590 --> 09:27.340
provider

183
09:27.340 --> 09:29.420
out there on the internet.

184
09:29.420 --> 09:34.500
So let's talk about some of the pros and cons of this model.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

184
09:29.420 --> 09:34.500
So let's talk about some of the pros and cons of this model.

185
09:34.500 --> 09:40.260
Starting with the pros, this is a central solution.

186
09:40.260 --> 09:44.060
This design generally makes implementing services.

187
09:44.060 --> 09:45.740
We could say easier.

188
09:45.740 --> 09:51.140
We could say more controlled depending on how you want to look at this.

189
09:51.140 --> 09:55.750
What it means is we're going to go through say a central pair of firewalls,

190
09:55.750 --> 09:56.780
maybe a central

191
09:56.780 --> 10:00.500
set of intrusion prevention or detection systems.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

191
09:56.780 --> 10:00.500
set of intrusion prevention or detection systems.

192
10:00.500 --> 10:04.660
We could have centralized web caching and not just web caching.

193
10:04.660 --> 10:07.380
It can really be any kind of caching service.

194
10:07.380 --> 10:12.020
The point is we can have all of this in a single central location.

195
10:12.020 --> 10:16.850
Again, that enterprise that I referred to earlier that was using the frame

196
10:16.850 --> 10:17.620
relay with

197
10:17.620 --> 10:23.490
ATM solution, this is exactly the model we were using because they did not want

198
10:23.490 --> 10:24.020
any of

199
10:24.020 --> 10:27.500
the remote sites to be able to go directly to the internet.

200
10:27.500 --> 10:30.080
And they did this for security reasons.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

200
10:27.500 --> 10:30.080
And they did this for security reasons.

201
10:30.080 --> 10:35.850
In that enterprise, we had somewhere in the neighborhood of about 520 remote

202
10:35.850 --> 10:36.340
sites.

203
10:36.340 --> 10:42.480
And it just really wasn't felt that we could put 520 firewalls and IDS and IPS

204
10:42.480 --> 10:43.300
systems and

205
10:43.300 --> 10:48.450
all that stuff out there at every location and manage it in any kind of an

206
10:48.450 --> 10:49.380
effective

207
10:49.380 --> 10:50.380
way.

208
10:50.380 --> 10:55.070
Now, of course, looking at technology such as SD-WAN, you can see how this has

209
10:55.070 --> 10:55.860
definitely

210
10:55.860 --> 10:57.820
changed over the years.

211
10:57.820 --> 11:02.610
And it wouldn't be that big of a deal to actually implement all of these
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

211
10:57.820 --> 11:02.610
And it wouldn't be that big of a deal to actually implement all of these

212
11:02.610 --> 11:03.860
services, maybe not

213
11:03.860 --> 11:09.630
the caching so much, but certainly the firewall, IDS, IPS systems at each

214
11:09.630 --> 11:11.300
remote location and

215
11:11.300 --> 11:13.980
have them have direct internet access.

216
11:13.980 --> 11:17.900
And that's of course, what we're going to talk about in the upcoming videos.

217
11:17.900 --> 11:22.700
But for now, let's take a look at some of the cons here.

218
11:22.700 --> 11:27.890
So for the cons, we're going to be looking at this strictly from the SaaS

219
11:27.890 --> 11:29.260
perspective.

220
11:29.260 --> 11:34.000
So from that perspective, what are the disadvantages to this centralized
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

220
11:29.260 --> 11:34.000
So from that perspective, what are the disadvantages to this centralized

221
11:34.000 --> 11:35.900
internet gateway design?

222
11:35.900 --> 11:39.700
Well, first is we have these WAN links.

223
11:39.700 --> 11:42.620
And again, we've talked about all their different options, right?

224
11:42.620 --> 11:45.580
Maybe private MPLS circuits, for example.

225
11:45.580 --> 11:51.600
But now we're having this SaaS traffic, which we know is just going to the

226
11:51.600 --> 11:52.780
internet.

227
11:52.780 --> 11:57.980
But all of that has to come across these private circuits now.

228
11:57.980 --> 12:02.540
And ultimately, what that means is we're going to have reduced bandwidth for
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

228
11:57.980 --> 12:02.540
And ultimately, what that means is we're going to have reduced bandwidth for

229
12:02.540 --> 12:03.500
those internal

230
12:03.500 --> 12:04.500
apps.

231
12:04.500 --> 12:10.100
So maybe that internal web traffic or email or DNS, maybe just file and print

232
12:10.100 --> 12:11.500
services,

233
12:11.500 --> 12:15.950
anything that we're hosting inside of the company, all of that is going to have

234
12:15.950 --> 12:16.380
less

235
12:16.380 --> 12:22.860
bandwidth available if the SaaS traffic is using that same bandwidth.

236
12:22.860 --> 12:25.220
And again, that may not be a big deal.

237
12:25.220 --> 12:32.340
However, this could also affect SaaS applications if they're bandwidth hungry.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

237
12:25.220 --> 12:32.340
However, this could also affect SaaS applications if they're bandwidth hungry.

238
12:32.340 --> 12:36.860
Think about things like Dropbox or Microsoft's OneDrive.

239
12:36.860 --> 12:41.420
Any of these sort of file sharing applications that have to synchronize files

240
12:41.420 --> 12:42.340
back and forth

241
12:42.340 --> 12:46.260
and so on, they're really going to take a lot of bandwidth.

242
12:46.260 --> 12:50.950
And it's even possible that those private circuits don't even have enough

243
12:50.950 --> 12:51.700
bandwidth

244
12:51.700 --> 12:52.900
on them.

245
12:52.900 --> 12:56.340
That's not going to be as big of a deal in today's networks.

246
12:56.340 --> 13:00.790
But again, thinking back to that enterprise that I was talking about earlier,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

246
12:56.340 --> 13:00.790
But again, thinking back to that enterprise that I was talking about earlier,

247
13:00.790 --> 13:01.420
we basically

248
13:01.420 --> 13:08.420
had T1 lines going out to these remote locations at 1.54 megabits per second.

249
13:08.420 --> 13:12.310
That's nowhere near enough bandwidth for the things we're trying to do today

250
13:12.310 --> 13:12.900
with these

251
13:12.900 --> 13:15.180
SaaS applications.

252
13:15.180 --> 13:19.460
If they went directly to the internet, that would be a different story.

253
13:19.460 --> 13:24.690
And sort of right along with this same issue is the internet connection at the

254
13:24.690 --> 13:25.340
central

255
13:25.340 --> 13:28.820
location might start becoming a bottleneck.

256
13:28.820 --> 13:32.340
We have all of this traffic coming in from these remote sites.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

256
13:28.820 --> 13:32.340
We have all of this traffic coming in from these remote sites.

257
13:32.340 --> 13:36.690
And now all of it has to go out through our main internet connection at the

258
13:36.690 --> 13:37.580
centralized

259
13:37.580 --> 13:38.580
gateway.

260
13:38.580 --> 13:43.470
Well, if we distributed that workload and let those sites go out to the

261
13:43.470 --> 13:45.140
internet directly,

262
13:45.140 --> 13:46.980
that would not become a problem.

263
13:46.980 --> 13:51.220
And again, this could even overwhelm the security stack itself.

264
13:51.220 --> 13:54.660
How much traffic can our centralized firewall handle?

265
13:54.660 --> 13:57.820
How much can our IPS or IDS system handle?

266
13:57.820 --> 14:02.490
These are all things that have to be considered when we're bringing all of the
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

266
13:57.820 --> 14:02.490
These are all things that have to be considered when we're bringing all of the

267
14:02.490 --> 14:02.860
traffic back

268
14:02.860 --> 14:04.940
through the central location.

269
14:04.940 --> 14:10.060
Also, just based on the fact that we're adding more circuits into the entire

270
14:10.060 --> 14:11.060
connection,

271
14:11.060 --> 14:14.060
this can also introduce jitter.

272
14:14.060 --> 14:19.520
As these circuits start getting congestion on them, we can actually cause

273
14:19.520 --> 14:20.540
problems not

274
14:20.540 --> 14:25.580
only for the SaaS applications, but also for the internal traffic, which is

275
14:25.580 --> 14:26.500
probably why

276
14:26.500 --> 14:30.430
we had these private WAN circuits to begin with, because it all started with
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

276
14:26.500 --> 14:30.430
we had these private WAN circuits to begin with, because it all started with

277
14:30.430 --> 14:31.020
internal

278
14:31.020 --> 14:32.580
servers.

279
14:32.580 --> 14:37.430
Now we can manage some of this, of course, with things like QOS or quality of

280
14:37.430 --> 14:38.180
service.

281
14:38.180 --> 14:43.460
However, that's not an end-all be-all magic solution for everything.

282
14:43.460 --> 14:45.020
It can certainly help.

283
14:45.020 --> 14:49.920
And we certainly need to do it, particularly things like voice and video

284
14:49.920 --> 14:50.860
traffic.

285
14:50.860 --> 14:55.900
But right along with jitter, we also could have a problem with latency.

286
14:55.900 --> 14:59.820
Latency is going to happen just because we're doing this suboptimal routing.

287
14:59.820 --> 15:04.340
Rather than going out to the internet directly and going to our destination, we
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

287
14:59.820 --> 15:04.340
Rather than going out to the internet directly and going to our destination, we

288
15:04.340 --> 15:05.140
're instead

289
15:05.140 --> 15:11.540
going from our remote offices directly to the central location out to the

290
15:11.540 --> 15:12.780
internet.

291
15:12.780 --> 15:17.060
And the thing is, a lot of these remote offices, they may already have a direct

292
15:17.060 --> 15:19.220
internet connection,

293
15:19.220 --> 15:23.260
particularly if they're connecting in with a VPN.

294
15:23.260 --> 15:27.180
That VPN is most likely going over the internet.

295
15:27.180 --> 15:32.090
So the question becomes, do we make all of the traffic go through the VPN back
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

295
15:27.180 --> 15:32.090
So the question becomes, do we make all of the traffic go through the VPN back

296
15:32.090 --> 15:33.260
to headquarters

297
15:33.260 --> 15:35.340
and then out to the internet?

298
15:35.340 --> 15:41.940
Or do we allow it to do a split tunnel where internal traffic goes through the

299
15:41.940 --> 15:42.180
VPN, but

300
15:42.180 --> 15:45.340
internet traffic is allowed to go direct.

301
15:45.340 --> 15:51.970
And therefore, bypassing this suboptimal routing problem and therefore reducing

302
15:51.970 --> 15:53.220
latency because

303
15:53.220 --> 15:58.980
we're not going through a whole other connection or possibly more than one

304
15:58.980 --> 15:59.340
connection.

305
15:59.340 --> 16:04.870
So in this video, we talked about the centralized internet gateway design,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

305
15:59.340 --> 16:04.870
So in this video, we talked about the centralized internet gateway design,

306
16:04.870 --> 16:05.740
which is really the

307
16:05.740 --> 16:10.990
traditional way that we have connected our remote sites to some form of a

308
16:10.990 --> 16:12.060
centralized

309
16:12.060 --> 16:17.410
headquarters using private WAN circuits and sending all of the traffic from

310
16:17.410 --> 16:18.340
those remote

311
16:18.340 --> 16:24.460
offices to the central location before then sending it out to the internet.

312
16:24.460 --> 16:30.530
Now we talked about some of the pros and cons, mostly from the SaaS perspective
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

312
16:24.460 --> 16:30.530
Now we talked about some of the pros and cons, mostly from the SaaS perspective

313
16:30.530 --> 16:30.580
.

314
16:30.580 --> 16:35.580
Of course, the biggest one is that these branch offices probably have some form

315
16:35.580 --> 16:36.140
of an internet

316
16:36.140 --> 16:41.460
connection already, but we're not using it to deliver internet traffic.

317
16:41.460 --> 16:44.940
And we also discussed a bit about why that is.

318
16:44.940 --> 16:50.300
It's all about that centralized control and traditionally maybe saving some

319
16:50.300 --> 16:51.180
money on some

320
16:51.180 --> 16:52.660
of that hardware.

321
16:52.660 --> 16:57.040
But now that our hardware at our remote locations can handle these services,

322
16:57.040 --> 16:57.740
not so much of

323
16:57.740 --> 17:03.120
an advantage, and it may just be a better idea to let those remote sites go
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

323
16:57.740 --> 17:03.120
an advantage, and it may just be a better idea to let those remote sites go

324
17:03.120 --> 17:03.900
directly

325
17:03.900 --> 17:05.940
to the internet.

326
17:05.940 --> 17:08.700
Maybe we could call that direct internet access.

327
17:08.700 --> 17:12.380
Why don't we go ahead and take a look at that coming up next.

328
17:12.380 --> 17:22.380
[BLANK_AUDIO]