[nsp] Performance of gsr engine-0 and -1 LC's with ACLs

[Saku Ytti]

On (2004-06-04 15:33 -0700), Steve Francis wrote:

> Does anyone have any light to shed on the actual performance impacts of running ACL's on GSR engine-0 and engine-1 line cards?
> Per cio, engine-1 LC's can support inbound ACL's in hardware with recent IOS releases. Does that mean no impact?
> WIth engine-0 LCs, what effective pps can be supported with inbound acls? in- and outbound acls? (Specifically on a 4 port OC3 POS card, only one port in use.)

 E0 and E1 are both software switching card, E2 is first one with ASIC.
E0/E1 have baseline of 400kpps (E2 4Mpps) and with ACL's around 150kpps
(E2 0.8Mpps). Of course size of ACL matter in E0/E1 much.
 To make it tricky, E2 does ingress ACL's in PSA (it's ASIC), but
E1 can also use something they call 'salsa' (access-list hardware salsa)
But I have no clues about salsa, nor it's performance increase. I suspect
that performance increase is not dramatic with 'salsa'.

 E3,E4+(And supposedly E5,E6) OTOH can do ACL's on wire speed in both
directions. And are much sensible line cards in general terms.

 This is not even worst thing to say about E0/E1 cards, IMHO they introduce
serious risk to continuity of whole core. E2 might be acceptable in pure core
links, but even then it's very easy to DoS E2 down, it has one queue to LC
CPU, and understanding how it handles different packet types makes overloading
E2 very feasible, much under 4Mpps. rACL/control-plane policer (12.0(29)S)
bring little help this issue, as they are not implemented in ASIC, but in
LC CPU.

 Two top picks to worry about from top of my head:
1) E1/E0 sending back pressure signal, don't allow it.
2) putting egress ACL on E0/E1/E2/GRP interfaces implements it on E2 ingress,
     remember the dramatic decreaes in forwarding speed.

> Is there any info about the impacts, or do I just have to try it and see?
> Thanks

 
-- 
  ++ytti