Re: [PATCH][RFC] bonding: delete migrated IP addresses from the rlb hash table

On Wed, Feb 29, 2012 at 09:58:53PM +0800, WeipingPan wrote:

On 02/28/2012 01:34 AM, Jiri Bohac wrote:

quoted

Bonding in balance-alb mode records information from ARP packets
passing through the bond in a hash table (rx_hashtbl).

At certain situations (e.g. link change of a slave),
rlb_update_rx_clients() will send out ARP packets to update ARP
caches of other hosts on the network to achieve RX load balancing.

The problem is that once an IP address is recorded in the hash
table, it stays there indefinitely [1]. If this IP address is
migrated to a different host in the network, bonding still sends
out ARP packets that poison other systems' ARP caches with
invalid information.

I met this problem, too.

quoted

This patch solves this by looking at all incoming ARP packets,
and checking if the source IP address is one of the source
addresses stored in the rx_hashtbl. If it is, the corresponding
hash table entries are removed. Thus, when an IP address is
migrated, the first ARP broadcast by its new owner will purge the
offending entries of rx_hashtbl.

  (a simpler approach, where bonding would monitor IP address
   changes on the local system does not work for setups like:
   HostA --- NetworkA --- eth0-bond0-br0 --- NetworkB --- hostB
   and an IP address migrating from HostB to HostA)

Could you explain in detail or step by step how to reproduce your problem ?
I made a patch but I do not know whether it can fix your problem.

quoted

   HostA --- NetworkA --- eth0-bond0-br0 --- NetworkB --- hostB

the simplest setup is something like:

                       ---- HostC ------
HostA ----- switch ---|-- eth0 - bond0  |
HostB -----/       \--|-- eth1 -/       |
                       -----------------

HostA has IP address A, HostB has IP address B, HostC has IP
address C).

Set link of eth1 down.

Ping from C to A. This will create the rlb hash table entry with 
ip_src = C and ip_dst = A and tx_slave = eth0.

Delete IP address C from bond0.
Assign IP address C to HostB

Set link of eth1 up.
Set link of eth0 down.


This should cause the hash table to be walked and all clients
(HostA included) "updated" win a unicast ARP REPLY sent by
rlb_update_client(). The reply will claim that IP address C has
the MAC address of eth1.

If at this point HostA communicated with HostB using IP address
C, communication will be broken, because the ARP cache of Host A
will be poisoned.

My patch would delete the bad hash table entry when 
it sees an ARP packet from Host B from IP address C.

Now, this packet is not guaranteed to be broadcast
(imagine HostA sending a broadcast ARP request for IP address C
and HostB replying with an unicast ARP reply.)
But setups that migrate IP addresses from host to hosts often use
gratuitous ARPs to update ARP caches after the IP address
migration and that would make sure the hash table entry is
deleted.

-- 
Jiri Bohac [off-list ref]
SUSE Labs, SUSE CZ