|
I installed conntrack tool and conntrack -L does not list the ssh
connection between the client and the real server through the load
balancer, I guess the xt_ipvs unable to find a connection track entry
in conntrack table, so no jump to SNAT for source address translation?
On Thu, Jun 27, 2013 at 3:54 PM, Vincent Li <vincent.mc.li@xxxxxxxxx> wrote:
> 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
|
