[c-nsp] CoPP on 7600s

[Saku Ytti]

On (2015-06-25 22:13 +0100), James Bensley wrote:

Hey James,

> I am trying to write a CoPP template for some 7600s running as PEs. It
> would be handy if they were running a similar CoPP configuration to
> that on our Juniper PEs we are going to be connecting these 7600's too
> so we have consistent CoPP across that domain of equally exposed

It's not going to be consistent, CoPP does work, but can't really compete with
over decade newer Trio kit.

> CoPP on 7600's can't police ARP but one can use the MLS HWRL for that.
> The HWRLs can also handle other protocols like HSRP and CoPP can't
> police multicast in hardware, so do people usually police ARP and HSRP
> using the MLS HWRLs instead of CoPP?

Pretty sure HSRP works just fine. For multicast, you just need to allow all
multicast in CoPP (otherwise it's processed by software CoPPP, which you don't
want) and then limit in mls rate-limit.

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

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

> any any eq 179" as above then I feel I need to police, unless I can
> guarantee at the edge I have filtered out traffic on TCP 179 from
> everywhere it shouldn't be coming from. What approach to others take
> here? Why?

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

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

> 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

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

-- 
  ++ytti