All of this is great when we're talking about what we might call a fixed
configuration switch,
meaning that even though we might have an uplink module or something that
allows us to customize a few ports,
for the most part we have a fixed amount of ports on the switch, like a 24 or
48 port switch,
and if we want more ports in our access closet we're just going to have to add
another switch.
And maybe we support stacking the two switches together and making a logical
switch, there's lots of options here.
But a fixed configuration switch is fixed from a physical perspective. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But a fixed configuration switch is fixed from a physical perspective.
I can't simply add a bunch of new ports without adding a whole new switch.
Whereas we also have chassis switches.
And chassis switches are going to allow us to find a architecture that allows
for physical modularity.
The way this works is we usually have a supervisor line card,
and potentially a redundant supervisor line card in here, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and potentially a redundant supervisor line card in here,
and these are going to manage the control plane.
It's effectively managing the brains of the outfit.
So the system, the control plane, all kinds of operations are managed by the
supervisors.
Meanwhile, if I want front-facing ports, meaning ports that connect out to the
rest of the world,
well, then I'm going to have to add individual line cards here, sometimes
abbreviated as LCs.
These line cards operate the data plane.
And so we see we have physical separation. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And so we see we have physical separation.
We have data plane operation on the line cards, control plane operation on the
supervisors.
And then a lot of chassis will allow us to add potentially a small amount,
potentially an enormous amount of line cards to be able to scale up or scale
down our operations.
So the question is we've talked about a lot of tables.
We have the cam, we have the t-cam, we have the rib, and we have the fib,
and we have the adjacency table.
And all of these are required in order for us to forward packets. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And all of these are required in order for us to forward packets.
So the question is where in this architecture do these tables exist?
Because all of these tables are populated by the control plane,
and yet we use them at the data plane to forward packets.
And the answer to this question is going to lie in another question we have to
ask,
which is which architecture type do we want to use here?
And there are two primary architectures that we can use to decide where these
tables are,
and it impacts how we forward our packets. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and it impacts how we forward our packets.
The first option is a centralized architecture,
which is typically considered to be a standard or maybe even in some cases a
low-end
operational architecture for a Cisco switch.
So a centralized architecture is going to allow me to keep the tables on the
supervisor,
meaning that the supervisor is responsible for switching packets. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
meaning that the supervisor is responsible for switching packets.
So at this point, the supervisor is going to sort of sit in the middle here.
I'm going to have my cam and my t-cam and all my tables here
so that when a line card receives a packet, it can't make forwarding decisions
on its own.
It doesn't have the information in the tables.
And so it has to forward it along the back plane here
to get to the supervisor to make a forwarding decision,
at which point the supervisor is going to forward it to the destination line
card
with instructions on which port to forward it out. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
with instructions on which port to forward it out.
But again, this line card doesn't know what to do with it.
As much as the first one, it just is following orders from the supervisor,
which makes all of the decisions.
Notice that this architecture is going to hold true,
even if the ultimate destination is on the same line card,
meaning you would have to forward it up to the supervisor
and then it forwards it right back to the same line card
and allows it to forward that packet outbound.
Now, even in some centralized architectures, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now, even in some centralized architectures,
we at a layer two, we might actually see localized cam tables,
but for the most part, we're talking about centralized architectures.
This is what we're talking about.
So that's great. And again, the advantage to this is that it saves some money.
Keep putting tables on line cards, if we wanted to do that,
which is the next architecture we're going to talk about,
it requires expensive memory on those line cards,
it requires additional hardware, it's going to cost more.
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
So this is a cheaper option for one, but do keep in mind that it's also going
to increase
the overall latency and decrease the overall performance
of the system relative to the other architecture.
And so the other architecture here is known as the distributed architecture.
And sometimes we might see this called a decentralized architecture,
but for the most part, we'll refer to it as a distributed architecture.
At this point, the supervisor is going to still perform all control plane WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
At this point, the supervisor is going to still perform all control plane
operations.
The difference here is that it's going to push that information down
to the line cards. And so these line cards now are going to have all of the
table information
stored locally. What this allows for us to do here is to take advantage of
local forwarding decisions. So such that if a packet arrives here,
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
I can make my own decisions, send it through the back plane to the destination
line card
and allow it to send it out in the same way that I can make my own forwarding
decisions
and send it out my local interface. And yes, these tables have the full amount
of information.
We have the cam, we have the fib, we have the adjacency tables. We have all of
the capabilities
to send layer two and layer three information. Now remember, the supervisor is
still in charge
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
of the control plane. It's going to perform our interior gateway, EIGRP or OSPF
communications.
It's going to build all of those tables, whether it's the topology table for E
IGRP or the OSPF
database. It's going to populate the rib and then it's going to decide, make
all of the decisions
as far as which routes get installed into the rib. All of that is still
performed by the supervisor.
But the decisions are sent downstream, which keeps data plane operations here
at the line card. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
at the line card.
And again, control plane operations on the supervisor really segments them more
.
Whereas with the centralized architecture, the soup is responsible for data
control plane
and some amount of the data plane operations because it's got to receive every
packet and
decide what to do with it. Now we look at our modern hardware. For the most
part, if we look at
catalyst nine Ks, these are largely going to use a centralized architecture. We
're talking about
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
chassis in the 94 hundreds and the 9600s. And at the time of this video, both
of these use
a centralized architecture. If we look at Nexus nine Ks in the data center,
these are some pretty
popular switches. These use a fully distributed architecture. So we're not even
able to run a
centralized architecture using the Nexus platforms. Now if we look at more
legacy type of switches,
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
then we'll find that the 4500 switches, these were originally developed to be
the centralized
option. Whereas the 6500s and the 6800s, these were built to be distributed,
although in some cases,
it depended on the line card. And the Nexus seven K was also a distributed
platform. But for the
most part, for our modern platforms, just kind of keep in mind which
architectures we're talking
about here. And also always keep an eye on Cisco white papers and data sheets
to find out if they
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
end up coming out with a new switch that runs a different architecture. But
once we know the
difference between distributed and centralized, then we can look at a switch,
chassis switch,
and know exactly how it forwards traffic based on the architecture that it uses
.