[c-nsp] CoPP on 7600s

[Mack McBride]

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

We use separate BGP and BGP flags groups in our network.
So BGP is one and any port 179 source or destination with SYN, FIN, or RST set is another.
We also have a default BGP class so all BGP works but if it isn't specifically allowed it can be slow
To converge.  We make updating the ACL part of the BGP provisioning process.
Since we have to update prefix-lists as well, this isn't extraordinarily difficult.

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

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.

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.

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: Monday, June 29, 2015 6:03 AM
To: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] CoPP on 7600s

On (2015-06-29 10:00 +0100), James Bensley wrote:

Hey,

> Using MLS I can choose any of the following protocols...
> 7606(config)#mls qos protocol ?

These are not control-plane, they apply to transit as well. You don't want to use them, unless you must (neigh-disco, arp)

> I can knock up a quick script to generate ACLs for CoPP but then every
> time a peer is added the ACL needs updating. Since this is a PE box
> BGP adds/moves/changes are fairly frequent. This will quickly reach
> the point where someone forgets to remove a peer or add them to the
> script etc. The KISS approach is always best but "any any eq 179" is
> just too simple IMO, perhaps a policer for connections with SYN flag
> set on TCP 179 and then another policer for all other traffic on TCP
> 179.

We've not had problems with it. It's just one line to add, to already quite many lines when provisioning BGP peer. And no one forgets, because peer won't come up without.
Forgetting extra lines there, does not appear catastrophic to me.

> OK I had read about it potentially stopping the evaluation against
> remaining ACLs so noted. Perhaps a better method here is to make
> another ACL that matches the traffic I definatly want to drop and in
> there have "permit icmp any any" which is less specific and then under
> my CoPP policy just have the drop action.

Let unwanted just to flow to last class of 'IP' which matches ACL 'any any'
and drops even conforming traffic.
Then leave class-default as last, and allow traffic there (non IP will hit it, like CLNS)

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