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 _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
