WEBVTT

1
00:00.000 --> 00:09.200
Next, let's take a closer look at AAR or Application Aware Routing.

2
00:09.200 --> 00:15.200
The main function here is to identify the traffic based on deep packet

3
00:15.200 --> 00:17.000
inspection and then

4
00:17.000 --> 00:20.680
appropriately send that traffic down a tunnel.

5
00:20.680 --> 00:24.400
Now that tunnel is going to be based on our policies.

6
00:24.400 --> 00:28.570
We can choose the tunnels based on a variety of measurements, which of course

7
00:28.570 --> 00:29.240
will explore

8
00:29.240 --> 00:31.680
more in this video.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

8
00:29.240 --> 00:31.680
more in this video.

9
00:31.680 --> 00:35.610
But once we've chosen the best tunnel, it will then send the traffic down that

10
00:35.610 --> 00:36.400
appropriate

11
00:36.400 --> 00:37.480
tunnel.

12
00:37.480 --> 00:41.930
And the other really cool thing is if a tunnel were to fail or the attributes

13
00:41.930 --> 00:42.600
of that tunnel

14
00:42.600 --> 00:46.720
were to change, it will reroute the traffic accordingly.

15
00:46.720 --> 00:52.600
So let's jump in and take a closer look at AAR.

16
00:52.600 --> 00:58.180
So let's begin by talking about the attributes that AAR is going to be using to

17
00:58.180 --> 00:58.840
choose

18
00:58.840 --> 01:01.120
that best path.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

18
00:58.840 --> 01:01.120
that best path.

19
01:01.120 --> 01:06.880
And it's going to choose this best path based on a service level agreement and

20
01:06.880 --> 01:07.760
on the following

21
01:07.760 --> 01:09.680
attributes.

22
01:09.680 --> 01:13.000
First it's going to be looking at packet loss.

23
01:13.000 --> 01:16.320
Of course, lowest packet loss is going to be preferred.

24
01:16.320 --> 01:18.760
We don't want to lose packets.

25
01:18.760 --> 01:21.080
Then we're going to look at latency.

26
01:21.080 --> 01:26.280
Remember that latency is the end to end delay on a connection.

27
01:26.280 --> 01:28.280
Then we'll look at jitter.

28
01:28.280 --> 01:33.960
Remember that jitter is a variation in the delay or the latency.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

28
01:28.280 --> 01:33.960
Remember that jitter is a variation in the delay or the latency.

29
01:33.960 --> 01:38.880
So this is going to be really bad for certain applications such as voice.

30
01:38.880 --> 01:42.540
So if we're going to send voice down a particular tunnel, we would want to make

31
01:42.540 --> 01:43.440
sure that it has

32
01:43.440 --> 01:45.600
very low jitter.

33
01:45.600 --> 01:49.740
It will also look at the current load on the circuit and choose of course the

34
01:49.740 --> 01:50.320
one with

35
01:50.320 --> 01:52.400
the lowest load.

36
01:52.400 --> 01:57.580
Then there's of course cost which is just an arbitrary value that we can assign

37
01:57.580 --> 01:57.960
to have

38
01:57.960 --> 02:01.720
it prefer certain paths if we choose to do so.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

38
01:57.960 --> 02:01.720
it prefer certain paths if we choose to do so.

39
02:01.720 --> 02:05.200
And finally it will also look at bandwidth.

40
02:05.200 --> 02:11.990
So given all of these criteria, it will choose the best path based on again the

41
02:11.990 --> 02:12.560
SLA that

42
02:12.560 --> 02:19.120
we create saying what our requirements are for each of these other values.

43
02:19.120 --> 02:24.020
Now as I mentioned during the introduction in the event of a failure, the

44
02:24.020 --> 02:25.320
really cool thing

45
02:25.320 --> 02:30.520
is that AAR is going to re-optimize that traffic flow.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

45
02:25.320 --> 02:30.520
is that AAR is going to re-optimize that traffic flow.

46
02:30.520 --> 02:35.160
And the reason that's so important is that optimization is going to

47
02:35.160 --> 02:36.840
significantly reduce

48
02:36.840 --> 02:37.840
costs.

49
02:37.840 --> 02:39.080
Why?

50
02:39.080 --> 02:44.040
Because we're always going to be using the best tunnel available for the type

51
02:44.040 --> 02:44.840
of traffic

52
02:44.840 --> 02:47.400
that we need to prioritize.

53
02:47.400 --> 02:52.530
And because we're optimizing across multiple tunnels based on different types

54
02:52.530 --> 02:53.440
of traffic,

55
02:53.440 --> 02:57.270
that means that we're actually going to be increasing our performance without

56
02:57.270 --> 02:57.840
actually

57
02:57.840 --> 03:00.000
having to do WAN upgrades.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

58
03:00.000 --> 03:04.640
Again, that's part of where this cost savings comes in as well.

59
03:04.640 --> 03:08.850
Now of course in order to accomplish this, each router is going to have to have

60
03:08.850 --> 03:09.440
multiple

61
03:09.440 --> 03:12.040
WAN lengths or T-locks.

62
03:12.040 --> 03:19.110
And in fact, each router can have up to eight T-locks or WAN lengths that it

63
03:19.110 --> 03:20.120
can use for

64
03:20.120 --> 03:26.360
load sharing, re-optimization, and that it can use to choose the best path.

65
03:26.360 --> 03:31.760
Now of course, all of this information has to be exchanged between the devices.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

65
03:26.360 --> 03:31.760
Now of course, all of this information has to be exchanged between the devices.

66
03:31.760 --> 03:35.200
In order to do that, we're going to be using OMP.

67
03:35.200 --> 03:40.320
This is what advertises all those attributes and routes that are available for

68
03:40.320 --> 03:40.880
each of

69
03:40.880 --> 03:41.880
our links.

70
03:41.880 --> 03:45.720
We have to know which destinations are available down which tunnels, and we

71
03:45.720 --> 03:46.600
have to know all

72
03:46.600 --> 03:51.240
of the attributes of those tunnels to choose the best one.

73
03:51.240 --> 03:55.510
Then of course, like I said, it's going to look at our best path policies,

74
03:55.510 --> 03:56.540
which are based

75
03:56.540 --> 04:02.180
on those SLAs, and it's going to choose the optimal or best path for the
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

75
03:56.540 --> 04:02.180
on those SLAs, and it's going to choose the optimal or best path for the

76
04:02.180 --> 04:03.240
network.

77
04:03.240 --> 04:08.390
So all of this is really cool, but let's talk about the actual mechanisms that

78
04:08.390 --> 04:08.760
are being

79
04:08.760 --> 04:11.440
used to make all of this happen.

80
04:11.440 --> 04:17.690
First and foremost, the WAN edge is going to be installing routes to enforce

81
04:17.690 --> 04:19.000
this behavior

82
04:19.000 --> 04:21.040
that we want it to enforce.

83
04:21.040 --> 04:26.960
That's how it's going to send the correct traffic down the correct tunnels.

84
04:26.960 --> 04:32.930
If there are multiple equal tunnels, it will do equal cause multi-pathing if we
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

84
04:26.960 --> 04:32.930
If there are multiple equal tunnels, it will do equal cause multi-pathing if we

85
04:32.930 --> 04:33.800
have identical

86
04:33.800 --> 04:34.800
paths.

87
04:34.800 --> 04:39.350
So it's not like it's going to choose just one if it has multiple paths that

88
04:39.350 --> 04:39.960
all meet

89
04:39.960 --> 04:46.760
the criteria of this best path policy that we were talking about right up here.

90
04:46.760 --> 04:52.760
So if multiple tunnels meet the criteria, it will do equal cause multi-pathing.

91
04:52.760 --> 04:56.240
Now the next question of course is how does it know?

92
04:56.240 --> 04:58.600
How do we actually measure the tunnel?

93
04:58.600 --> 05:03.280
And the answer for that is we use BFD pros.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

93
04:58.600 --> 05:03.280
And the answer for that is we use BFD pros.

94
05:03.280 --> 05:07.320
Now if you don't remember or you're not real familiar with it, BFD is bidire

95
05:07.320 --> 05:08.240
ctional forwarding

96
05:08.240 --> 05:09.640
detection.

97
05:09.640 --> 05:14.200
This is a mechanism that we generally use to make sure a link is up and active.

98
05:14.200 --> 05:21.650
However, we can also use the information from BFD, monitor it with the SLA to

99
05:21.650 --> 05:22.840
make sure that

100
05:22.840 --> 05:26.080
we're meeting the SLA for a particular tunnel.

101
05:26.080 --> 05:30.520
That's how we know if it's going to meet our best path policy.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

101
05:26.080 --> 05:30.520
That's how we know if it's going to meet our best path policy.

102
05:30.520 --> 05:35.090
Now another really cool thing that we can do as administrators is we can choose

103
05:35.090 --> 05:35.520
not only

104
05:35.520 --> 05:41.280
the primary path that we're going to use, but we can also choose a backup.

105
05:41.280 --> 05:47.420
So if a particular tunnel fails or maybe we run out of tunnels in our best path

106
05:47.420 --> 05:48.280
policy,

107
05:48.280 --> 05:51.800
we can have a backup for that application.

108
05:51.800 --> 05:58.080
AAR itself is configured as a centralized data policy.

109
05:58.080 --> 06:04.060
And essentially what it's doing is mapping an application to a particular SLA
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

109
05:58.080 --> 06:04.060
And essentially what it's doing is mapping an application to a particular SLA

110
06:04.060 --> 06:05.480
requirement.

111
06:05.480 --> 06:10.140
So in other words, the best path policy again that we were referring to up

112
06:10.140 --> 06:10.840
above.

113
06:10.840 --> 06:16.870
We're going to say this application needs this SLA requirement and then AAR is

114
06:16.870 --> 06:17.360
going to

115
06:17.360 --> 06:23.640
map that application to a tunnel that meets that SLA requirement.

116
06:23.640 --> 06:30.560
And one other cool thing about AAR is there's actually an AAR default policy.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

116
06:23.640 --> 06:30.560
And one other cool thing about AAR is there's actually an AAR default policy.

117
06:30.560 --> 06:35.070
So you can have a default policy, which is basically how it's going to treat

118
06:35.070 --> 06:35.680
traffic

119
06:35.680 --> 06:38.880
if nothing else specifies differently.

120
06:38.880 --> 06:45.960
And there is a wizard supplied in SDWand Manager to help configure this default

121
06:45.960 --> 06:47.040
policy.

122
06:47.040 --> 06:51.370
It's going to walk us through configuring the three elements needed for this

123
06:51.370 --> 06:52.120
policy.

124
06:52.120 --> 06:54.000
That being identification.

125
06:54.000 --> 06:58.960
So again, choosing the traffic itself, how we're going to do our monitoring and

126
06:58.960 --> 06:59.720
measuring

127
06:59.720 --> 07:03.680
as far as making sure that the traffic is going the way we want and making sure
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

127
06:59.720 --> 07:03.680
as far as making sure that the traffic is going the way we want and making sure

128
07:03.680 --> 07:04.160
that it's

129
07:04.160 --> 07:06.360
working properly.

130
07:06.360 --> 07:13.200
And then ultimately mapping that application traffic to a particular tunnel.

131
07:13.200 --> 07:16.800
So setting up the default policy is not necessarily a requirement.

132
07:16.800 --> 07:22.720
However, they do provide a wizard to do this if we choose to do so.

133
07:22.720 --> 07:27.570
So in this video, we just jumped in and took a look at some more detail on

134
07:27.570 --> 07:28.560
application

135
07:28.560 --> 07:29.920
aware routing.

136
07:29.920 --> 07:34.730
How it's going to match on a particular application and then based on our SLA
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

136
07:29.920 --> 07:34.730
How it's going to match on a particular application and then based on our SLA

137
07:34.730 --> 07:36.240
requirements, basically

138
07:36.240 --> 07:41.720
our best path policy, we're then going to choose the tunnels that are eligible

139
07:41.720 --> 07:43.200
for the traffic

140
07:43.200 --> 07:49.020
and then either send it down a particular tunnel or do equal cost multi-pathing

141
07:49.020 --> 07:49.840
across multiple

142
07:49.840 --> 07:52.600
tunnels in the case of a tie.

143
07:52.600 --> 07:56.430
But either way, we're going to be using this to make intelligent decisions

144
07:56.430 --> 07:56.880
about which

145
07:56.880 --> 08:02.720
tunnels to use for different applications based on our SLA requirements.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

145
07:56.880 --> 08:02.720
tunnels to use for different applications based on our SLA requirements.

146
08:02.720 --> 08:06.490
So now that we've talked about all of these things about policies, it's time to

147
08:06.490 --> 08:07.040
actually

148
08:07.040 --> 08:12.160
jump into SDWand Manager and take a look at how these are configured.

149
08:12.160 --> 08:15.080
of course exactly what we're going to do in the next video.

150
08:15.080 --> 08:25.080
[BLANK_AUDIO]