Re: Debugging ISR 4k COPP drops

kjdhghsghsfg · ‎05-13-2019

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

Giuseppe Larosa · ‎05-13-2019

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

kjdhghsghsfg · ‎05-13-2019

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".

Giuseppe Larosa · ‎05-16-2019

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

kjdhghsghsfg · ‎05-22-2019

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.

Giuseppe Larosa · ‎05-22-2019

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