WEBVTT

1
00:00.000 --> 00:04.200
So, let's turn our attention to layer 3.

2
00:04.200 --> 00:10.970
And so, we've got a layer 3 device here and a packet is going to get evaluated

3
00:10.970 --> 00:11.140
and we

4
00:11.140 --> 00:16.000
need to figure out what interface to send this packet out.

5
00:16.000 --> 00:18.970
But keep in mind, when it comes to layer 3, I not only need to know the

6
00:18.970 --> 00:20.120
outgoing interface,

7
00:20.120 --> 00:23.480
I also need to know what the next hop is.

8
00:23.480 --> 00:28.700
In most cases, this next hop, which is a layer 3 next hop, in other words, an

9
00:28.700 --> 00:29.520
IP address

10
00:29.520 --> 00:34.810
for what the next device is, is going to be used to actually look up the layer
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

10
00:29.520 --> 00:34.810
for what the next device is, is going to be used to actually look up the layer

11
00:34.810 --> 00:35.720
2 address

12
00:35.720 --> 00:38.440
for my new layer 2 frame.

13
00:38.440 --> 00:42.300
Because this packet is going to have its layer 2 ethernet header, let's just

14
00:42.300 --> 00:43.760
say it's ethernet,

15
00:43.760 --> 00:48.180
it's going to have this layer 2 header stripped off, evaluate the layer 3, move

16
00:48.180 --> 00:48.720
it to the

17
00:48.720 --> 00:54.010
destination interface, but now this packet, which is about to get sent out, is

18
00:54.010 --> 00:54.800
going to

19
00:54.800 --> 00:59.570
need to be reconstructed with a new layer 2 header as it gets sent to the next

20
00:59.570 --> 01:00.080
device
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

20
00:59.570 --> 01:00.080
device

21
01:00.080 --> 01:01.480
in the path.

22
01:01.480 --> 01:07.240
And so, we've got this layer 3 device here, packet arrives, going to send it

23
01:07.240 --> 01:07.800
out to or

24
01:07.800 --> 01:12.800
out this interface, but again, what is this device that I'm sending it to?

25
01:12.800 --> 01:17.940
That would be the next hop layer 3 device or address, which will lead me to

26
01:17.940 --> 01:18.560
decipher

27
01:18.560 --> 01:21.600
or figuring out what the layer 2 address would be.

28
01:21.600 --> 01:25.810
And usually I'm just going to use ARP or IPv6 neighbor discovery in order to

29
01:25.810 --> 01:26.640
figure out

30
01:26.640 --> 01:30.360
what that is based on the layer 3 next hop.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

30
01:26.640 --> 01:30.360
what that is based on the layer 3 next hop.

31
01:30.360 --> 01:34.360
So this is the process that we're going to use, so how do we get from point A

32
01:34.360 --> 01:34.920
to point

33
01:34.920 --> 01:35.920
B?

34
01:35.920 --> 01:41.160
Well, we're going to start with this concept of the routing table.

35
01:41.160 --> 01:46.740
We refer to the routing table a lot, and Cisco has a fancier word for this, and

36
01:46.740 --> 01:47.120
I guess

37
01:47.120 --> 01:52.080
the industry at large does, and the fancy word for the routing table is known

38
01:52.080 --> 01:52.600
as the

39
01:52.600 --> 02:01.440
routing information base, otherwise known as the rib.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

39
01:52.600 --> 02:01.440
routing information base, otherwise known as the rib.

40
02:01.440 --> 02:05.600
So this routing information base is how all of the data gets stored in a

41
02:05.600 --> 02:06.560
structured way

42
02:06.560 --> 02:10.400
and allows us to perform a lookup.

43
02:10.400 --> 02:13.730
Figure out where this packet should go, and again, two key pieces of

44
02:13.730 --> 02:14.920
information here,

45
02:14.920 --> 02:20.160
outgoing interface, as well as the layer 3 next hop address.

46
02:20.160 --> 02:24.070
Another important aspect of the routing table is that we have a routing table

47
02:24.070 --> 02:25.440
on a per VRF

48
02:25.440 --> 02:26.440
basis.

49
02:26.440 --> 02:32.800
Sort of like how we had a cam table per VLAN at layer 2.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

49
02:26.440 --> 02:32.800
Sort of like how we had a cam table per VLAN at layer 2.

50
02:32.800 --> 02:37.670
At layer 3 we have the exact same concept, but it's a routing table per VRF now

51
02:37.670 --> 02:38.280
, which

52
02:38.280 --> 02:42.430
is that virtual routing and forwarding instance, basically a way for us to

53
02:42.430 --> 02:43.360
carve up a layer

54
02:43.360 --> 02:47.330
3 device in the multiple layer 2 domains, in the same way that VLANs carve a

55
02:47.330 --> 02:48.000
layer 2

56
02:48.000 --> 02:51.280
device up in the multiple layer 2 domains.

57
02:51.280 --> 02:55.520
So yes, we have a routing table per VRF.

58
02:55.520 --> 03:00.080
Now if we don't specify which VRF we're using, then most of everything we do is
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

58
02:55.520 --> 03:00.080
Now if we don't specify which VRF we're using, then most of everything we do is

59
03:00.080 --> 03:00.560
going to

60
03:00.560 --> 03:03.760
go into the default VRF.

61
03:03.760 --> 03:05.160
That's a pretty common situation.

62
03:05.160 --> 03:08.830
If I do a show IP route on a Cisco device, it's going to assume we meant the

63
03:08.830 --> 03:09.400
default

64
03:09.400 --> 03:15.790
VRF, we have to actually intentionally specify other VRFs if we want to use

65
03:15.790 --> 03:16.600
them.

66
03:16.600 --> 03:21.520
So the question is, how does the routing table get populated?

67
03:21.520 --> 03:23.720
Where is all of this information coming from?

68
03:23.720 --> 03:28.560
Well, it's going to aggregate data from all of our other routing protocols.

69
03:28.560 --> 03:32.780
So I might have, for example, OSPF running, and it's going to feed information
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

69
03:28.560 --> 03:32.780
So I might have, for example, OSPF running, and it's going to feed information

70
03:32.780 --> 03:33.200
into the

71
03:33.200 --> 03:34.480
routing table.

72
03:34.480 --> 03:39.940
I might have EIGRP running, I might have RIP running, and by the way, I might

73
03:39.940 --> 03:40.720
actually

74
03:40.720 --> 03:44.240
also have static routes included here as well.

75
03:44.240 --> 03:48.330
Yeah, I might have a layer 3 device that's running all three of these different

76
03:48.330 --> 03:49.120
protocols,

77
03:49.120 --> 03:54.120
and they're all feeding the same routing table or the same rib.

78
03:54.120 --> 03:57.550
But once again, we have to ask this question of how are we populating the

79
03:57.550 --> 03:58.360
routing table

80
03:58.360 --> 03:59.360
then?

81
03:59.360 --> 04:04.240
What if they're all providing information on how to reach a specific route?
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

81
03:59.360 --> 04:04.240
What if they're all providing information on how to reach a specific route?

82
04:04.240 --> 04:09.320
Well, this is where we have to worry about administrative distance.

83
04:09.320 --> 04:15.110
And if we have the administrative distance helping us to figure this out, then

84
04:15.110 --> 04:15.760
we have

85
04:15.760 --> 04:21.180
to remember how exactly this works, which is that the lowest administrative

86
04:21.180 --> 04:21.920
distance

87
04:21.920 --> 04:24.600
or AD is going to win.

88
04:24.600 --> 04:27.680
Now here's the very important part in all of this.

89
04:27.680 --> 04:36.000
This is only going to apply only if the routes are identical, meaning that we
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

89
04:27.680 --> 04:36.000
This is only going to apply only if the routes are identical, meaning that we

90
04:36.000 --> 04:37.640
have the exact

91
04:37.640 --> 04:42.680
same network ID and the exact same subnet mask.

92
04:42.680 --> 04:50.880
So in other words, if we had, for example, 10.0.0.0/24, and then we also have

93
04:50.880 --> 04:54.680
10.0.0.0/25,

94
04:54.680 --> 04:59.540
these are completely different subnets and entries into the rib as far as that

95
04:59.540 --> 05:00.080
device
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

95
04:59.540 --> 05:00.080
device

96
05:00.080 --> 05:01.080
is concerned.

97
05:01.080 --> 05:04.460
So if one of these, let's say, is coming from RIP and the other one is coming

98
05:04.460 --> 05:06.320
from OSPF,

99
05:06.320 --> 05:07.760
well, guess what?

100
05:07.760 --> 05:12.630
From a human perspective, these might look like the same network, but from a

101
05:12.630 --> 05:13.760
router perspective,

102
05:13.760 --> 05:17.680
looking at the mask as well, we see they're two completely different routes.

103
05:17.680 --> 05:23.320
And so both of these would get installed into the routing table at the same

104
05:23.320 --> 05:24.280
time.

105
05:24.280 --> 05:29.650
So let's have a quick review about administrative distance values, at least as

106
05:29.650 --> 05:30.560
far as some of
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

106
05:29.650 --> 05:30.560
far as some of

107
05:30.560 --> 05:33.840
the common ones, and keep in mind, these are the default values.

108
05:33.840 --> 05:37.880
We can always change these in our environment if we so desire.

109
05:37.880 --> 05:43.920
But a static route is going to have an administrative distance of one.

110
05:43.920 --> 05:48.920
EBGP external BGP is going to have an AD of 20.

111
05:48.920 --> 05:52.440
EIGRP is 90.

112
05:52.440 --> 05:56.040
OSPF is 110.

113
05:56.040 --> 05:58.840
RIP is 120.

114
05:58.840 --> 06:05.200
And then we might have an IBGP or internal BGP show up, which would be 200.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

114
05:58.840 --> 06:05.200
And then we might have an IBGP or internal BGP show up, which would be 200.

115
06:05.200 --> 06:09.580
So generally speaking, we are going to have an order of operations in here for

116
06:09.580 --> 06:10.520
our IGP,

117
06:10.520 --> 06:16.200
these are interior gateway protocols, BGP is split between the EBGP and IBGP.

118
06:16.200 --> 06:21.120
We always want to trust an IGP over IBGP, which is why it's so high.

119
06:21.120 --> 06:25.160
And then static, the assumption here is we're for including static routes that

120
06:25.160 --> 06:25.920
that is meant

121
06:25.920 --> 06:30.800
to override anything that's happening from a dynamic perspective.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

121
06:25.920 --> 06:30.800
to override anything that's happening from a dynamic perspective.

122
06:30.800 --> 06:34.480
But again, we're always going to prefer the lower administrative distance.

123
06:34.480 --> 06:38.040
And so EIGRP is generally preferred over OSPF.

124
06:38.040 --> 06:43.510
We just have to remember the big caveat here, which is that the subnet has to

125
06:43.510 --> 06:44.840
match perfectly

126
06:44.840 --> 06:46.400
in order for those to get compared.

127
06:46.400 --> 06:49.360
Otherwise they will both be installed.

128
06:49.360 --> 06:55.560
Now, lastly, again, we have to ask this question of how do these routing

129
06:55.560 --> 06:56.800
protocols, how do

130
06:56.800 --> 06:59.560
these learn what's going on?

131
06:59.560 --> 07:03.360
I mean, how do we populate them?
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

131
06:59.560 --> 07:03.360
I mean, how do we populate them?

132
07:03.360 --> 07:05.240
Or how are they learning about routes?

133
07:05.240 --> 07:10.640
Well, on the back end here, each one of these, at least the dynamic routing

134
07:10.640 --> 07:11.920
protocols, not

135
07:11.920 --> 07:18.870
the static side, but OSPF and EIGRP, they're both maintaining their own sets of

136
07:18.870 --> 07:19.760
data.

137
07:19.760 --> 07:25.650
And this data is going to be compiled and taken a look at and evaluated within

138
07:25.650 --> 07:26.280
the routing

139
07:26.280 --> 07:27.720
process.

140
07:27.720 --> 07:31.440
This is where we use the cost or metric.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

140
07:27.720 --> 07:31.440
This is where we use the cost or metric.

141
07:31.440 --> 07:36.320
So a metric is an EIGRP term, OSPF is going to use the phrase cost, but we're

142
07:36.320 --> 07:36.720
going to

143
07:36.720 --> 07:41.370
evaluate it within the routing protocol process without comparing back and

144
07:41.370 --> 07:42.440
forth, because

145
07:42.440 --> 07:47.800
I have no way of comparing EIGRP metric with OSPF cost.

146
07:47.800 --> 07:51.030
The two can't possibly intermix with one another, which is why we have

147
07:51.030 --> 07:51.920
administrative

148
07:51.920 --> 07:55.360
distance to compare routing protocols.

149
07:55.360 --> 08:05.160
This information is stored in the OSPF database and the EIGRP topology table.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

149
07:55.360 --> 08:05.160
This information is stored in the OSPF database and the EIGRP topology table.

150
08:05.160 --> 08:11.240
Notice that these terms are not established as if they're standardized.

151
08:11.240 --> 08:15.390
Each protocol is going to have its own way of storing data and figuring things

152
08:15.390 --> 08:15.800
out, but

153
08:15.800 --> 08:20.080
that all happens before we ever consider pushing anything down to the routing

154
08:20.080 --> 08:20.700
table.

155
08:20.700 --> 08:24.680
This is the last part of the process.

156
08:24.680 --> 08:29.000
Once OSPF and EIGRP, once they decide which routes are best from their

157
08:29.000 --> 08:30.000
perspective, they
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

157
08:29.000 --> 08:30.000
perspective, they

158
08:30.000 --> 08:33.440
will attempt to push things down to the routing table.

159
08:33.440 --> 08:38.180
And this is where we have to compare with other routing processes to find out

160
08:38.180 --> 08:39.480
if administrative

161
08:39.480 --> 08:42.360
distance is going to come into play.

162
08:42.360 --> 08:46.280
One thing worth noting in all of this is we've said that the global routing

163
08:46.280 --> 08:47.000
table here is

164
08:47.000 --> 08:48.400
known as the rib.

165
08:48.400 --> 08:56.290
Every now and again, we will hear these tables referred to as their own little

166
08:56.290 --> 08:57.240
ribs.

167
08:57.240 --> 08:59.280
Cisco doesn't usually use this term.

168
08:59.280 --> 09:03.600
If Cisco is saying rib, they're usually referring to the global routing table.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

168
08:59.280 --> 09:03.600
If Cisco is saying rib, they're usually referring to the global routing table.

169
09:03.600 --> 09:08.580
Something to keep in mind, but in certain documents, you might see something

170
09:08.580 --> 09:10.080
called in the OSPF

171
09:10.080 --> 09:12.120
rib or something like that.

172
09:12.120 --> 09:16.320
It's really talking about the OSPF database at that point.

173
09:16.320 --> 09:20.480
So as far as the last part of this process is concerned, what are we looking at

174
09:20.480 --> 09:20.480
?

175
09:20.480 --> 09:23.530
Well, again, if they're different routes, then they're both going to get

176
09:23.530 --> 09:24.440
installed or

177
09:24.440 --> 09:25.600
in that case.

178
09:25.600 --> 09:32.080
But if it is a 10.0.0, let's just say they're both the same thing.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

178
09:25.600 --> 09:32.080
But if it is a 10.0.0, let's just say they're both the same thing.

179
09:32.080 --> 09:36.000
They have the same subnet mass 24/24/24.

180
09:36.000 --> 09:37.000
One is OSPF.

181
09:37.000 --> 09:42.190
One is EIGRP, which yes, from a Cisco CLI perspective is labeled with a D there

182
09:42.190 --> 09:42.520
.

183
09:42.520 --> 09:44.000
That would be EIGRP.

184
09:44.000 --> 09:49.690
Well, in this case, OSPF is going to lose out to EIGRP because EIGRP has the

185
09:49.690 --> 09:51.560
lower administrative

186
09:51.560 --> 09:52.600
distance.

187
09:52.600 --> 09:55.200
So the OSPF route does not get installed.

188
09:55.200 --> 09:57.840
The EIGRP route does get installed.

189
09:57.840 --> 10:03.360
Whereas again, if we did have a different subnet in here, like a slash 25 for O
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

189
09:57.840 --> 10:03.360
Whereas again, if we did have a different subnet in here, like a slash 25 for O

190
10:03.360 --> 10:04.120
SPF, well,

191
10:04.120 --> 10:08.200
both of these would end up getting installed into the routing table.

192
10:08.200 --> 10:15.440
And so now we have to say, well, which of these routes are we going to pick?

193
10:15.440 --> 10:17.480
The answer is always the same.

194
10:17.480 --> 10:20.120
And it has nothing to do with administrative distance.

195
10:20.120 --> 10:29.120
It is always the longest prefix match, meaning the prefix that has the most

196
10:29.120 --> 10:31.000
bits that match
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

196
10:29.120 --> 10:31.000
bits that match

197
10:31.000 --> 10:32.600
the destination.

198
10:32.600 --> 10:37.260
So usually this can be related back to the most specific or the smallest subnet

199
10:37.260 --> 10:37.640
that

200
10:37.640 --> 10:38.640
applies.

201
10:38.640 --> 10:46.380
So if I'm sending to 10.0.0.1 here, well, slash 24, that has 256 different

202
10:46.380 --> 10:47.640
possibilities.

203
10:47.640 --> 10:50.360
A slash 25 is 128.

204
10:50.360 --> 10:54.430
As long as this fits into both of these and it does in this situation, well, I

205
10:54.430 --> 10:54.800
'm going

206
10:54.800 --> 10:57.640
to take the most specific path.

207
10:57.640 --> 11:01.600
That would be the OSPF route.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

207
10:57.640 --> 11:01.600
That would be the OSPF route.

208
11:01.600 --> 11:05.970
And so at that point, once the once the routes have been installed in the

209
11:05.970 --> 11:07.200
routing table, administrative

210
11:07.200 --> 11:09.560
distance has already been taken into account.

211
11:09.560 --> 11:12.160
We are no longer concerned with administrative distance.

212
11:12.160 --> 11:15.800
I am always going to take the longest prefix match at that point.

213
11:15.800 --> 11:24.300
[BLANK_AUDIO]