WEBVTT

1
00:00.000 --> 00:05.600
One of the big benefits to having SD-WAN is to be able to improve our

2
00:05.600 --> 00:06.840
efficiency

3
00:06.840 --> 00:10.440
around the use of multiple WAN circuits.

4
00:10.440 --> 00:15.400
Because now we can truly talk about load balancing across these circuits.

5
00:15.400 --> 00:20.840
In a traditional network, if I have a WAN router at the edge of my network

6
00:20.840 --> 00:24.880
and I have a WAN circuit here, let's say this is MPLS,

7
00:24.880 --> 00:28.880
and maybe I just pay for a second circuit just for the sake of redundancy.

8
00:28.880 --> 00:34.800
So I get another provider here, and this might be, let's just say this is a 100
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

8
00:28.880 --> 00:34.800
So I get another provider here, and this might be, let's just say this is a 100

9
00:34.800 --> 00:36.040
-meg circuit,

10
00:36.040 --> 00:40.400
and I just go ahead and get a different MPLS provider to give me a 10-meg

11
00:40.400 --> 00:42.080
circuit much cheaper

12
00:42.080 --> 00:44.560
and I'm just using this for redundancy.

13
00:44.560 --> 00:49.280
Well, again, in this traditional environment, usually what I'm focused on here

14
00:49.280 --> 00:53.400
is turning this into an active standby type of deployment.

15
00:53.400 --> 00:59.080
All of my user traffic as it comes into the network is going to flow this way

16
00:59.080 --> 01:00.440
out the active.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

16
00:59.080 --> 01:00.440
out the active.

17
01:00.440 --> 01:07.640
And the reason for that is simply put, load balancing is very, very complex.

18
01:07.640 --> 01:11.460
There's a lot that I have to worry about in the routing space in order to make

19
01:11.460 --> 01:12.120
this work,

20
01:12.120 --> 01:17.880
and the other question in all of this is how exactly do we load balance?

21
01:17.880 --> 01:21.960
Now, traditionally, again, if I have a really small backup circuit like this,

22
01:21.960 --> 01:27.640
I have 110 total mag of throughput here, and I'm only using 100.

23
01:27.640 --> 01:30.920
Well, 100 out of 110 isn't all that bad.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

23
01:27.640 --> 01:30.920
Well, 100 out of 110 isn't all that bad.

24
01:30.920 --> 01:33.960
We could say that we're using the vast majority of our bandwidth,

25
01:33.960 --> 01:35.720
and naturally we still have the redundancy.

26
01:35.720 --> 01:40.760
If circuit 1 goes down, we can direct all of that out the MPLS circuit,

27
01:40.760 --> 01:46.110
and at that point we're at least online, even if we are limping along on much

28
01:46.110 --> 01:47.800
less bandwidth.

29
01:47.800 --> 01:53.320
While all of this complexity and questions about how to do it, they go away

30
01:53.320 --> 01:54.360
when we're talking about

31
01:54.360 --> 02:00.030
deploying SD-WAN. This is a massive benefit to be able to perform load
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

31
01:54.360 --> 02:00.030
deploying SD-WAN. This is a massive benefit to be able to perform load

32
02:00.030 --> 02:01.800
balancing across multiple

33
02:01.800 --> 02:09.320
WAN circuits, which leads to the ability to leverage all of our bandwidth.

34
02:09.320 --> 02:14.200
And so now we can truly look at this again from a tunnel perspective,

35
02:14.200 --> 02:19.080
as saying that I've got choices as traffic comes in to send it out one tunnel

36
02:19.080 --> 02:20.280
or the other.

37
02:20.280 --> 02:25.480
And I can make these decisions very simply by getting into V-manage and config

38
02:25.480 --> 02:26.440
uring policy.

39
02:26.440 --> 02:31.400
This policy gets pushed down by the V-Smart via OMP,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

39
02:26.440 --> 02:31.400
This policy gets pushed down by the V-Smart via OMP,

40
02:31.400 --> 02:34.840
and so now this router knows exactly what to do, and I didn't have to get in

41
02:34.840 --> 02:35.720
there and do anything

42
02:35.720 --> 02:41.880
complex from a routing and switching perspective. Now, we still need to ask the

43
02:41.880 --> 02:43.000
question of how,

44
02:43.000 --> 02:47.640
how do we go about load balancing this? Because we could just say, "Hey, I'm

45
02:47.640 --> 02:49.160
going to do a 50/50 split,"

46
02:49.160 --> 02:54.320
or "wait it based on percentage." So again, maybe I have 100 Meg here and a 10

47
02:54.320 --> 02:55.240
Meg over here,

48
02:55.240 --> 03:00.920
and now we can load balance still by setting most of the traffic out the 100,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

48
02:55.240 --> 03:00.920
and now we can load balance still by setting most of the traffic out the 100,

49
03:00.920 --> 03:04.600
but still send a little bit of traffic out the 10 to take advantage of it.

50
03:04.600 --> 03:08.880
I will say this from a real world perspective, what we might end up seeing is

51
03:08.880 --> 03:09.240
that,

52
03:09.800 --> 03:14.600
in the past, we would not want to spend a bunch of money on 200 Meg circuits

53
03:14.600 --> 03:15.720
because if one is just

54
03:15.720 --> 03:19.900
sitting there idle, then I'm wasting that amount of bandwidth. So instead of

55
03:19.900 --> 03:21.080
what we might see here,

56
03:21.080 --> 03:26.200
I say, you know, maybe instead of going 100 Meg to get me 100 Meg of throughput

57
03:26.200 --> 03:27.000
and then 10 Meg

58
03:27.000 --> 03:31.200
as a backup, which by the way puts me in a really bad situation on the day I
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

58
03:27.000 --> 03:31.200
as a backup, which by the way puts me in a really bad situation on the day I

59
03:31.200 --> 03:32.440
have to fail over,

60
03:32.440 --> 03:36.610
because all of that throughput is now being squeezed into a much smaller

61
03:36.610 --> 03:37.720
bandwidth circuit.

62
03:37.720 --> 03:41.960
Usually that means I have to disable some amount of services, but now I could

63
03:41.960 --> 03:42.920
actually say,

64
03:42.920 --> 03:48.390
"Alright, let's not do that. Let's do a 75 Meg connection to one and a 75 Meg

65
03:48.390 --> 03:49.720
connection to another,"

66
03:49.720 --> 03:55.750
or maybe even a 50 Meg connection. But the idea here is I can still get my 100

67
03:55.750 --> 03:56.840
Meg of throughput

68
03:56.840 --> 04:04.200
that I needed by load balancing. In fact, I can get 125 of that 125, which is a
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

68
03:56.840 --> 04:04.200
that I needed by load balancing. In fact, I can get 125 of that 125, which is a

69
04:04.200 --> 04:05.800
way better ratio,

70
04:05.800 --> 04:09.800
even than this was, and it gives me more throughput. And it still gives me a

71
04:09.800 --> 04:11.400
lot of throughput on a

72
04:11.400 --> 04:16.750
redundancy situation where I actually end up failing one of these links. And so

73
04:16.750 --> 04:18.040
it does afford

74
04:18.040 --> 04:22.830
the ability for me to now cost justify a much better backup link, even though

75
04:22.830 --> 04:23.960
it's not necessarily

76
04:23.960 --> 04:28.300
backup anymore because I'm actually using it for production traffic. So

77
04:28.300 --> 04:30.040
regardless, we do stuff
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

77
04:28.300 --> 04:30.040
regardless, we do stuff

78
04:30.040 --> 04:33.190
to decide how we're going to load balance it. And so we have four different

79
04:33.190 --> 04:34.600
options here. We could do

80
04:35.160 --> 04:40.280
just what's known as active active load balanced, which means that we're just

81
04:40.280 --> 04:41.800
going to divide our

82
04:41.800 --> 04:49.340
load between the two circuits. We can also do active active weighted, giving

83
04:49.340 --> 04:50.760
weight to one over

84
04:50.760 --> 04:56.680
the other and allowing me to direct more traffic through one of those circuits.

85
04:56.680 --> 04:58.040
But here's where things

86
04:58.040 --> 05:06.130
start to get really interesting. We can also do an active standby methodology.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

86
04:58.040 --> 05:06.130
start to get really interesting. We can also do an active standby methodology.

87
05:06.130 --> 05:08.200
But this is based

88
05:08.200 --> 05:13.890
on application and specifically it's called application pinning. What this

89
05:13.890 --> 05:15.320
means is I might have

90
05:15.320 --> 05:21.080
application A down here and I'm going to statically pin it to this link and

91
05:21.080 --> 05:24.680
then application B goes out

92
05:24.680 --> 05:30.580
this link. So from application A application A is perspective. This is active
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

92
05:24.680 --> 05:30.580
this link. So from application A application A is perspective. This is active

93
05:30.580 --> 05:32.040
and this is standby.

94
05:32.040 --> 05:38.050
But from B's perspective, the right is active and the left is standby. That

95
05:38.050 --> 05:39.560
should be an S. There we go.

96
05:39.560 --> 05:46.190
So now if this link goes down, application A can fail over to the other side.

97
05:46.190 --> 05:46.920
And that's why we call

98
05:46.920 --> 05:51.180
active standby. Even though we're leveraging both circuits, we're looking at

99
05:51.180 --> 05:53.080
things specifically from

100
05:53.080 --> 05:58.950
one application's perspective. Now lastly, this is where it gets really fun. We

101
05:58.950 --> 06:01.080
can use application
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

101
05:58.950 --> 06:01.080
can use application

102
06:01.080 --> 06:11.300
aware load balancing in order to optimize our traffic paths based on the

103
06:11.300 --> 06:13.880
metrics that we're seeing

104
06:13.880 --> 06:20.450
via service level agreements or SLAs. Now here's the crazy thing. These method

105
06:20.450 --> 06:22.440
ologies are not global.

106
06:22.920 --> 06:26.470
I don't actually get into v-manage and say, okay, this is just how I'm going to

107
06:26.470 --> 06:27.560
do this. This is

108
06:27.560 --> 06:33.330
configured per application. So I could have some of my smaller applications
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

108
06:27.560 --> 06:33.330
configured per application. So I could have some of my smaller applications

109
06:33.330 --> 06:35.000
just to use something

110
06:35.000 --> 06:40.110
basic like active active load balancing. But then when it comes to my more

111
06:40.110 --> 06:42.040
sensitive applications,

112
06:42.040 --> 06:46.040
maybe I go application aware to make sure that I'm paying attention to the

113
06:46.040 --> 06:46.920
state of these

114
06:46.920 --> 06:51.630
WAN circuits so that if there's a problem with one, even though it's online, I

115
06:51.630 --> 06:52.840
end up failing over.

116
06:52.840 --> 06:58.720
But here is an interesting question. If I can apply policy on a per application

117
06:58.720 --> 06:59.160
basis,

118
06:59.160 --> 07:04.730
like what I have here with application A and application B, well, these packets
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

118
06:59.160 --> 07:04.730
like what I have here with application A and application B, well, these packets

119
07:04.730 --> 07:05.560
arrive on the

120
07:05.560 --> 07:11.420
router just like every other packet. So how does the router know which

121
07:11.420 --> 07:14.040
application is which? Or maybe

122
07:14.040 --> 07:18.870
I should say which packet belongs to which application? Well, we have several

123
07:18.870 --> 07:19.800
different ways,

124
07:19.800 --> 07:25.560
and two different ways of analyzing this. So we have to concern ourselves with

125
07:25.560 --> 07:26.440
application

126
07:26.440 --> 07:31.770
identification. The first way to do it is by performing a matching of
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

126
07:26.440 --> 07:31.770
identification. The first way to do it is by performing a matching of

127
07:31.770 --> 07:33.320
parameters, which is going

128
07:33.320 --> 07:37.200
to sound familiar because this is actually how we do it with net flow as well,

129
07:37.200 --> 07:38.120
just with slightly

130
07:38.120 --> 07:44.030
different parameters. Cisco SD-WAN is going to use a six-touple of information,

131
07:44.030 --> 07:45.400
meaning we have six

132
07:45.400 --> 07:49.690
different pieces of information. We're going to extract out of a packet to

133
07:49.690 --> 07:51.080
figure out and identify

134
07:51.080 --> 07:56.430
which application it belongs to. So the six-touples going to include source

135
07:56.430 --> 07:58.360
destination IP address,

136
07:58.360 --> 08:02.480
source and destination port. So that's four of them, by the way, source and
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

136
07:58.360 --> 08:02.480
source and destination port. So that's four of them, by the way, source and

137
08:02.480 --> 08:03.880
destination for each.

138
08:03.880 --> 08:09.070
Then we look at the DSEP value, which is for QOS, and the protocol number would

139
08:09.070 --> 08:09.960
be our sixth.

140
08:09.960 --> 08:15.640
And the idea here is generally speaking, if I have two packets that have the

141
08:15.640 --> 08:17.240
same information here,

142
08:17.240 --> 08:23.560
so this packet, packet one and packet two, if they have the same information,

143
08:23.560 --> 08:24.280
then these are

144
08:24.280 --> 08:31.210
likely part of the same application. That's what we're hoping. Now it's not
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

144
08:24.280 --> 08:31.210
likely part of the same application. That's what we're hoping. Now it's not

145
08:31.210 --> 08:32.920
going to be 100%

146
08:32.920 --> 08:37.080
accurate because you might just happen to be talking to two different servers,

147
08:37.080 --> 08:38.600
two different applications,

148
08:38.600 --> 08:43.960
well, same server, but then same port potentially, two different applications.

149
08:43.960 --> 08:44.440
Maybe it's

150
08:44.440 --> 08:49.000
netted. There will be situations where we don't quite get as granular with the

151
08:49.000 --> 08:49.640
application

152
08:49.640 --> 08:55.210
identification. So as a result, we can also leverage Cisco's deep packet

153
08:55.210 --> 08:56.120
inspection

154
08:58.920 --> 09:06.440
or DPI. Deep packet inspection has been around for a long time on Cisco devices
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

154
08:58.920 --> 09:06.440
or DPI. Deep packet inspection has been around for a long time on Cisco devices

155
09:06.440 --> 09:07.080
, and it was a

156
09:07.080 --> 09:11.560
technology that they were able to bring into this whole SD-WAN equation when

157
09:11.560 --> 09:12.440
they acquired the

158
09:12.440 --> 09:18.810
solution. And the idea here is that Cisco has a database of thousands of

159
09:18.810 --> 09:20.120
applications,

160
09:20.120 --> 09:26.610
and it can look at a packet and perform a level of pattern matching to figure

161
09:26.610 --> 09:27.880
out which application

162
09:27.880 --> 09:33.780
it likely belongs to. And this is going to be much more accurate because it's
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

162
09:27.880 --> 09:33.780
it likely belongs to. And this is going to be much more accurate because it's

163
09:33.780 --> 09:34.840
going to look at the

164
09:34.840 --> 09:38.540
actual application that the traffic belongs to rather than just collecting a

165
09:38.540 --> 09:39.400
bunch of data and

166
09:39.400 --> 09:44.390
hoping it's all the same. This also enables a little bit more in the way of

167
09:44.390 --> 09:46.760
analytics so that we can

168
09:46.760 --> 09:54.630
take this information, submit it to NetFlow. We can run data queries via REST

169
09:54.630 --> 09:55.240
APIs,

170
09:55.240 --> 09:59.900
and there's just a lot more information that we can glean out of this. Now, at

171
09:59.900 --> 10:00.440
the time of this
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

171
09:59.900 --> 10:00.440
the time of this

172
10:00.440 --> 10:05.480
video, DPI is a licensed feature, meaning that we have to pay extra for it if

173
10:05.480 --> 10:07.240
that's what we want.

174
10:07.240 --> 10:13.320
And so keep that in mind that even though DPI's packet inspection is generally

175
10:13.320 --> 10:13.880
speaking

176
10:13.880 --> 10:18.400
superior, we might need to pay a little bit of extra in order to gain access to

177
10:18.400 --> 10:19.720
it. In the meantime,

178
10:19.720 --> 10:24.040
if we don't want to pay for that, we can still leverage this 6-Tupel method and

179
10:24.040 --> 10:25.000
still achieve our

180
10:25.000 --> 10:32.120
load-downs in goals. Now, the result of all of this is pretty stellar, really,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

180
10:25.000 --> 10:32.120
load-downs in goals. Now, the result of all of this is pretty stellar, really,

181
10:32.120 --> 10:33.000
because now we can

182
10:33.000 --> 10:38.800
identify our links by purpose. We don't have to worry about it just being

183
10:38.800 --> 10:40.680
primary and secondary

184
10:40.680 --> 10:48.180
anymore. For example, I could have a high throughput, but a low reliability

185
10:48.180 --> 10:50.200
circuit like the internet,

186
10:50.200 --> 10:54.840
and I can send my bulk data needs across it. So we're talking about bulk data.

187
10:54.840 --> 10:55.640
We're usually talking

188
10:55.640 --> 11:01.560
about major file transfers, maybe accessing file servers, downloading things,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

188
10:55.640 --> 11:01.560
about major file transfers, maybe accessing file servers, downloading things,

189
11:01.560 --> 11:03.880
all of that. I can have

190
11:03.880 --> 11:07.940
this type of circuit and send those types of applications across that circuit.

191
11:07.940 --> 11:08.840
Meanwhile, I could

192
11:08.840 --> 11:14.600
still have that low throughput high reliability circuit type like an MPLS or

193
11:14.600 --> 11:16.040
something along those

194
11:16.040 --> 11:21.160
lines, and I could send my voice over IP through that. We don't have to worry

195
11:21.160 --> 11:23.160
anymore about trying to

196
11:23.160 --> 11:28.850
deploy complicated source-based routing, policy-based routing policies onto our

197
11:28.850 --> 11:29.880
routers and making

198
11:29.880 --> 11:35.230
sure we're managing that everywhere. Instead, I just have to configure this in
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

198
11:29.880 --> 11:35.230
sure we're managing that everywhere. Instead, I just have to configure this in

199
11:35.230 --> 11:38.040
V-manage as a policy.

200
11:38.040 --> 11:44.790
And again, thanks to the architecture that exists via the V-Smarts and the OMP

201
11:44.790 --> 11:46.360
propagation of information,

202
11:46.360 --> 11:50.120
that policy I define will get pushed out and we will be able to take advantage

203
11:50.120 --> 11:51.160
of this load-balancing

204
11:51.160 --> 11:52.600
methodologies.