A router forwards most traffic in hardware and never thinks about it. A small fraction has to be handled by the processor instead — routing protocol messages addressed to the router, management sessions, packets that need an error response, anything the forwarding path cannot resolve on its own. That fraction is small by design and there is nothing preventing it from becoming large.
Control plane policing is a rate limit on that path. It does not protect the network and it does not filter transit traffic; it protects the processor from being given more work than it can do, so that a flood aimed at the router does not take down the routing adjacencies that hold the network together. The mechanism is the ordinary quality-of-service toolset pointed at an unusual target.
This article covers exactly what the policer sees and what it will never see, how to design classes that are useful rather than decorative, how to choose rates from measurement instead of from a template, what the separate control plane protection feature adds, and the ways a deployment causes the outage it was meant to prevent. It is written for the lab rather than for the written exam, and sits alongside the rest of the CCIE Enterprise Infrastructure lab certification track.
The policer acts only on traffic punted to the processor, never on traffic forwarded through the device, and the classes are built so that the traffic the router cannot operate without has its own guaranteed allowance.What Exactly Does the Policer See?
Which traffic is affected?
Only traffic that the forwarding path has handed to the processor. Packets addressed to the router itself, packets that require an error response to be generated, and packets the forwarding path could not resolve. Traffic passing through the device is untouched at any rate, because it never reaches the path being policed. That boundary is the single most important thing to understand, because a policy written as though it filters traffic will not do anything it appears to do.
A Deeper Dive into the Punt Path
Three reasons a packet is handed up
It is addressed to the router, which covers every routing protocol message, every management session and every monitoring query. It requires the router to generate something — a time-exceeded message for a packet whose lifetime ran out, an unreachable message for a destination with no route. Or the forwarding path encountered something it does not handle: an unusual header option, a destination with no resolved next hop, a state that requires software.
The first category is the one the router cannot operate without. The second is a courtesy to the rest of the network that can be limited hard. The third is where an attack arrives, because generating a large volume of packets in that category is easy and the effort is asymmetric.
Why this is not a filter
A packet crossing the router from one interface to another is forwarded by the hardware and is never presented to the policy. No rate, however low, affects it. This is correct — the feature exists to protect the processor, not to control traffic — and it is the source of a recurring misunderstanding where a class is written to block something that was never going to appear.
Where transit traffic must be controlled, that is an interface access list or a forwarding policy, and it belongs somewhere else entirely. Mixing the two intentions into one policy produces classes that never match and a false sense that something is being enforced.
The asymmetry that makes this necessary
Generating a packet that must be punted costs the sender almost nothing. Handling it costs the router a software operation. A modest stream of such packets from a compromised host can saturate a processor that comfortably forwards many gigabits per second in hardware, because the two paths have nothing in common.
When that happens, the first casualties are the routing adjacencies, because they are handled on the same path as the flood and they have hold timers. A router that forwards perfectly and loses every adjacency takes a large part of the network with it. Preventing that specific outcome is the entire purpose of this feature.
The building blocks
Ordinary classification and policing, applied to a target that is not an interface. Access lists identify traffic, class maps reference them, a policy map assigns a rate and an action to each class, and the policy is attached to the control plane rather than to a physical interface.
Everything else about it is familiar. The unusual parts are the target and the consequences of getting it wrong, not the syntax.
! Classification lists. Note what deny means here - see below.
R1(config)# ip access-list extended ACL-CP-ROUTING
R1(config-ext-nacl)# permit tcp host 10.255.0.2 host 10.255.0.1 eq bgp
R1(config-ext-nacl)# permit tcp host 10.255.0.2 eq bgp host 10.255.0.1
R1(config-ext-nacl)# permit ospf any host 224.0.0.5
R1(config-ext-nacl)# permit ospf any host 224.0.0.6
R1(config-ext-nacl)# permit eigrp any host 224.0.0.10
!
R1(config)# ip access-list extended ACL-CP-MANAGEMENT
R1(config-ext-nacl)# permit tcp 10.200.0.0 0.0.0.255 any eq 22
R1(config-ext-nacl)# permit udp 10.200.0.0 0.0.0.255 any eq snmp
R1(config-ext-nacl)# permit udp host 10.200.0.10 any eq ntp
What deny means in a classification list
Nothing is blocked by it. A list used for classification answers one question: does this packet belong to this class? A permit entry means yes and the class's action applies. A deny entry means no, and the packet continues to the next class — usually ending in the default class, where whatever rate is set there applies to it.
So a deny written with the intention of blocking something achieves the opposite of what was intended: the packet escapes the class that would have limited it and lands in the one that was meant for unclassified traffic. This is the most common single error in these policies and it is entirely invisible until the default class is given a real rate.
show policy-map control-plane shows the intended class with almost no matches and the default class with many. Fix: express exclusions by ordering classes, not by deny entries — put the specific class before the general one and let matching order do the work.How Should the Classes Be Designed?
What is the structure?
Five classes, ordered from most important to least. Critical, holding the routing protocols the router cannot operate without. Management, holding administrative access from known source networks. Normal, holding the error responses and diagnostic traffic that should exist in small quantities. Undesirable, holding traffic that is known to be unwanted and can be discarded outright. And default, which catches everything the other four did not and is the class that must not be given a rate until it has been measured.
A Deeper Dive into Class Design
Critical, which is defined by consequence
A class earns this designation if losing it takes the network down rather than degrading it. The routing protocols in use, and the mechanisms the routing protocols depend on, and nothing else. Keeping it small is the point: a generous allowance is only safe if the set of things receiving it is tightly defined.
It should be written against specific neighbours rather than against a protocol generally wherever that is practical. A class matching one protocol from anywhere is a class an attacker can fill; a class matching that protocol from the four addresses that are actually neighbours is not.
Management, and why the source matters more than the port
Administrative access should be matched by source network as well as by service. An administrative class open to the whole world is an invitation to fill it, and filling it locks out the people who would otherwise fix the problem — which is the worst possible failure mode for this particular class.
Where a management network exists, match on it. Where administrative access can come from anywhere, split the class: a generous allowance for the known networks and a small one for everything else, so that a flood from outside cannot consume the capacity the operations team needs.
Normal, which is mostly error responses
Time-exceeded and unreachable messages, echo requests, and the traffic generated by ordinary diagnostics. All of it is useful, none of it is urgent, and a small fixed allowance is appropriate. This class is where the limit should be visibly tight, because the volume required for legitimate use is genuinely small.
It is worth separating the error responses from the echo traffic if the platform's counters make that useful, because a surge in generated unreachable messages is a specific signal — it usually means somebody is scanning an address range that routes to this device and has no destinations in it.
Undesirable, which is an opinion
Traffic the organisation has decided should never reach a router's processor. Legacy protocols that are no longer in use, services that were never enabled, source addresses that should not exist on the network. This class drops rather than polices, and its contents are a policy decision rather than a technical one.
The discipline it needs is review. A class that drops outright will eventually contain something that became legitimate, and nothing will report it — the traffic simply disappears. An annual read of what this class contains is enough and is more than most deployments get.
Default, which is where the danger is
Everything that did not match. In a well-understood network this should be almost empty, and in a real network it never is, because there is always something nobody remembered. Setting a rate on it before finding out what is in it is the single most reliable way to cause an outage with this feature.
The correct sequence is covered in the next section and amounts to: apply the policy with the default class counting rather than dropping, read it, investigate what turns up, and only then decide.
! Class maps referencing the lists
R1(config)# class-map match-all CP-CRITICAL
R1(config-cmap)# match access-group name ACL-CP-ROUTING
R1(config)# class-map match-all CP-MANAGEMENT
R1(config-cmap)# match access-group name ACL-CP-MANAGEMENT
R1(config)# class-map match-all CP-NORMAL
R1(config-cmap)# match access-group name ACL-CP-NORMAL
R1(config)# class-map match-all CP-UNDESIRABLE
R1(config-cmap)# match access-group name ACL-CP-UNDESIRABLE
!
! Policy. Order matters - first match wins.
R1(config)# policy-map COPP
R1(config-pmap)# class CP-CRITICAL
R1(config-pmap-c)# police cir 512000 conform-action transmit exceed-action transmit
R1(config-pmap)# class CP-MANAGEMENT
R1(config-pmap-c)# police cir 256000 conform-action transmit exceed-action transmit
R1(config-pmap)# class CP-NORMAL
R1(config-pmap-c)# police cir 64000 conform-action transmit exceed-action transmit
R1(config-pmap)# class CP-UNDESIRABLE
R1(config-pmap-c)# police cir 8000 conform-action transmit exceed-action transmit
R1(config-pmap)# class class-default
R1(config-pmap-c)# police cir 128000 conform-action transmit exceed-action transmit
! Attached to the control plane, not to an interface
R1(config)# control-plane
R1(config-cp)# service-policy input COPP
!
! Every exceed action above is transmit. Nothing is dropped yet.
! That is deliberate - this is the measurement phase.
Ordering, which does the work exclusions cannot
Classes are evaluated in order and the first match wins. That property is how an exception is expressed: put the specific class before the general one. Administrative access from the management network matches the generous class; the same service from anywhere else falls past it into a tighter one, because the tighter class comes second.
Building exceptions this way rather than with deny entries produces a policy whose behaviour can be read off the order, which is also the thing the counters will show you. It is easier to verify and harder to get subtly wrong.
| Class | Contains | Action | Written against |
|---|---|---|---|
| Critical | Routing protocols | Generous limit | Specific neighbours |
| Management | Administrative access | Moderate limit | Known source networks |
| Normal | Error responses, echo | Tight limit | Protocol and type |
| Undesirable | Known unwanted | Drop | Organisational policy |
| Default | Everything else | Count first, always | Nothing — it is the remainder |
How Do You Choose the Rates Without Guessing?
Where do the numbers come from?
From the network, over at least a week. Apply the full policy with every class counting and nothing dropping, leave it, and read the counters. The peaks observed — including the ones during the weekly backup, the monthly change window and whatever else the first week happens to contain — are the basis for the rates, with headroom. Rates taken from a published example describe somebody else's network and have no relationship to this one.
A Deeper Dive into Rate Selection
The measurement phase in detail
Every class present, every access list complete, and every exceed action set to transmit. Nothing is discarded and the policy is, in forwarding terms, doing nothing at all. What it is doing is counting, per class, which is information that exists nowhere else on the device.
A week is a minimum because network traffic has a weekly cycle. A month is better if the change calendar has a monthly rhythm. The cost of waiting is zero because the policy is not enforcing anything, and the cost of not waiting is an outage during whatever periodic event was not represented in a shorter sample.
! Read the counters. These are the only numbers that matter.
R1# show policy-map control-plane input
Control Plane
Service-policy input: COPP
Class-map: CP-CRITICAL (match-all)
184052 packets, 14908212 bytes
5 minute offered rate 12000 bps, drop rate 0000 bps
police:
cir 512000 bps, bc 16000 bytes
conformed 184052 packets, 14908212 bytes; action: transmit
exceeded 0 packets, 0 bytes; action: transmit
Class-map: class-default (match-any)
98214 packets, 7211004 bytes
5 minute offered rate 41000 bps, drop rate 0000 bps
The class-default number, which is the point of the exercise
A default class with meaningful traffic in it means something is reaching the processor that nobody classified. That is exactly the information the exercise exists to produce, and it is always more interesting than expected: a monitoring system using a protocol nobody documented, a legacy discovery mechanism still enabled, a neighbour that is not in the list because it was added after the list was written.
Every one of those should be investigated and then either given its own class or deliberately left in the default. What must not happen is a rate being applied to the default while its contents are unknown, because the unknown contents are frequently something important.
Choosing headroom
The measured peak is a floor, not a target. The rate should sit above it by enough to absorb a legitimate surge — a device rebooting and re-establishing every adjacency at once, a management system doing a full inventory sweep, a topology change causing a convergence burst.
Doubling the measured peak is a reasonable starting point for the critical and management classes and is deliberately generous, because the cost of a rate that is too high is that an attack takes slightly longer to be limited, while the cost of a rate that is too low is an outage. Those consequences are not symmetric and the rates should not be either.
Enforcing gradually
Change the exceed action to drop on one class at a time, least critical first. Undesirable, then normal, then management, then critical, and the default class last of all — after everything found in it during measurement has been given a home or consciously abandoned.
Between each step, leave enough time for the periodic events to recur. Enforcing all five at once means that if anything breaks there are five candidate causes, and the investigation starts by undoing all of it.
! Enforce one class at a time, least critical first
R1(config)# policy-map COPP
R1(config-pmap)# class CP-UNDESIRABLE
R1(config-pmap-c)# police cir 8000 conform-action drop exceed-action drop
!
! Later, after observation
R1(config-pmap)# class CP-NORMAL
R1(config-pmap-c)# police cir 64000 conform-action transmit exceed-action drop
!
! Reset the counters when starting a new observation period
R1# clear control-plane *
Rate or packet rate
Some platforms allow the limit to be expressed as packets per second rather than as bits per second, and for this application that is usually the more meaningful unit. The processor's cost is per packet and is largely independent of packet size, so a limit in packets corresponds to the resource actually being protected.
Where both are available, packets per second is the better choice for the classes that exist to stop a flood, and bits per second is fine for classes whose traffic is bulk. Where only one is available, it is not worth agonising over — a measured limit in the wrong unit is far better than an unmeasured limit in the right one.
The burst allowance
A policer has a burst size as well as a rate, and the default burst is often small relative to what a legitimate convergence event produces. A routing protocol re-establishing many adjacencies simultaneously generates a short, intense burst that is well within the average rate and can exceed a tight burst allowance.
The symptom is characteristic: everything is fine for weeks, and a maintenance window that restarts several devices produces drops in the critical class at exactly the moment the network is trying to reconverge. Sizing the burst to cover a full reconvergence, rather than leaving it at whatever the rate implies, prevents it. Reading this once is not the same as being able to do it under time pressure, which is what repetition against realistic CCIE lab practice scenarios is for.
What Does Control Plane Protection Add?
How is it different?
The basic feature treats everything punted to the processor as one aggregate. The extended feature divides it into three separate paths — traffic addressed to the router itself, traffic being sent to the processor because it could not be forwarded, and traffic requiring an exception to be generated — and allows a separate policy on each. It also adds two mechanisms the basic feature has no equivalent of: discarding traffic to ports with no listener, and limiting the queue depth any single protocol can occupy.
A Deeper Dive into the Extended Feature
Three paths instead of one
Separating them matters because their traffic profiles are entirely different. Traffic addressed to the router is what the routing protocols and management sessions use and should have a generous, carefully classified allowance. Traffic punted because the forwarding path could not resolve it is almost always either a transient or an attack. Exception traffic is the error responses and should be small.
With one aggregate policy, a flood in the second category consumes the allowance the first category needs, unless the classification is perfect. With separate policies, the categories cannot take capacity from one another, which is a structural protection rather than a classification-dependent one.
! Separate policies for the three paths
R1(config)# control-plane host
R1(config-cp-host)# service-policy input COPP-HOST
!
R1(config)# control-plane transit
R1(config-cp-transit)# service-policy input COPP-TRANSIT
!
R1(config)# control-plane cef-exception
R1(config-cp-cef)# service-policy input COPP-EXCEPTION
Closed ports, handled before classification
A packet sent to a port on which the router has no listener will be punted, examined and discarded, having cost a software operation. Sending a large number of such packets to random ports is trivial and the cost falls entirely on the router.
The port filter discards these earlier, without the per-packet examination. It is a specific defence against a specific and easy attack, it needs no configuration beyond enabling it, and it has no legitimate traffic to break — by definition the packets it discards were going to be discarded anyway.
! Discard traffic to ports with no listener, before it costs anything
R1(config)# class-map type port-filter match-all CP-PORT-FILTER
R1(config-cmap)# match closed-ports
!
R1(config)# policy-map type port-filter CP-PORT-POLICY
R1(config-pmap)# class CP-PORT-FILTER
R1(config-pmap-c)# drop
!
R1(config)# control-plane host
R1(config-cp-host)# service-policy type port-filter input CP-PORT-POLICY
Queue depth, which limits one protocol's share
Separately from rate, the number of packets any one protocol may hold in the input queue can be capped. This addresses a different failure: not too much traffic overall, but one protocol monopolising the queue so that others are dropped at the queue rather than by any policy.
It is most useful for protocols that can legitimately burst but whose loss is tolerable. Capping their queue share guarantees space for the protocols whose loss is not tolerable, regardless of what rates were configured elsewhere.
! No single protocol may monopolise the input queue
R1(config)# class-map type queue-threshold match-all CP-QUEUE
R1(config-cmap)# match protocol ftp
!
R1(config)# policy-map type queue-threshold CP-QUEUE-POLICY
R1(config-pmap)# class CP-QUEUE
R1(config-pmap-c)# queue-limit 50
!
R1(config)# control-plane host
R1(config-cp-host)# service-policy type queue-threshold input CP-QUEUE-POLICY
Switches, where much of this is built in
On a modern campus switch a comprehensive control plane policy usually ships enabled, with classes for each kind of punted traffic and rates chosen by the vendor. Customisation means adjusting that policy rather than writing one, and the classes have fixed names that must be used.
Two consequences. The measurement phase is still necessary but starts from a populated policy rather than a blank one, which is less work. And the platform's own hardware rate limiters may act before the software policy does, which means a rate configured in software is an upper bound rather than the operative limit. Checking the platform's own view, rather than only the policy counters, is necessary on these devices.
! Campus switch: adjust the built-in policy, do not replace it
Sw1(config)# policy-map system-cpp-policy
Sw1(config-pmap)# class system-cpp-police-routing-control
Sw1(config-pmap-c)# police rate 2000 pps
!
! And read the platform's own counters, not only the policy's
Sw1# show policy-map control-plane
Sw1# show platform hardware fed switch active qos queue stats internal cpu policer
Whether the extended feature is worth it
On a router carrying transit traffic at the edge of the network, yes, because the separation between the three paths is exactly the separation that matters there. On a device deep inside a controlled network, the basic aggregate policy with good classification delivers most of the benefit for considerably less configuration.
The honest position is that the aggregate policy, measured properly and enforced gradually, is worth far more than an elaborate three-path policy with rates nobody measured. Effort spent on measurement outperforms effort spent on structure.
| Capability | Basic policy | Extended feature |
|---|---|---|
| Rate limit punted traffic | Yes, as one aggregate | Yes, per path |
| Separate self-addressed from unresolvable | No | Yes |
| Discard traffic to closed ports | No | Yes |
| Limit one protocol's queue share | No | Yes |
| Configuration effort | Modest | Substantially more |
| Benefit without measurement | None, in either case | |
Which Deployments Cause Their Own Outages?
What goes wrong?
Four things, and all of them are self-inflicted. A default class given a rate before anyone looked at what it contained. Rates copied from an example written for a different network. A burst allowance that cannot absorb a reconvergence. And a management class narrow enough that the people who could fix any of the above cannot reach the device. That last one turns a manageable mistake into a site visit.
A Deeper Dive into Self-Inflicted Failures
The default class, applied early
The most common serious failure. Somebody writes a good policy, gives the default class a modest rate because it is "only unclassified traffic", and discovers over the following weeks that the unclassified traffic included a monitoring protocol, a backup system's discovery mechanism and a neighbour that was added after the access lists were written.
The symptoms are intermittent and appear unrelated, which makes the connection to the policy hard to draw. Weeks can pass between the change and the diagnosis, and the policy is often not the first suspect because it was working when it was applied.
show policy-map control-plane shows a non-zero drop counter on the default class. Fix: set the default class back to transmitting, identify everything in it, give each item a class, and only then reconsider enforcing.Rates from an example
Published examples exist to demonstrate structure, and their numbers describe the network they were written for. A branch router's legitimate control plane traffic and a data centre aggregation router's differ by orders of magnitude, and neither resembles the figure in a document.
The structure is worth copying. The rates are not, and a policy deployed with borrowed rates has not been designed at all — it has been guessed at, with the consequences of a bad guess falling on the routing protocols.
Locking yourself out
A management class matched narrowly to a management network is good practice until the management network is unreachable and access has to come from somewhere else. If the alternative path lands in a default class with an enforced rate, and something is already filling that class, the device cannot be reached at the moment it most needs to be.
The mitigation is a second management class with a small allowance, matching administrative access from anywhere. It is tiny — enough for one session — and it is the difference between fixing a problem remotely and driving to a site. Console access is the fallback and is not always available.
Forgetting that it does nothing for transit traffic
A policy written in the belief that it filters traffic will have classes that never match and will provide no protection of the kind intended. The router's processor is protected; nothing else is. Where the intention was to control what crosses the device, that work still has to be done, elsewhere.
This one is not an outage, it is a false sense of security, which is arguably worse because nothing ever reveals it.
A verification set worth keeping
Five checks. The policy is attached. Every class has non-zero matches, because a class with none is either wrong or unnecessary. No class has drops other than the ones intended to drop. The default class's volume is understood. And the burst allowance on the critical class has been tested by an actual reconvergence rather than by reasoning.
That last one is the one nobody does, and it is the one that catches the failure most likely to occur at the worst possible moment.
! The five checks
R1# show policy-map control-plane input | include Class-map|drop rate|exceeded
R1# show policy-map control-plane input | include packets,
!
! Is it attached at all?
R1# show running-config | section control-plane
!
! Reset before an observation period, and after any change
R1# clear control-plane *
!
! Then cause a real reconvergence and read the critical class again
R1# show policy-map control-plane input | section CP-CRITICAL
What to keep in the change record
The measured peaks that produced each rate, and the date they were measured. Without that, a future engineer looking at a rate cannot tell whether it was derived or invented, and will treat it as arbitrary — which means it will be changed without measurement, or left in place long after the traffic profile has changed.
A line per class, with a number and a date, is enough. It is the difference between a policy that can be maintained and one that becomes untouchable because nobody knows where the numbers came from.
Blueprint framing
The CCIE Enterprise Infrastructure v1.1 blueprint covers device access control and control plane protection within its infrastructure security and services domain. What is asked is generally the mechanism and its boundary — what is policed, what is not, and why a classification list's deny behaves as it does — rather than a large policy build.
| Failure | Root cause | Prevented by |
|---|---|---|
| Intermittent failures weeks later | Default class enforced blind | Measure first, enforce last |
| Drops during reconvergence | Burst too small | Test with a real restart |
| Cannot reach the device | Management class too narrow | A small catch-all admin class |
| Class never matches | Deny used as a block | Order classes instead |
| Nothing is actually protected | Rates copied from an example | Rates from this network |
| Policy becomes untouchable | No record of the measurements | A number and a date per class |
Conclusion
The feature protects one thing: the processor's ability to keep doing the work only it can do. Traffic crossing the device is untouched at any rate, which means a policy written as though it filters will contain classes that never match and will deliver none of the protection intended. The boundary is the punt path, and everything else follows from it.
The class structure is the easy part and copying it is fine. Critical for what the network cannot survive losing, management scoped to known sources, a tight allowance for error responses, an outright drop for what the organisation has decided it does not want, and a default class holding the remainder. Exceptions belong in the ordering rather than in deny entries, because a deny in a classification list does not block anything — it moves the packet to the next class, usually the default, which is the opposite of the intention.
The rates are the hard part and there is no shortcut. A policy applied with every class counting and nothing dropping, left alone for a week, produces the only numbers that describe this network. The default class's contents will contain something nobody expected, every time, and that discovery is the point of the exercise rather than an interruption to it. Enforce gradually afterwards, least critical first, default last, and size the burst by restarting something rather than by reasoning about it — because the burst is what fails, and it fails during the reconvergence the policy was supposed to protect. More CCIE Enterprise Infrastructure material — labs, protocol breakdowns and study guides — is collected on the SPOTO CCIE site.
External Links
- RFC 6192 — Protecting the Router Control Plane
- RFC 2474 — Definition of the Differentiated Services Field
- RFC 2698 — A Two Rate Three Color Marker
- RFC 2697 — A Single Rate Three Color Marker
- RFC 1812 — Requirements for IP Version 4 Routers
- Cisco Learning Network — CCIE Enterprise Infrastructure
Reference Notes
- RFC 6192 describes protection of the router control plane, distinguishing traffic destined for the router from traffic transiting it and recommending that only the former be subject to control plane filtering.
- RFC 6192 recommends a permissive initial deployment that logs or counts rather than discards, so that legitimate control plane traffic is identified before any policy is enforced.
- RFC 6192 notes that control plane traffic includes both packets addressed to the router and packets that require the router to generate a response, such as ICMP errors.
- RFC 1812 specifies the conditions under which a router generates ICMP messages, including time exceeded and destination unreachable, which are handled by the control plane rather than the forwarding path.
- RFC 2697 defines a single rate three colour marker, specifying the committed information rate together with committed and excess burst sizes, which is the model a policer implements.
- RFC 2698 defines a two rate three colour marker, in which a peak rate is specified in addition to the committed rate.
- RFC 2474 defines the differentiated services field used for marking, which policers may set as a conform or exceed action instead of transmitting or discarding.
- Cisco documentation describes control plane policing as a modular QoS policy applied to the control plane interface, acting on traffic punted to the route processor.
- Cisco documentation states that an access list used for classification within a class map treats a permit entry as a match and a deny entry as a non-match, so that denied traffic is evaluated against subsequent classes.
- Cisco documentation describes control plane protection, which divides the control plane into host, transit and CEF-exception subinterfaces, each supporting its own policy.
- Cisco documentation describes the port-filter and queue-threshold policy types available under control plane protection, which discard traffic to closed ports and limit the queue occupancy of individual protocols.
- The CCIE Enterprise Infrastructure v1.1 unified exam topics include device access control and control plane protection within the infrastructure security and services domain.