Let's dig into some device architecture now.
In this particular case, we're going to have to be well aware of a multitude of terms and definitions for the certification exam.
So the first discussion I want to have is about planes, not the ones that fly, planes within our device.
So in the context of networking devices, we have the concept of planes.
And this is not only true for Cisco networking equipment, it's true for all networking equipment.
We have the concept of planes.
And planes refers to the different functional layers within our devices architecture.
These planes help what?
They help us organize and compartmentalize various tasks and functions that the networking device is going to have to perform.
And each plane serves a very specific purpose and is going to contribute to the overall operation of the device itself.
So starting here with the data plane.
The data plane, also known as the forwarding plane, is going to be responsible for the actual forwarding of data packets.
So our end user traffic.
So the frames, the packets, the actual traffic that's coming from a PC in some sort of VLAN, subnet, broadcast domain, going where?
Some web server, wherever it happens to be, on the internet, in a data center, doesn't matter.
That's our data plane.
So the data plane handles the routing, the switching of packets based on their destination addresses, their MAC addresses, their IP addresses.
And so it's going to be using tables at the data plane.
You can see some tables here.
The CAM table, MAC address table, CAM table, our forwarding table, our forwarding information base, our adjacency table, our adjacency information base, more on those later, very important.
So this plane is what?
Concerned with the efficient movement of data and doesn't make any high level decisions.
The control plane is responsible for making those high level decisions about how data should be forwarded.
It maintains the routing tables, the MAC address tables.
It's the one responsible for using our dynamic routing protocols to learn information and build our tables.
It's the plane that's responsible for our ARPing and populating an ARP cache.
It's the brains of the device, calculating the routes, resolving the network addresses, updating routing information, using spanning tree protocol, building and sending those BPDUs.
Processing the DTP messages, the VTP messages, the Ether channel LACP or PEGP messages, and the list goes on and on and on.
That's the control plane.
That's what it's doing.
And then you have the management plane.
The management plane is really all about those protocols and services we can use to manage the device itself.
So any tasks related to configuration, monitoring, maintenance by you as an administrator, it falls under this particular plane.
And so the benefits of having these different planes are what?
Well, number one, security, right?
If we isolate the control plane from the data plane, it's possible to prevent unauthorized access to critical routing and control functions.
So enhancing overall network security by having these different layers.
Performance is also improved because if we can separate the data plane and the control plane again, the performance can be improved because this layer can focus on just forwarding of packets,
while this layer can focus on making decisions.
Making decisions like how to build the tables that are necessary to forward the packets.
You keep those separate, then you can associate specific resources to do this and certain resources to do that.
If they don't have to do the same thing or interfere with each other, you get better performance.
And you get resiliency as well.
Why do you get resilience in this particular case?
Because if one plane experiences issues, it's isolated from the other planes.
And so what happens in one plane should not affect another plane.
Meaning a failure of the control plane should not necessarily disrupt the data forwarding that's happening in the data plane.
Stateful switchover, nonstop forwarding.
Remember those?
Yes.
So there's a good example of how when you have different planes,
that you can have nonstop forwarding of the data plane while a switchover is happening at the control plane.
So know at a high level these different planes.
More importantly, control plane and data plane as I've described them to you.
However, we still have to learn about the RIB, the FIB.
What's really going on here with these different types of tables?
Yes, exam relevant.
So routing information base and forwarding information base.
Two distinct components within our routing architecture, within our devices architecture.
They are related.
They kind of work together, but they serve two completely different purposes in the end.
All because they are in different planes.
I encourage you to be able to compare and contrast RIB versus FIB in Encore.
So let's talk about them.
The RIB is responsible for what?
The RIB is responsible for storing, managing, all the routing information that has been learned from the multitude of sources that you have running on that device.
For example, your routing protocols like OSPF, BGP, EIGRP, static routes, connected routes.
All of those help populate our RIB, our routing information base.
And our device has to process and calculate all that information, all those details.
So think about administrative distance, think about metrics.
All of that comes into play.
We're at the control plane to help build that RIB, that routing information base.
So when you typically type in show IP route, you're really looking at the RIB in the control plane, folks.
That's really what you're looking at.
The FIB, on the other hand, is responsible for really just forwarding network traffic in an optimized way, as fast and efficiently as it possibly can down at the data plane.
So the FIB, the forwarding information base, is in the data plane.
It's all about optimizing the forwarding of network traffic.
So the RIB contains what?
The RIB contains a comprehensive list of all the available routes, the different destination networks, the details that are necessary.
But again, it's at the control plane.
If it's at the control plane, then the CPU deals with it.
But the data plane doesn't need the CPU to do what it needs to do with the FIB.
So the FIB is what?
The FIB is a subset of the RIB.
It is a copy of the best RIB information.
It contains the best information that is needed in order to forward traffic.
So the FIB is built from the RIB.
Let me repeat that in case you didn't hear that.
The FIB is built based on the information from the RIB.
And it's the FIB that's actually being used to forward our traffic.
The forwarding information base.
So the FIB is our routing table in our data plane.
Whereas the RIB is our routing table in the control plane.
So if you're on your device, your Cisco device, you can type in show IP route and you're really looking at the RIB.
But if you type in show IP set, you're looking at the FIB.
Let me repeat that.
Show IP set, you're looking at the FIB.
Show IP route, you're looking at the RIB.
So the location, as you've seen, the RIB is the control plane.
Know that.
The FIB is the data plane.
It's programmed into the hardware.
And it's optimized for quick lookups.
Why?
What are we trying to do?
Traffic comes in.
Without bugging the CPU, we want to make a decision as quickly as possible and forward it out in egress interface.
So we want it to be as fast as possible.
Fast forwarding decisions.
Whereas the control plane would be slow.
Why?
Because the CPU has to get involved.
And you see, the FIB is only going to be updated if the RIB gets updated.
So our dynamic routing protocols are running between our devices.
We're building hello packets.
We're sending them.
We're out sending LSAs for OSPF.
We're sending EIGRP updates for EIGRP.
Whatever protocols are running.
And that information is being gathered by the control plane.
It's being processed by the control plane.
The RIB is being built.
The RIB is being updated.
And then when the updates happen here, then that can be updated down here.
So there's no actual processing that's going on in the data plane to build a table.
The table is built from the information of the control plane.
Can't stress that enough.
So when you look at your ARP table, your ARP cache, it's up here in the control plane.
So the ARP table is built from information obtained from what?
The address resolution protocol.
Protocol.
The ARP protocol is used by IP-enabled devices.
To what?
Dynamically learn the Ethernet MAC address of other IP-enabled devices on the same subnet
slash VLAN slash broadcast domain.
So with that in mind, whenever our router needs to build a frame or our multilayer switch needs to build a frame,
what does it need to do?
It needs to send out an ARP request to get the MAC address of the next top IP address so it can build the frame.
If it already has that in the ARP cache, though, it doesn't have to ARP because it's already done it before.
So the ARP cache is in the control plane because the process is involved with building the ARP requests
and receiving the ARP replies and processing all that information and building an ARP cache.
But again, do we want to get the CPU involved when we're trying to forward frames as quickly as possible,
as fast as possible through the data plane?
Well, no, we don't want the control plane to get involved because that requires the CPU to get involved.
So this is where the adjacency table comes into play.
The adjacency table, also known as the adjacency information base or the AIB,
contains the MAC address mappings that we need to make fast, efficient, effective forwarding decisions
right here at the data plane.
So this is going to allow our router now, our multilayer switch, when making those forwarding decisions,
to accept the packet inbound, the frame inbound, using correct terms,
when the frame comes in, and then from there, make the decisions right here,
and then forward it out and never have to get the CPU involved.
Because if the CPU gets involved, that is what we call process switching.
And we don't want the CPU involved, and that would be Cisco Express forwarding.
So the term switching, folks, is kind of misleading until somebody explains it to you,
which I'm going to do right now.
You see, when we say switch, we typically think of a switch at Layer 2 forwarding frames.
When we think of a router, we think of something that takes Layer 3 packets
and makes decisions based on the destination IP address, forwards them.
But what do we call the process?
For example, taking a packet or a frame, whatever, that arrives inbound on an interface,
and then we move it through the device to the exiting interface.
We actually call this movement here from the incoming interface to the outgoing interface.
And the movement is called switching.
That's what it is, regardless of the device.
So the method which our routers or our switches move packets arriving on an inbound interface
to the outbound interface so they can be forwarded on.
So we got process switching, and we got Ceph switching.
So when it comes to process switching,
this is the slowest method that our Cisco devices support.
It's the earliest and least efficient methods that our device could use.
Why? Because it involves the CPU being involved with every single forwarding decision,
every single one.
All right, so consider this from a multilayer switch standpoint.
So we have our frame that arrives on our inbound interface.
The frame needs to get sent to the control plane if we're using process switching.
And so now the CPU gets involved.
What's the CPU going to do?
It's going to strip the Layer 2 header information.
The CPU then has to look up the Layer 3 destination IP address
and compare it to the RIB, the routing information base.
It then figures out, based on the information in the routing table,
what is the exiting interface and the next top IP address.
Once it figures that out, it checks the ARP cache to see if there's a MAC address
for that next top IP address.
If there's not, then it has to send out an ARP request and wait for the ARP reply to come back.
But if it already has it in the ARP cache, then it can go ahead and use the information.
So once it has that information, then it can go ahead and build a new frame, the CPU that is.
So now the new frame is built, and now we can send it down to the outgoing interface so it can be sent.
So think about the fact that you have billions and billions and billions and billions of packets
that need to be processed.
And how big is typically a packet?
A packet is 1,500 bytes, biggest size.
So most packets are going to be probably smaller than that, not much.
And then you get your voice packets that are a lot smaller.
But in the end, could you imagine every single packet having to go through this?
And that's the way it used to be.
Right.
That's the way it used to be.
So software running on the CPU is going to be responsible for making the forwarding decision
on a packet-by-packet-by-packet-by-packet basis.
It's the most CPU-intensive method that is available on our devices.
We could still have our devices do this.
All you have to do is shut off Cisco Express Forwarding.
So if you want to just shut it off on a single interface,
you can do that by going to the interface on your device and saying,
no, the command is, let me write this out for you just in case,
noiprout, R-O-U-T-E, dash, C-A-C-H-E, cef.
So essentially you're saying on the interface,
I don't want to run Cisco Express Forwarding on the interface,
and I don't want to cache any interface, interface,
I don't want to cache any information, that's the word,
information on the interface either.
So in the end, kick everything to the processor for processing.
So that's on the interface.
That's an interface-level command.
And the global command would be noipcef.
That's what it would be.
So if you go to global configuration mode, you type in noipcef,
you then end up shutting off cef on the entire device.
That means every single packet would be kicked to the CPU for processing sakes,
and you don't want that, okay, in modern-day networks.
That would be bad for your network.
So Cisco Express Forwarding is actually the default switching method
that we have running on our Cisco devices.
So it's our fastest method,
and the packets are forwarded based on pre-populated tables where?
In hardware.
So what we have now is we have this high-performance packet forwarding technology,
that's a little Cisco marketing there for you, used in our Cisco network devices.
So our routers, our switches, and so on and so forth using Cisco Express Forwarding.
So we have significant improvement here over process switching.
Why is that?
Well, we get better efficiency, we get better speed, we get better scalability
because we are not having to rely on the CPU anymore.
Remember that with process switching,
the CPU is involved in every decision that has to be made for all the user traffic.
Whereas with Cisco Express Forwarding,
we are going to be using the forwarding information base.
We are going to be using the adjacency information base.
Cef uses fib and AIB.
I'm going to repeat that.
Cef uses fib and AIB.
So both those tables are created, remember, in advance.
They are created in advance and they are going to be stored where?
At the hardware layer.
So depending on the device, this information can actually be stored on your line cards.
So not on the supervisor module, but on the line cards themselves.
And so based on that, just think about the fact that now,
as traffic comes in on an interface on a line card,
if it's going to be going out another interface on the same line card,
it can stay within the line card
and all the information can be decided right there using these tables.
It never even has to go through the back plane of the device.
It can stay within the line card.
Now, if it had to go to a different line card,
then it could actually go from line card to line card
without even needing the supervisor module to get involved.
So the CPU, the route processor, not needed.
That's why this is so powerful.
That's why this is so important.
So we have what we call here hardware tables.
I'm going to put those in quotes.
Why hardware tables?
Because of the fact that this is down in the hardware layer, not the software layer.
We consider the control plane our software layer
because that's where software runs and does things.
This is our hardware layer.
No software is running in here.
We're just trying to take information we have, compare it to a table,
make a decision, move it on.
That's what we're trying to do.
So our AIB, our FIB, hardware tables,
in case they refer to it that way on the exam,
they're created ahead of time by information in the control plane,
as we talked about earlier,
and then they're going to be put into the data plane for us
even before the first packet arrives.
So now the CPU, the control plane, is no longer involved in the forwarding.
So how is that going to happen?
Well, the frame arrives on our ingress interface,
so arriving on an interface inbound.
And in the Layer 2 header now, it doesn't even have to be taken apart.
Because up here, with process switching, we said,
oh, we're going to tear apart, rip apart, destroy the Layer 2 header.
Well, not with Cisco Express Forwarding.
We could just preserve the header information.
We don't have the time or the need to rebuild a frame.
Let's just preserve that framing information,
and we'll just rewrite what needs to be rewritten inside,
making it faster now.
So we don't have to tear apart and build.
We just have to erase and add information in it.
So we look at the Layer 2 header information.
We make a decision based on that.
And if we were a router, as an example,
our MAC address would have been the destination MAC address
in that particular frame,
based on our packet forwarding process, right?
So it comes in, I look, oh, it's my MAC address.
Okay, so don't delete the frame.
Just erase what you don't need and preserve all the formatting,
preserve everything, and just add stuff in after.
So now what are you going to do?
You're going to go ahead and look at the destination IP address.
And now you're going to check it against the FIB and not the RIP.
The FIB.
With the FIB, you're going to figure out what the exit interface is.
You're going to figure out what the next hop IP address is.
You'll then be able to use the adjacency table
to figure out the MAC address of the next hop IP address.
And now you can add that information into the frame that you preserved.
So erase the destination IP, put the new destination,
not destination IP, destination MAC.
Erase the destination MAC, put the new destination MAC in,
source MAC, erase that, put your source MAC in there,
and now you can send it out the egress interface.
So we're just staying in here, and away we go.
So it's much better, much, much better.
And this is all done in hardware, as he said,
in what are called application-specific integrated circuits,
application-specific integrated circuits, ASICs.
So if you don't know what an ASIC is,
an ASIC is an application-specific integrated circuit, all right?
But what that means, it is designed and fabricated
for a very specific application for a very specific purpose.
So think about our networking equipment here.
What do we need?
We need ASICs that are tailored to perform a very particular function.
And what is that going to be?
Well, it's going to be the ability to accelerate the packet processing
that we need to have done and improve our data throughput.
So these are specific ASICs designed to make this happen so fast,
so that way we can have the tables, we can have the lookups,
we can have everything we need done as quickly as possible
with this purpose-built circuit that's going to do it just for us.
That's exactly what we need.
So unlike, what, a general-purpose microprocessor
that can do a multitude of tasks,
this is designed specifically for accelerating the packet process
and improving our data throughput.
Now, not all packets can be processed in hardware.
Let's be very clear about that.
And when they can't be processed in hardware, then what has to happen?
It has to be, the term is, ready for it?
Punted.
So anything that needs to go to the control plane is punted.
Keep that in mind.
Punted.
Just like in football, when you punt the ball,
you are punting it to the control plane in this particular case.
So when might this happen?
Well, if the packet destination is actually the router itself,
like a management packet goes to the router, as an example.
So if that management packet was an SSH connection to this router,
well, then it has to be punted to the CPU for processing.
There is the possibility that the packet might contain IP header options,
and if it does, it's got to be punted to the control plane for processing.
If the time to live is expired, well, then what has to happen?
Well, it needs to be punted to the CPU so the CPU can drop it,
but then the CPU can create a time-to-live-exceeded message,
so an ICMP time-to-live-exceeded message,
and send that back to the original sending device.
So that way there it knows that the time-to-live was exceeded
or the packet expired in transit.
Maybe we have a packet that needs to be sent out a tunnel interface,
then it's got to be punted to the CPU.
Why? Because we have to do some encapsulation now.
We might have a packet that arrives with an unsupported encapsulation type.
Well, in that case, we punt it to the control plane
so the control plane can deal with that.
What about a packet that has an MTU that's too large?
If the MTU is too large, what has to happen?
Fragmentation, that's right.
So fragmentation has to happen,
so we have to punt it to the CPU for fragmentation to occur,
and if the do not fragment bit is set, well, then the packet gets dropped,
but if the do not fragment bit is not set,
then it can be fragmented in that particular case by the CPU,
slowing the device down.
So that's why fragmentation is bad, folks.
It's because we are no longer using Cisco Express Forwarding
where packets need to be fragmented.
We go back to doing good old-fashioned process switching
for that particular packet.
All right.
So with Ceph, we have two different modes.
We have central Ceph and distributed Ceph.
What's the difference?
Well, Ceph is enabled by default, as I said, on our devices,
but not all devices can have a distributed Ceph architecture,
and why is that?
Well, if you think about a lot of your devices,
they are a standalone router, a standalone switch.
They're not modular, but they still use Cisco Express Forwarding.
So in that particular case, the FIB, the adjacency table,
everything that we have in our data plane is not going to be on our line card,
per se, right?
It's still going to be part of our route processor
on that particular device that we have.
So we have central switching because no matter what is going on in the device,
it is happening from a centralized standpoint.
That's the idea here.
Whereas with distributed Ceph, think of your modular switches
with all the different modules you could have.
Well, when you have a modular switch, then you have your route processor.
You have your supervisor modules that are going to be in certain slots.
Well, now you have line cards in the other slots.
Well, in the distributed Ceph for that particular device,
what happens is that those tables are actually going to be stored where?
On the line cards, distributed Cephs.
Now, the line cards can perform the Express Forwarding by themselves,
and it relieves the main processor of the involvement
of being part of this entire process.
That's the difference between central Ceph and distributed Ceph,
what it boils down to.
Now we have our CAM and our TCAM.
CAM and TCAM, two terms I want you to know for the exam.
CAM and TCAM are just really referring to the concept of tables
stored in fast memory so that forwarding decisions are made extremely fast.
When you think about something like our FIB, where is that?
Well, that is in our TCAM.
When you think about our MAC address table, that is in our CAM.
CAM and TCAM, what are they really?
CAM, content-addressable memory, used to make Layer 2 forwarding decisions,
contains our MAC address to port mappings.
CAM is our table at the hardware layer that has our MAC addressing information in it.
When you type in show MAC address table, what you're seeing is information
that would be in the CAM, in your hardware tables,
or in RAM in your MAC address table.
Think about your MAC address table that's in RAM,
for hardware tables stored in CAM, it would essentially be a duplicate of it.
What do we have?
We have our VLAN information, our MAC address information, the port,
so the forwarding decisions can be made that need to be made
as fast as they possibly can.
If we didn't have CAM, then it would be in RAM,
and that would be a lot slower and we'd have to get the CPU involved.
But because CAM is part of our application-specific integrated circuits,
we can do this at the hardware layer as opposed to relying on what?
Software control plane layer making our decisions.
So, used to make Layer 2 forwarding decisions and recording the MAC address,
port MAC was learned on, VLAN of the port, so on and so forth,
at the hardware layer to make fast, efficient, effective forwarding lookups,
to make our switches as fast as possible.
And in TCAM, ternary content addressable memory.
Now, T means ternary.
It really stands for three when it's all said and done.
And the way to best understand ternary is to go back and say,
well, CAM is based on two possible options,
meaning the answer we're looking for is either in the table or it's not in the table.
It's either in the table as an exact match, I should say, or it's not in the table at all.
And you know that from your CCNA days,
when you're learning about how the switch makes Layer 2 forwarding decisions for frames.
It looks in the MAC address table.
Are you there?
If it is, forward it out the very specific port.
If you're not in there, then what?
Flood it out all ports except the port it came in on.
There you go.
Those are your two options.
That is CAM.
Ternary CAM, ternary content, means we have another option that exists.
And just think about the routing table.
So here's an example of the FIB, the Forwarding Information Base, SOAR IPSEF.
What I want you to realize here is that we could have three possible options,
either an exact match or a match that's not exact but still works or no match at all.
And if there's no match at all, what happens?
You get dropped, right?
If there's no match at all, you get dropped when it comes to routing.
If there's an exact match, what does it mean?
Do exactly what it says.
And then based on the fact that we could have those multiple matches,
then we can get as close as possible without being exact.
That is our third possible option there.
So if it is in the table, let's say, for example, 10.40.23.A, I'm just going to use that number, for example.
10.40.23.A, is it in there?
Yes.
Do exactly what it says.
If you're not in the table at all, then drop.
So then what's the other option?
The other option is everything in between.
So think about something like 10.40.12.70.
10.40.12.70, where is that?
That would match here.
Nope, wrong one.
That would match here.
That's what that would match.
So based on it matching that, oh, but also matching that, right?
Longest match rule comes into play, right?
This is our winner.
It's not a perfect match, right?
It's not actually 10.40.12.70, but that is the best option we have.
Ternary content and addressable memory.
And you'll see here that we store not only things like our FIB, but ACL information,
so we can have quick ACL lookups at the hardware layer instead of bugging the CPU.
In the olden days, we had to bug the CPU for ACL processing,
which really slowed down our routers, really slowed them down.
And that's why we were always,
always taking the time to create the smallest ACLs possible by combining
together as many addresses as we possibly could.
That way there's less lookups that have to happen.
But now that we are dealing with ACLs in, what, TCAM, hardware layer,
we don't have to be so perfect with our ACLs.
If I wanted to create 32 entries for 32 different networks in my ACL,
instead of one entry that matches them all, I could get away with that nowadays
because of the fact that this is in the hardware layer now.
Same thing with QoS information.
Also hanging out here in TCAM.
Even policy-based routing information, folks, in TCAM.
So that way there we don't have to punt it to the CPU.
Because if we punt it to the CPU, why would I ever want to do policy-based routing then?
So nowadays, all these features, functions, have the ability to run in TCAM,
so that way there we can take advantage of them
and build the best possible networks we possibly can
with the best, most efficient, fastest forwarding we possibly can.
All right, so CAM tables found on switches, MAC to port to VLAN mapping,
Layer 2 forwarding decisions, TCAM tables on multilayer switches and routers,
ACLs, QoS, Layer 3 processing, and multiple TCAMs exist for better performance.
So that way there we can do what type of lookups?
We can do lookups in parallel.
So while we're looking up the security information and the QoS information,
we could be making a forwarding decision all at the exact same time.
So there's a lot we covered, folks, more than many,
much more than many of you may have hoped for.
So what I want you to know, I want you to know things like what is the RIB,
what is the FIB, what is CAM, what is TCAM, what is the control plane,
what is the data plane, where do I find that ARP cache, that adjacency table,
where do I find the RIB, where do I find the FIB, what is process switching,
what is SEF switching.
Make sure you can differentiate between all of those for the certification exam
because those are more than likely going to be some of the easier questions you face.
They're going to be like short one-liner questions,
and if you don't know exactly what that one-liner is asking you about,
then you're missing out on, I like to call some of the easier points that you can get
on the certification exam.
So make sure you review this, don't take that discussion lightly,
and be able to differentiate between all of those as I have described them to you
to get ready for the certification exam.