WEBVTT

1
00:00.000 --> 00:08.760
Next, let's take a look at deduplication or not sending redundant data across

2
00:08.760 --> 00:10.160
our network.

3
00:10.160 --> 00:13.370
This is of course one of the most obvious ways to get better performance out of

4
00:13.370 --> 00:14.800
our win is

5
00:14.800 --> 00:17.400
simply to send less traffic across it.

6
00:17.400 --> 00:21.280
So this is going to include topics such as compression, which of course is

7
00:21.280 --> 00:21.760
sending less

8
00:21.760 --> 00:27.760
data and compression works by reducing or eliminating duplicate data.

9
00:27.760 --> 00:32.320
We're also going to take a look here at smart caching, and then all of this is
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

9
00:27.760 --> 00:32.320
We're also going to take a look here at smart caching, and then all of this is

10
00:32.320 --> 00:33.440
managed through

11
00:33.440 --> 00:35.320
something called profiles.

12
00:35.320 --> 00:41.220
So let's go ahead and jump in and take a look at how we do our packet dedupl

13
00:41.220 --> 00:42.240
ication.

14
00:42.240 --> 00:48.250
So as we mentioned during the introduction, data redundancy elimination or dedu

15
00:48.250 --> 00:49.080
plication

16
00:49.080 --> 00:55.520
of data has three major components, the first of which is the data removal

17
00:55.520 --> 00:56.520
itself.

18
00:56.520 --> 00:59.760
And the way we're going to do this is through smart caching.

19
00:59.760 --> 01:03.120
We're going to talk about this more in just a second.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

19
00:59.760 --> 01:03.120
We're going to talk about this more in just a second.

20
01:03.120 --> 01:06.840
The second component is the actual data compression.

21
01:06.840 --> 01:11.630
And as we said, whenever you do data compression, you are of course removing

22
01:11.630 --> 01:12.760
duplication.

23
01:12.760 --> 01:14.920
That's how compression works.

24
01:14.920 --> 01:20.600
And all of this is going to be handled, managed or you could say sized with a D

25
01:20.600 --> 01:22.160
RE profile.

26
01:22.160 --> 01:28.490
Now clearly things like smart caching are going to take space and things like

27
01:28.490 --> 01:30.240
data compression
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

27
01:28.490 --> 01:30.240
data compression

28
01:30.240 --> 01:33.400
are going to take CPU.

29
01:33.400 --> 01:37.840
So DRE in general takes resources.

30
01:37.840 --> 01:44.410
This is what the profile is about, how many resources for both space and CPU

31
01:44.410 --> 01:45.320
are going

32
01:45.320 --> 01:47.720
to be made available to DRE.

33
01:47.720 --> 01:51.920
And this is of course naturally going to depend on the platform.

34
01:51.920 --> 01:55.680
We'll talk more about that in just a moment.

35
01:55.680 --> 01:58.200
But first, what exactly are we talking about?

36
01:58.200 --> 02:04.410
So for the data removal, first we have to understand that the LAN segments send
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

36
01:58.200 --> 02:04.410
So for the data removal, first we have to understand that the LAN segments send

37
02:04.410 --> 02:05.080
the full

38
02:05.080 --> 02:06.240
data.

39
02:06.240 --> 02:10.040
So essentially what you're going to have is you're going to have your WAN edge

40
02:10.040 --> 02:11.000
devices.

41
02:11.000 --> 02:16.040
These are of course going to be connected by some form of a WAN.

42
02:16.040 --> 02:20.790
And of course on each side of this, you're going to have a LAN with your

43
02:20.790 --> 02:21.800
resources, work

44
02:21.800 --> 02:26.040
stations, servers and so on that need to talk.

45
02:26.040 --> 02:32.220
On this side or the inside, the LAN segments of each of these devices is going
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

45
02:26.040 --> 02:32.220
On this side or the inside, the LAN segments of each of these devices is going

46
02:32.220 --> 02:33.200
to be normal

47
02:33.200 --> 02:36.120
standard TCP communication.

48
02:36.120 --> 02:41.960
However, the overlay, so again that tunnel that's going to be formed between

49
02:41.960 --> 02:42.640
the edge

50
02:42.640 --> 02:43.640
devices.

51
02:43.640 --> 02:49.330
Again, this is an IPsec tunnel, but the overlay tunnel, this is where we're

52
02:49.330 --> 02:50.680
going to be doing

53
02:50.680 --> 02:52.480
the DRE.

54
02:52.480 --> 02:57.480
So given that the tunnel is going to be using the data removal, again, what are

55
02:57.480 --> 02:58.400
we referring

56
02:58.400 --> 02:59.400
to?

57
02:59.400 --> 03:05.040
Well, first like we mentioned, this uses a shared cache architecture.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

57
02:59.400 --> 03:05.040
Well, first like we mentioned, this uses a shared cache architecture.

58
03:05.040 --> 03:08.280
This cache is going to be synchronized.

59
03:08.280 --> 03:13.390
So the first time the data is sent from one side to the other, that data is

60
03:13.390 --> 03:13.920
going to be

61
03:13.920 --> 03:18.240
cached on each of our WAN edge devices.

62
03:18.240 --> 03:21.880
If at some point that data changes.

63
03:21.880 --> 03:26.300
So perhaps our headquarters site here sends that same data out to some other

64
03:26.300 --> 03:26.920
site that

65
03:26.920 --> 03:29.440
I didn't draw on the diagram here.

66
03:29.440 --> 03:34.880
Well now the head end router knows that that data has been updated.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

66
03:29.440 --> 03:34.880
Well now the head end router knows that that data has been updated.

67
03:34.880 --> 03:39.680
So what it's going to do, it's going to update the cache in the other edge

68
03:39.680 --> 03:40.800
routers that have

69
03:40.800 --> 03:42.920
that same cache.

70
03:42.920 --> 03:47.760
So that takes care of the synchronization and getting the cache updated.

71
03:47.760 --> 03:49.840
But how does it actually function?

72
03:49.840 --> 03:52.200
So let's clean this up a little bit.

73
03:52.200 --> 03:57.690
So now let's say that somebody else at the same site requests that same piece

74
03:57.690 --> 03:59.160
of information.

75
03:59.160 --> 04:02.640
Well the request is going to come in and hit this WAN edge router, who's going
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

75
03:59.160 --> 04:02.640
Well the request is going to come in and hit this WAN edge router, who's going

76
04:02.640 --> 04:03.200
to say,

77
04:03.200 --> 04:06.360
wait a minute, that's cached information.

78
04:06.360 --> 04:09.800
There's no need to send this across the WAN.

79
04:09.800 --> 04:15.060
Instead what it does is it sends a reference number to the cache information on

80
04:15.060 --> 04:15.600
the other

81
04:15.600 --> 04:20.400
device saying this is the information the client requested.

82
04:20.400 --> 04:25.310
So this device then sends the client the information that was requested from

83
04:25.310 --> 04:27.320
the local cache.

84
04:27.320 --> 04:32.970
So as we can see here the only thing that's actually being sent across the
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

84
04:27.320 --> 04:32.970
So as we can see here the only thing that's actually being sent across the

85
04:32.970 --> 04:33.800
tunnel is the

86
04:33.800 --> 04:39.560
reference to the data, not the data itself, which of course is going to be much

87
04:39.560 --> 04:41.680
much smaller.

88
04:41.680 --> 04:46.500
Now of course as we mentioned before, clearly this is going to take storage

89
04:46.500 --> 04:47.400
space on the

90
04:47.400 --> 04:49.320
WAN edge devices.

91
04:49.320 --> 04:53.880
There's just no way around that because it is storing that local cache.

92
04:53.880 --> 04:58.440
So there are going to be minimum RAM and storage requirements.

93
04:58.440 --> 05:03.440
Of course the bigger one in this case is going to be the storage requirements.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

93
04:58.440 --> 05:03.440
Of course the bigger one in this case is going to be the storage requirements.

94
05:03.440 --> 05:07.520
But nonetheless there are some requirements for this to function.

95
05:07.520 --> 05:12.080
The next piece of all of this of course is the data compression.

96
05:12.080 --> 05:19.630
Now DRE uses the LZW algorithm, which of course like most algorithms is named

97
05:19.630 --> 05:20.800
after the people

98
05:20.800 --> 05:25.680
who created it, whose names I am not going to attempt to say.

99
05:25.680 --> 05:30.040
But it's LZW, this is the compression algorithm that we use.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

99
05:25.680 --> 05:30.040
But it's LZW, this is the compression algorithm that we use.

100
05:30.040 --> 05:33.880
And the cool thing is this is a time tested algorithm.

101
05:33.880 --> 05:38.330
This has been around for a really long time and it's used in a lot of different

102
05:38.330 --> 05:39.120
things.

103
05:39.120 --> 05:43.120
We use this in graphic formats for images.

104
05:43.120 --> 05:47.480
We use this in PDF documents if we choose to compress them.

105
05:47.480 --> 05:52.230
And of course good old fax machines, that was a very important place we use

106
05:52.230 --> 05:53.000
these.

107
05:53.000 --> 05:56.610
I don't know the last time you even saw a fax machine, but just in case you

108
05:56.610 --> 05:57.520
were wondering

109
05:57.520 --> 05:59.680
they use LZW.

110
05:59.680 --> 06:04.560
And of course LZW is still used for file archives.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

110
05:59.680 --> 06:04.560
And of course LZW is still used for file archives.

111
06:04.560 --> 06:09.300
So essentially we're just using this well known compression algorithm to

112
06:09.300 --> 06:10.040
compress the

113
06:10.040 --> 06:11.040
data.

114
06:11.040 --> 06:18.080
As I've mentioned previously, we do have to make sure that the CPU involved in

115
06:18.080 --> 06:18.560
doing

116
06:18.560 --> 06:25.080
the compression and decompression on the receiving side is actually saving us

117
06:25.080 --> 06:26.280
bandwidth.

118
06:26.280 --> 06:31.320
In other words, sometimes it's faster to just send all the data than it is to
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

118
06:26.280 --> 06:31.320
In other words, sometimes it's faster to just send all the data than it is to

119
06:31.320 --> 06:32.040
compress

120
06:32.040 --> 06:33.560
and decompress it.

121
06:33.560 --> 06:39.520
We have to look at the CPU utilization versus the speed of the WAN link.

122
06:39.520 --> 06:45.160
The faster the WAN link, the less likely data compression is to help.

123
06:45.160 --> 06:49.120
The final component of course is the DRE profiles.

124
06:49.120 --> 06:54.210
This allows the reservation of these resources based on what that particular

125
06:54.210 --> 06:55.320
branch requires

126
06:55.320 --> 07:00.920
and possibly the size or type of the edge device deployed.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

126
06:55.320 --> 07:00.920
and possibly the size or type of the edge device deployed.

127
07:00.920 --> 07:06.770
So the profiles are simply small, medium, large and extra large, as if you're

128
07:06.770 --> 07:07.600
ordering

129
07:07.600 --> 07:10.040
fries or a soda.

130
07:10.040 --> 07:13.640
But the point is that doesn't really tell us much.

131
07:13.640 --> 07:18.120
So let's jump over to Cisco's documentation real quick and take a look at what

132
07:18.120 --> 07:19.520
these DRE

133
07:19.520 --> 07:25.440
profiles actually mean and what type of devices each one is supported on.

134
07:25.440 --> 07:31.270
So here we're looking at the SD WAN app QOE configuration guide specifically
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

134
07:25.440 --> 07:31.270
So here we're looking at the SD WAN app QOE configuration guide specifically

135
07:31.270 --> 07:32.280
for release

136
07:32.280 --> 07:40.000
17.x and we're under the section for traffic optimization with DRE.

137
07:40.000 --> 07:43.390
Now if we look down over here, of course, there's a lot of things we can look

138
07:43.390 --> 07:43.840
at, but

139
07:43.840 --> 07:49.490
specifically if we scroll down here a bit to the overview of DRE, we'll see

140
07:49.490 --> 07:50.120
here what

141
07:50.120 --> 07:55.300
I was talking about about how on the land sides we're not doing DRE and this is

142
07:55.300 --> 07:55.720
just

143
07:55.720 --> 08:00.040
happening on the SD WAN overlay tunnel in the middle.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

143
07:55.720 --> 08:00.040
happening on the SD WAN overlay tunnel in the middle.

144
08:00.040 --> 08:04.410
Going down here a little further, we see those DRE profiles that are being

145
08:04.410 --> 08:06.040
defined here.

146
08:06.040 --> 08:09.990
But once again, this isn't really telling us what they are or what they

147
08:09.990 --> 08:11.680
actually support.

148
08:11.680 --> 08:15.240
So for that, we need to scroll down just a little bit further.

149
08:15.240 --> 08:19.460
But before we get all the way down to the profiles, take a look here at the

150
08:19.460 --> 08:20.200
different

151
08:20.200 --> 08:22.640
devices that are supported.

152
08:22.640 --> 08:27.340
So here we're listing the different devices that are either integrated or

153
08:27.340 --> 08:28.520
external service

154
08:28.520 --> 08:31.040
nodes and controllers.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

154
08:28.520 --> 08:31.040
nodes and controllers.

155
08:31.040 --> 08:37.900
We see here which release of iOS XE is required and how much RAM, storage and/

156
08:37.900 --> 08:39.680
or virtual CPUs

157
08:39.680 --> 08:43.400
are required for each of these devices.

158
08:43.400 --> 08:49.580
Also a little bit further down here, we see the disk requirements for DRE and

159
08:49.580 --> 08:50.200
we see the

160
08:50.200 --> 08:53.600
secondary disk requirements for DRE.

161
08:53.600 --> 08:58.800
So again, there is storage required in order for this to work.

162
08:58.800 --> 09:05.280
And finally, further down, we get to the supported DRE profiles.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

162
08:58.800 --> 09:05.280
And finally, further down, we get to the supported DRE profiles.

163
09:05.280 --> 09:11.110
And we can see here for each different platform which DRE profiles are

164
09:11.110 --> 09:13.520
supported, we see clearly

165
09:13.520 --> 09:17.080
that not all of them support all the sizes.

166
09:17.080 --> 09:21.640
So you need to step up to something like this to get the XL for example.

167
09:21.640 --> 09:25.440
So on the catalyst 8,700L.

168
09:25.440 --> 09:29.960
So again, we need to reference this chart because of course things like this

169
09:29.960 --> 09:30.560
change,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

169
09:29.960 --> 09:30.560
change,

170
09:30.560 --> 09:36.640
I have provided a link to this section of the document down below this video.

171
09:36.640 --> 09:40.100
And of course, I would encourage you to reference that before you choose to

172
09:40.100 --> 09:41.720
deploy DRE in your

173
09:41.720 --> 09:43.840
environment.

174
09:43.840 --> 09:48.660
So in this video, we took a look at data redundancy elimination or dedupl

175
09:48.660 --> 09:49.440
ication of

176
09:49.440 --> 09:50.560
our data.

177
09:50.560 --> 09:56.150
We do this of course primarily through compression as we saw and through smart

178
09:56.150 --> 09:57.080
caching.

179
09:57.080 --> 10:04.800
Of course, those do require RAM, CPU and storage on those edge devices.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

179
09:57.080 --> 10:04.800
Of course, those do require RAM, CPU and storage on those edge devices.

180
10:04.800 --> 10:09.770
And how much of that is available is of course, well, dependent on the device

181
10:09.770 --> 10:11.360
itself and managed

182
10:11.360 --> 10:13.680
through DRE profiles.

183
10:13.680 --> 10:18.340
So now that we have a good idea of how DRE works, let's jump in and take a look

184
10:18.340 --> 10:18.920
at sort

185
10:18.920 --> 10:22.800
of the opposite of this, which is packet duplication.

186
10:22.800 --> 10:32.800
[BLANK_AUDIO]