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

[Anton Kapela]

On Mar 21, 2010, at 12:39 PM, Dobbins, Roland wrote:

> While this represents a lot of work and experimentation which is greatly to be admired, mightn't simple iACLs plus the GTSM and a few other standard BCPs achieve pretty much the same desired goal with quite a bit less effort?

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. 

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

I would appreciate anything you can share regarding how this is implemented internally on PFC/MSFC platforms. Silently discarded, how? At what point?

All in all (and aside from CoPP), these two mechanisms are indeed great--but they're only great when implemented on $platform, and when it's clear "how" they work on $platform.

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 ports. In my proposal and example previous, the service-policy and route-map pair are required to be applied to protocol-carrying interfaces, not customer/agg/dist-facing ports. The built-in mls rate-limiter handles spurious l2/l3 punts from glean/receive adj. across the entire chassis already -- I merely wanted a few 'narrow exceptions' to that for a handful of interfaces. ;)

-Tk

[1] http://www.cisco.com/en/US/docs/ios/12_3t/12_3t7/feature/guide/gt_btsh.html