|
On Fri, 19 Oct 2001, Fabrice wrote:
> Hello,
>
> Resumé: Synchronization only works when you use eth0
> to send "connections informations" (at least for me).
>
> My two directors are running Linux 2.4.10 with IPVS 0.9.4.
> There is a link between those on eth2:
>
> LVS-NAT: VIP = 192.168.1.10, GW_VIP=192.168.2.1
>
> Clients
>
> ----+--------------------+--------------------+----
>
> eth0 | 192.168.1.11 192.168.1.12 | eth0
> +---+---+ +---+---+
>
> | | 192.168.3.1 192.168.3.2 | |
> |
> | DIR_1 +---------------------------------+ DIR_2 |
> |
> | | eth2 eth2 | |
>
> +---+---+ +---+---+
> eth1 | 192.168.2.11 192.168.2.12 | eth1
>
> ----+---+---------------------------------+---+----
>
> eth0 | 192.168.2.21 192.168.2.22 | eth0
> +---+---+ +---+---+
>
> | RS1 | | RS2 |
>
> +-------+ +-------+
>
>
> On director 1:
> ipvsadm --start-daemon=master --mcast-interface=eth2
>
> On director 2:
> ipvsadm --start-daemon=slave --mcast-interface=eth2
>
> The connectivity is ok, "connection information" packets are
> sent/received correctly, as shown with tcpdump:
>
> 11:33:51.738631 192.168.1.11.1028 > 224.0.0.81.8848: udp 28 (DF) [ttl 1]
>
> The problem is that the source address seems to confuse
> the receiving socket (on the backup machine) and doesn't
> take the packet in consideration.
>
We use UDP multicast. The source address of UDP packet isn't that
important. In the code, I didn't bind the sending socket with a local
address specifically, the address:port (such as 192.168.1.11.1028 in your
example) is automatically allocated by the kernel.
The ipvs sync code set the specified interface for outgoing multicast
messages in the master side, and the specified interface for incoming
multicast messages.
> I verified it by changing the link used for synchronization to
> eth0. The result is positive, the synchronization is correct.
>
> I dunno if it's a kernel problem (shouldn't the source address
> on eth2 be 192.168.3.1 instead of eth0's address: 192.168.1.11)?
>
> If it's the normal behavior, then the bug may be in ipvs.
>
> I looked a bit at the sources ("ip_vs_sync.c") in the infinite loop
> in function "sync_backup_loop". It seems that, when I configure
> the synchronization daemons to use eth2, the receive queue
> is always empty:
>
If you set the master director send mulitcast sync info through eth0, and
the backup director listen to eth2 for mulitcast, then the receive queue
of the backup will be definitely empty.
> "while (!skb_queue_empty(&(sock->sk->receive_queue))) {"
>
> Thats why I don't know if it's a kernel or ipvs bug :)
>
No, it is not the bug of ipvs, not the bug of the kernel either. :)
Regards,
Wensong
|
