But believe it or not, when we talk about routers and layer three devices, we
're usually talking
about them performing routing.
And they do perform routing.
That involves looking things up from a routing table perspective.
But believe it or not, they also perform switching.
Just why we often talk about the concept of layer three switching.
And so when we're looking at things from simply a process perspective, it's
going to be very
important to understand how exactly packets get switched within a layer three WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
important to understand how exactly packets get switched within a layer three
device.
So what we're talking about here is we have our layer three device and a packet
has just
arrived.
Well the routing side of things is going to look at the rib and it's going to
decide
which interface to send it out as well as what that next top is.
The process of switching it over and writing the new headers, this is the
switching part
of it. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
of it.
And so we want to be able to perform this switching, which again involves the
interface
and the new layer two header, want to perform this operation as fast as
possible.
And from start to finish here really, even the rib part, we really want to try
to speed
this up, however we can do it.
So how exactly does this process work?
Well at a fundamental level, we have the concept of process routing.
This is how we're going to perform routing by involving the route processor or WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
This is how we're going to perform routing by involving the route processor or
the CPU.
The router CPU is going to be involved with process routing and really this is
the, again
the foundational version of performing layer three switching because it can't
get any simpler
than this.
What happens here is the packet arrives and the packet gets processed by the
CPU itself.
The CPU is going to check the rib and get all the information and then the CPU WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
The CPU is going to check the rib and get all the information and then the CPU
is also
going to check the layer two information such as checking the art table and
everything to
build the new layer two header and then it's going to place it onto the new
interface for
us.
This is an intensely slow process.
For a couple of reasons, first of all the CPU is, yeah it's plenty fast but it
's really
not built to operate at the speed at which we're talking about here at least
when we
think about receiving gigabits per second of packets and having to do this that WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
think about receiving gigabits per second of packets and having to do this that
many
times per second, especially when it has other responsibilities.
And that's just it.
A CPU is going to perform operations in a list or sequential order.
And so it might have lots of operations here and so operations like crazy.
And so at some point we need to process the packet that just arrived.
So it's going to wait for that process in order to perform it.
So maybe finally here we can actually take a look at the packet and do WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So maybe finally here we can actually take a look at the packet and do
everything that
needs to and send that packet on.
But then we're waiting until the next opportunity for the next packet to be
sent.
And meanwhile we're just waiting in here for the CPU to do all the other things
that
are responsible for on the platform.
So that's number one why this whole process is very slow.
There's a second reason however and that has to do with the rib itself. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
There's a second reason however and that has to do with the rib itself.
Rib lookups operate sequentially.
Meaning that if I have to, if I have to look up a particular subnet, I have to
look through
all of the routes in order or more to the point, I have to look at every single
route
until I have found a match.
So if I have 1000 routes, this might take 1000 different lookups.
If it happens to be the very last route that I take a look at, it's going to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
If it happens to be the very last route that I take a look at, it's going to
take a very
long time to get through the rib.
So if I have to do this with every single packet and when I think about the
concept of waiting
for the CPU to be available, plus how long it takes for the rib lookups to
happen, this
would be very, very slow.
So we need to come up with methods for speeding this up.
Now the first method that was developed was known as fast switching. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now the first method that was developed was known as fast switching.
Fast switching is not what we prefer to use today, but it was a step in the
right direction.
And the idea here was to, first of all, perform process switching one time.
So we perform process switching on the first packet.
That's going to a particular destination.
Then what we're going to do is we're going to create a cache and we're going to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Then what we're going to do is we're going to create a cache and we're going to
cache
that destination.
So now when there's a new destination that comes in, it's going to have to go
through
the entire process routing process and then it will get forwarded on.
No problem.
When an old, we'll call it old here, maybe we should say it's a repeat.
Let's use that word instead of old.
When we have a repeat destination come in, well, instead of going through the
process WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
process
routing process, we are going to check that cache.
This cache is going to be a whole lot faster in terms of getting the
information that I
need so that I can send this out quickly.
So this accomplishes two things.
First of all, the cache is faster.
So it's a faster lookup process, which is important compared to the rib being a
slow
process here.
And second of all, we don't have to wait for the CPU's availability. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And second of all, we don't have to wait for the CPU's availability.
And so fast switching actually lives up to its name.
It's a much faster way for us to perform routing on a layer three device.
However, we do still have some problems here and it really especially involves
the fact
that we're still relying on process switching.
It's the first packet of every destination.
And our cache is only, I mean, it's limited. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And our cache is only, I mean, it's limited.
We're going to run out of space eventually.
And so occasionally a repeat destination is still going to have to go back
through the
process routing process in order to repopulate the cache.
And so those are some problems with fast switching.
And fortunately we do have a solution to this.
is known as Cisco Express Forwarding or SEF.
[BLANK_AUDIO]