|
Jeffrey Watterson wrote:
>
>
> The setup is backwards from the example as my corporate LAN is at 10.0.1.
> This is where clients for the test would be located.
> I can isolate completely and follow example if needed but do not see reason
> why (yet)
> So I have this setup:
> Machine IP
> client CIP=10.0.1.120 (should this just be the
> default route for the clients network?)
you don't need one, you just need a route to 10.0.1.0, which you presumably
already have (on eth0)
> director VIP VIP=10.0.1.168 (eth0:1)
> Director internal interface DIP=192.168.1.1 (eth0)
> realserver1 RIP1=192.168.1.2 (eth0)
> realserver2 RIP2=192.168.1.3 (eth0)
>
> The lvs.nat.conf looks like this:
> LVS_TYPE=VS_NAT
> INITIAL_STATE=on
> VIP=eth0:1 10.0.1.168 255.255.255.0 10.0.1.255
should be
VIP=eth0:1 10.0.1.168 255.255.255.255 10.0.1.168
> DIRECTOR_INSIDEIP=eth0 192.168.1.1 192.168.1.0 255.255.255.0 192.168.1.255
> DIRECTOR_DEFAULT_GW=10.0.1.120 (this doesn't seem right?)
this is fine
you don't really need a default gw for the director as it will
aleady have a route to 10.0.1.0, but the script expects one.
> SERVICE=t telnet rr 192.168.1.2:telnet 192.168.1.3:telnet
> SERVER_NET_DEVICE=eth0
> SERVER_DEFAULT_GW=192.168.1.1
>
> When I run the script on the director I seems to be OK when I run on the
> real-servers it hangs and complains about my route.
for the real-server which fails, can you send the output of ifconfig -a, netstat
-rn
and the output from sh -x ./rc.lvs_nat in the region where the script fails.
Joe
--
Joseph Mack PhD, Senior Systems Engineer, Lockheed Martin
contractor to the National Environmental Supercomputer Center,
mailto:mack.joseph@xxxxxxx ph# 919-541-0007, RTP, NC, USA
|
