|
Hello,
Could you do me a small favour? Do not top post, please. I do get a lot
of emails and it is just a lot more convenient the other way, because
then I see immediately what issue we've solved and what is remaining.
Justin Georgeson wrote:
If I understand all the VIP/RIP/CIP, than yes, that is the VIP. Those
And the DGW of the RS point to the director, right?
two telnet commands should both work, if you sit and try it over and
over, it will succeed every other time. I'm not blocking it with IP
Ok, I just tried it and it indeed is just like you described it.
tables. tcpdump on ~.18 shows no packets when coming in this way. The
Could you tcpdump on the outgoing (towards the private net) interface to
see if the packets are crafted correctly for both RSs? Please send it to
the list (should not be too long if we dump only for 2 connection requests).
director has a dozen or so aliased interfaces (eth0:1-n). I bind those
aliased interfaces to other public IPs and use LVS to NAT to particular
That seems resonable. One thing I wonder is how the routing table looks
like on the director and the RS. If you could provide us with those and
maybe the link configuration?
ip rule show
ip route show table main
ip addr show dev eth0
machines on the private lan. So I can actually telnet directly to port
5222 on the IPs I have aliased for the two boxes in question. In this
You mean you have other public IPs (not the VIP) which will get port
forwarded with a 1:1 NAT to the assigned RS?
particular case, I need to have one FQDN/IP to load balance between a
couple of them.
It is not a DNS problem. And the FQDN is only for the VIP. You do not
want to people to connect to the RS directly anyway, so keep them on a
IP basis.
After one connection
TCP 66.150.129.229:5222 wrr
-> 192.162.10.18:5222 Masq 1 0 0
-> 192.168.10.17:5222 Masq 1 0 1
After 2nd attempt (says Trying 66.150.129.229... then nothing, so I
<Ctrl>+<c>)
TCP 66.150.129.229:5222 wrr
-> 192.162.10.18:5222 Masq 1 0 1
-> 192.168.10.17:5222 Masq 1 0 1
Verified with telnet from here. This indicates to me that the second RS
is not set up the same way as the first one (routing issue, firewall
rules on the RS, VIP not correctly set or missing). Normally the above
indicates that the daemon somehow died in a select loop but didn't close
the listener. Since you mentioned that you can successfully connect to
both RS on port 5222 and do get a telnet prompt, we have to assume that
both daemons are working correctly.
All of my ipvsadm rules are LVS-NAT, but they probably don't need to be.
What rules? Do you mean setup?
I'm fully prepared to accept that I'm using lvs all wrong, but so far
it's been working for me. :) If there is a better configuration for me
What do you mean with '... so far it's been working for me ...'? Did it
work up to a certain point with this setup and layout and it stopped
working afterwards?
to use, I'll certainly open to trying it.
Since for me everything indicates that your second RS is not configured
like the first one, we do not need to change the LVS configuration.
Regards,
Roberto Nibali, ratz
--
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dc
|
