[c-nsp] CoPP on 7600s

James Bensley jwbensley at gmail.com
Mon Jun 29 05:00:08 EDT 2015

On 26 June 2015 at 10:10, Saku Ytti <saku at ytti.fi> wrote:
> On (2015-06-25 22:13 +0100), James Bensley wrote:
> Hey James,

Hi Saku, thanks for the response...

>> The HWRLs support other protocols too that ARE supported in CoPP in
>> hardware, so are there any other protocols that people prefer to
>> police using the HWRLs?
> Example please, I cannot recall overlap.

Using MLS I can choose any of the following protocols...

7606(config)#mls qos protocol ?

And follow that with a policer "mls qos protocol xxx police <bps> <burst>"

So I'm wondering if it's best to police protocols using these MLS
HWRLs or in CoPP, why would policing via one method be better than the

>> With regards to ACLs, do people really have giant access lists of
>> peers they allow BGP to/from? The 7600 I am piloting this on has over
> Yes. Two, one low rate for SYN and one for other BGP, alas. However if your
> master configuration data is not network, but database, then it does not
> really matter how complex or simple the network configuration is, as it's
> generated automatically from database.
> If it's pure CLI jockey network, it can be a challenge.
> But even this is isn't as good as it should be, as each neighbour would need
> to have their own policer, like Cisco LPTS or Juniper ddos-protection can do.
> But this is one of those things where you'll rather carry a risk than
> overcomplicate the configuration.
> I have opted for simplicity, I have CoPP class for internal signalling stuff,
> which is critical, another for important customer/peer stuff, like BGP, and
> another for unimportant stuff (ping, udp traceroute...)

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

>> What do people do with unusual traffic like IP fragments? I am
>> discarding them. Thoughts?
> If you can get away discarding fragments hitting control-plane, do it. If not,
> police it.

Agreed, done!

>> What about packets with IP options set, I am allowing record-route
>> only and dropping the rest. Thoughts?
> No on expects IP options to work in the Internet, there is mls command
> to police them, I would do that, even for transit

Agreed, done!

>> ICMP, I'm just proposing to allow the follow:
>> ip access-list extended CoPP-Limit-and-Permit-ICMP
>>  permit icmp any any echo
>>  permit icmp any any echo-request
>>  permit icmp any any unreachable
>>  permit icmp any any ttl-exceeded
>>  permit icmp any any packet-too-big
>>  deny icmp any any
>> Again, any thoughts there?
> Never use 'deny' in PFC3 CoPP ACLs. It's not needed, and it may not be
> supported and may cause negative match and stop of evaluation (i.e. won't fall
> to next classs).

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.


More information about the cisco-nsp mailing list