WEBVTT

1
00:00.000 --> 00:06.560
A major part of our day-to-day operation is enabling our users to connect out

2
00:06.560 --> 00:08.460
to applications

3
00:08.460 --> 00:12.280
that live usually out on the internet.

4
00:12.280 --> 00:15.040
We have a lot of these applications.

5
00:15.040 --> 00:19.290
In fact, we have a name for this in our world that's called Software as a

6
00:19.290 --> 00:20.120
Service, meaning

7
00:20.120 --> 00:24.830
it's a software that I didn't have to deploy onto my own servers in my own data

8
00:24.830 --> 00:25.400
center.

9
00:25.400 --> 00:30.800
I just subscribe, usually, and spend some amount of money a month to subscribe
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

9
00:25.400 --> 00:30.800
I just subscribe, usually, and spend some amount of money a month to subscribe

10
00:30.800 --> 00:32.160
to this software

11
00:32.160 --> 00:36.880
platform and then my users directly connect via the internet.

12
00:36.880 --> 00:37.880
But here's the question.

13
00:37.880 --> 00:43.630
It's one thing to say that my users have an internet circuit, and so they're

14
00:43.630 --> 00:44.200
going

15
00:44.200 --> 00:49.080
to go through that internet circuit to reach the SaaS provider.

16
00:49.080 --> 00:53.360
But what if we have multiple internet circuits available?

17
00:53.360 --> 00:59.970
This is especially a topology we might see more and more of thanks to SD-WAN,

18
00:59.970 --> 01:00.640
because
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

18
00:59.970 --> 01:00.640
because

19
01:00.640 --> 01:04.660
I might deploy an internet circuit to a site and then another internet circuit,

20
01:04.660 --> 01:05.200
and maybe

21
01:05.200 --> 01:09.940
I'm building my SD-WAN tunnels across these internet circuits to remote

22
01:09.940 --> 01:10.920
locations, or

23
01:10.920 --> 01:16.310
maybe I'm just using a tunnel out the MPLS circuit and a tunnel out this

24
01:16.310 --> 01:17.320
internet for

25
01:17.320 --> 01:21.840
the sake of my WAN, but then I have this other internet provider here as well.

26
01:21.840 --> 01:26.390
So, we've got a lot of different options where we might see multiple internet

27
01:26.390 --> 01:27.560
service providers

28
01:27.560 --> 01:28.640
at play.

29
01:28.640 --> 01:32.800
And depending on where in the world this is and the service providers that are
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

29
01:28.640 --> 01:32.800
And depending on where in the world this is and the service providers that are

30
01:32.800 --> 01:33.480
providing

31
01:33.480 --> 01:39.700
connectivity, the question is which one of these is going to be better to use

32
01:39.700 --> 01:40.160
for the

33
01:40.160 --> 01:44.320
sake of accessing the software as a service provider.

34
01:44.320 --> 01:48.270
Now I don't know about you, but I have a tendency to look at two internet

35
01:48.270 --> 01:49.600
circuits and say,

36
01:49.600 --> 01:51.320
oh, those are equivalent.

37
01:51.320 --> 01:54.260
If they're both the same bandwidth, they're both 100 megabits per second and

38
01:54.260 --> 01:54.840
they're both

39
01:54.840 --> 01:58.000
pretty reliable, that, well, that doesn't matter, right?

40
01:58.000 --> 02:03.840
Flip of Coin, just go out the internet to connect to the SaaS service provider.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

40
01:58.000 --> 02:03.840
Flip of Coin, just go out the internet to connect to the SaaS service provider.

41
02:03.840 --> 02:05.480
Here's the problem with that logic.

42
02:05.480 --> 02:09.400
The internet is not just one big blob.

43
02:09.400 --> 02:14.480
It's actually thousands of blobs that are out there, and so we might have a

44
02:14.480 --> 02:15.400
much longer

45
02:15.400 --> 02:20.800
path to get to this service provider depending on which internet circuit we use

46
02:20.800 --> 02:21.040
.

47
02:21.040 --> 02:28.150
For example, what if this SaaS provider actually shares this internet circuit,

48
02:28.150 --> 02:29.840
service provider?

49
02:29.840 --> 02:35.140
So they're connected to the same service provider directly, and as a result, if
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

49
02:29.840 --> 02:35.140
So they're connected to the same service provider directly, and as a result, if

50
02:35.140 --> 02:35.760
we send

51
02:35.760 --> 02:39.970
traffic out this way, we're going to have to go from one service provider to

52
02:39.970 --> 02:40.560
another

53
02:40.560 --> 02:48.120
service provider to another service provider to get to this SaaS provider.

54
02:48.120 --> 02:51.830
And again, especially when we think about places around the world, if you're

55
02:51.830 --> 02:52.720
coming from

56
02:52.720 --> 02:57.120
one country and you're going to a whole other country, these types of

57
02:57.120 --> 02:58.000
situations might

58
02:58.000 --> 03:03.430
develop where we have two very different experiences by going out to different
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

58
02:58.000 --> 03:03.430
develop where we have two very different experiences by going out to different

59
03:03.430 --> 03:05.000
internet circuits,

60
03:05.000 --> 03:10.870
even though they have a lot of the same traits and qualities such as bandwidth

61
03:10.870 --> 03:12.520
and reliability.

62
03:12.520 --> 03:13.720
So here's the idea.

63
03:13.720 --> 03:21.400
Cisco with SD-WAN, they have this cloud-on-ramp set of technologies.

64
03:21.400 --> 03:24.040
Cloud-on-ramp takes a few different forms, and the first thing we're going to

65
03:24.040 --> 03:25.080
look at is

66
03:25.080 --> 03:29.980
cloud-on-ramp for software as a service, the exact situation that we're talking

67
03:29.980 --> 03:30.440
about
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

67
03:29.980 --> 03:30.440
about

68
03:30.440 --> 03:31.440
here.

69
03:31.440 --> 03:35.040
Again, not all certain internet circuits are created equal, and we want to find

70
03:35.040 --> 03:35.640
the best

71
03:35.640 --> 03:40.200
most optimal path to get to a specific SaaS service provider.

72
03:40.200 --> 03:48.570
So the idea here is that our SD-WAN devices will be sending HTTP probes out

73
03:48.570 --> 03:50.220
towards this

74
03:50.220 --> 03:54.320
SaaS provider that we have configured to be monitoring.

75
03:54.320 --> 03:59.880
And based on this, we're going to have an idea of where exactly we should be

76
03:59.880 --> 04:00.520
going,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

76
03:59.880 --> 04:00.520
going,

77
04:00.520 --> 04:04.320
or which internet circuit we should be relying on if we indeed have two

78
04:04.320 --> 04:05.200
different internet

79
04:05.200 --> 04:06.800
circuits.

80
04:06.800 --> 04:10.860
We're going to measure this and know that one of these locations has a better

81
04:10.860 --> 04:11.120
or one

82
04:11.120 --> 04:16.660
of these circuits has a much better quality of experience by extending

83
04:16.660 --> 04:18.160
connections out

84
04:18.160 --> 04:20.040
in this fashion.

85
04:20.040 --> 04:23.680
So that's the idea of cloud-on-ramp for SaaS, and it's especially going to be

86
04:23.680 --> 04:24.200
used when

87
04:24.200 --> 04:29.600
we have two what we call DIAs or direct internet access points.

88
04:29.600 --> 04:34.720
So if we have two DIAs at a particular site, then this technology is going to
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

88
04:29.600 --> 04:34.720
So if we have two DIAs at a particular site, then this technology is going to

89
04:34.720 --> 04:35.360
make a lot

90
04:35.360 --> 04:36.920
of sense.

91
04:36.920 --> 04:41.400
But what if we only have a single circuit?

92
04:41.400 --> 04:44.400
Is there any value in using this?

93
04:44.400 --> 04:47.460
And the answer is going to be it depends a little bit, but we do have a

94
04:47.460 --> 04:48.360
solution that we

95
04:48.360 --> 04:54.790
could potentially rely on, and it's going to involve the concept of a regional

96
04:54.790 --> 04:55.480
hub.

97
04:55.480 --> 05:00.140
So our WAN circuits and our SD-WAN environments can be very large, especially
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

97
04:55.480 --> 05:00.140
So our WAN circuits and our SD-WAN environments can be very large, especially

98
05:00.140 --> 05:01.240
if we're a global

99
05:01.240 --> 05:02.920
organization.

100
05:02.920 --> 05:09.640
And what we might end up finding is that we have remote sites that have tunnel

101
05:09.640 --> 05:11.000
connectivity

102
05:11.000 --> 05:15.840
back to a regional hub.

103
05:15.840 --> 05:21.410
So let's say that I have this remote site, and I have an internet circuit, and

104
05:21.410 --> 05:21.840
I'm trying

105
05:21.840 --> 05:25.720
to connect out to my software as a service type of environment.

106
05:25.720 --> 05:36.940
Meanwhile I've got SD-WAN tunnels that form out this way towards my regional
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

106
05:25.720 --> 05:36.940
Meanwhile I've got SD-WAN tunnels that form out this way towards my regional

107
05:36.940 --> 05:38.080
hub.

108
05:38.080 --> 05:43.920
Well that regional hub likely has an internet circuit as well that has a path

109
05:43.920 --> 05:44.880
to the software

110
05:44.880 --> 05:46.640
as a service vendor.

111
05:46.640 --> 05:51.600
And so what we can do with Enramp for SAS is to truly say, hey which one's

112
05:51.600 --> 05:52.480
better?

113
05:52.480 --> 05:58.630
To go this way, this is option one, or to go through one of these tunnels and

114
05:58.630 --> 05:59.000
out the

115
05:59.000 --> 06:01.760
internet circuit, that would be option two.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

115
05:59.000 --> 06:01.760
internet circuit, that would be option two.

116
06:01.760 --> 06:05.560
And look at this, we have a third option as well.

117
06:05.560 --> 06:08.960
So we can evaluate this based on the tunnels.

118
06:08.960 --> 06:17.360
Now keep in mind that my metric has to take into account the WAN circuit as

119
06:17.360 --> 06:19.240
well, meaning

120
06:19.240 --> 06:26.350
that if I measure this path through my own internet circuit, and this regional

121
06:26.350 --> 06:27.160
hub is saying,

122
06:27.160 --> 06:31.440
hey I've got a pretty good connection as well to this.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

122
06:27.160 --> 06:31.440
hey I've got a pretty good connection as well to this.

123
06:31.440 --> 06:35.280
Well that's great, and I'll accept I still have to go through the WAN tunnel.

124
06:35.280 --> 06:37.960
And so I have to take that into account as well.

125
06:37.960 --> 06:45.000
So it's the WAN circuit plus the internet experience.

126
06:45.000 --> 06:50.640
And so I'm comparing this versus taking my direct path.

127
06:50.640 --> 06:55.140
So this is certainly an option with single circuit types of deployments where I

128
06:55.140 --> 06:55.800
might find

129
06:55.800 --> 07:01.920
that it's actually better for me to extend connectivity out through my SD-WAN
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

129
06:55.800 --> 07:01.920
that it's actually better for me to extend connectivity out through my SD-WAN

130
07:01.920 --> 07:02.600
pathing

131
07:02.600 --> 07:07.190
to get to a regional hub and then turn around and allow it to send me to the

132
07:07.190 --> 07:07.920
software

133
07:07.920 --> 07:09.920
as a service provider.

134
07:09.920 --> 07:16.120
Now we keep mentioning this, we're evaluating metrics, we're evaluating the

135
07:16.120 --> 07:17.160
quality, and

136
07:17.160 --> 07:25.480
this all comes down to a measurement that we use that is known as the Viptela

137
07:25.480 --> 07:26.480
quality

138
07:26.480 --> 07:28.680
of experience.

139
07:28.680 --> 07:34.540
And as of the time of this video, we do still indeed have the PTIAs part of the
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

139
07:28.680 --> 07:34.540
And as of the time of this video, we do still indeed have the PTIAs part of the

140
07:34.540 --> 07:35.320
name.

141
07:35.320 --> 07:38.960
And part of the reason for that is because usually we don't call it this.

142
07:38.960 --> 07:42.480
We call it the VQOE.

143
07:42.480 --> 07:45.800
And this is a metric that ranges from 0 to 10.

144
07:45.800 --> 07:50.410
So we're going to evaluate these paths and figure out, okay maybe this is just

145
07:50.410 --> 07:51.440
a 4 extending

146
07:51.440 --> 07:55.280
out to my local or through my local DIA.

147
07:55.280 --> 08:01.220
But if I go through, go with my regional hub, they have a, and by the way, this
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

147
07:55.280 --> 08:01.220
But if I go through, go with my regional hub, they have a, and by the way, this

148
08:01.220 --> 08:02.000
is high.

149
08:02.000 --> 08:05.200
You do want a high quality of experience.

150
08:05.200 --> 08:08.680
So maybe we have a 10 going out via the hub.

151
08:08.680 --> 08:13.760
So the question is, okay, well, what about my circuit?

152
08:13.760 --> 08:17.320
I'm going to have to compare this and try to figure out, okay, if this is like

153
08:17.320 --> 08:17.880
a, maybe

154
08:17.880 --> 08:22.530
an 8, well, maybe it is better for me to take two really good hops rather than

155
08:22.530 --> 08:23.080
one really

156
08:23.080 --> 08:24.240
bad one.

157
08:24.240 --> 08:30.000
And so that's going to be the decision point that our SD-WAN edges are going to
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

158
08:30.000 --> 08:31.080
be making

159
08:31.080 --> 08:35.800
when they're trying to decide which path to send it out with this technique.

160
08:35.800 --> 08:39.980
Now we do have a couple of other solutions to be aware of as well, one of which

161
08:39.980 --> 08:40.520
is known

162
08:40.520 --> 08:42.480
as another on ramp.

163
08:42.480 --> 08:48.160
So again, it's cloud on ramp.

164
08:48.160 --> 08:54.000
And this one is for IaaS, infrastructure as a service.

165
08:54.000 --> 08:57.310
Infrastructure as a service means that I have a cloud environment except

166
08:57.310 --> 08:58.040
instead of it

167
08:58.040 --> 09:04.040
being where the provider, the application developer has deployed it onto their
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

167
08:58.040 --> 09:04.040
being where the provider, the application developer has deployed it onto their

168
09:04.040 --> 09:05.400
own environment,

169
09:05.400 --> 09:10.520
I now have to deploy my application onto my own virtual machines.

170
09:10.520 --> 09:12.760
But I still want to deploy this into the cloud space.

171
09:12.760 --> 09:18.220
So for example, Amazon Web Services and Azure allow me to spin up these virtual

172
09:18.220 --> 09:19.000
machines

173
09:19.000 --> 09:23.640
and then I just connect it back into my network in some capacity.

174
09:23.640 --> 09:29.390
Now SD-WAN allows me to be really smart about this and the cool thing about

175
09:29.390 --> 09:30.280
this is this
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

175
09:29.390 --> 09:30.280
this is this

176
09:30.280 --> 09:35.920
is very much automated through the use of V-Manage.

177
09:35.920 --> 09:41.320
I can go into V-Manage and configure it to access my cloud environment and it

178
09:41.320 --> 09:43.320
will deploy

179
09:43.320 --> 09:50.380
virtual SD-WAN edges of these virtual routers into the space and connect it

180
09:50.380 --> 09:51.500
back into my

181
09:51.500 --> 09:56.020
own SD-WAN infrastructure.

182
09:56.020 --> 09:59.940
So now I can have a physical router out here.

183
09:59.940 --> 10:03.380
These are physical, these are virtual.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

183
09:59.940 --> 10:03.380
These are physical, these are virtual.

184
10:03.380 --> 10:07.680
And I can also connect it into whatever this environment is and now I can build

185
10:07.680 --> 10:08.180
tunnels

186
10:08.180 --> 10:11.540
straight into the cloud environment.

187
10:11.540 --> 10:13.620
Look at that.

188
10:13.620 --> 10:18.030
In a lot of cases, I have to normally leverage V-PNs through the internet to

189
10:18.030 --> 10:18.700
connect to my

190
10:18.700 --> 10:20.020
cloud space.

191
10:20.020 --> 10:24.300
Now I can encrypt my own traffic going across the internet or potentially

192
10:24.300 --> 10:25.260
another WAN

193
10:25.260 --> 10:26.420
circuit type.

194
10:26.420 --> 10:33.260
But in the end, I have connectivity via my IPsec tunnels into my AWS or Azure
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

194
10:26.420 --> 10:33.260
But in the end, I have connectivity via my IPsec tunnels into my AWS or Azure

195
10:33.260 --> 10:33.940
space.

196
10:33.940 --> 10:38.240
Now the last product that Cisco has in this portfolio, at least again, as of

197
10:38.240 --> 10:38.940
the time of

198
10:38.940 --> 10:45.260
this video, is cloud on ramp for multi-cloud.

199
10:45.260 --> 10:50.880
This is an interesting product and it actually is intended to eventually

200
10:50.880 --> 10:52.380
replace cloud on

201
10:52.380 --> 10:55.020
ramp for IaaS.

202
10:55.020 --> 10:59.840
The idea here is that we want to take our cloud connectivity up to another

203
10:59.840 --> 11:00.660
level and we're
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

203
10:59.840 --> 11:00.660
level and we're

204
11:00.660 --> 11:07.420
going to leverage a provider type known as software define cloud interconnect

205
11:07.420 --> 11:08.100
or this

206
11:08.100 --> 11:10.380
SD-CI provider.

207
11:10.380 --> 11:17.030
The SD-CI provider has native connections into cloud spaces and this solution

208
11:17.030 --> 11:17.820
is going

209
11:17.820 --> 11:23.600
to support not just Amazon web services and Microsoft Azure, but also Google's

210
11:23.600 --> 11:24.100
cloud

211
11:24.100 --> 11:27.300
platform as well.

212
11:27.300 --> 11:33.520
So this SD-CI provider is one that can connect us into the cloud regardless of
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

212
11:27.300 --> 11:33.520
So this SD-CI provider is one that can connect us into the cloud regardless of

213
11:33.520 --> 11:34.300
where in the

214
11:34.300 --> 11:38.400
world we are, which can be very beneficial because if we think about this

215
11:38.400 --> 11:39.220
situation, it

216
11:39.220 --> 11:44.040
can be difficult to make sure that we have actual network connectivity between

217
11:44.040 --> 11:44.840
whatever this

218
11:44.840 --> 11:50.060
physical router is and the cloud space, short of just going across the internet

219
11:50.060 --> 11:50.080
.

220
11:50.080 --> 11:54.780
So we leverage an SD-CI and as of the time of this video, Cisco natively integr

221
11:54.780 --> 11:55.220
ates

222
11:55.220 --> 12:06.380
with a couple of SD-CI providers, namely Megaport and Equinix.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

222
11:55.220 --> 12:06.380
with a couple of SD-CI providers, namely Megaport and Equinix.

223
12:06.380 --> 12:09.680
They might continue to expand this offering or they might not sometimes they do

224
12:09.680 --> 12:10.180
sometimes

225
12:10.180 --> 12:11.180
they don't.

226
12:11.180 --> 12:15.370
So definitely do the research there when making decisions for your organization

227
12:15.370 --> 12:15.740
and what

228
12:15.740 --> 12:17.380
you want to purchase.

229
12:17.380 --> 12:22.480
But in the end, what we can do is leverage cloud on ramp for multi cloud to

230
12:22.480 --> 12:23.740
take our SD-WAN

231
12:23.740 --> 12:30.980
routers and integrate it into the SD-CI and this allows us to connect in again
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

231
12:23.740 --> 12:30.980
routers and integrate it into the SD-CI and this allows us to connect in again

232
12:30.980 --> 12:31.540
to our

233
12:31.540 --> 12:33.620
multi cloud environment.

234
12:33.620 --> 12:37.680
So it's no longer just about deploying virtual routers into our own cloud space

235
12:37.680 --> 12:37.940
.

236
12:37.940 --> 12:41.730
It's using a little bit more sophisticated of a method and a little more

237
12:41.730 --> 12:42.500
scalable of a

238
12:42.500 --> 12:43.660
method.

239
12:43.660 --> 12:47.840
Something that we can hopefully take advantage of regardless of where in the

240
12:47.840 --> 12:49.020
world our SD-WAN

241
12:49.020 --> 12:49.660
devices are.

242
12:49.660 --> 12:59.660
[BLANK_AUDIO]