Group, I investigated further on this. The default value of net.ipv4.conf.eth0.rp_filter is 1 Which means that Reverse Path filter is in Strict mode i.e 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. Since I have only one ethernet interface and the same interface has the information of reverse path to external WAN network and Both the internal networks (Real server networks and VIP network) I believe that there are very less chance that this could be the issue. Please guide me on which direction I need to investigate further it will be a great help.
Thanks, -Rahul N. On Sat, Aug 11, 2012 at 9:10 PM, Rahul Nair <rahul.n...@finicity.com> wrote: > Group, > > Any advise on this? > > -Rahul N. > > > On Saturday, August 11, 2012, Rahul Nair <rahul.n...@finicity.com> wrote: > > By default net.ipv4.conf.eth0.rp_filter is 1 which means IP spoofing > protection is enabled (source route verification is turned on) > > As far as I understand, TPROXY spoofs outgoing connections using the > client's IP address. > > But since all the IPs are configured on same physical adapter, not sure > if setting net.ipv4.conf.eth0.rp_filter to 0 will make any difference. > > Also the issue is intermittent and not Boolean in nature. > > -Rahul N. > > On Sat, Aug 11, 2012 at 12:01 AM, Rahul Nair <rahul.n...@finicity.com> > wrote: > > > > Willy, > > Following are the information I could gather: > > As per this link 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" t > >
