|
Rainer, guys,
I have to apologise to you for my absence but I'm currently in the
hospital because I have once again kidney stones which need to be
"nuked". Unfortunately I do not have any means to get online besides
social engineering the beautiful nurses with my charme to get access to
their stationary computer.
I'll be operated on Wednesday and will be awake on Wednesday evening.
I'm telling you all this because I promised to fix your problem so you
do not have to move to a hardware load balancer. But I'm unable to fix
your problem over the Internet so I'll give you my mobile number and you
can call either today or again starting from Wednesday evening.
++41-79-478-5645 (Don't give it to your gf's, you might not like the result)
I do speak German so don't worry about a possible language barrier,
except if you have a difficult to understand Austrian accent (like those
guys from Vienna or so) ;). And keep on posting to the list, someone
else might help you too.
I made this config with ipvsadm himself and not with keepalived, because
i would disable the vrrp. And at the moment, it seems, that the error
will occur 10 times under befor.
I'm sorry, I do not understand "... it seems, that the error will occur
10 times under befor". What do you mean?
I am running tcpdump on each nic. Every 300000 packets tcpdump make an
new file. Then i count the icmp messages ( Destination Port unreachable
) in this file. With vrrpd there where approximate 0.2 % of errors,
without vrrpd approximate 0.02%.
Hmmm, do you have any packet filter rules enabled? Or did you fiddle
around with the MTU? How many ICMP messages get to the router?
With this information I cannot deduce much. Can you correlate the ICMP
messages to in vain connection attempts to your provided service? I mean
could you show me an example of a single connection attempt which failed
to get into the ipvs table and yielded a ICMP destination unreachable?
Could you increase the verbosity of vs_debug and capture the log
statements during such an event, please? Obviously your RS' service is
down or someone is standing on the network cable :).
Stupid question, but who can i increase the debuging? The
kernelparameter /proc/sys/net/ipv4/vs/debug_level make no different.
That's strange, I just did a
echo "666" > /proc/sys/net/ipv4/vs/debug_level
and my logs got seriously filled up instantly. Is your
syslog/klog/syslog-ng/<whatever you use to log> configured correctly to
read /proc/kmsg?
23:10:37.492264 80.240.228.28 > 224.0.0.18: VRRPv2-advertise 28: vrid=17
prio=150 intvl=1 [tos 0xc0]
I thought, you disabled keepalived?
This entries are from the firewall. They also work with vrrp. But we use
diffrent id's.
What kind of firewall is this? Proprietary? It will probably help if you
would draw a simple sketch of your network architecture. I have a vague
suspection of a PMTU problem somewhere on your network.
Currently i am seeking an other NIC like 3COM, because i am not sure
about intel cards working correctly.
The Intel NICs should be working fine with 2.4.21 (that's what you used,
IIRC) as long as you use the eepro100 driver provided by Intel.
s/\(.*\)epro\([0-9]*\)/\1\2/ of course!
I tried it also with an 3COM card, but the result is the same.
That's what I thought.
Cheers,
Roberto Nibali, ratz
--
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dc
|
