Hello, On Thu, 27 Jun 2013, Vincent Li wrote: > Hi, > > I am running most recent net-next git tree version and compiled the > xt_ipvs match extension for ipvs, here is the info: > > # uname -a > Linux vincent-hp 3.10.0-rc6-ipvs-with-nat #3 SMP Wed Jun 26 21:19:32 > PDT 2013 i686 GNU/Linux > > Module Size Used by > xt_TRACE 726 0 > xt_tcpudp 1895 0 > iptable_raw 1162 0 > xt_LOG 11066 0 > arptable_filter 1122 0 > arp_tables 9012 1 arptable_filter > iptable_filter 1302 0 > xt_nat 1746 2 > iptable_nat 2646 1 > nf_conntrack_ipv4 12368 1 > nf_defrag_ipv4 1181 1 nf_conntrack_ipv4 > nf_nat_ipv4 3487 1 iptable_nat > ip_tables 10235 3 iptable_raw,iptable_filter,iptable_nat > nf_nat 14458 3 xt_nat,iptable_nat,nf_nat_ipv4 > xt_ipvs 1620 2 > x_tables 15304 10 > xt_TRACE,xt_tcpudp,iptable_raw,xt_LOG,arptable_filter,arp_tables,iptable_filter,xt_nat,ip_tables,xt_ipvs > binfmt_misc 5844 1 > ppdev 5120 0 > ip_vs_rr 1643 2 > ip_vs 148089 6 xt_ipvs,ip_vs_rr > nf_conntrack 77550 5 > iptable_nat,nf_conntrack_ipv4,nf_nat_ipv4,nf_nat,ip_vs > libcrc32c 855 1 ip_vs > > root@vincent-hp:/usr/src/net-next# iptables -t nat -n -L > Chain PREROUTING (policy ACCEPT) > target prot opt source destination > > Chain INPUT (policy ACCEPT) > target prot opt source destination > > Chain OUTPUT (policy ACCEPT) > target prot opt source destination > > Chain POSTROUTING (policy ACCEPT) > target prot opt source destination > SNAT all -- 0.0.0.0/0 0.0.0.0/0 vaddr > 10.1.72.169 vport 80 to:10.2.72.139 > SNAT all -- 0.0.0.0/0 0.0.0.0/0 vaddr > 10.1.72.169 vport 22 to:10.2.72.139 > > # ipvsadm -L -n > > IP Virtual Server version 1.2.1 (size=4096) > Prot LocalAddress:Port Scheduler Flags > -> RemoteAddress:Port Forward Weight ActiveConn InActConn > TCP 10.1.72.169:22 rr > -> 10.2.72.99:22 Masq 1 0 0 > TCP 10.1.72.169:80 rr > -> 10.2.72.9:80 Masq 1 0 0 > -> 10.2.72.99:80 Masq 1 0 0 > > no any filter, mangle, raw iptable rules. > > the ipvs load balance works fine, but running tcpdump on LVS director > and real server shows the client source address is not translated to > specified address 10.2.72.139. > > I used TRACE target in raw filter to trace the packet, I saw the > packet went through 'nat' table PREROUTING chain, not POSTROUTING > chain. > > I am using LVS NAT mode. I have seen this issue before with previous > kernel 3.6.x release, but not bothered to file report, it hasn't > worked for me so I am wondering if I am missing something or there is > bug in xt_ipvs match extension, any debugging tips or idea would be > appreciated. Make sure you have CONFIG_IP_VS_NFCT enabled and sysctl var "conntrack" set to 1. IIRC, it is needed for xt_ipvs in 2.6.37+. Let me know if you still have problems, so that we can track the problem. > I can post the tcpdump capture or debugging message with TRACE in raw > table if needed > > Thanks Regards -- Julian Anastasov <ja@xxxxxx> -- To unsubscribe from this list: send the line "unsubscribe lvs-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
