|
Hello,
Unfortunately "quit working after some time" is about the best way to
describe it. All software are original RedHat AS 3.0 rpms:
kernel-2.4.21-15.0.2.EL
iptables-1.2.8-12.3
ipvsadm-1.21-9.ipvs108
piranha-0.7.6-1
Fair enough, I believe you; however it does sound kind of unbelieveable
considering that you're running a Unix-like system which regarding it's
history has a long and violent path of spitting out all kinds of error
and warning messages into logfiles.
I have static NAT configured for a particular server using this iptables
command:
iptables -v -t nat -I POSTROUTING -s 172.28.1.25 -j SNAT --to-source
66.165.220.47
LVS-NAT is configured using the /etc/sysconfig/ha/lvs.conf file which
appears to be part of the RedHat piranha package.
I see.
When I say "quit working after some time" i mean exactly that. After the
firstor boots everything works just fine. After several hours the director
ceases to forward packets to the 172.28.1.25 RIP. Things break in both
Hmmm, could you enable debug in the proc-fs after such an incident and
send a couple of lines along (max. 30kb), please. Also send a copy of
/proc/net/ip_conntrack and /proc/slabinfo. A tcpdump on both physical
interfaces would be interesting as well plus the link state and
statistical information such as 'ip -s -s link show' and 'ip -s -s route
show cache'. Thank you.
directions, LVS processed packets as well as packets processed using the
iptables rule. There is nothing in dmesg indicating there is anything
wrong.
I reckon there's also no kernel oops in kernlog or whereever RH sends
those dumps?
I cannot find any aparent cause, no trigger for this happening.
Also, I cannot get the director to resume forwarding packets to/from the
172.28.1.25 RIP by restarting services, reloading iptables, LVS rules,
etc. The only things that makes a difference is a reboot.
That rings a bell however ... what network cards are you using?
The director is in a production environment. So far the timing of these
outages hasn't been a"convenient" to do any troubleshooting.
I completely understand. Please provide also your hardware configuration.
In the documentation I read the floating ip address is the ip address that
switches between the two directors in a failover configuration. On the
0k, thank you, didn't know that. What documentation would you be
referring to?
internal network side of LVS-NAT this would be the default gateway all
real servers point to.
Yes.
Correct, but I would like to continue using LVS-NAT, with the directors
continuing to be default gateways. Reason for this is the ARP problem and
the fact that there are a variety of OSs on the real servers.
I understand, so let's address your initial problem then if you want to.
But you have to provide me (us) with more details, especially when
this incident happens.
Thank you for your patience,
Roberto Nibali, ratz
--
echo
'[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc
|
