Willy, Following are the information I could gather:
As per this link <http://www.snapt-ui.com/haproxy/snapt-haproxy-and-tproxy/> we need to add following sysctl parameters. #Reverse Path Filtering: Basically, if the reply to a packet wouldn't go out the interface this packet came in, then this is a bogus packet and should be ignored. net.ipv4.conf.default.rp_filter = 2 net.ipv4.conf.all.rp_filter = 2 #Disable Reverse Path Filtering net.ipv4.conf.eth0.rp_filter = 0 I am currently using a single physical ethernet interface for both the networks (realservers network and VIPs network) Are there any chances that this could create any issues? Regarding kernel bugs: - 2.6.28 to 2.6.32 have different rp_filter configuration. The rp_filter settings (0 or 1) for these kernels will silently block TPROXY if used on newer kernels. - 2.6.28 to 2.6.36 are known to have ICMP and TIME_WAIT issues. - 2.6.32 to 2.6.34 have bridging issues on some systems I am now using kernel version: 2.6.38-15-server Thanks Rahul N. On Fri, Aug 10, 2012 at 1:30 PM, Rahul Nair <rahul.n...@finicity.com> wrote: > Just FYI... > Following are the config parameters that I use: > > global > log 127.0.0.1 local0 info > ulimit-n 80038 > chroot /var/lib/haproxy > daemon > > defaults > log global > mode http > option dontlognull > retries 3 > option redispatch > maxconn 2000 > timeout connect 5000 > timeout client 300000 > timeout server 300000 > > > listen httpsite 10.1.16.15:80 > mode http > balance leastconn > cookie PHPSESSID prefix > option httpclose > server web01 10.1.1.20 cookie web01 check > server web02 10.1.1.30 cookie web02 check > > listen httpssite 10.1.16.15:443 > mode tcp > source 0.0.0.0 usesrc clientip > balance source > option ssl-hello-chk > server web01 10.1.1.20 check > server web02 10.1.1.30 check > > Thanks > Rahul N. > > On Fri, Aug 10, 2012 at 11:20 AM, Rahul Nair <rahul.n...@finicity.com>wrote: > >> Willy, >> >> The issue still persists. >> Not sure what am I missing. >> >> -Rahul N. >> >> >> On Friday, August 10, 2012, Rahul Nair <rahul.n...@finicity.com> wrote: >> > Willy, >> > I have upgraded the Linux kernel to and haproxy to 1.4.18 and kernel >> to 2.6.38-15-server >> > Will monitor it for few days and will let you know the updates. >> > -Rahul N. >> > >> > On Fri, Aug 10, 2012 at 2:04 AM, Willy Tarreau <w...@1wt.eu> wrote: >> >> >> >> On Thu, Aug 09, 2012 at 11:54:08PM +0530, Rahul Nair wrote: >> >> > Willy, >> >> > >> >> > >From your description, it could be an issue with some connection >> >> > tracking somewhere caused by excess of source addr:ports. >> >> > >> >> > Ohh ok.. >> >> > Also I just found that as per the documentation in this link , it >> says that >> >> > "it can cause problems when IP connection tracking is enabled on the >> >> > machine, because a same connection may be seen twice with different >> states". >> >> > Does this mean that I need to disable the nf_conntrack module by >> adding >> >> > "net.netfilter.nf_conntrack_acct = 0" to "/etc/sysctl.conf" ? >> >> >> >> You can't disable nf_conntrack using a sysctl. You need to unload the >> >> module itself. It's not nf_conntrack_acct but nf_conntrack. >> >> >> >> > Bu default this module seems to be enabled. >> >> > cat /proc/sys/net/netfilter/nf_conntrack_acct >> >> > 1 >> >> > >> >> > Following are the answers to your questions: >> >> > >> >> > What's your haproxy version and kernel version ? >> >> > >> >> > - HA-Proxy version: 1.4.8 2010/06/16 >> >> >> >> Be careful, this is quite outdated ! 2 years of fixes have been merged >> >> since : >> >> $ git log --pretty=oneline v1.4.8..|grep -c BUG >> >> 72 >> >> >> >> => Your version has 72 bugs that have already been fixed now. >> >> I don't remember of any affecting transparent proxying though, but >> >> when you fix the issue you'd be advised to update it. >> >> >> >> > - Kernel Version: 2.6.32-24-server >> >> > - OS: Ubuntu 10.04 >> >> >> >> You should also check that your kernel is up to date, as what you're >> >> observing might as well simply be a kernel bug. >> >> >> >> > Are you sure all your servers route back through your haproxy box ? >> >> > >> >> > - Yes the default gateway of all the real servers is HAProxy >> server. >> >> > - On real servers I have multiple IPs of two different networks >> >> > - One which we use for communication between HAproxy server >> and Real >> >> > servers. >> >> > - And One which is used by the real servers to communicate >> with our >> >> > internal application servers >> >> >> >> OK. >> >> >> >> > Did you test only from one source machine or did you have many >> clients ? >> >> > >> >> > - This issue occurs intermittently from one or two different >> source IPs >> >> > - At the same time when I check the functionality from another >> source >> >> > IP, it works fine. >> >> >> >> Fine, then it really makes me think about a conntrack issue. Also, you >> >> should ensure that your client never directly talks to the server >> without >> >> passing via haproxy (which I can imagine you do during your tests when >> >> observing the issue). It only makes the problem worse with conntrack. >> >> >> >> Regards, >> >> Willy >> >> >> > >> > >> > >> > -- >> > -Rahul N. >> > IT Department >> > In2M Technologies Pvt Ltd. (Finicity) >> > Website: www.finicity.com/india >> > >> >> -- >> -Rahul N. >> IT Department >> In2M Technologies Pvt Ltd. (Finicity) >> Website: www.finicity.com/india >> >> > > > -- > -Rahul N. > IT Department > In2M Technologies Pvt Ltd. (Finicity) > Website: www.finicity.com/india > > -- -Rahul N. IT Department In2M Technologies Pvt Ltd. (Finicity) Website: www.finicity.com/india
