Mailing List Archive

RE: configure script
Hello

I made the changes as suggested to the config file and re-ran configure and
nat.rc on the director. Then scp'd the rc. to each real server. Prior to
running the rc I piped the output of ifconfig -a and netstat -rn to files. I
then ran the rc with sh -x and piped that to a file as well. Then I re-ran
netstat -rn and ifconfig -a again >/tmp/xxx.out

From what I could tell I already had the correct default gw on the real
servers prior to running the rc. The rc appears to be stripping the gw to
the director and not replacing it.

So on each real server I just manually added it back in and I then set
ip_forward to 1 on each real server and now appear to have a working load
balanced set of real servers. Not sure if this last bit was needed but it
appeared to not work until I did that last step. Without it I never got
anything back to the client even though ipvsadm -l on the director was
showing connections being made. After setting ip_forward to 1, my clients
finally connected to the vip and the realservers behind it in a rr scheme as
exampled in the simple test. Though I am not convinced it is working
properly even though it looks like it may. I will continue to parse through
the archives.

I apologize for the length. Could I have just attached the files? Is it in
general good etiquette to reply directly to a list member?

Here is the content of the files you requested.

ifconfig -a (was the same pre and post running the lvs script on the RIP's):
dummy Link encap:Ethernet HWaddr 00:00:00:00:00:00
BROADCAST NOARP MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0

eth0 Link encap:Ethernet HWaddr 00:01:02:C4:28:43
inet addr:192.168.1.3 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2637 errors:0 dropped:0 overruns:0 frame:0
TX packets:1313 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
Interrupt:5 Base address:0xd800

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:3924 Metric:1
RX packets:28 errors:0 dropped:0 overruns:0 frame:0
TX packets:28 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0


netstat -rn (pre sh -x rc.nat_lvs):
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt
Iface
192.168.1.3 0.0.0.0 255.255.255.255 UH 0 0 0
eth0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0
eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0
eth0


output from sh -x rc.nat_lvs:
changing default gw to 192.168.1.1
showing routing table
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt
Iface
192.168.1.3 0.0.0.0 255.255.255.255 UH 0 0 0
eth0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0
eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo

checking if DEFAULT_GW 192.168.1.1 is reachable - PING 192.168.1.1
(192.168.1.1) from 192.168.1.3 : 56(84) bytes of data.64 bytes from
192.168.1.1: icmp_seq=0 ttl=255 time=163 usec--- 192.168.1.1 ping statistics
---1 packets transmitted, 1 packets received, 0% packet lossround-trip
min/avg/max/mdev = 0.163/0.163/0.163/0.000 ms, good
LVS realserver type vs-nat


looking for DIIP 192.168.1.1
PING 192.168.1.1 (192.168.1.1) from 192.168.1.3 : 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=0 ttl=255 time=140 usec

--- 192.168.1.1 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/mdev = 0.140/0.140/0.140/0.000 ms
found, good
not local, good


looking for VIP on director from realserver
director is accepting packets on network device eth0:168
VIP not on real-server at this stage
VIP will be on director
pinging VIP
warning:10.0.1.168 not pingable.
depending on the default gw on the real-server, and the network of the VIP,
you may or may not be able to ping the VIP on the director from the
real-server.
I'll work on rules to give a pass/fail here.
Untill I do, note this result in case the LVS doesn't work.
If you didn't run the script on the director first, then go do this now.

checking default routing for vs-nat realserver
packets to director's default gw should go through director.
(this test will return quickly if the routing is wrong for VS-NAT,)
(will return in about 2 secs if setup correctly,)
(and will hang if the routing is deranged.)
Is director's default gw 2 hops away and is director one hop away on the
path to the director's gw?
error: the path to the director's default gw does not go through the
director.
hops to director's gw 0
hops to director
this vs-nat LVS will not work.
you can fix this by changing the IP's, networks and routing of the LVS.
1. the network for the realservers must be private.
2. the default gw for the realservers must be the director.
3. a route to the director is not good enough, it won't work, the director
must be the default gw.
4. the realservers must not have any other routes to the client.
(Some routing problems are fixed by rerunning the script.)

To help debug the problem, here's the output of netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt
Iface
192.168.1.3 0.0.0.0 255.255.255.255 UH 0 0 0
eth0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0
eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo


netstat -rn (after running sh-x rc.lvs_nat):
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt
Iface
192.168.1.3 0.0.0.0 255.255.255.255 UH 0 0 0
eth0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0
eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo


Regards
jeff

>>>
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
--
Re: configure script [ In reply to ]
Jeffrey Watterson wrote:


> >From what I could tell I already had the correct default gw on the real
> servers prior to running the rc. The rc appears to be stripping the gw to
> the director and not replacing it.

that's helpful.

>
> So on each real server I just manually added it back in and I then set
> ip_forward to 1 on each real server and now appear to have a working load
> balanced set of real servers.

hmm, mine work OK with

#cat /proc/sys/net/ipv4/ip_forward
0

for both 2.2.x and 2.4.x real-servers

got any suggestions.

> Could I have just attached the files?

It doesn't matter.
the postings occupy the same amount of disk space on the
archive, whether the files are in the body or attached.


Is it in
> general good etiquette to reply directly to a list member?

this is OK. If anything of interest comes out of it, it is
posted to the list.

> output from sh -x rc.nat_lvs:

you should be getting heaps of debugging info with sh -x rc.lvs_nat.
What you've posted looks like the output from $./rc.lvs_nat

> changing default gw to 192.168.1.1
> showing routing table
> Kernel IP routing table
> Destination Gateway Genmask Flags MSS Window irtt
> Iface
> 192.168.1.3 0.0.0.0 255.255.255.255 UH 0 0 0
> eth0
> 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0
> eth0
> 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo

you're right. It didn't add the default gw.

In line 1151 of configure, there is a command

route add.

This should be

$ROUTE add

Since route is /sbin/route, it will not be in the PATH (if PATH
is /bin;/usr/bin) and nothing will be executed.

can you change your configure and let me know what happens?

Joe

--
Joseph Mack PhD, Senior Systems Engineer, Lockheed Martin
contractor to the National Environmental Supercomputer Center,
mailto:mack.joseph@epa.gov ph# 919-541-0007, RTP, NC, USA