On Wed, Nov 09, 2011 at 12:18:22PM -0400, mike wrote: > Thanks Nick: > > Here's the config that is the issue right now: > #SERVER1.vip.intranet.mydomain.com > virtual=172.28.191.194:8080 > protocol=tcp > scheduler=lc > checktype=connect > checkport=8080 > #negotiatetimeout=10 > real=172.28.191.170:8080 masq > real=172.28.191.171:8080 masq > #service=ldap > protocol=tcp > checktimeout=10 > checkinterval=10 > > #SERVER2.vip.intranet.mydomain.com > virtual=172.28.191.155:8080 > protocol=tcp > scheduler=lc > checktype=connect > checkport=8080 > #negotiatetimeout=10 > real=172.28.191.139:8080 masq > real=172.28.191.140:8080 masq > protocol=tcp > checktimeout=10 > checkinterval=10 > > So traffic comes in to 155 on Blade A or B depending on which LVS server > s primary, gets "sprayed" to 139/140 on Blades A,B > From 139/140 on Blade A or B it goes to 194 on Blade A and gets > "sprayed" to 170/171 on Blades A,B > (FWIW, I didn't design this mess, in fact I argued vehemently against it > and lost so it is what it is.) > > Summary: > Request ---- > 155 LVS (Blade A or B) > ----> 139/140 (Blade A or B) > ---- > 194 LVS (Blade A or B) > ----- > 170 Blade A /171 Blade B > > The problem arises when traffic is routed from 194 on Blade A to 170 on > Blade A. It hangs. If it goes to 171 on Blade B, it works.
Hi Mike, I believe that you will need to use SNAT on at least the 172.28.191.194 virtual service as it is connected to by realservers. This is to ensure that return packets from 172.28.191.170,171 go via 172.28.191.194 rather than directly back to 172.28.191.139,140. SNAT support was added to LVS in the 2.6.36 kernel. Loadbalancer.Org have an overview of how it may be used: http://blog.loadbalancer.org/enabling-snat-in-lvs-xt_ipvs-and-iptables/ _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
