[c-nsp] CoPP on 7600s

[James Bensley]

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 ?
  ipx
  isis
  eigrp
  ldp
  ospf
  rip
  bgp
  hsrp
  bfd-ctrl
  bfd-echo
  vrrp
  glbp
  ospfv3
  bgpv2
  ripng
  neigh-discover
  wlccp
  arp

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
other?


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


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


Cheers,
James.