daryl herzmann <[email protected]> wrote: >On Fri, 24 May 2013, Graeme Fowler wrote: > >> If you have rules in place and something making use of the conntrack >> modules (matching ESTABLISHED/RELATED for example) then you *could* - > >> I'm not saying *will :) - see performance problems. That may explain >the >> "single connection is fast but lots at the same time aren't" >scenario. >> As the conntrack modules run in kernel space that could explain the >CPU >> usage stats, too. >> >> Try turning off any conntrack-related rules and see if it helps. > >Thanks for your help. Here's my current iptables setup, I thought I >had >enabled NOTRACK for http and https traffic to prevent this. 1.1.1.1 is >my >fake public IP for this email and 192.168.0.0 is the LAN. > >Table: filter >Chain INPUT (policy ACCEPT) >num target prot opt source destination > >Chain FORWARD (policy ACCEPT) >num target prot opt source destination > >Chain OUTPUT (policy ACCEPT) >num target prot opt source destination > >Table: nat >Chain PREROUTING (policy ACCEPT) >num target prot opt source destination > >Chain POSTROUTING (policy ACCEPT) >num target prot opt source destination >1 SNAT all -- 192.168.0.0/24 0.0.0.0/0 to:1.1.1.1 >2 MASQUERADE all -- 0.0.0.0/0 0.0.0.0/0 > >Chain OUTPUT (policy ACCEPT) >num target prot opt source destination > >Table: mangle >Chain PREROUTING (policy ACCEPT) >num target prot opt source destination >1 MARK tcp -- 0.0.0.0/0 1.1.1.1 tcp dpt:21 MARK set >0x15 ># naughty machines blocked... >2 DROP all -- 1.1.1.77 0.0.0.0/0 >3 DROP all -- 1.1.1.22 0.0.0.0/0 > >Chain INPUT (policy ACCEPT) >num target prot opt source destination > >Chain FORWARD (policy ACCEPT) >num target prot opt source destination > >Chain OUTPUT (policy ACCEPT) >num target prot opt source destination > >Chain POSTROUTING (policy ACCEPT) >num target prot opt source destination > >Table: raw >Chain PREROUTING (policy ACCEPT) >num target prot opt source destination >1 NOTRACK tcp -- 0.0.0.0/0 1.1.1.1 tcp dpt:80 >2 NOTRACK tcp -- 192.168.0.0/24 0.0.0.0/0 tcp >spt:80 >3 NOTRACK tcp -- 0.0.0.0/0 1.1.1.1 tcp dpt:443 >4 NOTRACK tcp -- 192.168.0.0/24 0.0.0.0/0 tcp >spt:443 > >Chain OUTPUT (policy ACCEPT) >num target prot opt source destination >1 NOTRACK tcp -- 0.0.0.0/0 1.1.1.1 tcp dpt:80 >2 NOTRACK tcp -- 192.168.0.0/24 0.0.0.0/0 tcp >spt:80 >3 NOTRACK tcp -- 0.0.0.0/0 1.1.1.1 tcp dpt:443 >4 NOTRACK tcp -- 192.168.0.0/24 0.0.0.0/0 tcp >spt:443 > >thank you, > daryl > >_______________________________________________ >Please read the documentation before posting - it's available at: >http://www.linuxvirtualserver.org/ > >LinuxVirtualServer.org mailing list - [email protected] >Send requests to [email protected] >or go to http://lists.graemef.net/mailman/listinfo/lvs-users
Have you tried running a test with no iptables rules at all? Even NOTRACK has to parse the packet headers before handing it to IPVS, so there's obviously a performance hit there. Graeme [sent from mobile, excuse top-posting] _______________________________________________ Please read the documentation before posting - it's available at: http://www.linuxvirtualserver.org/ LinuxVirtualServer.org mailing list - [email protected] Send requests to [email protected] or go to http://lists.graemef.net/mailman/listinfo/lvs-users
