05-13-2019 01:17 AM
Hi
Summary: How can I log COPP (Control plane policer) hits on ISR4k platform?
I have a COPP that accepts required stuff (e.g. ssh, routing protocols...) and explicitly denies everything else in the end. Without going into details it looks like this:
policy-map COPP-POLICY
class PERMIT-BGP
police cir 10000000 bc 625000 conform-action transmit exceed-action transmit violate-action transmit
[ lots of permit stuff omitted ]
class class-default
police 8000 conform-action drop exceed-action drop violate-action drop
control-plane
service-policy input COPP-POLICY
Everything appears to be working but class-default keeps getting hits:
ROUTER#sh policy-map control-plane | s class-default
Class-map: class-default (match-any)
252747 packets, 12917077 bytes
5 minute offered rate 0000 bps, drop rate 0000 bps
Match: any
police:
cir 8000 bps, bc 1500 bytes, be 1500 bytes
conformed 252747 packets, 12917077 bytes; actions:
drop
exceeded 0 packets, 0 bytes; actions:
drop
violated 0 packets, 0 bytes; actions:
drop
conformed 0000 bps, exceeded 0000 bps, violated 0000 bps
[ wait a few seconds ]
ROUTER#sh policy-map control-plane | s class-default
Class-map: class-default (match-any)
252758 packets, 12917796 bytes
5 minute offered rate 0000 bps, drop rate 0000 bps
Match: any
police:
cir 8000 bps, bc 1500 bytes, be 1500 bytes
conformed 252758 packets, 12917796 bytes; actions:
drop
exceeded 0 packets, 0 bytes; actions:
drop
violated 0 packets, 0 bytes; actions:
drop
conformed 0000 bps, exceeded 0000 bps, violated 0000 bps
I would like to see what packets are hitting the class-default. How can I accomplish this?
Things I have already tried:
1) Logging acl. Not supported.
2) Policy-map type logging. Not supported on ISR4k. Works on some other hardware. E.g:
class-map type logging match-all LOGDEBUG-CLASS
match packets dropped
match packets error
policy-map type logging LOGDEBUG-MAP
class LOGDEBUG-CLASS
log interval 2000
3) Packet tracer. I can see dropped packets but no further info about them (e.g. protocol/ip addresses). Is e.g. additional config required?
debug platform packet-trace packet 256 circular data-size 2048
debug platform packet-trace punt
debug platform packet-trace drop
#sh platform packet-trace summary
Pkt Input Output State Reason
0 Gi0/0/2 internal0/0/rp:0 DROP 20 (QosPolicing)
#sh platform packet-trace packet 0
Packet: 0 CBUG ID: 0
Summary
Input : GigabitEthernet0/0/2
Output : internal0/0/rp:0
State : DROP 20 (QosPolicing)
Timestamp
Start : 236896005069573 ns (05/13/2019 07:41:55.530447 UTC)
Stop : 236896005074836 ns (05/13/2019 07:41:55.530453 UTC)
Device is ISR4431 running 16.6.5
Thanks
05-13-2019 01:30 AM
Hello,
in CoPP class-default processes all IP traffic not matched by previous user defined classes and non IP traffic like ARP and STP that are necessary to receive and process
Your configuration
class class-default
police 8000 conform-action drop exceed-action drop violate-action drop
Your configuration has to allow some traffic for class default for ARP to work properly. You shouldn't drop anything in class-default.
Hope to help
Giuseppe
05-13-2019 02:13 AM
Thanks for response. As I wrote I omitted a lots of permitted stuff. For example ARP has been explicitly permitted and it works. I would appreciate answers to my question "How can I log COPP hits on ISR4k platform".
05-16-2019 12:47 AM - edited 05-16-2019 01:17 AM
Hello,
my answer was based on experience with other platforms that do not allow to match ARP packets in a user defined class but only in class-default.
So when I saw your class-default configuration I was worried by the policer configured.
Nice to know that CoPP is smarter in newer platforms.
I agree I haven't answered to your question about logging but my first thought was about possible problems with ARP.
Edit:
In my personal opinion it is not possible to log what CoPP does. This should be an implementation choice.
CoPP has been introduced as a feature to protect the main router CPU from excessive traffic that could cause high CPU usage and even a denial of service.
By dropping packets that can be malformed or are fragments or have options in header that causes CEF to punt those packets to the CPU CoPP actually protects / saves CPU utilization.
If logging those drops detalis would be possible it would cause an increase in CPU usage that is the opposite of the target of the feature.
I think is meaningful that ACLs used in CoPP to match traffic cannot use the log option.
Edit2:
in the following link a doc about best practices for CoPP
https://www.cisco.com/c/en/us/about/security-center/copp-best-practices.html?dtid=osscdc000283
About debugging it reports the following sentence:
Debug Commands — There are no debug commands directly associated with control plane policing in Cisco IOS software releases. The command debug control-plane was introduced in Cisco IOS Release 12.4(4)T, but it is otherwise not widely available and is not discussed here.
Hope to help
Giuseppe
05-22-2019 03:23 AM
Hi
Thanks for explanation. It strongly looks like it's not possible to achieve my goal. This is sad, because IMHO the only way to build a good COPP is to use "explicitly allow required stuff and drop the rest" approach. And by doing so you risk something being dropped inadvertently. It would be very nice to see what's being dropped.
Cisco's dear competitor Juniper offers a very simple solution. You can use "log" keyword in control plane (RE) filter. It stores the log in a special "dataplane ring buffer" that consumes only very little resources.
05-22-2019 04:51 AM
Hello,
Juniper implementation for routing engine protection is different it applies a firewall filter to interface lo0.0 in master routing instance., if I remember correctly.
Hope to help
Giuseppe
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide