Reflexive ACL: slow throughput and high cpu (sup2t/ios15.2)

[ralfw]

Hello,

if I attach the below acls I get slow throughput and high cpu on a sup2t with ios 15.2. If I copy a file with scp from 172.22.91.41 to 172.22.152.x with the acls attached I get 4.4MB/s and without the acls 111.7MB/s. What's wrong with the acls ? Shouldn't the sup2t do this in hardware ?

Thanks
Ralf

interface Vlan152
description MENET (ME Management Net)
ip address 172.22.152.1 255.255.255.0
ip access-group MENET_in in
ip access-group MENET_out out
no ip unreachables

interface Vlan291
description EDUNET02
ip address 172.22.91.1 255.255.255.0
ip access-group EDUNET02_in in
ip access-group EDUNET02_out out
no ip unreachables

ip access-list extended EDUNET02_in
evaluate EDUNET02_traffic_out
permit udp 172.22.91.0 0.0.0.255 host 172.22.1.10 eq domain reflect EDUNET02_traffic_in
permit udp 172.22.91.0 0.0.0.255 host 172.22.1.10 eq ntp reflect EDUNET02_traffic_in
permit udp 172.22.91.0 0.0.0.255 host 172.22.1.20 eq domain reflect EDUNET02_traffic_in
permit udp 172.22.91.0 0.0.0.255 host 172.22.1.20 eq ntp reflect EDUNET02_traffic_in
permit udp host 172.22.91.41 172.22.148.0 0.0.3.255 range 1025 65535 reflect EDUNET02_traffic_in
permit tcp host 172.22.91.41 172.22.148.0 0.0.3.255 range 1025 65535 reflect EDUNET02_traffic_in
deny ip 172.22.91.0 0.0.0.255 10.0.0.0 0.255.255.255
deny ip 172.22.91.0 0.0.0.255 172.16.0.0 0.15.255.255
deny ip 172.22.91.0 0.0.0.255 192.168.0.0 0.0.255.255
permit ip 172.22.91.0 0.0.0.255 any reflect EDUNET02_traffic_in
deny ip any any
ip access-list extended EDUNET02_out
evaluate EDUNET02_traffic_in
permit ip 172.22.0.0 0.0.255.255 172.22.91.0 0.0.0.255 reflect EDUNET02_traffic_out
permit ip 192.168.0.0 0.0.1.255 172.22.91.0 0.0.0.255 reflect EDUNET02_traffic_out
deny ip any any

ip access-list extended MENET_in
evaluate MENET_traffic_out
permit udp 172.22.152.0 0.0.0.255 host 172.22.1.10 eq domain reflect MENET_traffic_in
permit udp 172.22.152.0 0.0.0.255 host 172.22.1.10 eq ntp reflect MENET_traffic_in
permit udp 172.22.152.0 0.0.0.255 host 172.22.1.20 eq domain reflect MENET_traffic_in
permit udp 172.22.152.0 0.0.0.255 host 172.22.1.20 eq ntp reflect MENET_traffic_in
permit ip 172.22.152.0 0.0.0.255 172.22.0.0 0.0.255.255 reflect MENET_traffic_in
permit tcp 172.22.152.0 0.0.0.255 host 192.168.255.209 eq 443 reflect MENET_traffic_in
deny ip 172.22.152.0 0.0.0.255 10.0.0.0 0.255.255.255
deny ip 172.22.152.0 0.0.0.255 172.16.0.0 0.15.255.255
deny ip 172.22.152.0 0.0.0.255 192.168.0.0 0.0.255.255
permit ip 172.22.152.0 0.0.0.255 any reflect MENET_traffic_in
deny ip any any
ip access-list extended MENET_out
evaluate MENET_traffic_in
permit ip host 172.22.0.4 172.22.152.0 0.0.0.255 reflect MENET_traffic_out
permit ip host 172.22.0.8 172.22.152.0 0.0.0.255 reflect MENET_traffic_out
permit ip host 172.22.0.16 172.22.152.0 0.0.0.255 reflect MENET_traffic_out
permit ip 172.22.212.0 0.0.1.255 172.22.152.0 0.0.0.255 reflect MENET_traffic_out
permit ip 192.168.199.0 0.0.0.255 172.22.152.0 0.0.0.255 reflect MENET_traffic_out
deny ip any any

[ralfw]

can't remove these post..

[Joseph W. Doherty]

15.2SY?

• Except on MPLS interfaces, reflexive ACL flows are processed in hardware after the first packet in a session is processed in software on the RP.
• Reflexive ACL flows are not accelerated in hardware for traffic from IP to various tags and traffic from various tags to IP. Reflexive ACL flows are also not accelerated in hardware for any traffic coming in and going out of all tunnel interfaces.

• With egress ACL support for remarked DSCP configured, the PFC and DFCs do not provide hardware-assistance for these features:

– Cisco IOS reflexive ACLs

From the above, it appears there's some hardware limitations when using reflexive ACLs.

At a quick glance of your ACLs, it's not obvious (to me), from the above, why such a performance loss.

You might be able, if you take much time, to identify, what particular ACEs seems to cause the most impact, if such can be identified.

Or, perhaps you might try to tailor your ACLs following the traditional ACL performance rules used on software based routers, such as trying to get the most hit ACEs toward the top of the ACL or, if possible, simplification of the ACL, such as using an ACE to allow TCP with established bit set to avoid using an actual reflexive rule for such TCP flows.

[ralfw]

Yes, version is 15.2 and as soon I start the scp the load get high
an IP input usage CPU..

fb4_int2#sh version
Cisco IOS Software, s2t54 Software (s2t54-ADVENTERPRISEK9-M), Version 15.2(1)SY5, RELEASE SOFTWARE (fc4)

fb4_int2#sh processes cpu sorted
CPU utilization for five seconds: 100%/25%; one minute: 34%; five minutes: 13%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
461 24322532 129253491 188 61.64% 17.61% 4.16% 0 IP Input

fb4_int2#sh processes cpu history

9999999999911111 1111111111 11111 11111
9999995555522222777770000022222888880000055555333336666677
100 ***********
90 ***********
80 ***********
70 ***********
60 ***********
50 ***********
40 ***********
30 ***********
20 ***********
10 **********************************************************
0....5....1....1....2....2....3....3....4....4....5....5....
0 5 0 5 0 5 0 5 0 5
CPU% per second (last 60 seconds)

[Joseph W. Doherty]

IP input is CPU doing data forwarding rather than dedicated ASIC hardware.

So, for whatever reason, from what you describe, your ACL appears to be done by CPU.  (Which, in my experience, on switches, is of low capacity - as normally it appears to be sized for expected control plane processing needs.)

One (perhaps the only) option is to try to find an acceptable ACL that is processed by the ASICs, or can be done much faster by the CPU.