[c-nsp] Protecting a sup2/msfc2 in 2010: CoPP the "hard way"

[Dobbins, Roland]

On Mar 22, 2010, at 1:17 AM, Anton Kapela wrote:

> Input/receive acls, as far as I'm aware, are not supported (on 65xx), regardless of cfc/dfc/etc status--and only exist in the GSR and 10k platforms. 

iACL = infrastructure ACL.  It's merely a technique making use of normal inbound ACLs, processed in hardware on Sup2 (as well as later Sups).  You're thinking of the rACL, which is supported on GSR and 7500 only, AFAIK.

> 
> With regards to GTSM[1] -- indeed it's in the SX train and available for sup2 in SXE onwards. However, one bit gives gave me a bit of pause when reviewing it at 2am: "If the value is less than the configured value, the packet is silently discarded and no Internet Control Message Protocol (ICMP) message is generated."  

Combine it with iACLs and you're set.

> I also argue that maintaining a flattened-out input ACL blocking packets to receive adjacencies puts the engineering effort-required slider up a few notches; I appreciate the clean/simple nature of CoPP and dislike loading up ACL cam, per port, with repetitive filters, across all or most port

>From my standpoint, it's a whole lot *easier* to generate an iACL than making use of the HWRL (or using CoPP), and it only has to be applied to edge interfaces on edge boxes, nowhere else.  And it's the same on every box, irrespective of platform.  The only prerequisite is a rational, summarizable IP addressing plan for one's loopbacks and p2p interfaces.

If you take some time to plan it out, I think you'll find the iACL is pretty useful.

;>

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

    Injustice is relatively easy to bear; what stings is justice.

                        -- H.L. Mencken