|
Jeremy Kerr wrote:
-> 192.162.10.18:5222 Masq 1 0 0
-> 192.168.10.17:5222 Masq 1 0 0
You do realise that the .18 entry is 192.162, rather than 192.168 ??
Hehe :). This is the only thing that I didn't check carefully enough. I
should have gone to bed earlier because this morning this was the first
thing I checked because during the massive email exchange with Justin
off-list we finally got to the conclusion that it must be the director.
<OT>
If you think about it afterwards, it's so clear and you'll slap your
forehead. Because the most important thing Justin said right from the
beginning was that absolutely _no_ packets are leaving the director if
it should be forwarded to ~.18. This can only mean three things:
1. routing problem (sick LVS)
2. configuration mismatch (confused LVS)
3. bug in LVS (bug in LVS)
In cases (1.) and (2.) LVS has a completely broken configuration (as
Justin's case showed) and thus renders the poor LVS pretty sick, because
it doesn't know anymore where to send the packets to, except the default
route, which is back to the Internet :)
For case (3.) there are a couple of rules:
1. First rule of LVS, we do not talk about LVS bugs in its code.
2. Second rule of LVS, there are no BUGs in the LVS code :)
3. Third rule of LVS, see first rule of LVS.
But this is the beauty of open source. So many bright people to help
each other. Thank you Jeremy. I wonder if we should write some code to
catch such configuration issues.
</OT>
Cheers,
Roberto Nibali, ratz
--
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dc
|
