[lvs-users] Realservers not replying to sync packets

Paul Pech paul.pech at gmx.de
Wed Dec 2 14:58:38 GMT 2009


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.org
> Send requests to lvs-users-request at LinuxVirtualServer.org
> or go to http://lists.graemef.net/mailman/listinfo/lvs-users





More information about the lvs-users mailing list