|
here is the interface info and packet flow if it helps
client (10.1.72.6) <-->VIP 10.1.72.169 <-->RIP 10.2.72.99 (gateway 10.2.72.139)
auto eth1.1101
iface eth1.1101 inet static
address 10.1.72.9
netmask 255.255.0.0
network 10.1.0.0
broadcast 10.1.255.255
vlan-raw-device eth1
mtu 1500
auto eth1.1101:0
iface eth1.1101:0 inet static
address 10.1.72.169
netmask 255.255.0.0
network 10.1.0.0
broadcast 10.1.255.255
auto eth1.1102
iface eth1.1102 inet static
address 10.2.72.139
netmask 255.255.0.0
network 10.2.0.0
broadcast 10.2.255.255
vlan-raw-device eth1
On Thu, Jun 27, 2013 at 3:46 PM, Vincent Li <vincent.mc.li@xxxxxxxxx> 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.
>
> I can post the tcpdump capture or debugging message with TRACE in raw
> table if needed
>
> Thanks
--
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
|
