paul.pech at gmx
Dec 2, 2009, 6:58 AM
Post #2 of 2
(759 views)
Permalink
|
|
Re: [lvs-users] Realservers not replying to sync packets
[In reply to]
|
|
Hi,
I think I found the solution to the problem below.
When using openSuSE 10.3 or 11.0 with kernel 2.6.22 the RealServers
respond to the SYN packet (by the client) if
net.ipv4.conf.all.rp_filter = 1
in /etc/sysctl.conf.
If the same option is used on openSuSE 11.2 with kernel 2.6.31 the RS
doesn't respond to the SYN anymore.
If you use
net.ipv4.conf.all.rp_filter = 2
all is well again - the RS responds to SYN and the connection works.
>From ip-sysctl.txt:
> rp_filter - INTEGER
> 0 - No source validation.
> 1 - Strict mode as defined in RFC3704 Strict Reverse Path
> Each incoming packet is tested against the FIB and if the interface
> is not the best reverse path the packet check will fail.
> By default failed packets are discarded.
> 2 - Loose mode as defined in RFC3704 Loose Reverse Path
> Each incoming packet's source address is also tested against the FIB
> and if the source address is not reachable via any interface
> the packet check will fail.
>
> Current recommended practice in RFC3704 is to enable strict mode
> to prevent IP spoofing from DDos attacks. If using asymmetric routing
> or other complicated routing, then loose mode is recommended.
>
> conf/all/rp_filter must also be set to non-zero to do source validation
> on the interface
>
> Default value is 0. Note that some distributions enable it
> in startup scripts.
Setting rp_filter to 0 or 2 does the trick.
Yours,
Paul
Am Dienstag, den 01.12.2009, 23:33 +0100 schrieb Paul Pech:
> Hi,
>
> I've been successfully using LVS-DR for the past two years on SuSE
> Linux.
>
> After upgrading one of the RealServers to openSuSE 11.2 (Kernel 2.6.31)
> I can't get LVS-DR working anymore (for the updated RealServer).
>
> Here's my configuration for the LVS load-balancer (on openSuSE 11.1
> Kernel 2.6.27; just the updated RealServer shown here (debugging)):
>
> ---
> #ipvsadm -L
> IP Virtual Server version 1.2.1 (size=4096)
> Prot LocalAddress:Port Scheduler Flags
> -> RemoteAddress:Port Forward Weight ActiveConn InActConn
> TCP 10.0.0.182:https lc persistent 360
> -> 192.168.201.10:https Route 1 0 0
> ---
>
> On the RealServer (IP 192.168.201.10) the VIP is bound to lo:0
>
> ---
> #ifconfig (on RealServer; openSuSE 11.2 Kernel 2.6.31)
> eth0 Link encap:Ethernet HWaddr 00:E0:81:28:4D:EF
> inet addr:192.168.201.10 Bcast:192.168.201.255 Mask:255.255.255.0
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:1028 errors:0 dropped:0 overruns:0 frame:0
> TX packets:582 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:100
> RX bytes:94528 (92.3 Kb) TX bytes:84802 (82.8 Kb)
>
> eth1 Link encap:Ethernet HWaddr 00:E0:81:28:4D:F0
> inet addr:10.0.0.180 Bcast:10.255.255.255 Mask:255.0.0.0
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:34 errors:0 dropped:0 overruns:0 frame:0
> TX packets:26 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:100
> RX bytes:3150 (3.0 Kb) TX bytes:1988 (1.9 Kb)
>
> lo Link encap:Local Loopback
> inet addr:127.0.0.1 Mask:255.0.0.0
> UP LOOPBACK RUNNING MTU:16436 Metric:1
> RX packets:61 errors:0 dropped:0 overruns:0 frame:0
> TX packets:61 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:0
> RX bytes:10223 (9.9 Kb) TX bytes:10223 (9.9 Kb)
>
> lo:0 Link encap:Local Loopback
> inet addr:10.0.0.182 Mask:255.255.255.255
> UP LOOPBACK RUNNING MTU:16436 Metric:1
> ---
>
> Apache is configured and working (both with http and https; can be
> connected to from LVS load-balancer and by "lynx https://10.0.0.182" on
> the RealServer).
>
> Now, client mframe (10.0.0.20) tries to connect to 10.0.0.182 (via LVS
> load-balancer). This does not work, as the RealServer does not reply to
> the SYN packet (not even accepts it?).
>
> 1. mframe connects to https://10.0.0.182
> 2. "tcpdump -i any" on RealServer shows just one line and nothing more
> (except for re-transmissions of the SYN packet by mframe):
>
> ---
> 23:05:27.750176 IP mframe.test-lab.local.39129 > 10.0.0.182.https: Flags [S], seq 3161375135, win 5840, options [mss 1460,sackOK,TS val 42229465 ecr 0,nop,wscale 7], length 0
> ---
>
> 3. ipvsadm -Lc on LVS load-balancer shows:
>
> ---
> IPVS connection entries
> pro expire state source virtual destination
> TCP 00:48 SYN_RECV mframe:39129 10.0.0.182:https 192.168.201.10:https
> TCP 04:15 NONE mframe:0 10.0.0.182:https 192.168.201.10:https
> ---
>
> There are no iptable rules in place on either the LVS load-balancer or
> the RealServer. Behavior of the RealServer does not change when not
> using persistency or when using http - still no reply so SYN packets.
>
> This seems to be exactly the same problem as in this post (from 2004):
>
> http://archive.linuxvirtualserver.org/html/lvs-users/2004-09/msg00066.html
>
> Unfortunately there's no final answer there to what the problem is/was
> and how to fix it...
>
> I'm really at a loss here, so any help on how to get this working again
> is greatly appreciated.
>
> Yours,
>
> Paul
>
>
>
> _______________________________________________
> Please read the documentation before posting - it's available at:
> http://www.linuxvirtualserver.org/
>
> LinuxVirtualServer.org mailing list - lvs-users [at] LinuxVirtualServer
> Send requests to lvs-users-request [at] LinuxVirtualServer
> or go to http://lists.graemef.net/mailman/listinfo/lvs-users
_______________________________________________
Please read the documentation before posting - it's available at:
http://www.linuxvirtualserver.org/
LinuxVirtualServer.org mailing list - lvs-users [at] LinuxVirtualServer
Send requests to lvs-users-request [at] LinuxVirtualServer
or go to http://lists.graemef.net/mailman/listinfo/lvs-users
|
