WEBVTT

1
00:00.000 --> 00:05.000
So next, let's talk about that looping problem.

2
00:05.000 --> 00:07.080
And we're gonna start off by discussing

3
00:07.080 --> 00:12.080
what the problem actually is using a very simple diagram here.

4
00:12.080 --> 00:14.680
So we simply have two routers.

5
00:14.680 --> 00:16.720
They're gonna be doing redistribution

6
00:16.720 --> 00:20.680
between EBGP and OSPF.

7
00:20.680 --> 00:22.040
Now, as we jump into this,

8
00:22.040 --> 00:27.040
remember that the admin distance of EBGP is 20

9
00:27.560 --> 00:32.560
and the default admin distance of OSPF is 110.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

9
00:27.560 --> 00:32.560
and the default admin distance of OSPF is 110.

10
00:32.560 --> 00:36.840
This is important because the problem is going to occur

11
00:36.840 --> 00:41.440
on whichever side has the worst admin distance.

12
00:41.440 --> 00:44.280
Remember that with admin distance, lowest wins.

13
00:44.280 --> 00:47.920
So EBGP is actually gonna be okay here.

14
00:47.920 --> 00:51.920
OSPF is the side that's going to have the problem.

15
00:51.920 --> 00:55.160
So let's take a look at what the issue actually is.

16
00:55.160 --> 00:58.320
Let's say that we'll put a couple more routers in here,

17
00:58.320 --> 01:01.560
just generic, let's just say we have a couple routers here
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

17
00:58.320 --> 01:01.560
just generic, let's just say we have a couple routers here

18
01:01.560 --> 01:04.360
for the sake of argument, they're connected like this.

19
01:04.360 --> 01:06.760
We don't really care anything about the detail

20
01:06.760 --> 01:10.920
in the EBGP side, but let's say that there's a network

21
01:10.920 --> 01:13.640
down here, network X.

22
01:13.640 --> 01:17.200
And when network X gets advertised up to this router

23
01:17.200 --> 01:22.200
here in the middle, it has a cost on it of 500.

24
01:22.720 --> 01:25.760
For whatever reason, it doesn't matter why.

25
01:25.760 --> 01:28.840
Let's talk about what ultimately happens here.

26
01:28.840 --> 01:31.360
This router in the middle, and this of course
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

26
01:28.840 --> 01:31.360
This router in the middle, and this of course

27
01:31.360 --> 01:33.160
is going to happen both directions,

28
01:33.160 --> 01:37.200
but as I always say, we have to talk about one direction

29
01:37.200 --> 01:40.200
at a time, understand it's gonna go both ways,

30
01:40.200 --> 01:43.560
but ultimately that just over complicates the discussion.

31
01:43.560 --> 01:45.440
So let's just say that this router in the middle

32
01:45.440 --> 01:50.440
sends the route up to router one, who puts it in its database.

33
01:50.440 --> 01:51.920
Now at the same time, of course,

34
01:51.920 --> 01:54.920
we know this is gonna arrive at router two.

35
01:54.920 --> 01:58.360
Well, let's just say it arrived on router one first.

36
01:58.360 --> 02:02.280
Therefore router one takes this network X
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

36
01:58.360 --> 02:02.280
Therefore router one takes this network X

37
02:02.280 --> 02:06.600
and redistributes it up into BGP.

38
02:06.600 --> 02:09.400
Well, as it should, router one advertises that route

39
02:09.400 --> 02:13.040
into the BGP environment, and whatever it goes through,

40
02:13.040 --> 02:18.040
it ends up coming back in to router two through EBGP.

41
02:19.160 --> 02:22.040
And router two now has a huge question

42
02:22.040 --> 02:25.240
about what to do with network X.

43
02:25.240 --> 02:28.200
I've learned the prefix from EBGP

44
02:28.200 --> 02:31.600
with an admin cost of 20 and OSPF
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

44
02:28.200 --> 02:31.600
with an admin cost of 20 and OSPF

45
02:31.600 --> 02:34.160
with an admin cost of 110.

46
02:34.160 --> 02:36.800
Knowing that lowest admin distance wins,

47
02:36.800 --> 02:41.800
router two installs the EBGP route into its routing table.

48
02:41.800 --> 02:46.240
Well, remember router two is also configured

49
02:46.240 --> 02:50.200
to redistribute EBGP into OSPF.

50
02:50.200 --> 02:51.320
So guess what?

51
02:51.320 --> 02:52.880
It does just that.

52
02:52.880 --> 02:57.880
It takes the EBGP route, sends it back into OSPF.

53
02:57.880 --> 03:01.680
And if you didn't configure any sort of a seed metric,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

53
02:57.880 --> 03:01.680
And if you didn't configure any sort of a seed metric,

54
03:01.680 --> 03:04.560
this is gonna come in with a metric of 20.

55
03:04.560 --> 03:09.120
Well, the 20 beats the 500 that was already on this OSPF route.

56
03:09.120 --> 03:11.040
So guess what happens?

57
03:11.040 --> 03:14.440
This update now gets sent back down here

58
03:14.440 --> 03:16.320
to this router in the middle,

59
03:16.320 --> 03:21.320
who now has the same route from two different OSPF routers,

60
03:21.320 --> 03:25.480
one with a metric of 500 and one with a metric of 20.

61
03:25.480 --> 03:27.480
Now, a little bit of good news here

62
03:27.480 --> 03:29.800
is that in most situations,

63
03:29.800 --> 03:31.880
this is not gonna be a problem,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

63
03:29.800 --> 03:31.880
this is not gonna be a problem,

64
03:31.880 --> 03:35.640
because in OSPF, we do prefer internal routes

65
03:35.640 --> 03:38.080
over external routes.

66
03:38.080 --> 03:40.840
But who's to say that network X

67
03:40.840 --> 03:44.320
wasn't another external route coming in on OSPF

68
03:44.320 --> 03:46.120
down here at the bottom.

69
03:46.120 --> 03:47.640
So if it's an internal route,

70
03:47.640 --> 03:50.280
again, this isn't gonna be a huge deal,

71
03:50.280 --> 03:52.440
but we do still have to understand

72
03:52.440 --> 03:54.440
what could potentially happen.

73
03:54.440 --> 03:59.440
So again, this route now ends up at the middle router again.

74
03:59.440 --> 04:01.840
So once again, we're down here,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

74
03:59.440 --> 04:01.840
So once again, we're down here,

75
04:01.840 --> 04:04.560
and it's got two different routes.

76
04:04.560 --> 04:07.200
The original with a metric of 500,

77
04:07.200 --> 04:09.800
and now the one coming from router two

78
04:09.800 --> 04:11.920
with a metric of 20.

79
04:11.920 --> 04:13.480
And that middle router is gonna say,

80
04:13.480 --> 04:16.200
"Well, that looks really good.

81
04:16.200 --> 04:19.920
"I'm going to now take out this metric of 500.

82
04:19.920 --> 04:21.680
"I'm gonna ignore this route."

83
04:21.680 --> 04:23.360
Again, it's still gonna be in the database

84
04:23.360 --> 04:26.440
'cause OSPF has to have a consistent database,

85
04:26.440 --> 04:29.800
but now it's going to like this entry

86
04:29.800 --> 04:34.640
with a metric of 20 going up to router two.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

86
04:29.800 --> 04:34.640
with a metric of 20 going up to router two.

87
04:34.640 --> 04:37.200
Here's where the problem comes in.

88
04:37.200 --> 04:41.840
Now we have traffic arrives from the outside world

89
04:41.840 --> 04:43.760
at router one.

90
04:43.760 --> 04:46.120
Router one looks at its table.

91
04:46.120 --> 04:49.960
It sees this update that came in originally,

92
04:49.960 --> 04:53.240
forwards the traffic to the router in the middle.

93
04:53.240 --> 04:57.600
The router in the middle now uses its newly learned route

94
04:57.600 --> 04:59.360
with a metric of 20,

95
04:59.360 --> 05:03.040
and goes ahead and sends this up to router two.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

95
04:59.360 --> 05:03.040
and goes ahead and sends this up to router two.

96
05:03.040 --> 05:06.760
Router two, who has an EVGP route,

97
05:06.760 --> 05:10.800
goes ahead and forwards this through the EVGP environment

98
05:10.800 --> 05:12.560
over to router one,

99
05:12.560 --> 05:15.640
and well, if you just follow the red arrows,

100
05:15.640 --> 05:17.720
there's our routing loop.

101
05:17.720 --> 05:20.000
So that's how a routing loop can occur

102
05:20.000 --> 05:22.200
in an environment such as this.

103
05:22.200 --> 05:26.200
Now, what could we have done to stop this whole problem?

104
05:26.200 --> 05:28.520
Let's clean this up a little bit.

105
05:28.520 --> 05:33.200
What should have happened is router two here
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

105
05:28.520 --> 05:33.200
What should have happened is router two here

106
05:33.200 --> 05:37.000
should never have accepted this route.

107
05:37.000 --> 05:40.200
It never should have accepted the BGP route.

108
05:40.200 --> 05:44.760
It should have kept believing the OSPF route.

109
05:44.760 --> 05:46.560
How do we accomplish that?

110
05:46.560 --> 05:48.760
Well, let's take a look.

111
05:48.760 --> 05:51.200
The most common way to solve this problem

112
05:51.200 --> 05:53.560
is just through filtering,

113
05:53.560 --> 05:56.280
which is what we've discussed previously.

114
05:56.280 --> 05:58.760
Now, the most common way of doing the filtering

115
05:58.760 --> 06:02.440
is to use something called route tags.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

115
05:58.760 --> 06:02.440
is to use something called route tags.

116
06:02.440 --> 06:05.240
All of our protocols support route tags,

117
06:05.240 --> 06:07.760
which makes it a very popular way of doing it.

118
06:07.760 --> 06:12.600
So basically what we do is we tag the routes as they go one way

119
06:12.600 --> 06:14.440
and then we deny those tags

120
06:14.440 --> 06:17.400
from coming back into the same environment.

121
06:17.400 --> 06:21.400
But there are also many, many other methods.

122
06:21.400 --> 06:23.400
We could use any of the filtering methods

123
06:23.400 --> 06:25.160
we talked about earlier.

124
06:25.160 --> 06:27.080
In the case of BGP,

125
06:27.080 --> 06:30.520
we could use things like community strings,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

125
06:27.080 --> 06:30.520
we could use things like community strings,

126
06:30.520 --> 06:32.640
we could use prefix lists.

127
06:32.640 --> 06:34.200
There's several different ways

128
06:34.200 --> 06:37.280
that we can handle all of this filtering.

129
06:37.280 --> 06:40.480
The other choice is we could do something called

130
06:40.480 --> 06:43.400
split administrative distance,

131
06:43.400 --> 06:48.400
where we treat internal versus external differently.

132
06:48.400 --> 06:51.360
Two routing protocols support this.

133
06:51.360 --> 06:56.280
And the good news is one of them is OSPF.

134
06:56.280 --> 06:58.920
The other one, although we're probably not gonna be using it,

135
06:58.920 --> 07:01.520
is EIGRP.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

135
06:58.920 --> 07:01.520
is EIGRP.

136
07:01.520 --> 07:06.520
EIGRP, by the way, does this automatically and by default.

137
07:06.520 --> 07:11.520
OSPF, you're going to have to configure it yourself.

138
07:11.520 --> 07:14.400
So this is going to be up to the admin.

139
07:14.400 --> 07:16.880
You have to enable this feature.

140
07:16.880 --> 07:20.040
And again, just a quick reminder on our defaults

141
07:20.040 --> 07:21.840
for admin distance,

142
07:21.840 --> 07:24.400
for our two big protocols that we're using,

143
07:24.400 --> 07:29.400
BGP defaults to 24 EIGRP and 200 for IBGP.

144
07:29.400 --> 07:38.080
So in a way, this is sort of like doing split admin distance.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

144
07:29.400 --> 07:38.080
So in a way, this is sort of like doing split admin distance.

145
07:38.080 --> 07:41.400
The only reason we don't really qualify it as that

146
07:41.400 --> 07:46.160
is split admin distance actually looks at the route

147
07:46.160 --> 07:49.480
to see if it's internal or external.

148
07:49.480 --> 07:54.480
BGP only looks at what type of neighbor I learned it from.

149
07:54.480 --> 07:57.200
So if I learned it from an EIGRP neighbor

150
07:57.200 --> 07:59.560
versus an IBGP neighbor,

151
07:59.560 --> 08:02.880
that determines the default admin distance.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

151
07:59.560 --> 08:02.880
that determines the default admin distance.

152
08:02.880 --> 08:05.040
Where OSPF and EIGRP,

153
08:05.040 --> 08:08.240
we'll just put OSPF up here since I just mentioned it,

154
08:08.240 --> 08:10.800
they can do split admin distance.

155
08:10.800 --> 08:14.120
They do it based on the type of the route,

156
08:14.120 --> 08:16.360
not the type of the neighbor.

157
08:16.360 --> 08:18.360
That's the distinction when we're talking about

158
08:18.360 --> 08:20.160
split admin distance.

159
08:20.160 --> 08:25.440
So in this video, we talked about some of the important aspects

160
08:25.440 --> 08:27.720
of doing redistribution.

161
08:27.720 --> 08:30.200
The big things to take away.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

161
08:27.720 --> 08:30.200
The big things to take away.

162
08:30.200 --> 08:34.360
First, we always redistribute from the routing table,

163
08:34.360 --> 08:36.720
never from databases.

164
08:36.720 --> 08:41.000
That's why things like admin distance to stop loops

165
08:41.000 --> 08:43.360
can be useful and beneficial.

166
08:43.360 --> 08:45.840
If we redistributed from the databases,

167
08:45.840 --> 08:48.520
admin distance wouldn't really make any difference

168
08:48.520 --> 08:51.160
because these routes would of course still be

169
08:51.160 --> 08:54.000
in the databases and topology tables

170
08:54.000 --> 08:56.120
of our various protocols.

171
08:56.120 --> 08:58.960
Of course, the main thing we focused on here

172
08:58.960 --> 09:00.960
is loop prevention.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

172
08:58.960 --> 09:00.960
is loop prevention.

173
09:00.960 --> 09:03.560
And that is one of the biggest things we need to watch

174
09:03.560 --> 09:07.640
when we're doing redistribution on more than one point.

175
09:07.640 --> 09:10.320
Now again, some protocols have some things

176
09:10.320 --> 09:12.080
that can help with this a little bit

177
09:12.080 --> 09:15.080
like OSPF can do split admin distance,

178
09:15.080 --> 09:18.560
EIGRP can as well and it's on by default.

179
09:18.560 --> 09:23.080
But overall, routing protocols have loop prevention

180
09:23.080 --> 09:26.040
within the protocol, but not when you're doing

181
09:26.040 --> 09:28.360
redistribution between them.

182
09:28.360 --> 09:30.560
At the bare minimum, you need to sit down,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

182
09:28.360 --> 09:30.560
At the bare minimum, you need to sit down,

183
09:30.560 --> 09:33.240
think it through, think where routes are coming from,

184
09:33.240 --> 09:36.520
where they're going to, and if they can loop back around,

185
09:36.520 --> 09:41.240
if they can, we then need to filter them out in some way

186
09:41.240 --> 09:43.040
to prevent the loops.

187
09:43.040 --> 09:45.840
So that covers everything that we need to discuss

188
09:45.840 --> 09:47.600
in this skill.

189
09:47.600 --> 09:50.200
So now we just have to do the challenge.

190
09:50.200 --> 09:52.640
So go ahead and give the challenge a shot

191
09:52.640 --> 09:56.280
and I'll see you in the solution video on the other side.

192
09:56.280 --> 10:14.940
[ Pause ]