|
On Jul 19, 2007, at 5:02 PM, Joseph Mack NA3T wrote:
> On Thu, 19 Jul 2007, Jessie wrote:
>
>> Update-
>>
>> I discovered the problem lies in routing. Our director is newly
>> multi-
>> homed and it seems that whichever interface our default gw lies, will
>> allow the LVS-DR to actually work. So for all other interfaces on the
>> director, the VIP instances will no longer work outside of the
>> subnet.
>
> you've done something funny with the routing.
>
> I assume there's clients on your LAN and clients coming from
> the internet. They all should have a route to the VIP (which
> I assume is on the outside/internet side of the director)
> even if the clients on the LAN have to make a short hop to
> the internet first.
>
Actually, our clients are on the outside/internet.
I noted that it works within the subnet just to state that LVS-DR is
load balancing *some* traffic
> The director doesn't need (and for security shouldn't have)
> a default gw for tcp/udp packets from the VIP - all return
> packets come from the VIP on the realservers.
>
Director:
eth0 = a public ip... let's say 64.65.66.67/24
eth1 = a private ip .. let's say 172.16.10.61/24
I have two, completely separate VIPS
VIP1: 64.65.66.70/32
VIP2: 172.16.10.20/32
the default gateway on the director goes out eth0 to 64.65.66.1/24
in this configuration, VIP2 does not work, VIP1 does.
if I change my default gw to a router/PIX on the eth1 network such as
172.16.10.254/32 then VIP2 will only work and now VIP1 will not.
I am using keepalived / vrrp and am wondering if I need special
virtual_routes ?
psuedo-code..
vrrp_instance VI_9
{
virtual_address
{
172.16.10.20/24
}
}
...
vrrp_instance VI_8
{
virtual_address
{
64.65.66.70/24
}
}
-Jessie
|
