ah, yes, I didn't set the sysctl conntrack to 1, it works now, thanks a lot, sorry for the noise On Thu, Jun 27, 2013 at 11:07 PM, Julian Anastasov <ja@xxxxxx> wrote: > > 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
