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 - [email protected] > Send requests to [email protected] > 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 - [email protected] Send requests to [email protected] or go to http://lists.graemef.net/mailman/listinfo/lvs-users
