WEBVTT

1
00:00.000 --> 00:04.490
All of this is great when we're talking about what we might call a fixed

2
00:04.490 --> 00:06.240
configuration switch,

3
00:06.240 --> 00:11.040
meaning that even though we might have an uplink module or something that

4
00:11.040 --> 00:12.940
allows us to customize a few ports,

5
00:12.940 --> 00:17.600
for the most part we have a fixed amount of ports on the switch, like a 24 or

6
00:17.600 --> 00:18.920
48 port switch,

7
00:18.920 --> 00:22.910
and if we want more ports in our access closet we're just going to have to add

8
00:22.910 --> 00:23.760
another switch.

9
00:23.760 --> 00:27.940
And maybe we support stacking the two switches together and making a logical

10
00:27.940 --> 00:29.720
switch, there's lots of options here.

11
00:29.720 --> 00:35.120
But a fixed configuration switch is fixed from a physical perspective.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

11
00:29.720 --> 00:35.120
But a fixed configuration switch is fixed from a physical perspective.

12
00:35.120 --> 00:39.400
I can't simply add a bunch of new ports without adding a whole new switch.

13
00:39.400 --> 00:41.920
Whereas we also have chassis switches.

14
00:41.920 --> 00:49.320
And chassis switches are going to allow us to find a architecture that allows

15
00:49.320 --> 00:53.080
for physical modularity.

16
00:53.080 --> 00:57.440
The way this works is we usually have a supervisor line card,

17
00:57.440 --> 01:01.000
and potentially a redundant supervisor line card in here,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

17
00:57.440 --> 01:01.000
and potentially a redundant supervisor line card in here,

18
01:01.000 --> 01:03.880
and these are going to manage the control plane.

19
01:03.880 --> 01:06.880
It's effectively managing the brains of the outfit.

20
01:06.880 --> 01:11.060
So the system, the control plane, all kinds of operations are managed by the

21
01:11.060 --> 01:12.040
supervisors.

22
01:12.040 --> 01:16.420
Meanwhile, if I want front-facing ports, meaning ports that connect out to the

23
01:16.420 --> 01:17.320
rest of the world,

24
01:17.320 --> 01:23.370
well, then I'm going to have to add individual line cards here, sometimes

25
01:23.370 --> 01:25.680
abbreviated as LCs.

26
01:25.680 --> 01:28.640
These line cards operate the data plane.

27
01:28.640 --> 01:30.400
And so we see we have physical separation.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

27
01:28.640 --> 01:30.400
And so we see we have physical separation.

28
01:30.400 --> 01:34.690
We have data plane operation on the line cards, control plane operation on the

29
01:34.690 --> 01:35.680
supervisors.

30
01:35.680 --> 01:39.760
And then a lot of chassis will allow us to add potentially a small amount,

31
01:39.760 --> 01:43.750
potentially an enormous amount of line cards to be able to scale up or scale

32
01:43.750 --> 01:45.600
down our operations.

33
01:45.600 --> 01:48.240
So the question is we've talked about a lot of tables.

34
01:48.240 --> 01:52.720
We have the cam, we have the t-cam, we have the rib, and we have the fib,

35
01:52.720 --> 01:55.040
and we have the adjacency table.

36
01:55.040 --> 02:00.240
And all of these are required in order for us to forward packets.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

36
01:55.040 --> 02:00.240
And all of these are required in order for us to forward packets.

37
02:00.240 --> 02:06.560
So the question is where in this architecture do these tables exist?

38
02:06.560 --> 02:10.480
Because all of these tables are populated by the control plane,

39
02:10.480 --> 02:14.240
and yet we use them at the data plane to forward packets.

40
02:14.240 --> 02:19.160
And the answer to this question is going to lie in another question we have to

41
02:19.160 --> 02:19.600
ask,

42
02:19.600 --> 02:23.760
which is which architecture type do we want to use here?

43
02:23.760 --> 02:29.190
And there are two primary architectures that we can use to decide where these

44
02:29.190 --> 02:29.840
tables are,

45
02:29.840 --> 02:32.400
and it impacts how we forward our packets.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

45
02:29.840 --> 02:32.400
and it impacts how we forward our packets.

46
02:32.400 --> 02:35.360
The first option is a centralized architecture,

47
02:35.360 --> 02:40.880
which is typically considered to be a standard or maybe even in some cases a

48
02:40.880 --> 02:41.440
low-end

49
02:41.440 --> 02:45.840
operational architecture for a Cisco switch.

50
02:48.400 --> 02:55.520
So a centralized architecture is going to allow me to keep the tables on the

51
02:55.520 --> 02:57.200
supervisor,

52
02:57.200 --> 03:01.520
meaning that the supervisor is responsible for switching packets.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

52
02:57.200 --> 03:01.520
meaning that the supervisor is responsible for switching packets.

53
03:01.520 --> 03:06.080
So at this point, the supervisor is going to sort of sit in the middle here.

54
03:06.080 --> 03:09.680
I'm going to have my cam and my t-cam and all my tables here

55
03:09.680 --> 03:14.070
so that when a line card receives a packet, it can't make forwarding decisions

56
03:14.070 --> 03:14.640
on its own.

57
03:14.640 --> 03:16.960
It doesn't have the information in the tables.

58
03:16.960 --> 03:20.000
And so it has to forward it along the back plane here

59
03:20.000 --> 03:24.560
to get to the supervisor to make a forwarding decision,

60
03:24.560 --> 03:28.720
at which point the supervisor is going to forward it to the destination line

61
03:28.720 --> 03:29.440
card

62
03:29.440 --> 03:31.840
with instructions on which port to forward it out.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

62
03:29.440 --> 03:31.840
with instructions on which port to forward it out.

63
03:31.840 --> 03:35.200
But again, this line card doesn't know what to do with it.

64
03:35.200 --> 03:39.360
As much as the first one, it just is following orders from the supervisor,

65
03:39.360 --> 03:41.280
which makes all of the decisions.

66
03:41.280 --> 03:45.200
Notice that this architecture is going to hold true,

67
03:45.200 --> 03:49.760
even if the ultimate destination is on the same line card,

68
03:49.760 --> 03:53.040
meaning you would have to forward it up to the supervisor

69
03:53.040 --> 03:55.760
and then it forwards it right back to the same line card

70
03:55.760 --> 03:58.720
and allows it to forward that packet outbound.

71
03:58.720 --> 04:01.920
Now, even in some centralized architectures,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

71
03:58.720 --> 04:01.920
Now, even in some centralized architectures,

72
04:01.920 --> 04:05.760
we at a layer two, we might actually see localized cam tables,

73
04:05.760 --> 04:09.120
but for the most part, we're talking about centralized architectures.

74
04:09.120 --> 04:10.720
This is what we're talking about.

75
04:11.920 --> 04:16.160
So that's great. And again, the advantage to this is that it saves some money.

76
04:16.160 --> 04:20.720
Keep putting tables on line cards, if we wanted to do that,

77
04:20.720 --> 04:23.040
which is the next architecture we're going to talk about,

78
04:23.040 --> 04:25.600
it requires expensive memory on those line cards,

79
04:25.600 --> 04:28.160
it requires additional hardware, it's going to cost more.

80
04:28.160 --> 04:33.360
So this is a cheaper option for one, but do keep in mind that it's also going
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

80
04:28.160 --> 04:33.360
So this is a cheaper option for one, but do keep in mind that it's also going

81
04:33.360 --> 04:34.560
to increase

82
04:34.560 --> 04:39.360
the overall latency and decrease the overall performance

83
04:40.000 --> 04:44.400
of the system relative to the other architecture.

84
04:44.400 --> 04:50.480
And so the other architecture here is known as the distributed architecture.

85
04:50.480 --> 04:55.200
And sometimes we might see this called a decentralized architecture,

86
04:55.200 --> 04:58.720
but for the most part, we'll refer to it as a distributed architecture.

87
04:58.720 --> 05:03.270
At this point, the supervisor is going to still perform all control plane
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

87
04:58.720 --> 05:03.270
At this point, the supervisor is going to still perform all control plane

88
05:03.270 --> 05:04.240
operations.

89
05:04.240 --> 05:08.320
The difference here is that it's going to push that information down

90
05:08.880 --> 05:14.400
to the line cards. And so these line cards now are going to have all of the

91
05:14.400 --> 05:15.360
table information

92
05:15.360 --> 05:21.600
stored locally. What this allows for us to do here is to take advantage of

93
05:21.600 --> 05:26.400
local forwarding decisions. So such that if a packet arrives here,

94
05:26.400 --> 05:32.600
I can make my own decisions, send it through the back plane to the destination
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

94
05:26.400 --> 05:32.600
I can make my own decisions, send it through the back plane to the destination

95
05:32.600 --> 05:33.440
line card

96
05:33.440 --> 05:36.400
and allow it to send it out in the same way that I can make my own forwarding

97
05:36.400 --> 05:37.440
decisions

98
05:37.440 --> 05:42.880
and send it out my local interface. And yes, these tables have the full amount

99
05:42.880 --> 05:43.520
of information.

100
05:43.520 --> 05:48.720
We have the cam, we have the fib, we have the adjacency tables. We have all of

101
05:48.720 --> 05:50.320
the capabilities

102
05:50.320 --> 05:56.000
to send layer two and layer three information. Now remember, the supervisor is

103
05:56.000 --> 05:56.640
still in charge

104
05:56.640 --> 06:02.640
of the control plane. It's going to perform our interior gateway, EIGRP or OSPF
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

104
05:56.640 --> 06:02.640
of the control plane. It's going to perform our interior gateway, EIGRP or OSPF

105
06:02.640 --> 06:04.080
communications.

106
06:04.080 --> 06:08.700
It's going to build all of those tables, whether it's the topology table for E

107
06:08.700 --> 06:10.080
IGRP or the OSPF

108
06:10.080 --> 06:17.440
database. It's going to populate the rib and then it's going to decide, make

109
06:17.440 --> 06:18.320
all of the decisions

110
06:18.320 --> 06:21.920
as far as which routes get installed into the rib. All of that is still

111
06:21.920 --> 06:24.080
performed by the supervisor.

112
06:24.080 --> 06:29.280
But the decisions are sent downstream, which keeps data plane operations here

113
06:29.280 --> 06:30.080
at the line card.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

113
06:29.280 --> 06:30.080
at the line card.

114
06:30.080 --> 06:35.030
And again, control plane operations on the supervisor really segments them more

115
06:35.030 --> 06:35.200
.

116
06:35.200 --> 06:38.870
Whereas with the centralized architecture, the soup is responsible for data

117
06:38.870 --> 06:39.920
control plane

118
06:39.920 --> 06:45.810
and some amount of the data plane operations because it's got to receive every

119
06:45.810 --> 06:46.560
packet and

120
06:46.560 --> 06:51.880
decide what to do with it. Now we look at our modern hardware. For the most

121
06:51.880 --> 06:53.120
part, if we look at

122
06:53.120 --> 06:57.470
catalyst nine Ks, these are largely going to use a centralized architecture. We

123
06:57.470 --> 06:58.880
're talking about

124
06:59.440 --> 07:04.550
chassis in the 94 hundreds and the 9600s. And at the time of this video, both
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

124
06:59.440 --> 07:04.550
chassis in the 94 hundreds and the 9600s. And at the time of this video, both

125
07:04.550 --> 07:05.440
of these use

126
07:05.440 --> 07:10.960
a centralized architecture. If we look at Nexus nine Ks in the data center,

127
07:10.960 --> 07:12.400
these are some pretty

128
07:12.400 --> 07:18.280
popular switches. These use a fully distributed architecture. So we're not even

129
07:18.280 --> 07:19.120
able to run a

130
07:19.120 --> 07:24.280
centralized architecture using the Nexus platforms. Now if we look at more

131
07:24.280 --> 07:26.320
legacy type of switches,

132
07:26.320 --> 07:32.720
then we'll find that the 4500 switches, these were originally developed to be
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

132
07:26.320 --> 07:32.720
then we'll find that the 4500 switches, these were originally developed to be

133
07:32.720 --> 07:33.520
the centralized

134
07:33.520 --> 07:41.040
option. Whereas the 6500s and the 6800s, these were built to be distributed,

135
07:41.040 --> 07:42.720
although in some cases,

136
07:42.720 --> 07:47.410
it depended on the line card. And the Nexus seven K was also a distributed

137
07:47.410 --> 07:49.120
platform. But for the

138
07:49.120 --> 07:51.770
most part, for our modern platforms, just kind of keep in mind which

139
07:51.770 --> 07:52.960
architectures we're talking

140
07:52.960 --> 07:57.710
about here. And also always keep an eye on Cisco white papers and data sheets

141
07:57.710 --> 07:59.360
to find out if they

142
07:59.360 --> 08:03.040
end up coming out with a new switch that runs a different architecture. But
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

142
07:59.360 --> 08:03.040
end up coming out with a new switch that runs a different architecture. But

143
08:03.040 --> 08:03.680
once we know the

144
08:03.680 --> 08:08.580
difference between distributed and centralized, then we can look at a switch,

145
08:08.580 --> 08:09.600
chassis switch,

146
08:09.600 --> 08:13.550
and know exactly how it forwards traffic based on the architecture that it uses

147
08:13.550 --> 08:13.760
.