|
daryl herzmann <akrherz@xxxxxxxxxxx> 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 - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
>Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
>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 - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
or go to http://lists.graemef.net/mailman/listinfo/lvs-users
|
