Network slow with ACLs

[sasaadamovic]

Hi All,

Any help here would be apreciated.

We are doing our DR tests and having issue with network being realy slow when polling data from backup servers. I have a workarround, but trying to understand what is the cause of the issue and if that can be resolved.

Here is scenario. There is 6506 switch with following config:

Mod Ports Card Type                              Model              Serial No.
--- ----- -------------------------------------- ------------------ -----------
  1    8  CEF720 8 port 10GE with DFC            WS-X6708-10GE      SAL1309KZDC
  2    8  CEF720 8 port 10GE with DFC            WS-X6708-10GE      SAL1309KZCY
  3   48  48 port 10/100/1000mb EtherModule      WS-X6148-GE-TX     SAL1306JB2S
  4   48  48 port 10/100/1000mb EtherModule      WS-X6148-GE-TX     SAL1306J3EZ
  6    2  Supervisor Engine 720 (Active)         WS-SUP720-3B       SAL12351H62

Mod MAC addresses                       Hw    Fw           Sw           Status
--- ---------------------------------- ------ ------------ ------------ -------
  1  0021.a0ef.7368 to 0021.a0ef.736f   1.6   12.2(18r)S1  12.2(18)SXF1 Ok
  2  0021.a0ef.73b8 to 0021.a0ef.73bf   1.6   12.2(18r)S1  12.2(18)SXF1 Ok
  3  0024.c40f.71e8 to 0024.c40f.7217   7.2   7.2(1)       8.5(0.46)RFW Ok
  4  0024.c40f.6b88 to 0024.c40f.6bb7   7.2   7.2(1)       8.5(0.46)RFW Ok
  6  000a.b86d.8104 to 000a.b86d.8107   5.7   8.5(2)       12.2(18)SXF1 Ok

Mod  Sub-Module                  Model              Serial       Hw     Status
---- --------------------------- ------------------ ----------- ------- -------
  1  Distributed Forwarding Card WS-F6700-DFC3C     SAL1308K23T  1.2    Ok
  2  Distributed Forwarding Card WS-F6700-DFC3C     SAL1309KZPH  1.2    Ok
  6  Policy Feature Card 3       WS-F6K-PFC3B       SAL12330EVD  2.4    Ok
  6  MSFC3 Daughterboard         WS-SUP720          SAL12330KS2  3.2    Ok

We have a number of VLANs and number of access lists, that we need to protect our production environment. ACLs are allowing all devices within DR

to talk to each other and stops any communication toward production environment.

Issue is that when we transfer data between servers on different VLANs it is slow. If we move servers on same VLAN transfer speds up dramatically. Also, if we live servers on different VLANs and remove ACLs transfer improves dramaticaly.

Speed with ACLs and servers in various VLANs is fine for running DR scenarios, but too slow for recovering number of servers from backup servers. I have worked arround this by moving servers between VLANs as they are being recovered and puting them back once data is transfered. However, would like to now what has caused this issue and how to solve it.

If you have any ideas, please let me know.

Regards,

Sasa

[Edison Ortiz · Accepted solution]

Let's see the ACL. In some cases, an ACL may be running in software if you add log keyword for instance.

[sasaadamovic]

Hi,

Thanks for your reply.

Yes, I am using logging in each line of ACLs. If that makes ACLs run in software that would explain issues I am seeing.

ACLs are now proven to work correctly (from access controll point of view), so I can remove log keyword and see if performance improves.

As you asked, here is one of my ACLs:

ip access-list extended EUR521
10 permit ip 167.229.222.128 0.0.0.63 167.229.222.128 0.0.0.63 log
20 permit ip 167.229.222.128 0.0.0.63 10.1.3.0 0.0.0.255 log

30 permit ip 167.229.222.128 0.0.0.63 167.229.143.0 0.0.0.63 log
40 permit ip 167.229.222.128 0.0.0.63 167.229.150.128 0.0.0.63 log
50 permit ip 167.229.222.128 0.0.0.63 167.229.148.224 0.0.0.31 log
60 permit ip 167.229.222.128 0.0.0.63 167.229.149.0 0.0.0.127 log
70 permit ip 167.229.222.128 0.0.0.63 167.229.222.192 0.0.0.63 log
80 permit ip 167.229.222.128 0.0.0.63 167.229.223.0 0.0.0.63 log
90 permit ip 167.229.222.128 0.0.0.63 167.229.153.0 0.0.0.255 log
100 permit ip 167.229.222.128 0.0.0.63 167.229.219.0 0.0.0.127 log
110 permit ip 167.229.222.128 0.0.0.63 167.229.219.128 0.0.0.63 log
120 permit ip 167.229.222.128 0.0.0.63 167.229.219.192 0.0.0.63 log
130 permit ip 167.229.222.128 0.0.0.63 167.229.140.0 0.0.0.255 log
140 permit ip 167.229.222.128 0.0.0.63 10.53.53.0 0.0.0.255 log
150 permit ip 167.229.222.128 0.0.0.63 167.229.146.192 0.0.0.63 log
160 permit ip 167.229.222.128 0.0.0.63 167.229.141.0 0.0.0.127 log
170 permit ip 167.229.222.128 0.0.0.63 167.229.132.128 0.0.0.127 log
180 permit ip 167.229.222.128 0.0.0.63 167.229.138.0 0.0.0.127 log
190 permit ip 167.229.222.128 0.0.0.63 167.229.218.0 0.0.0.255 log

There is one ACL per each VLAN and it is applied in-wards at VLAN interface. It allows all traffic from that VLANs address range towards all other DR VLANs and test users range.

Cheers,

Sasa

[Edison Ortiz · Accepted solution]

Yes, the log keyword is punting the flow up to the MSFC and it's not being done in hardware.

Removing the log keyword will definitely improve performance.

Please let us know how it works out and if it does, please mark this thread as resolved.

Regards,

Edison

[sasaadamovic]

Hi,

Yes, removing log keyword from ACL statements resolved performance issue.

Thanks a lot for your help.

Regards,

Sasa