[c-nsp] CoPP on 7600s

[Mack McBride]

Ah, that explains it.
It works unless there is more than one match statement.
All of our classes just have one match statement.
Interesting to know.  The older code (6500 code) didn't support multiple
match statements at all so we never added them when we upgraded.

I would evaluate what you can move from HWRL to CoPP.
And yes if you have no icmp redirect everywhere then you can disable the HWRL that corresponds.
Just remember to put it on the Loopback interfaces otherwise you can still have issues.

Mack McBride | Network Architect | ViaWest, Inc.
O: 720.891.2502 | mack.mcbride at viawest.com | www.viawest.com | LinkedIn | Twitter | YouTube


-----Original Message-----
From: cisco-nsp [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Saku Ytti
Sent: Wednesday, July 01, 2015 12:44 AM
To: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] CoPP on 7600s

On (2015-06-30 22:06 +0000), Mack McBride wrote:

Hey,

> I have never run into a problem with using deny in a CoPP ACL.
> It ends that specific class processing if the deny matches.
> The next class will still be processed properly (or at least I have never run into a problem).

In 2006-06-20 I opened CSCse90832 titled 'explicit deny in a CoPP ACL allows traffic to skip later match statemets'. It has this:

--
Workaround:
Use only one match statement per class-map and create multiple class-maps.

Do not use the deny statement in an ACL that will be used as a part of a class-map that has more than one match statement.
--

It's terminated with no fixed versions.


I recall also discussion how it's not supported. And at any rate, there is no use case for it. As self-documenting policy I too like to explicitly add implicit ultimate rules, but in this case it bit me.
I had to open about dozen DDTS's on CoPP when I deployed it in 2006. But I am extremely happy how Cisco handled it, I had access to clued people in escalation TAC and issues were resolved in timely manner.

> We break out classes for pretty much everything we can.
> Complex CoPP tends to work better and need fewer major changes.

We've not changed the design since 2006 and it's ran on hundreds of 7600. I know it's not bullet proof, as some compromises are made for simplicity but I accept that, as 7600 cannot be protected perfectly from directly connected attackers.

> As for HWRL, we use glean and mtu-failure.
> Use of other rate limiters can cause the CoPP to be bypassed on
> ingress And all CoPP to be done in software on the RP.

Our HWRL are full, and I'd like to use more:

mls rate-limit multicast ipv4 fib-miss 2000 10 mls rate-limit multicast ipv4 non-rpf 10 10 mls rate-limit multicast ipv4 igmp 2000 10 mls rate-limit multicast ipv4 partial 2000 10 mls rate-limit unicast cef glean 200 50 mls rate-limit unicast ip options 10 10 mls rate-limit unicast ip rpf-failure 10 10 mls rate-limit unicast ip icmp redirect 0 mls rate-limit unicast ip icmp unreachable no-route 10 10 mls rate-limit unicast ip icmp unreachable acl-drop 10 10 mls rate-limit unicast ip errors 10 10 mls rate-limit all ttl-failure 200 50 mls rate-limit all mtu-failure 10 10 mls rate-limit layer2 pdu 20 20

I could probably get rid of 'icmp redirect' as all interfaces have redirects disabled, that would free me another slot for things I need.

> One important thing to remember with CoPP is to baseline before you
> implement dropping traffic.  That way you can verify what you are
> doing will not affect normal operations.

You can also redirect dropped traffic out to an analyzer port, just to monitor early on what exactly is being dropped, so you can react.

--
  ++ytti
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
This message contains information that may be confidential, privileged or otherwise protected by law from disclosure. It is intended for the exclusive use of the addressee(s). Unless you are the addressee or authorized agent of the addressee, you may not review, copy, distribute or disclose to anyone the message or any information contained within. If you have received this message in error, please contact the sender by electronic reply and immediately delete all copies of the message.