So before we begin our discussion on control plane policing, I want to go back and revisit
our discussion on device access and authentication when we were messing around with AAA authentication
and AAA authorization.
So let's go back to R1 on pod 3 just for a moment here. And let's hit enter to get started like we did.
So we have AAA authentication set up. I configured authorization just like we did in our last session.
But what we need to realize is right now the way I have it configured, if we type in Raymond,
we type in our password, remember AAA server is not set up. So we are using our local user
and password database as a fallback. And our problem here was that I wasn't able to get that
privileged command to work. And even after research for quite a while last night,
a lot of the documentation was the exact same. What I did and it still wasn't working, right?
So anyways, in the end, I tested it on another device I had and what the documentation shows worked
on that particular device. So basically, device specific, operating specific,
and you would think that all Cisco iOS routers, same thing, same command set, same everything would work.
Well, obviously, now there's a little bit extra I had to do on this device in order to get it working.
So let me show you here what we have right now as our config. So show run piped section line console 0
and then we will type in AAA. So that way there we can see the config that we have so far.
So right now what we have is we have the authentication command here
and we have the authorization command. So the authentication method list has been applied to my line,
but we still have to go ahead and apply the actual authorization method list.
So let's go ahead and apply that. So we'll type in line console 0
and the command is authorization and then you'll see here that for exec,
we will now type in the name of that method list that we actually created.
So you would do that and notice it actually gives you a warning as well saying this is not going to do anything.
This is useless. It doesn't even work as such.
And so we'll exit out of here. I'll exit out of here.
And let's go ahead and type in our username, type in our password,
and you'll see I'll still be in user exec mode. I won't be elevated to privilege exec mode.
So we'll type in Raymond. We'll type in our password and you'll see I'm still in user exec mode.
So with that in mind, remember the command they said I need to add one more command.
It's not to the line. It's the global configuration mode.
So let's go ahead and add this one more command that we don't have in our configuration.
And let's go ahead and right click, put that in.
And now when we look at our output of do show run pipe to section line, console zero, pipe to triple A,
we'll see here that now we have the authorization.
We have the authentication, but we also have this authorization console as well
because we're connecting through the console port in this particular case.
So if we take a look at do show run pipe to section username now,
what we'll see is that Raymond has privilege 15, but Conrad you don't.
So Conrad, I'm going to pick on you right now. So I have privilege 15, Conrad doesn't.
So let's go ahead and log in as Raymond and see if I automatically get put in privilege exec mode
because it says privilege level 15. And then we'll go ahead and try Conrad's account
and we'll see that Conrad, because it doesn't have privilege level 15,
we're not going to be able to get in in that case.
So let's put in Raymond. Let's put in Raymond's password of Cisco
and you'll see that I'm automatically in privilege exec mode.
All right. So let's back out of there. And now let's go ahead and try Conrad's account.
We'll type in Conrad, put in Conrad's password and you'll see Conrad didn't use our exec mode.
All right. So we're in. We got it. With all that pain yesterday, I figured it out.
Oops. And there we go. So I had to create my method list like we did,
but I also had to put this command in and make sure that we specify it right here.
And it's amazing how many documents out there do not include all of that stuff.
And those are Cisco articles as well. So there you go, folks.
Just something to keep in mind. Probably not going to come up on the certification exam,
but if it does come up on the certification exam, then yeah,
it's quite possible that you might be tested on, for example,
maybe applying that authorization command to the console port
or even maybe that console command authorization console.
So you know about it now. If it does show up, you're all prepared for it.
If it doesn't show up, well, you know more than you need to know, which is not a bad thing either.
All right. So let's go on to control plane policing now.
And so with control plane policing,
we are dealing with a service that gives us the opportunity
to protect our control plane from being overwhelmed with traffic.
So every single one of our Cisco devices has different planes.
We have a control plane, a data plane, a security plane, a management plane,
and so on and so forth. Right? So what is the data plane all about?
The data plane is all about moving traffic. Moving traffic comes in on an interface
and then it gets forwarded through the data plane out another interface.
The goal of the data plane is not to bug the CPU.
So up here we have our brains. Down here we have our power.
So the idea is, is I want to move as much traffic as I possibly can
without ever having to bug the control plane, without ever having to bug the CPU
or using random access memory or anything like that.
At the data plane, we have hardware-based tables. We have forwarding tables.
We have adjacency tables. And when we say hardware-based table,
we're talking about tables that are stored in ternary content addressable memory
and also content addressable memory, so CAM and TCAM.
And we are using application-specific integrated circuits,
also known as ASICs, down at the data plane in order to make sure
that we can make decisions at the data plane based on tables at the data plane
without ever having to bug the control plane.
So all user traffic, our goal is, hey, in and out, in and out, in and out.
As you can see, data traffic comes in port 1, goes out port 2,
never goes to the control plane. Never, never, never, never. Right?
So how does the data plane get built? The data plane gets built based on the control plane.
So the control plane uses address resolution protocol to build, what, an ARP cache.
We have routing protocols, OSPF, EIGRP, BGP, ISIS, RIP, right?
All of those protocols are running in the control plane,
ultimately figuring out how to populate the routing table.
We type in commands to do things, maybe a static route,
or maybe we set a Spanish-free protocol, whatever we're doing, right?
We're typing things, and everything we're doing is affecting the control plane.
Once the tables are built at the control plane,
then the tables that can be put into the data plane are put in there.
So, for example, your routing table, your RIB, Routing Information Base,
is going to ultimately become your FIB down at the data plane,
using Cisco Express Forwarding on our routers.
You have an ARP cache up here that's created,
but down here you're going to have an adjacency table that is going to be used instead.
Even your access control list, you're building your access control list here,
but ultimately the data plane gets a copy of that access control list,
and it's going to be stored in TCAM.
Even your quality of service decisions are decided up here,
but ultimately in the end stored down here.
Why? So that way there we don't have to bug the CPU
every time we need to make a forwarding decision for that end-user traffic.
But let's think about everything else, right?
Think about your ARP traffic.
Think about your OSPF traffic, your EIGRP traffic, your BGP traffic.
Think about pings, trace routes that are to the device or from the device, right?
All of that stuff, the management traffic to or from the device,
the control traffic to or from the device,
that all has to be what we call punted to the control plane.
Punted, that's the official term, to our control plane.
Why? Because that's control type traffic.
Now even management traffic has to get punted to the control plane,
especially if it's management traffic for this device.
Now if it's management traffic not for this device,
then it doesn't get punted to the control plane.
For example, if I'm a user and I'm sitting here
and I ping to, let's say, the IP address of this device,
well, the ping goes through the forwarding plane here,
goes through the forwarding plane here,
and gets punted to the control plane here because that's the destination.
So through this device, that ping is just forwarded at the data plane.
Here, just forwarded at the data plane.
But up here, because it's destined to that device,
it's got to get punted to the control plane
because it's got to be processed because it's for that particular device.
So even if we're running like EIGRP between these two devices,
EIGRP packets, hello packet, in, out, in, out,
punt to the control plane, punt to the control plane,
punt to the control plane, all right?
So you can see a lot of traffic can get punted to the control plane.
And that means our control plane can get overwhelmed.
And what happens when the control plane gets overwhelmed,
then the CPU gets bogged down.
If the CPU gets bogged down and memory gets overwhelmed,
then what happens to your device?
Your device can no longer process more control packets.
It can no longer make decisions.
And think about something like OSPF, our dead timer is 40 seconds.
Well, what if your router CPU is maxed out 100%, let's say, for 40 seconds?
Does that mean that our OSPF neighborhood is going to be broken down
because no hello packets were processed in that 40 seconds?
Absolutely, that's what that means.
So now it's going to have a massive ripple effect throughout the environment
because that neighborhood has gone down.
Therefore, other routers are going to have to clear out their databases
and learn new things, new type 1 LSAs.
So you can see the ripple effect.
If your control plane ever gets overwhelmed,
there can be some serious consequences associated with that control plane
not being able to do its job.
Just think about you running a PC.
And have you ever had your PC's CPU percentage ever go up extremely high?
And then all of a sudden you hear your fans crank up to try and cool it down.
But all of a sudden it's like your mouse is not really working,
things are not really going well for you
because your CPU is so overwhelmed it can't even process your mouse movements.
Well, now imagine a router or a switch's CPU being extremely overwhelmed
and not being able to do anything else that it needs to do.
Luckily, maybe it can still forward the traffic.
Thank goodness we have this separation here, your switches and your routers.
But being able to process like spanning tree messages
or any other type of requirements that it has to do,
maybe like encapsulation for GRE or encapsulation for something like IPsec,
now all of a sudden it can't do it, your routers, because it's overwhelmed.
Now all of a sudden you've got traffic issues.
So how can you get overwhelmed?
Well, in many different ways.
You can get overwhelmed by excessive traffic.
Excessive traffic having to get punted to the CPU.
It could be because of a bug, it could be because of a flaw,
it could be because of a vulnerability,
it could be because of a malicious event, a cyber criminal
causing a denial of service attack on your device by overwhelming your CPU.
So there's a lot of different reasons why that CPU can get overwhelmed.
Some of them are malicious, some of them are not malicious.
But the idea here is for you to take advantage of a feature called control plane policing
so you can stop that control plane from being overwhelmed.
So when we talk about control plane policing, think about it, it's a policer.
That's what it is, a policer for the control plane.
Let's police the traffic that is getting punted to the control plane.
Because if I could police the traffic that's getting punted to the control plane
by rate limiting that traffic, by essentially saying that,
oh, this traffic is going, or there's too much of this traffic going to the control plane.
Therefore, let's rate limit it.
And how do you rate limit?
You essentially drop some of that traffic.
So if all of a sudden somebody was excessively pinging my device
with massive amounts of, let's say, 1,500-byte ping packets
at an exceptional rate for many different devices,
and that's all getting punted to the CPU, that could ultimately overwhelm that CPU.
So if all of a sudden there's an excessive number of pings,
could we drop a lot of those pings
and therefore in the end not overwhelm the CPU anymore?
Absolutely, absolutely.
So you have to think about all the different types of traffic that gets punted to the CPU
and then create a policy that's going to help you rate limit that traffic,
filter that traffic, so it no longer overwhelms the control plane of your device.
So always remember, this is focusing on traffic that is destined to that device itself,
not traffic going through the device.
So if traffic's going through the device, then that means COP will not be applied.
But if traffic is to the device, the CPU of the device is an example,
that's when COP will get involved.
And the reason why is because on our control plane right here,
we actually have an interface.
It's our control plane interface. It's a virtual control plane interface.
So all traffic that gets punted to the CPU has to go through that control plane interface.
All of it.
So we're applying our COP policy to our control plane virtual interface,
so that way all that traffic can then be inspected and filtered as necessary,
so we don't overwhelm our CPU.
Now to implement COP, we're going to use a construct called the MQC.
So the MQC is the Modular Quality of Service Command Line Interface.
The Modular Quality of Service Command Line Interface.
So the MQC wasn't invented for COP.
The MQC was invented for quality of service.
And it's how we can implement quality services on a device,
by specifying class maps, policy maps, and applying a service policy,
all for quality of service.
But it just so happens that the MQC has a feature within it called a policer.
So we can take advantage of that policer aspect of the MQC,
and use it for control plane policing.
So we're only going to focus on the MQC here today,
from the perspective of control plane policing and nothing else.
So with the MQC, think of it like a route map.
Whereas a route map, you're going to have different sequences,
and inside those sequences, you're going to have to say what you want to match,
and then what the actions you want to have for it.
Sort of the same idea.
Not the exact same, right?
But sort of the same idea.
So first of all, you're going to define a class map,
which identifies traffic you want to match.
But here's the thing.
With control plane policing, there's really nothing built into class maps
that allows you to easily identify the traffic that you want to identify
for control plane policing.
So we need to rely on another service outside of this.
And that other service we're going to rely outside of this is access control lists.
So we're going to use access control lists, just like we did for VLAN access maps,
and a lot of other things like policy-based routing,
to define the traffic we want to match.
So typically speaking, your access control lists are all going to be
permits, permits, permits, permits, permits.
I want to permit this traffic, meaning I want to match this traffic.
So you create your ACLs to match the traffic that you want to match
for control plane policing, and then you embed the ACLs inside of the class map.
So the class map has an option to match an access control list.
But a lot of the other things that you can match in a class map
that are built into the class map are quality of service related.
So we're going to take advantage of the access control list option in that class map.
So we're going to create the ACL first, embed that in the class map,
and then we embed class maps inside of a policy map.
So the policy map is where we define what happens to the traffic that matches.
So if you match this class map, I want you to police it this way.
If you match this class map, I want you to police it this way.
So we're going to have one policy map with all the different class maps specified,
and then define the action we want to take on that traffic inside the policy map.
And then the service policy is just the application of the policy to the interface.
So once you apply the policy to your interface, in this case our control plane interface,
then what will happen is it becomes a service policy,
and it's effected that particular point in time.
So I encourage you to know these four levels for the certification exam,
and know what each of them are for, meaning know the definitions like you see them here.
So they say, hey, for cop, what do you use to identify your traffic?
Okay, that's your class map.
For cop, what do you use to define what happens?
That's your policy map.
For cop, what is a service policy?
It's a policy map that has been applied to an interface
and is now enforced and is now in effect.
So I'm going to give you a really poor example here for the certification exam.
Why? Because there are a billion different options,
billion different configurations when it comes to control plane policing.
Why? Because control plane policing is going to be something that you do based on your own circumstances,
your own situations, your own scenarios.
So there's no single perfect solution for everyone when it comes to control plane policing.
So the things I have to point out for you for the certification exam
are going to be things that are just generic in nature.
So that way you have the opportunity to configure, verify,
and troubleshoot control plane policing on the certification exam.
So first of all, let's talk about access control lists here.
Notice I have three different access control lists.
You could have a hundred different access control lists.
You could have one access control list.
But the important thing to realize is that we're going to take the access control lists that we have,
and each of these are going to be what? Part of some class map.
And you have to understand how this construct works of your ACL, your class map, your policy map.
Why? Because in your policy map, you define how the class map is being treated.
And as a result of that, any ACLs that are in the same class map get treated the exact same way.
So if I applied this, this, and this all to the same class map,
then in my policy map, I'd have to treat all this traffic, and this traffic, and this traffic the exact same way.
The same thing is true that if I put all three of these, if I put, sorry,
if I put two of these into a class map, then once they go into a policy map,
that class map, I'm going to have to treat those two the same way,
but the other one can be treated differently because it's going to be part of,
let's say, a different class map.
So inside your policy map, you have to think, okay, in my policy map,
I want to make sure that this is treated differently than this, which is treated differently than this.
So if that's the case, then what do I need? I'm going to need three different class maps
because each class map is then going to have a different treatment applied to it,
which then means I need three different access control lists
because this access control list would be part of one class map.
This access control list would be part of a different class map.
This access control list would be part of a different class map,
and therefore now this traffic can be treated differently than this traffic,
which could be treated differently than this traffic when it comes to control plane policing.
So there are millions of different possible combinations you can go with, right?
If you wanted to treat every single one of these entries differently, differently,
every single one of these traffic types, you wanted to do differently.
Well, then what does that mean for you?
It means you're going to have to have a different class map for each and every single one of these.
Now, in order to get a class map for each and every single one of these,
it means that you're going to have to have a different access control list
for each and every single one of these.
So that way there, this ACL goes into a class map, which then you apply a specific policy to.
Then this one goes in a different class map.
So you would have to have a different ACL, not different entries,
different ACLs, each with a single entry inside each and every single one of them.
So you can see how flexible you can be here.
You can be very granular if you want to be, or you can lump things together like we've done here.
In a lot of cases, you might just group your traffic together based on the types of traffic.
For example, grouping routing protocol traffic together like we've done down here,
or grouping, let's say, management traffic together like we've done here,
or grouping ICMP-related traffic like we have here.
Maybe you'll group reporting traffic together.
You'll group critical application traffic together.
You'll group layer two protocol traffic together.
And then maybe you'll have a grouping for everything else that you've identified that you want to block,
but it doesn't fall into one of those specific categories.
Or maybe something that you want to filter, right?
You're going to create a different access control list for that.
So you could end up with anything from one ACL to hundreds of ACLs just to accomplish your COP access control list.
But the key things to realize here is, you know, we've got all permit statements
because I'm not trying to control the traffic with the ACL.
I'm trying to match traffic with the ACL.
So permit means match this traffic.
I want to match this traffic.
Deny means do not match this traffic.
Ignore this traffic.
So if you're not on the list, I'm just going to simply ignore you and not worry about you.
All right.
So being able, obviously, for the exam to read an access control list entry for control plane policing is really important
because if you're troubleshooting a control plane policing setup and scenario,
it might be as easy as you identifying, oh, they have the wrong ACL.
That's why it's not control plane policing properly.
It's the wrong ACL, right?
They're matching the wrong type of traffic.
So since they're matching the wrong type of traffic,
that means the traffic we really want to match is not actually being matched.
So the answer to the control plane policing scenario on the exam might actually be fixing an ACL.
So being able to read ACLs is really, really important.
So then you get your class maps, and this is where we get into the MQC now,
the Modular Quality of Service Command Line Interface.
So with the MQC, you have, for example, your class map, your class map, and your class map.
You see, these are three different class maps I've created, three different ones.
Class map one, class map two, class map three.
And notice that inside of each class map, I'm matching an access group.
That means an access control list.
That's what that means, ACL in this case.
So I'm matching the access control list named COP ICMP ACL example.
So that is the names that we did over here.
And so I'm matching that one.
And if we look down here, I'm matching the management ACL.
If you look down here, I'm matching the routing protocol ACL.
So for the exam, you might even have to just double check and verify, is this the right one?
Is this the right one?
And remember that we're dealing with case-sensitive values here.
So the name you put here better be the exact same name that was created here because it's case-sensitive.
Now, another thing to look out for is when you create your class map, you're going to give it a name.
So later on, when you embed this name in your policy map, again,
you're going to have to make sure it's the right name that's embedded in the policy map on the exam.
But also, this keyword here, match all, you see how it's match all?
In this case, that is perfectly fine.
Why do I say that is perfectly fine?
I say it's perfectly fine because there is only one item in that class map, one item.
And that is the access control list.
So match all items in this class map, which is that single access control list.
So that's perfectly fine.
That is going to work exactly as we want it to.
But what if, for example, you had, let's pretend here right now, folks.
What if, let's erase this.
Let's erase all of this.
Let's erase this.
Let's erase all of this.
OK.
So let's say that was our class map now.
Class map, match all, match this access control list, this access control list,
and this access control list all within the same class map.
Match all, match all three.
Folks, just think about what that says.
It means match traffic.
That is ICMP traffic, management traffic, and routing traffic.
Is it possible for one packet to be all three of those at the exact same time?
Absolutely not.
Just think about it.
Can an OSPF packet also be a SSH packet and a ping packet all at the exact same time?
No, of course it can't.
So you see now how this is constructed incorrectly.
Because the match all keyword was used, you are telling the class map you want to match
all three of these at the exact same time.
So if this was the scenario, this is the wrong keyword.
You would need to use the other keyword that is match any.
So match any instead, you change that keyword, and now it's this or this or this.
That's the difference.
So pay attention to that as well.
Match all versus match any.
You type in match all, and if there's multiple matches, then that traffic must match all of those.
If you type in match any, then it's that or that or that when it's all said and done.
But now think about this scenario.
If all of them, if all the three ACLs are in that class map and it says match any, does
that now mean that every single one of these are going to have to be policed the exact
same way now because they're in the same class map?
The answer to that is yes, because once we get to our policy map and you specify the
class map in that policy, then anything that matches that class map is treated the same
way.
So again, if that's not the result you want, then you can't do something like this.
So on the exam, if they tell you you want this type of traffic to be treated one way
and this type of traffic to be treated another way, just remember that would require two
class maps, and then each class map would then have to have an access control list inside
of each of them.
So create an ACL for the two traffic types, and then that traffic gets, each ACL gets
embedded in its own class map, so that way they're in the policy map, you can now treat
each class map differently.
I know it's a lot, I know, but you have to learn the steps, you have to learn the construct.
So now if we type in show class map, you'll see that each class map has been created for
us based on our configuration, but there's also one here called the default class map.
So there is a class map that is automatically on your device called the default class map
that catches everything else.
So my ICMP traffic or my management traffic will be caught by this, my routing traffic
will be caught by this based on the ACLs, and then my ICMP traffic will be caught by
this, and then anything else falls into the default category.
So now we'll have the opportunity to police all four of these.
So now let's talk about the policy map.
So the policy map, we go to global configuration, we type in policy map, and we give it a name.
From there, you now start adding your class map.
So here's my first class map I want to add.
This is the management class map.
And then now I just police it.
So police it at what?
A certain rate.
So for example, 32,000 bits per second.
So police at 32,000 bits per second.
So for the exam, for example, they would tell you that number.
They would tell you that number.
So what is the value they want you to put there?
They'd have to tell you that, right?
So I put that in.
And then what do you do if you are conforming to that?
If that management traffic is 32,000 bits per second on average over like a five minute
period or less.
So if it's 32,000 bits per second or less on average, then we can punt it to the CPU.
But if we're exceeding that and traffic arrives, so if we're exceeding that at that moment,
let's say we're at 33,000 bits per second.
We're exceeding that value, then we're going to start dropping some of those packets to
get ourselves back down to 32,000 bits per second or less.
That's what that means.
There is another option here that you might see, and it's violate.
So if you see violate, it simply allows you to have three different actions.
So what does that mean?
Typically, if you violate, then you're going to be dropped.
And then exceed action, you could actually have a different option there.
So for example, traffic that exceeds that limit, you could turn around and you could
maybe mark it as being exceeded.
So you can take other actions like marking the traffic.
So that way there, you still allow it to go.
But if we continue to have issues, then we'll go into the violation mode to kind of give
it a little extra time if you wanted to.
So it's just a couple of different options.
So whether you see conform action, transmit, exceed action, drop, or conform action, transmit,
or violate action, drop, so you don't even have to have this one here.
Or you might see conform action, transmit, exceed action, transmit, violate action, drop.
Those could be options as well for you on the exam.
Just don't let that throw you off the wording.
There's three possible values that you could have.
And whatever you see, just look at what's going on.
Conforming, I'm transmitting, if I'm exceeding, I'm dropping, if I'm violating, dropping,
whatever it is.
The words tell you exactly what's going on.
Right.
And then if you look at our next class map, I'm embedding the next class map in my policy
map.
And this one is for the routing protocols.
I just put in a police here of 34,000 bits per second, conform action, transmit, exceed
action, drop as an example.
So again, reading it.
Can you read it top down?
And this is important.
This is top-down processing as well.
So when traffic arrives, it's going to be compared to this first.
Is it management traffic?
Oh, no, it's not.
Okay.
Go to the next one.
Is it routing traffic?
Yes, it is.
Okay.
This applies now.
Right.
Traffic comes in.
It's SSH traffic.
Oh, that's management traffic.
Okay.
So this one applies.
So top-down processing, immediate execution upon a match, and then you got your default
class at the very bottom, which is not shown here, because I'm just going to leave it as
its default values in this example.
That's why we don't see it.
But we'll see it in our policy map once it's applied.
I'll show it to you when we get there.
All right.
Now, this one here, I purposely set to very low value so I can do a demonstration.
And so this particular very low value says police at 8,000 bits per second.
And if we conform to that, we transmit.
If we exceed, we drop.
All right.
So that's all we're doing here with control plane policing.
Obviously, the MQC, when using it for quality of service, has a lot more options that come
into play.
But this is just the basics for control plane policing, and it's what you need to know for
the certification exam.
All right.
So now that we have our policy map created, then we can verify by typing in show policy
map.
So, for example, like being able to read this on the certification exam is important.
So the things to look out for is the committed information rate, 32,000 bits per second,
34,000.
Make sure those are the values that they actually specified for the certification exam.
And then make sure something like this, this, this, oops, this, this, this, and this are
exactly what they are specifying in those cases.
Those are the key values to know for the certification exam.
And make sure, is that the right class map?
Is that the right access control list?
That's what you're trying to verify in all those different scenarios.
And then we apply to the interface by going to the control plane interface.
So I told you it was an interface, it's having control plane, and now you're in the control
plane configuration mode.
And it says here, service policy input COF policy map examples, so putting the name of
the control plane policy in place.
Most Cisco devices only support input, meaning only if it's being punted, but you can actually
set up a COF policy for outbound traffic as well on a multitude of different devices.
So that's why input exists, because on some devices it's input, output.
So you can control a plane in or out of the control plane, or just so you can police in
or out of the control plane.
All right, so now the feature has been enabled in the control plane, great.
So if we type in show policy map interface brief, what will we see in this example?
COF policy map example, control plane.
So we know it's applied to the control plane interface.
All right, so let's look at our actual policy now in action, and I'll walk you through it.
So being able to read this on the exam is important, so come back and read this.
What I explain to you and show you to read in here is what you want to know.
Everything else would be noise on the certification exam.
Everything else would be noise as you prepare for the exam, so stay as focused as you can
with this.
And try not to get yourself too far in the weeds, because if you do, then you are going
to be spending a lot of time learning things you don't need to know for the exam, and that
is time you need to be learning a lot of other things to get ready for the exam.
So show policy map control plane, it's applied to the control plane.
This is the service policy that has been applied, meaning that you will want to double check,
is that actually the right policy map that was created?
Now down here, you can see the policy map is kind of laid out for you, exactly how you
created it, which is nice, but you also have your statistics in here.
That's why we're looking at it this way.
Because if we just typed in show policy map example, then what we'd be seeing, we'd be
seeing the policy map without the statistics.
So here's our class map that we created, and notice how it even says match all, so be mindful
with that as well.
If you're on the exam, and you're looking at the class map, and the scenario says this
is not working, that's not working, this traffic type is not being matched appropriately, or
it's not being controlled like you want it to, well, maybe it's because that's match
all instead of match any, so therefore the traffic's not being caught by that particular
class map that's specified in the policy map, and that goes back to what we talked about
a while ago.
So if you had match all, and you had four different access control lists inside of that
class map, and you had match all, well, the odds of any traffic matching that now is zero,
because there's no way your traffic could be all those different types of things.
They can't be a routing protocol, and a management protocol, and an ICMP packet, or anything
else all at the exact same time.
So be mindful, it could be something as simple as looking at this going, hmm, let's go double
check the class map and see what ACLs are inside of it.
Oh, look at that, there's three ACLs, that should be match any, not match all in that
particular case.
So then you look at the answer options, let's say it's a multiple choice question, multiple
choice question says change the class map caught, management traffic class map example
to match any.
There you go, you're done.
Right, it could be something as simple as that, but you gotta be aware of how the construct
works in order to figure that out.
You'll see here now that 120 packets so far have been punted to the CPU in this particular
case, or have been, I should say, seen in this particular case, doesn't mean they were
punted to the CPU, it means they have been seen right now by this particular class map
in this policy map, and they total approximately 6,662 bytes.
You'll see here that our five minute rate right now is 1,000 bits per second, and right
now our drop rate is zero, meaning we're not dropping anything.
You'll see that we're matching this particular access control list, so if the class map had
more than one access control list, they would all be listed here, so technically speaking
you do not have to leave here to see if that is correct or not, because just by looking
down here, if there was more than one access control list specified, and one was management,
let's say one was routing protocols, one was ICMP, well then you know that would be incorrect.
So you can go look at other values to confirm, and then answer your questions as needed.
But you'll see here, let's go back to our rate, five minute offer rate is 1,000, what
is our policing rate, it's 32,000 bits per second folks, that's what it is.
So we are well under 32,000 bits per second, what does that mean?
That means that all 120 packets so far have conformed, they have conformed.
And therefore, we transmitted them, whereas if we had exceeded, we would drop, but zero
packets have been exceeded.
Yeah, so your five minute offered rate is 1,000 bits per second, that is our average
over five minutes right now, that is our average over our five minute period.
Now look at our next one.
So when we read this for our next one, there's our class map, same thing to confirm this,
confirm all of this, you'll see 94 packets in total have been seen by this class map
and our policy map, totaling about 9,000 bytes.
Look at our five minute offered rate right now, there's like nothing, there is nothing.
There is not enough routing protocol traffic right now, because I think I was either running
EIGRP or OSPF, I can't remember when I did this example, that was all I was running.
So if it was EIGRP, there'd be an EIGRP packet once every five seconds.
And for OSPF, there'd be one every 10 seconds.
So in the end, over a five minute period, it's like nothing.
It's nothing as you can see.
And right now I have the policer set to 34,000 bits per second, so obviously we're not even
close to achieving that.
So there's all 94 packets being sent.
So what you want to realize for the real world, and like I said, there's no perfect answer
for this, is you would have to figure out what is the value that you would have here
in the real world.
What is your policer going to be set to?
What is the committed information rate you are going to have based on that policer?
And you are going to have to identify that by monitoring your traffic, by identifying
those traffic types and understanding what is the threshold you want to have for that
traffic, and if that is ever breached, then your policer is going to rate limit that traffic.
But if it's under that value, it's going to be perfectly fine.
So that's something you've got to figure out.
I don't have a perfect answer for you.
It takes time, it takes energy, and when you do control plane policing, it's something
you build and then you constantly tweak and tweak and tweak and tweak and tweak and tweak
and tweak and tweak and tweak.
For example, you might build something that is very simple, something that catches, for
example, specific types of traffic, but the access control list is very generic.
So it's not from a specific source or destination, the ACL, maybe it's just capture all IC and
P traffic from any source to any destination, right?
That's it.
And then over time, you monitor that, and then you might start identifying very specific
types of traffic, and maybe some of those very specific types of traffic are causing
you issues.
And then as a result of that, you might want to create an access control list that is very
specific to that traffic, and then create a class map, very specific to that traffic,
and then add an entry to your policy map earlier on, earlier on, because it's very,
the more granular, the earlier you want to put it, just like an ACL, typically, the more
granular it is, put it higher in the ACL list.
So put it nearer the top that class map, and then you're going to be able to catch that
granular traffic, whatever it happens to be, and drop it maybe, maybe you want to drop
it all.
Maybe you're like, hey, we don't even need this traffic type, but I keep getting messages
about it, and I don't even need it.
Okay, well, why is that happening?
It could be because some other service or feature or thing that's running in the environment
that your router gets a copy of like a broadcast message and punts it to the CPU.
It's like, well, geez, that's just causing undue stress on my router for no reason.
So let's drop that traffic if the router ever receives it.
So something as simple as that, right?
You could just totally say, I don't even want it punted to the CPU, just say, if the traffic
matches this ACL, drop, period, done.
Could be as simple as that.
So is there a way to send a message when the CPU goes bald on a certain threshold?
So for example, using SNMP for that would be a good option.
Using simple network management protocol to monitor CPU utilization, and if it goes beyond
a certain threshold, then you could be notified via SNMP about that, and then you could jump
in and figure out why that is, and once you figure out why it's gone, then you might want
to set up a cop policy to police that.
All right, let's move on down here now, because my final example in this particular
case is going to be one where we actually exceed and we actually drop.
So if you recall, this is about ICMP traffic.
So in this scenario, what I did is I had my cop policy set up on my router, and then I
went to all my other routers, all my other devices, and I sent 1,500 byte pings nonstop
to this device.
That's what I did.
And so as you can see, we had 200 packets, and it is showing up as 196,412 bytes, and
I wasn't even running this for five minutes.
So let's be clear.
This five-minute offered rate is like a calculation that the device does, approximation.
So I had only been running this for like a very small amount of time, because 200 packets
with all the devices that were pinging, that would have happened within a matter of less
than 30 seconds, as an example.
But by doing its calculations, it was able to figure out, wait a second, this five-minute
offered rate is going to be approximately 7,000 bits per second, or more than that,
pardon me.
It's going to be more than that, because if you look at the combined here, 7,000 plus
4,000.
7,000 plus 4,000.
Really, I've got 11,000.
So I'm going to approximate 7,000 here.
We got 4,000 as our drop rate, when it's all said and done.
So again, average over five minutes, whether it's been five minutes or not.
And so now we've got to be proactive here.
We've got to start dropping stuff.
So our committed information rate is 8,000, so we've got to be below 8,000.
So that's what it's done here.
You'll see that we've transmitted 103 packets successfully, but we've dropped 97 packets.
So that way there, we can make sure that we don't exceed the 8,000 bits per second.
So we had to drop 97 packets to keep ourselves under 8,000 bits per second.
So that's just an example, right?
So that's so you have the ability to read these on the exam.
They could give you any type of scenario.
It could be a silly scenario.
It could be a scenario that doesn't even make sense from a traffic standpoint.
But the idea here is, hey, they have a question.
They have a scenario.
They're asking you something specific.
Can you read through this and identify what it is?
It could be something as something as out of the following options, which are true.
So now you have to read all your options and you have to compare the options to what you
see.
And then whichever ones are true, those are your answers.
Whichever ones are false, those are not your answers.
So it could be a multiple choice, multiple answer question.
It could be a multiple choice, single answer question.
They'll let you know in those cases.
But the idea is to make sure, yeah, you can read through this and you understand what
you're looking at based on what I've shown you.
And the rest of the stuff would just be in the weeds.
It would be noise that'll distract you on the exam.
So your goal here is to be as focused as you possibly can with COP because there's so much
more to learn.
We could spend an entire session on control plane policing, get into the nitty gritty
details, a bunch of different things, but it's not going to benefit you for the certification
exam.
If you want to learn more about COP and the nitty gritty details for your real world,
then I suggest you look into the COP documentation that Cisco offers for the specific router
platforms that you have running the specific iOS version you have so that you can get the
nitty gritty details you need for that very specific scenario and circumstance you need.
So that is control plane policing to get you ready for the certification exam.