[c-nsp] Sup2T interface ACL limitations

[Łukasz Bromirski]

On 20 Dec 2013, at 14:36, Phil Mayers <p.mayers at imperial.ac.uk> wrote:

> On 16/12/13 14:26, "Rolf Hanßen" wrote:
> 
>>> These are all pretty basic questions; you might want to re-read the docs
>>> a few times to get a better understanding.
>> 
>> Unfortunatelly the docs only describe the theory.
> 
> I wrote a long answer, but decided on a short one:
> 
> Very large ACLs e.g. with 100k entries aren't that common. It's an odd thing to do, IMHO, and you should speak to your Cisco account manager / SE to get feedback from the platform team on the scale limits.
> Personally, I wouldn't do what you're doing - a 100k ACE ACL is just asking for trouble.

Indeed. Even if something that huge will fit into hardware to not
compromise speed, it will be unmanageable (and on most platforms it
will not).

I’ve witnessed two or three customers that I was responsible for @Cisco,
that were at the 60-80k entries mark. They were essentially
(no pun intended) coming from Checkpoint land, where ACLs were tool
to do anything. All of them essentially said: we no longer can manage
this, we no longer can track this, we no longer know what’s going on,
please find us some solution. Heck, I saw RFPs asking for
500-600k ACEs in hardware! (someone haven’t done any market research).

If you need that kind of scale, go for BGP blackholing coupled with
uRPF, and you will a) use the things routers are best in (using their
FIB) and b) dynamically scale/manage the solution.

ACLs are good for basic sanity checks and segmenting the traffic for
ports (L4+). BGP scales way better for L3 than them and it’s faster
and way easier to dynamically update the entries.

-- 
"There's no sense in being precise when |               Łukasz Bromirski
 you don't know what you're talking     |      jid:lbromirski at jabber.org
 about."               John von Neumann |    http://lukasz.bromirski.net