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 <[email protected]> // <http://www.arbornetworks.com> Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
