WEBVTT

1
00:00.000 --> 00:10.200
Next, let's take a look at how Cloud On-Ran4SaaS handles a situation where we

2
00:10.200 --> 00:11.520
have one local

3
00:11.520 --> 00:16.990
connection to the internet at a branch office and we have a regional gateway

4
00:16.990 --> 00:17.960
that we have

5
00:17.960 --> 00:20.160
a separate connection to.

6
00:20.160 --> 00:24.120
Of course, we can't be connecting to that over the same internet connection,

7
00:24.120 --> 00:24.480
but we

8
00:24.480 --> 00:29.600
have another regional gateway that we can get to through some other form of a W

9
00:29.600 --> 00:30.600
AN connection
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

9
00:29.600 --> 00:30.600
AN connection

10
00:30.600 --> 00:35.160
and that regional office also has an internet connection.

11
00:35.160 --> 00:39.580
Well, we again have to choose the best path and the best exit to use, which

12
00:39.580 --> 00:40.640
could actually

13
00:40.640 --> 00:42.640
be the regional gateway.

14
00:42.640 --> 00:44.560
But either way, we have to figure it out.

15
00:44.560 --> 00:49.210
This is not that different from the previous video where we had multiple exits

16
00:49.210 --> 00:50.040
at the same

17
00:50.040 --> 00:54.880
site, but there are a few more moving parts here because we have to make sort

18
00:54.880 --> 00:55.320
of a more

19
00:55.320 --> 00:58.680
complicated decision involving two different devices.

20
00:58.680 --> 01:01.640
They have to communicate with each other and share information.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

20
00:58.680 --> 01:01.640
They have to communicate with each other and share information.

21
01:01.640 --> 01:06.130
So let's go ahead and jump in and take a look at the rather minor differences,

22
01:06.130 --> 01:06.640
but some

23
01:06.640 --> 01:13.440
differences between this model and the one we just looked at.

24
01:13.440 --> 01:17.880
So probably the main reason we would not just be using multiple links at the

25
01:17.880 --> 01:19.520
same site and

26
01:19.520 --> 01:26.630
rather use a gateway site is because the branch office may only have a single

27
01:26.630 --> 01:28.840
internet connection.

28
01:28.840 --> 01:32.450
Of course, if there's only a single internet connection, then we're going to
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

28
01:28.840 --> 01:32.450
Of course, if there's only a single internet connection, then we're going to

29
01:32.450 --> 01:32.960
have to do

30
01:32.960 --> 01:38.640
something else if we want to provide either redundancy or load sharing.

31
01:38.640 --> 01:44.310
Well, this is where the option comes in that maybe there's a private connection

32
01:44.310 --> 01:45.160
to another

33
01:45.160 --> 01:49.520
site that has a DIA link.

34
01:49.520 --> 01:57.160
In that case, that site can be assigned as a cloud on ramp for SaaS gateway

35
01:57.160 --> 01:58.160
site.

36
01:58.160 --> 02:02.690
And that indicates that we're going to use the internet connection at that
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

36
01:58.160 --> 02:02.690
And that indicates that we're going to use the internet connection at that

37
02:02.690 --> 02:03.560
gateway site

38
02:03.560 --> 02:09.960
as a backup for the single internet connection at the branch office site.

39
02:09.960 --> 02:13.790
Now the way the traffic is going to get to this gateway site is it's going to

40
02:13.790 --> 02:14.560
be tunneled

41
02:14.560 --> 02:19.920
to the gateway just like we do any other SD-WAN traffic.

42
02:19.920 --> 02:26.100
So this would be really no different than any other site to site traffic in SD-

43
02:26.100 --> 02:26.760
WAN because

44
02:26.760 --> 02:30.640
that's really all this is is another site.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

44
02:26.760 --> 02:30.640
that's really all this is is another site.

45
02:30.640 --> 02:36.220
And the other cool thing is we can actually have multiple gateways, maybe use

46
02:36.220 --> 02:36.840
one for

47
02:36.840 --> 02:41.750
one type of traffic, one for another type of traffic, but this gives us even

48
02:41.750 --> 02:43.000
more flexibility

49
02:43.000 --> 02:47.390
when we're designing our network and deciding how we want the traffic to flow

50
02:47.390 --> 02:47.800
when we're

51
02:47.800 --> 02:50.160
involving gateway sites.

52
02:50.160 --> 02:52.440
But how do we actually accomplish this?

53
02:52.440 --> 02:58.310
Well, the fact of the matter is this is going to vary but only really slightly

54
02:58.310 --> 02:58.840
from the way

55
02:58.840 --> 03:03.610
we just did direct internet access at the branches when we had multiple
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

55
02:58.840 --> 03:03.610
we just did direct internet access at the branches when we had multiple

56
03:03.610 --> 03:04.840
connections at

57
03:04.840 --> 03:06.400
the branch office.

58
03:06.400 --> 03:09.280
So let's go through sort of the same steps again.

59
03:09.280 --> 03:13.250
The first thing that's going to happen is we're still going to do that DNS

60
03:13.250 --> 03:14.480
lookup over each

61
03:14.480 --> 03:17.320
available ISP link.

62
03:17.320 --> 03:21.320
That doesn't change except for one keyword here.

63
03:21.320 --> 03:28.200
Both WAN edge routers, meaning the one at the branch and the one at the gateway

64
03:28.200 --> 03:28.840
site.

65
03:28.840 --> 03:35.340
They're both going to do their own DNS queries for the application over each
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

65
03:28.840 --> 03:35.340
They're both going to do their own DNS queries for the application over each

66
03:35.340 --> 03:36.400
ISP link.

67
03:36.400 --> 03:41.040
And then in a similar fashion to what we did before, we're going to start that

68
03:41.040 --> 03:41.680
periodic

69
03:41.680 --> 03:45.320
or active HTTP ping.

70
03:45.320 --> 03:49.320
Remember we're using this to build the QOE score.

71
03:49.320 --> 03:55.440
Once again, the big difference is both routers are doing this individually.

72
03:55.440 --> 04:01.030
So now each router has made its own decision about its best path to get to the
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

72
03:55.440 --> 04:01.030
So now each router has made its own decision about its best path to get to the

73
04:01.030 --> 04:02.400
application.

74
04:02.400 --> 04:05.120
Now here's sort of where everything comes together.

75
04:05.120 --> 04:09.450
The branch edge router and the reason it's important that we understand it's

76
04:09.450 --> 04:10.040
the branch

77
04:10.040 --> 04:14.720
edge router here because it's the one ultimately making the decision.

78
04:14.720 --> 04:19.080
This is the router that's going to actually see the client traffic when it

79
04:19.080 --> 04:19.880
shows up.

80
04:19.880 --> 04:23.320
So this router has to choose the best path.

81
04:23.320 --> 04:25.160
Well, how does it do that?

82
04:25.160 --> 04:30.120
Well, we already know that it's the highest QOE score that wins.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

82
04:25.160 --> 04:30.120
Well, we already know that it's the highest QOE score that wins.

83
04:30.120 --> 04:32.160
But I need both scores.

84
04:32.160 --> 04:39.440
So we're going to compare the local QOE to the gateway QOE.

85
04:39.440 --> 04:45.190
Well how in the world would this branch office router know the QOE from the

86
04:45.190 --> 04:46.200
gateway?

87
04:46.200 --> 04:52.160
Well it's going to be learned through OMP or Overlay Management Protocol.

88
04:52.160 --> 04:57.200
This of course is the main protocol used for communication in SD-WAN.

89
04:57.200 --> 05:00.880
So that's how we're going to actually learn the information.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

89
04:57.200 --> 05:00.880
So that's how we're going to actually learn the information.

90
05:00.880 --> 05:06.760
But the problem is this is going to tell us the QOE from each individual router

91
05:06.760 --> 05:06.960
.

92
05:06.960 --> 05:12.980
Then what we have to do is look at the health, you could almost call it a score

93
05:12.980 --> 05:14.080
, of the actual

94
05:14.080 --> 05:16.880
tunnel to the gateway.

95
05:16.880 --> 05:20.870
Because just looking at the raw QOE score would not be enough, we still have to

96
05:20.870 --> 05:21.120
get

97
05:21.120 --> 05:23.080
to the gateway site.

98
05:23.080 --> 05:28.750
Now the way that tunnel health is determined is going to be through BFD or bid

99
05:28.750 --> 05:29.680
irectional

100
05:29.680 --> 05:36.320
forwarding detection which is enabled automatically on our tunnels in SD-WAN.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

100
05:29.680 --> 05:36.320
forwarding detection which is enabled automatically on our tunnels in SD-WAN.

101
05:36.320 --> 05:39.750
So this is really the fundamental difference here that we're going to be using

102
05:39.750 --> 05:40.480
two different

103
05:40.480 --> 05:46.110
QOE scores from two different routers and then using BFD taking into account

104
05:46.110 --> 05:47.000
the health

105
05:47.000 --> 05:49.280
of the tunnel between them.

106
05:49.280 --> 05:53.990
The rest of this process is pretty much the same but just to finish it out, the

107
05:53.990 --> 05:54.520
client

108
05:54.520 --> 06:00.360
again initiates that connection, it does its own DNS query.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

108
05:54.520 --> 06:00.360
again initiates that connection, it does its own DNS query.

109
06:00.360 --> 06:05.730
We again use deep packet inspection on the edge router to intercept the DNS

110
06:05.730 --> 06:06.440
query and

111
06:06.440 --> 06:11.500
again assuming it's a monitored SAS application, we're going to forward that

112
06:11.500 --> 06:12.440
over the best

113
06:12.440 --> 06:13.440
path.

114
06:13.440 --> 06:19.920
Again, the one with the highest QOE score and tunnel health combined.

115
06:19.920 --> 06:25.160
If it's not a monitored application, then we just do standard DNS forwarding.

116
06:25.160 --> 06:30.320
And just like before, once that connection is started by the client, the
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

116
06:25.160 --> 06:30.320
And just like before, once that connection is started by the client, the

117
06:30.320 --> 06:31.520
traffic itself

118
06:31.520 --> 06:36.000
is now of course going to flow over that best path.

119
06:36.000 --> 06:41.100
And again, it's going to be using application aware routing to accomplish that

120
06:41.100 --> 06:41.720
goal.

121
06:41.720 --> 06:45.080
So this last section is exactly the same.

122
06:45.080 --> 06:50.560
The only difference is the way we were choosing the best path.

123
06:50.560 --> 06:56.730
So in this video, we covered how Cloud OnRAMP for SaaS handles a gateway site

124
06:56.730 --> 06:58.040
and comparing

125
06:58.040 --> 07:02.080
the exit from the gateway site to the local exit.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

125
06:58.040 --> 07:02.080
the exit from the gateway site to the local exit.

126
07:02.080 --> 07:08.850
Again, the biggest difference here is we're exchanging that QOE score using OMP

127
07:08.850 --> 07:09.360
and we're

128
07:09.360 --> 07:13.600
monitoring the health of the tunnel using BFD.

129
07:13.600 --> 07:15.920
Those are the big things to keep in mind.

130
07:15.920 --> 07:19.840
So next, let's take a look at what happens if we involve a co-location.

131
07:19.840 --> 07:29.840
[BLANK_AUDIO]