martin.rosenmueller at gmx
Jul 19, 2007, 12:21 AM
Post #1 of 1
(616 views)
Permalink
|
|
Possible bug in conntrack
|
|
Hi all,
we are planning to build a loadsharing cluster of nodes based on
iptables CLUSTERIP target.
In our tests some real strange things happended.
For simplicity i will explain the problem with only one active node in
the cluster.
My configuration on the cluster node was:
- eth0 had 172.16.29.121 (real ip of the node)
- eth0:1 had 172.16.29.200 (virtual cluster ip)
- the clustered service was tcp port 80 (http) (other ports didn't work
also)
- please find my firewall-configuration script attached
- the firewall works as follows:
- first the stateful rule match ctstate in state ESTABLISHED, RELATED
- then the stateful rule match ctstate in state INVALID
- afterwards the CLUSTERIP target rule
- followed by the rule to accept new connections on the virtual
cluster ip on port 80
- finally the clean up rule to drop all traffic that didn't match up
to now
Surely i didn't forget to enter "echo +2
> /proc/net/ipt_CLUSTERIP/172.16.29.200" to accept all cluster traffic
on the only active node, the webserver was running and bind to the real
and the virtual cluster ip.
If you than connect to the cluster on the virtual ip 172.16.29.200 from
a client node on the same net (client has ip 172.16.29.211), you will
almost get no answer (client.pcap). The cluster node seems not to accept
any traffic than the first syn packet, although it answers with syn,ack.
Please see the network dump attached (clusternode.pcap). We have checked
the multicast mac, which seems to be ok. Logging in messages (messages)
is OK, too. All packets arriving the cluster node after the syn packet
are accepted by conntrack in state ESTABLISHED, which also seems to be
OK. In /proc/net/nf_conntrack you see the connection marked as state
ESTABLISHED, too.
Furthermore we tried to enter a static arp entry for the virtual cluster
ip on the client node, that points to the multicast mac. Same result.
But if you statically enter the real mac of the cluster node's interface
on the client node, see there, it works perfectly.
Is that possible a bug in conntrack?
Best,
Martin
|
client.pcap
