WEBVTT

1
00:00.000 --> 00:06.800
So now that we have our underlay squared away, it's time to turn our attention

2
00:06.800 --> 00:08.320
to the overlay,

3
00:08.320 --> 00:14.280
specifically talking about overlay routing, which means OMP.

4
00:14.280 --> 00:17.120
So our focus here is going to be on OMP.

5
00:17.120 --> 00:20.590
We're going to take a look at some of its attributes that we want to be aware

6
00:20.590 --> 00:21.240
of, specifically

7
00:21.240 --> 00:23.000
for troubleshooting.

8
00:23.000 --> 00:27.880
Then as usual, take a look at some troubleshooting commands that we can use.

9
00:27.880 --> 00:32.110
And we're going to talk about a very specific problem that we can have when we
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

9
00:27.880 --> 00:32.110
And we're going to talk about a very specific problem that we can have when we

10
00:32.110 --> 00:32.760
're using

11
00:32.760 --> 00:40.190
OMP in conjunction with BGP and two ways that we can solve the problem that

12
00:40.190 --> 00:40.760
comes up

13
00:40.760 --> 00:42.720
in that type of an environment.

14
00:42.720 --> 00:48.910
So let's go ahead and jump in and get started taking a look at some of the

15
00:48.910 --> 00:50.640
aspects of OMP.

16
00:50.640 --> 00:57.320
So remember that the whole goal of our overlay is to build IPsec tunnels.

17
00:57.320 --> 01:03.200
And those IPsec tunnels are created between our T-locks.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

17
00:57.320 --> 01:03.200
And those IPsec tunnels are created between our T-locks.

18
01:03.200 --> 01:09.040
Information about how to reach those T-locks is exchanged using OMP.

19
01:09.040 --> 01:11.640
So that's what we're using for our routing.

20
01:11.640 --> 01:14.640
So some of the attributes of OMP.

21
01:14.640 --> 01:19.040
First, this is definitely control plane only.

22
01:19.040 --> 01:25.570
We don't use OMP for any of our actual traffic forwarding because this actually

23
01:25.570 --> 01:26.560
runs on the

24
01:26.560 --> 01:28.760
V-Smart controllers.

25
01:28.760 --> 01:36.560
In fact, OMP acts a lot like a BGP route reflector type design where the V-
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

25
01:28.760 --> 01:36.560
In fact, OMP acts a lot like a BGP route reflector type design where the V-

26
01:36.560 --> 01:38.760
Smart controller is

27
01:38.760 --> 01:41.840
acting as the route reflector.

28
01:41.840 --> 01:47.150
And just like in a BGP route reflector design, we don't necessarily need that

29
01:47.150 --> 01:48.000
to be in the

30
01:48.000 --> 01:50.880
data plane or in the forwarding path.

31
01:50.880 --> 01:55.840
In fact, most of the time I would argue that it's not in the majority of

32
01:55.840 --> 01:56.800
designs.

33
01:56.800 --> 02:02.570
Now where OMP gets a little bit different from BGP is this actually carries
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

33
01:56.800 --> 02:02.570
Now where OMP gets a little bit different from BGP is this actually carries

34
02:02.570 --> 02:04.080
more information

35
02:04.080 --> 02:06.320
than BGP does.

36
02:06.320 --> 02:09.600
And BGP already is quite capable.

37
02:09.600 --> 02:14.620
But what's added in OMP is things like collecting statistics from the devices,

38
02:14.620 --> 02:15.760
how much traffic

39
02:15.760 --> 02:17.680
is going through interfaces.

40
02:17.680 --> 02:19.240
CPU load.

41
02:19.240 --> 02:23.360
Things along this line are also carried in OMP.

42
02:23.360 --> 02:27.760
So in other words, it's much more than just the routing.

43
02:27.760 --> 02:32.150
But right now we are focusing on the routing aspect because of course that is
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

43
02:27.760 --> 02:32.150
But right now we are focusing on the routing aspect because of course that is

44
02:32.150 --> 02:32.720
what allows

45
02:32.720 --> 02:38.750
us to build the tunnels which are of course the overlay which is our current

46
02:38.750 --> 02:39.920
topic.

47
02:39.920 --> 02:46.350
And finally, OMP does in fact run over those DTLS connections that are being

48
02:46.350 --> 02:47.660
built between

49
02:47.660 --> 02:51.100
our devices in the underlay.

50
02:51.100 --> 02:57.500
And finally, one more thing to discuss as far as attributes, when we use BGP

51
02:57.500 --> 02:58.360
with OMP,

52
02:58.360 --> 03:04.130
so in other words, OMP in the overlay and BGP at the edges, we do have to make
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

52
02:58.360 --> 03:04.130
so in other words, OMP in the overlay and BGP at the edges, we do have to make

53
03:04.130 --> 03:04.660
sure

54
03:04.660 --> 03:08.280
that we are avoiding possible routing loops.

55
03:08.280 --> 03:12.740
We'll discuss this in just a moment and see the ways that we can avoid this

56
03:12.740 --> 03:13.320
loop.

57
03:13.320 --> 03:17.260
And of course, we'll also discuss how the loop can occur.

58
03:17.260 --> 03:21.460
Before we do that however, let's take a look at some of our verification

59
03:21.460 --> 03:22.280
commands.

60
03:22.280 --> 03:27.050
So for verification, we have show OMP peers, which is a great command to see

61
03:27.050 --> 03:28.580
our neighborships.

62
03:28.580 --> 03:32.590
We have show OMP routes, which will of course show us all of the routes that
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

62
03:28.580 --> 03:32.590
We have show OMP routes, which will of course show us all of the routes that

63
03:32.590 --> 03:33.800
have been learned

64
03:33.800 --> 03:35.500
by OMP.

65
03:35.500 --> 03:40.040
We can also do a show run OMP just to look at its current configuration.

66
03:40.040 --> 03:45.660
And of course, another good one is show OMP T-locks, which would be all the T-

67
03:45.660 --> 03:46.360
locks that

68
03:46.360 --> 03:47.620
we have learned.

69
03:47.620 --> 03:51.360
So before we jump too much into the looping problem, let's jump into the

70
03:51.360 --> 03:52.120
command line

71
03:52.120 --> 03:54.820
and take a look at these commands.

72
03:54.820 --> 03:58.350
So we'll look at these commands on the controller, since again, this is acting

73
03:58.350 --> 03:58.900
as the route

74
03:58.900 --> 03:59.900
reflector.

75
03:59.900 --> 04:03.780
So again, let's start with our show OMP peers.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

75
03:59.900 --> 04:03.780
So again, let's start with our show OMP peers.

76
04:03.780 --> 04:06.580
And here we see our V edge devices.

77
04:06.580 --> 04:08.820
We see our two on-prem routers.

78
04:08.820 --> 04:13.770
And we also see the two routers that have been deployed into AWS, which is our

79
04:13.770 --> 04:15.900
site 20.

80
04:15.900 --> 04:19.340
Next we'll take a look at show OMP routes.

81
04:19.340 --> 04:23.240
Now as you can see, this is actually quite a long output.

82
04:23.240 --> 04:25.360
But first we can see the route itself.

83
04:25.360 --> 04:28.640
So in this case, it's 10 dot 10 dot 10 dot zero.

84
04:28.640 --> 04:34.360
And we can see that we have learned it from the peer 10 dot 255 dot 255 dot one
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

84
04:28.640 --> 04:34.360
And we can see that we have learned it from the peer 10 dot 255 dot 255 dot one

85
04:34.360 --> 04:34.960
, which

86
04:34.960 --> 04:37.600
is our on-prem R1.

87
04:37.600 --> 04:42.100
There's a lot of other information here, of course, some of the important

88
04:42.100 --> 04:42.960
aspects being

89
04:42.960 --> 04:48.260
the originator, the type being that it's installed in the route table.

90
04:48.260 --> 04:52.180
We can see the T lock where we're going to use its system IP.

91
04:52.180 --> 04:57.520
The color is biz internet and the encapsulation is IP sec.

92
04:57.520 --> 05:01.300
Again looking down over this, we can see other critical information such as it
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

92
04:57.520 --> 05:01.300
Again looking down over this, we can see other critical information such as it

93
05:01.300 --> 05:02.000
's from site

94
05:02.000 --> 05:04.400
ID 100 and so on.

95
05:04.400 --> 05:06.960
Again, there's a lot of information here.

96
05:06.960 --> 05:12.930
We can see that we also learned this prefix from 10 dot 255 dot 255 dot two,

97
05:12.930 --> 05:13.840
which is on-prem

98
05:13.840 --> 05:15.580
R2.

99
05:15.580 --> 05:19.360
And again, as we scroll down, we'll see the different prefixes.

100
05:19.360 --> 05:24.100
Here we see the 10 dot 20 dot zero dot zero slash 16, which is our AWS

101
05:24.100 --> 05:25.200
environment.

102
05:25.200 --> 05:30.080
And we see that the peer on this one is of course the 10 dot 255 dot 20 dot one
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

102
05:25.200 --> 05:30.080
And we see that the peer on this one is of course the 10 dot 255 dot 20 dot one

103
05:30.080 --> 05:30.640
, which

104
05:30.640 --> 05:33.400
is AWS R1.

105
05:33.400 --> 05:35.320
So again, we can go through this whole thing.

106
05:35.320 --> 05:38.720
It's a little long because of the number of prefixes here.

107
05:38.720 --> 05:44.440
And we really only have four routers and two prefixes aside from the transit

108
05:44.440 --> 05:45.120
links in

109
05:45.120 --> 05:46.220
our network.

110
05:46.220 --> 05:50.350
So there's a lot of information here, but needless to say, that's what we want

111
05:50.350 --> 05:50.480
when

112
05:50.480 --> 05:52.960
we're trying to troubleshoot an issue.

113
05:52.960 --> 05:55.760
We could also do a show run OMP.

114
05:55.760 --> 06:00.600
We see here that this is effectively just the default configuration for OMP,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

114
05:55.760 --> 06:00.600
We see here that this is effectively just the default configuration for OMP,

115
06:00.600 --> 06:01.360
but we can

116
06:01.360 --> 06:05.000
change different things in here if we want to.

117
06:05.000 --> 06:08.120
And let's look at the show OMP T locks.

118
06:08.120 --> 06:11.500
This you can see looks sort of similar to the routing table, but this is

119
06:11.500 --> 06:12.240
looking at the

120
06:12.240 --> 06:16.080
actual T locks themselves, not the prefixes.

121
06:16.080 --> 06:21.380
So this is the T lock for 10 dot two, five, five dot 20 dot one on the color b

122
06:21.380 --> 06:22.240
iz internet

123
06:22.240 --> 06:25.200
with the encapsulation IP sec.

124
06:25.200 --> 06:29.040
We can receive that it was actually received from that exact same device that

125
06:29.040 --> 06:29.600
holds that

126
06:29.600 --> 06:31.240
address.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

126
06:29.600 --> 06:31.240
address.

127
06:31.240 --> 06:35.220
And if we look down a little further, we can see things like the public address

128
06:35.220 --> 06:36.080
, the private

129
06:36.080 --> 06:42.560
address, the encapsulation that's going to be used for IP sec and so on.

130
06:42.560 --> 06:46.320
Once again, we have this for all of the T locks in our environment.

131
06:46.320 --> 06:49.400
We don't have to go through all the details on every single one.

132
06:49.400 --> 06:53.740
But of course, if you are trying to troubleshoot a particular T lock, that's

133
06:53.740 --> 06:54.720
exactly what you

134
06:54.720 --> 06:56.400
would want to do.

135
06:56.400 --> 07:01.030
So now let's jump over to a diagram that we can use here to discuss what the
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

135
06:56.400 --> 07:01.030
So now let's jump over to a diagram that we can use here to discuss what the

136
07:01.030 --> 07:02.080
looping problem

137
07:02.080 --> 07:06.560
can be when we're using OMP with BGP.

138
07:06.560 --> 07:09.400
So let's start by discussing the problem.

139
07:09.400 --> 07:13.050
And this is a problem that's going to take place in the event of possibly a

140
07:13.050 --> 07:14.120
couple failures.

141
07:14.120 --> 07:16.840
They don't necessarily have to happen at the same time.

142
07:16.840 --> 07:20.120
But let's walk through it and talk about what's going to happen.

143
07:20.120 --> 07:24.760
So to begin with, let's say that there's a network over here off router to we

144
07:24.760 --> 07:25.160
'll just

145
07:25.160 --> 07:33.450
call this network X router to is going to advertise that route using E BGP over
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

145
07:25.160 --> 07:33.450
call this network X router to is going to advertise that route using E BGP over

146
07:33.450 --> 07:34.320
here

147
07:34.320 --> 07:37.480
to CE three, which is connected to SD WAN.

148
07:37.480 --> 07:44.040
So this is an SD WAN edge router CE three is going to automatically redist

149
07:44.040 --> 07:45.600
ribute this

150
07:45.600 --> 07:47.200
into SD WAN.

151
07:47.200 --> 07:50.080
In other words, into OMP.

152
07:50.080 --> 07:56.250
So this now comes into OMP and is sent by again, the route reflector or the

153
07:56.250 --> 07:57.360
controller

154
07:57.360 --> 08:01.960
into CE one and CE two.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

154
07:57.360 --> 08:01.960
into CE one and CE two.

155
08:01.960 --> 08:07.600
So at this point, both of these routers have learned these routes from OMP.

156
08:07.600 --> 08:13.440
They're now going to take this route and advertise it through E BGP up to

157
08:13.440 --> 08:14.880
router one.

158
08:14.880 --> 08:20.910
And technically they're going to advertise this to each other as well using I B

159
08:20.910 --> 08:21.240
GP.

160
08:21.240 --> 08:24.000
And so far, all of this is fine.

161
08:24.000 --> 08:29.500
CE one and CE two will be preferring the route coming from OMP because that's

162
08:29.500 --> 08:30.400
how they learned
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

162
08:29.500 --> 08:30.400
how they learned

163
08:30.400 --> 08:31.400
it.

164
08:31.400 --> 08:36.770
And they'll redistribute it into I BGP and E BGP towards router one and towards

165
08:36.770 --> 08:37.200
each

166
08:37.200 --> 08:38.200
other.

167
08:38.200 --> 08:40.640
This is not where the problem comes in.

168
08:40.640 --> 08:46.840
Where the problem comes in is when this link right here goes down.

169
08:46.840 --> 08:50.440
Just as an example, of course, there's a couple links that could cause this.

170
08:50.440 --> 08:54.630
But now what's going to happen is, of course, this OMP neighborhood is going to

171
08:54.630 --> 08:55.160
go down

172
08:55.160 --> 08:58.640
and therefore the advertisement is going to go down.

173
08:58.640 --> 09:04.040
What that means is this and this are going to stop because we're no longer
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

173
08:58.640 --> 09:04.040
What that means is this and this are going to stop because we're no longer

174
09:04.040 --> 09:04.920
learning the

175
09:04.920 --> 09:08.120
route from OMP.

176
09:08.120 --> 09:15.160
The problem is that CE two is still receiving this route from CE one.

177
09:15.160 --> 09:19.240
So now it has an I BGP learned route.

178
09:19.240 --> 09:25.120
So now when this link comes back up, an SD-WAN advertises it again.

179
09:25.120 --> 09:30.550
Keep in mind, this is going to come in with an admin distance of the default to
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

179
09:25.120 --> 09:30.550
Keep in mind, this is going to come in with an admin distance of the default to

180
09:30.550 --> 09:31.480
51 when

181
09:31.480 --> 09:39.970
in fact the IBGP has the default of 200 and CE two is now going to continue to

182
09:39.970 --> 09:41.000
believe

183
09:41.000 --> 09:44.040
the IBGP learned route.

184
09:44.040 --> 09:46.720
And here's where the problem gets even worse.

185
09:46.720 --> 09:51.160
Since we're not following this OMP learned route, that means that we're going

186
09:51.160 --> 09:51.680
to feel

187
09:51.680 --> 09:58.320
the obligation that we should advertise this in to SD-WAN because we know about

188
09:58.320 --> 09:59.160
this IBGP

189
09:59.160 --> 10:03.080
prefix that we've learned from CE one.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

189
09:59.160 --> 10:03.080
prefix that we've learned from CE one.

190
10:03.080 --> 10:09.180
Now so far this isn't horribly bad except that CE two is going to be taking a

191
10:09.180 --> 10:09.920
very bad

192
10:09.920 --> 10:14.160
path to get to the X network.

193
10:14.160 --> 10:16.880
It's going to go up through CE one and then into SD-WAN.

194
10:16.880 --> 10:19.480
It's what we call suboptimal routing.

195
10:19.480 --> 10:22.120
But so far it's not a huge problem.

196
10:22.120 --> 10:27.630
Here it becomes sort of a bigger problem is let's say this link over here were

197
10:27.630 --> 10:29.640
to go down.

198
10:29.640 --> 10:36.490
Now this stops, this stops and you might think for a minute that I was going to
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

198
10:29.640 --> 10:36.490
Now this stops, this stops and you might think for a minute that I was going to

199
10:36.490 --> 10:37.400
cross this

200
10:37.400 --> 10:43.840
one out but I'm not going to because now what's going to happen is we're going

201
10:43.840 --> 10:44.960
to take this

202
10:44.960 --> 10:48.320
path coming from CE two down here.

203
10:48.320 --> 10:52.510
We're going to take this path, send it back through SD-WAN and it's going to

204
10:52.510 --> 10:53.120
get sent

205
10:53.120 --> 10:57.640
right back to CE one as an OMP route.

206
10:57.640 --> 11:01.470
So this is where the problem comes in CE one thinks it's still getting the
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

206
10:57.640 --> 11:01.470
So this is where the problem comes in CE one thinks it's still getting the

207
11:01.470 --> 11:03.640
route from OMP.

208
11:03.640 --> 11:09.360
It's still redistributing it into IBGP CE two now thinks it has a valid IBGP

209
11:09.360 --> 11:10.040
route and

210
11:10.040 --> 11:13.840
advertises it right back into SD-WAN.

211
11:13.840 --> 11:17.880
So this is the fundamental problem that we need to fix.

212
11:17.880 --> 11:21.920
Now the good news is there's sort of two ways that we can fix this.

213
11:21.920 --> 11:29.720
The first method is simply to enable a feature called OMP overlay AS.

214
11:29.720 --> 11:33.200
The good news here is this is very easy to configure.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

214
11:29.720 --> 11:33.200
The good news here is this is very easy to configure.

215
11:33.200 --> 11:42.760
We simply go into SD-WAN into OMP and we set an overlay AS number under OMP.

216
11:42.760 --> 11:49.940
And what that does is it implements BGP's own loop prevention to prevent this

217
11:49.940 --> 11:50.800
problem

218
11:50.800 --> 11:54.440
because it's going to stop what's going on right here.

219
11:54.440 --> 11:58.920
Let's take a look at how by bringing that AS number in here.

220
11:58.920 --> 12:04.230
So essentially what it's going to do is it's going to add this OMP overlay AS
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

220
11:58.920 --> 12:04.230
So essentially what it's going to do is it's going to add this OMP overlay AS

221
12:04.230 --> 12:04.840
and as this

222
12:04.840 --> 12:11.940
route is now passed through this environment OMP is now going to add to the AS

223
12:11.940 --> 12:12.960
path that

224
12:12.960 --> 12:15.080
BGP creates.

225
12:15.080 --> 12:22.370
Therefore as this gets sent over here to 65002 and CE one tries to send it down

226
12:22.370 --> 12:22.800
to CE

227
12:22.800 --> 12:24.960
two this is all fine.

228
12:24.960 --> 12:31.250
But when CE two now tries to send it back this is now going to get blocked
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

228
12:24.960 --> 12:31.250
But when CE two now tries to send it back this is now going to get blocked

229
12:31.250 --> 12:32.280
right here

230
12:32.280 --> 12:37.640
because the same AS is going to be in the AS path.

231
12:37.640 --> 12:41.040
So in this example 65003.

232
12:41.040 --> 12:47.680
So this is one way to prevent the loop is by simply enabling this OMP overlay

233
12:47.680 --> 12:49.160
AS feature.

234
12:49.160 --> 12:55.390
Another way to fix it is to use something called the BGP extended community and

235
12:55.390 --> 12:56.560
specifically

236
12:56.560 --> 13:04.760
we're talking about using the SOO or the site of origin extended community.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

236
12:56.560 --> 13:04.760
we're talking about using the SOO or the site of origin extended community.

237
13:04.760 --> 13:07.760
This one is actually a little bit simpler.

238
13:07.760 --> 13:12.280
It simply involves let's say for example that this is site 200.

239
13:12.280 --> 13:16.970
It simply means that when BGP updates are sent to other devices it's going to

240
13:16.970 --> 13:17.560
include

241
13:17.560 --> 13:20.000
this site of origin.

242
13:20.000 --> 13:26.520
If this same site of origin tries to come back into the same environment again.

243
13:26.520 --> 13:32.480
So say for example let's say that CE two tries to send it to CE one.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

243
13:26.520 --> 13:32.480
So say for example let's say that CE two tries to send it to CE one.

244
13:32.480 --> 13:34.480
We simply won't allow it.

245
13:34.480 --> 13:40.410
And the good news is as far as the CE's in this example the actual SD WAN

246
13:40.410 --> 13:41.800
devices that

247
13:41.800 --> 13:46.680
are doing the redistribution they have this enabled by default.

248
13:46.680 --> 13:50.730
But you can enable it on all of your other neighbor connections by simply

249
13:50.730 --> 13:51.520
saying send

250
13:51.520 --> 13:53.200
community both.

251
13:53.200 --> 13:59.600
The reason we need to do this is other Cisco routers do not perpetuate the send

252
13:59.600 --> 14:00.560
community
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

252
13:59.600 --> 14:00.560
community

253
14:00.560 --> 14:02.320
by default.

254
14:02.320 --> 14:07.570
The reason we need the both is because this is an extended community and we

255
14:07.570 --> 14:08.520
need to send

256
14:08.520 --> 14:12.600
extended communities not just standard communities.

257
14:12.600 --> 14:17.280
But simply enabling site of origin is another way to prevent these loops when

258
14:17.280 --> 14:18.600
we're redistributing

259
14:18.600 --> 14:24.160
from OMP into BGP and vice versa.

260
14:24.160 --> 14:29.440
So in this video we simply took a look at some tools and attributes that we

261
14:29.440 --> 14:29.800
want to

262
14:29.800 --> 14:35.840
be aware of when working with the overlay specifically meaning OMP routing.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

262
14:29.800 --> 14:35.840
be aware of when working with the overlay specifically meaning OMP routing.

263
14:35.840 --> 14:40.470
We also talked about how to prevent the loop using either site of origin or

264
14:40.470 --> 14:41.240
just using

265
14:41.240 --> 14:48.160
the overlay AS feature available in SD WAN specifically again OMP.

266
14:48.160 --> 14:52.130
Next up let's take a look at some tools that we have available for troubles

267
14:52.130 --> 14:53.400
hooting in Cloud

268
14:53.400 --> 14:54.000
on ramp.

269
14:54.000 --> 15:03.720
[BLANK_AUDIO]