[lvs-users] tftp service and firewall mark
Graeme Fowler
graeme at graemef.net
Mon Sep 28 12:38:28 BST 2009
On Mon, 2009-09-28 at 12:10 +0200, Nicolas Haller wrote:
<snip>
Firstly it would be really, really helpful in your posts if you use the
"-n" option to both ipvsadm and iptables. That saves us all having to a
host lookup to decipher the output your provide :)
> So, when I test, lvs said:
>
> Sep 28 11:55:05 balancoire-1v kernel: [1121193.129497] IPVS: lookup/in UDP 213.251.170.39:52249->194.79.128.129:69 not hit
> Sep 28 11:55:05 balancoire-1v kernel: [1121193.129514] IPVS: lookup/out UDP 213.251.170.39:52249->194.79.128.129:69 not hit
> Sep 28 11:55:05 balancoire-1v kernel: [1121193.129529] IPVS: lookup service: fwm 1 UDP 194.79.128.129:69 hit
> Sep 28 11:55:05 balancoire-1v kernel: [1121193.129545] IPVS: p-schedule: src 213.251.170.39:52249 dest 194.79.128.129:69 mnet 213.251.170.39
> Sep 28 11:55:05 balancoire-1v kernel: [1121193.129561] IPVS: template lookup/in IP 213.251.170.39:0->0.0.0.1:0 not hit
So it sees the fwmark, checks to see if there's an existing persistence
template (there isn't) and then... there should be more to this log.
> So, lvs see the mark and the packet but it don't send the packet into ip-ip
> tunnel and the director send an ICMP udp port unreachable back to the client.
If the log for that connection really did stop there, something is
*very* wrong indeed. I would expect at the very least to see the next
line/lines determining which realserver (hence which tunnel) the
connection is sent to.
It might also help you if your weights are set to something other than 1
(say 100). Also I note that only one of your realservers appears to be
functioning (which should greatly simplify the debugging!).
Graeme
More information about the lvs-users
mailing list