WEBVTT

1
00:00.000 --> 00:06.990
So when we're dealing with routing on our overlay, one of the fundamental

2
00:06.990 --> 00:08.880
questions we have is,

3
00:08.880 --> 00:13.840
"Have we deployed our own routers into the cloud provider, or are we using

4
00:13.840 --> 00:15.040
their virtual network

5
00:15.040 --> 00:19.910
gateways?" Of course, if we're using their gateways, most providers are only

6
00:19.910 --> 00:21.920
going to support either

7
00:21.920 --> 00:28.320
static routing or BGP. If we deploy our own routers, of course, we can pretty

8
00:28.320 --> 00:29.600
much run whatever protocol

9
00:29.600 --> 00:35.570
we want to over our IPsec tunnels. So technically, we could implement something
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

9
00:29.600 --> 00:35.570
we want to over our IPsec tunnels. So technically, we could implement something

10
00:35.570 --> 00:37.600
like EIGRP or

11
00:37.600 --> 00:42.380
RIT version 2, although I certainly wouldn't recommend that. But the point is,

12
00:42.380 --> 00:44.080
no matter which methods or

13
00:44.080 --> 00:49.300
protocols we're using, at some point, we are probably going to have to get

14
00:49.300 --> 00:50.800
routes from one

15
00:50.800 --> 00:56.860
protocol to another. And that process is called redistribution. When we're

16
00:56.860 --> 00:58.000
doing redistribution,

17
00:58.000 --> 01:03.140
there are some things we need to keep in mind. First, loops. That's going to be
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

17
00:58.000 --> 01:03.140
there are some things we need to keep in mind. First, loops. That's going to be

18
01:03.140 --> 01:04.480
our biggest problem.

19
01:04.480 --> 01:10.280
All of our routing protocols, even RIT version 2, has a loop prevention

20
01:10.280 --> 01:12.240
mechanism built in

21
01:12.240 --> 01:17.460
to prevent routing loops. The problem, of course, is that only works within

22
01:17.460 --> 01:19.520
that protocol. As soon

23
01:19.520 --> 01:24.890
as you start moving routes from one protocol to another, you start losing

24
01:24.890 --> 01:26.400
information, such as

25
01:26.400 --> 01:31.120
the metric used by that protocol. Well, the problem with that is when we start
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

25
01:26.400 --> 01:31.120
the metric used by that protocol. Well, the problem with that is when we start

26
01:31.120 --> 01:32.480
losing information,

27
01:32.480 --> 01:38.310
that means we also lose the loop prevention mechanism. There is nothing in

28
01:38.310 --> 01:39.360
place that will

29
01:39.360 --> 01:43.370
prevent loops between two different protocols that are doing route

30
01:43.370 --> 01:45.840
redistribution. Now, we're

31
01:45.840 --> 01:50.970
not going to run into these loops if we only redistribute at one central point.

32
01:50.970 --> 01:52.000
The problem,

33
01:52.000 --> 01:56.760
of course, with that is that's also one central point of failure. And we don't

34
01:56.760 --> 01:57.280
generally like

35
01:57.280 --> 02:01.810
to have a single point of failure in our networking. So we're almost always
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

35
01:57.280 --> 02:01.810
to have a single point of failure in our networking. So we're almost always

36
02:01.810 --> 02:03.280
going to want to do

37
02:03.280 --> 02:09.830
mutual redistribution on dual points. And that is where the problem with loops

38
02:09.830 --> 02:10.480
come into play.

39
02:10.480 --> 02:15.790
So what our goal is in this video is to look at some of the attributes of

40
02:15.790 --> 02:17.120
redistribution,

41
02:17.120 --> 02:21.300
dealing with things like those metrics. But most importantly, our biggest topic

42
02:21.300 --> 02:21.600
here,

43
02:21.600 --> 02:27.970
what is the looping problem? And of course, how do we fix it? So all of that

44
02:27.970 --> 02:29.280
said, let's jump in

45
02:29.280 --> 02:33.820
and take a closer look at doing redistribution between our various routing
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

45
02:29.280 --> 02:33.820
and take a closer look at doing redistribution between our various routing

46
02:33.820 --> 02:34.720
protocols.

47
02:34.720 --> 02:42.080
So let's begin by talking about some of the key aspects of redistribution. And

48
02:42.080 --> 02:43.360
the first one

49
02:43.360 --> 02:48.960
is going to be avoid when necessary. So what do you mean by that? Well, we

50
02:48.960 --> 02:50.320
really don't want to have

51
02:50.320 --> 02:55.100
to do redistribution. Now understand, in almost every environment out there, we

52
02:55.100 --> 02:55.840
will have to.

53
02:55.840 --> 03:01.680
But we don't want to do it if it's not necessary. If we can design around it or
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

53
02:55.840 --> 03:01.680
But we don't want to do it if it's not necessary. If we can design around it or

54
03:01.680 --> 03:02.560
come up with some

55
03:02.560 --> 03:08.700
other way to solve the problem, this really should be avoided if possible. Now

56
03:08.700 --> 03:09.040
again,

57
03:09.600 --> 03:13.720
it's often not possible. That's why we have to have this discussion. But we don

58
03:13.720 --> 03:14.320
't want to do

59
03:14.320 --> 03:19.670
redistribution just because why hopefully is pretty clear after our

60
03:19.670 --> 03:21.840
introduction. The biggest

61
03:21.840 --> 03:26.650
problem with redistribution is routing loops. And we as administrators have to

62
03:26.650 --> 03:27.440
do something to

63
03:27.440 --> 03:32.090
design around that. So it just complicates the environment. It can lead to
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

63
03:27.440 --> 03:32.090
design around that. So it just complicates the environment. It can lead to

64
03:32.090 --> 03:33.600
routing loops and so

65
03:33.600 --> 03:38.480
on. So again, it should be avoided if possible. The next point, and I think

66
03:38.480 --> 03:39.680
this one's really

67
03:39.680 --> 03:45.540
important to understand about redistribution is that it always does

68
03:45.540 --> 03:48.160
redistribution from the

69
03:48.160 --> 03:55.600
routing table, never from a database. So just as an example, let's say that you

70
03:55.600 --> 03:56.480
are redistributing

71
03:57.040 --> 04:07.110
OSPF into RIP, just as an example. And you learn the same route from OSPF and
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

71
03:57.040 --> 04:07.110
OSPF into RIP, just as an example. And you learn the same route from OSPF and

72
04:07.110 --> 04:08.400
from EIGRP.

73
04:08.400 --> 04:19.000
Now that route is going to be in both the EIGRP topology and the OSPF database.

74
04:19.000 --> 04:19.440
However,

75
04:20.080 --> 04:26.220
since EIGRP, assuming it's an internal route, has a default admin distance of

76
04:26.220 --> 04:29.680
90 and OSPF is 110,

77
04:29.680 --> 04:36.950
that means that the route in your routing table would be the EIGRP route. Once
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

77
04:29.680 --> 04:36.950
that means that the route in your routing table would be the EIGRP route. Once

78
04:36.950 --> 04:38.640
again, still in the

79
04:38.640 --> 04:47.240
OSPF database, but not in the routing table from OSPF. Now you go and configure

80
04:47.240 --> 04:49.120
redistribution

81
04:49.120 --> 04:57.320
from OSPF into RIP, you're not going to have that route in the RIP environment,

82
04:57.320 --> 04:58.080
because it's in that

83
04:58.080 --> 05:06.160
router from EIGRP and you didn't redistribute EIGRP into RIP. This also falls
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

83
04:58.080 --> 05:06.160
router from EIGRP and you didn't redistribute EIGRP into RIP. This also falls

84
05:06.160 --> 05:07.840
along the lines

85
05:07.840 --> 05:14.640
of it means you can't redistribute through another protocol on the same router.

86
05:14.640 --> 05:15.280
In other words,

87
05:15.920 --> 05:24.810
even if I said to redistribute EIGRP into OSPF and then OSPF into RIP in that

88
05:24.810 --> 05:25.600
same scenario,

89
05:25.600 --> 05:32.160
I'm still not going to end up with that route in RIP, because on that local
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

89
05:25.600 --> 05:32.160
I'm still not going to end up with that route in RIP, because on that local

90
05:32.160 --> 05:32.880
router,

91
05:32.880 --> 05:39.500
that route is still in the routing table from the original protocol, EIGRP. I

92
05:39.500 --> 05:40.480
would have to again

93
05:40.480 --> 05:46.120
redistribute directly from EIGRP into RIP. So it's sort of fundamental to

94
05:46.120 --> 05:47.600
understand that we

95
05:47.600 --> 05:53.710
always redistribute from the routing table, never from databases or topology

96
05:53.710 --> 05:54.560
tables.

97
05:54.560 --> 06:00.340
Now, one of the other things we mentioned during the introduction was the fact
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

97
05:54.560 --> 06:00.340
Now, one of the other things we mentioned during the introduction was the fact

98
06:00.340 --> 06:01.840
that we lose some

99
06:01.840 --> 06:07.140
information when we do redistribution. And one of those things we lose is going

100
06:07.140 --> 06:08.160
to be the metric.

101
06:08.800 --> 06:16.090
And therefore, some protocols are going to require a seed metric. Now, some

102
06:16.090 --> 06:18.240
protocols have a default

103
06:18.240 --> 06:23.420
seed metric and some don't. We'll discuss that in just a moment. But either way

104
06:23.420 --> 06:24.320
, we're going to

105
06:24.320 --> 06:28.500
probably need a seed metric of some sort because once again, to make a

106
06:28.500 --> 06:30.960
comparison, we can have an
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

106
06:28.500 --> 06:30.960
comparison, we can have an

107
06:30.960 --> 06:39.500
OSPF cost to get to a network of 550. Then we try to redistribute that route

108
06:39.500 --> 06:40.160
into RIP.

109
06:40.160 --> 06:46.590
Remember that RIP uses a hop count that hop count can't be higher than 15. Our

110
06:46.590 --> 06:49.040
OSPF metric is not

111
06:49.040 --> 06:54.780
going to fit in the RIP hop count. This is what we talk about a seed metric.

112
06:54.780 --> 06:57.040
The reason we say some,

113
06:57.760 --> 07:05.850
notably, BGP doesn't require it because BGP uses attributes, although Med or
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

113
06:57.760 --> 07:05.850
notably, BGP doesn't require it because BGP uses attributes, although Med or

114
07:05.850 --> 07:07.120
Metric is one of its

115
07:07.120 --> 07:13.030
attributes. It doesn't need that in order to propagate routes. So BGP would not

116
07:13.030 --> 07:13.760
need a seed

117
07:13.760 --> 07:18.800
metric, although we will talk about its behavior here in just a moment. And of

118
07:18.800 --> 07:19.600
course, I saved the

119
07:19.600 --> 07:25.520
most important one for last. We are going to have to avoid routing loops. Now,

120
07:25.520 --> 07:26.960
in just a moment,

121
07:26.960 --> 07:31.530
we're going to talk about what causes the loop? How does it happen? And of
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

121
07:26.960 --> 07:31.530
we're going to talk about what causes the loop? How does it happen? And of

122
07:31.530 --> 07:32.880
course, how do we avoid

123
07:32.880 --> 07:37.090
it? But this is going to be the most important aspect when we're dealing with

124
07:37.090 --> 07:38.080
redistribution.

125
07:38.080 --> 07:43.010
And understand, I'm going to talk about it sort of generically, because solving

126
07:43.010 --> 07:43.840
routing loops with

127
07:43.840 --> 07:48.390
redistribution is sort of a big topic. There's a lot of different ways we can

128
07:48.390 --> 07:49.440
do things, but I'm

129
07:49.440 --> 07:53.650
going to cover it generically. What has to happen and why do we need to take

130
07:53.650 --> 07:54.480
care of it?

131
07:55.200 --> 07:59.340
Before we get to that, though, let's wrap up those seed metrics. So for the

132
07:59.340 --> 08:00.160
seed metrics,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

132
07:59.340 --> 08:00.160
seed metrics,

133
08:00.160 --> 08:05.280
let's talk about our two primary protocols that we're discussing. First is OSPF

134
08:05.280 --> 08:07.120
. If you just

135
08:07.120 --> 08:13.900
redistribute a protocol, RIP, EIGRP, whatever, even a different OSPF instance

136
08:13.900 --> 08:15.840
into OSPF,

137
08:15.840 --> 08:21.180
it's going to default to a metric of 20 for those routes that have been

138
08:21.180 --> 08:22.720
redistributed.

139
08:23.520 --> 08:30.400
Now, we have an exception listed here. If you redistribute BGP into OSPF,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

139
08:23.520 --> 08:30.400
Now, we have an exception listed here. If you redistribute BGP into OSPF,

140
08:30.400 --> 08:36.640
it actually defaults to a metric of one. Now, remember, in the case of OSPF,

141
08:36.640 --> 08:42.820
the metric is the cost for the route. Our other major protocol, of course, is B

142
08:42.820 --> 08:43.360
GP.

143
08:43.360 --> 08:50.400
And as we said, BGP doesn't really need a metric. Now, Cisco refers to the MED,

144
08:51.360 --> 08:56.830
which is the official BGP attribute name as the metric. And the default

145
08:56.830 --> 08:59.200
behavior is that if you

146
08:59.200 --> 09:07.260
redistribute an IGP into BGP, it will take whatever metric is on that route and
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

146
08:59.200 --> 09:07.260
redistribute an IGP into BGP, it will take whatever metric is on that route and

147
09:07.260 --> 09:08.880
copy it into the MED

148
09:08.880 --> 09:15.530
attribute. Now, understand this could be of concern as well. If different

149
09:15.530 --> 09:17.520
routers are redistributing

150
09:17.520 --> 09:24.840
from different protocols into BGP, you may end up with the same prefix in BGP,

151
09:24.840 --> 09:25.920
one that came from

152
09:25.920 --> 09:31.670
a router that's redistributing OSPF, and one coming from a router that's redist
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

152
09:25.920 --> 09:31.670
a router that's redistributing OSPF, and one coming from a router that's redist

153
09:31.670 --> 09:32.800
ributing RIP.

154
09:32.800 --> 09:39.150
And when it gets to this MED field, the RIP would have a much lower MED. It

155
09:39.150 --> 09:39.840
would be again,

156
09:39.840 --> 09:45.890
somewhere between one and 15. OSPF could be in the hundreds or thousands,

157
09:45.890 --> 09:46.720
because again,

158
09:46.720 --> 09:54.410
it's the OSPF cost. So, MED is a rather weak attribute in BGP. So, it's not a

159
09:54.410 --> 09:55.600
big problem,

160
09:55.600 --> 10:01.160
but it is something to be aware of with these seed metrics. One final thing
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

160
09:55.600 --> 10:01.160
but it is something to be aware of with these seed metrics. One final thing

161
10:01.160 --> 10:02.400
about these seed

162
10:02.400 --> 10:06.350
metrics, which isn't really all that critical because they're not our main

163
10:06.350 --> 10:08.160
focus, but if you are

164
10:08.160 --> 10:15.720
going to use EIGRP or RIP version two, be aware that the seed metric for both

165
10:15.720 --> 10:16.640
of those

166
10:16.640 --> 10:22.800
is actually infinity, which means it won't use the routes, which means, well,

167
10:22.800 --> 10:24.080
invalid.

168
10:24.080 --> 10:30.810
So, really what that comes down to is if you are redistributing into either EIG
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

168
10:24.080 --> 10:30.810
So, really what that comes down to is if you are redistributing into either EIG

169
10:30.810 --> 10:32.080
RP or RIP version

170
10:32.080 --> 10:39.080
two, you must supply your own seed metrics. Now, you can set up a default seed

171
10:39.080 --> 10:39.840
metric,

172
10:39.840 --> 10:44.750
or you can do it when redistributing the routes on the redistribution line, but

173
10:44.750 --> 10:46.000
one way or another,

174
10:46.000 --> 10:49.600
you have to supply metrics for EIGRP and RIP.

175
10:49.600 --> 10:58.600
[BLANK_AUDIO]