Bug 610237 - [6u0] Bonding in ALB mode sends ARP in loop
[6u0] Bonding in ALB mode sends ARP in loop
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: kernel (Show other bugs)
6.0
All Linux
high Severity high
: rc
: ---
Assigned To: Flavio Leitner
Network QE
:
Depends On: 610234
Blocks: 610236
  Show dependency treegraph
 
Reported: 2010-07-01 15:59 EDT by Flavio Leitner
Modified: 2011-05-23 16:40 EDT (History)
3 users (show)

See Also:
Fixed In Version: kernel-2.6.32-83.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 610234
Environment:
Last Closed: 2011-05-23 16:40:22 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Flavio Leitner 2010-07-01 15:59:46 EDT
+++ This bug was initially created as a clone of Bug #610234 +++

Description of problem:
When two systems using bonding devices in adaptive load
balancing (ALB) communicates with each other, an endless
ping-pong of ARP replies starts between these two systems.

What happens? In the ALB mode, bonding driver keeps track
of each client connected in a hash table, so it can do the
receive load balancing (RLB). This hash table is updated
when an ARP reply is received, then it scans for the client
entry, updates its MAC address and flag it to be announced
later. Therefore, two seconds later, the alb monitor runs
and send for each updated client entry two ARP replies
updating this specific client. The same process happens on
the receiving system, causing the endless ping-pong of arp
replies.

See more information including the relevant functions below:

   System 1                          System 2
    bond0                             bond0

   ping <system2>
    ARP request  --------->
                           <--------- ARP reply

+->rlb_arp_recv  <---------------------+   <--- loop begins
|  rlb_update_entry_from_arp           |
|  client_info->ntt = 1;               |
|  bond_info->rx_ntt = 1;              |
|                                      |
|         <communication succeed>      |
|                                      |
|  bond_alb_monitor                    |
|  rlb_update_rx_clients               |
|  rlb_update_client                   |
|  arp_create(ARPOP_REPLY)             |
|   send ARP reply -------------->     V
|   send ARP reply -------------->
|                               rlb_arp_recv
|                               rlb_update_entry_from_arp
|                               client_info->ntt = 1;
|                               bond_info->rx_ntt = 1;
|                           < snipped, same as in system 1>
+-------           <-------------- send ARP reply
                   <-------------- send ARP reply

Besides the unneeded networking traffic, this loop breaks
a cluster because a backup system can't take over the IP
address. There is always one system sending an ARP reply
poisoning the network.

This patch fixes the problem adding a check for the MAC
address before updating it. Thus, if the MAC address didn't
change, there is no need to update neither to announce it later.

Version-Release number of selected component (if applicable):
5.6

How reproducible:
Always

Steps to Reproduce:
Just ping one system from another with both running bonding in ALB mode and you can see the ARP being sent each 2 seconds between them.
  
Actual results:
It is impossible for a backup system to take over the IP address when there are other systems sending wrong ARP packets poisoning the network.

Expected results:
Don't send unneeded ARP packets

Additional info:
The patch is available upstream:
http://git.kernel.org/?p=linux/kernel/git/davem/net-2.6.git;a=commit;h=42d782ac1bef7cbcdf05b857731345c6e8149f90

The patch is backported for RHEL5 and we are waiting for testing results.
Comment 1 Andy Gospodarek 2010-07-16 13:35:31 EDT
Flavio, you did the leg work on this and you earned the internal credit too. 
Please post this when you get positive feedback.
Comment 3 RHEL Product and Program Management 2010-10-04 21:54:41 EDT
This request was evaluated by Red Hat Product Management for inclusion
in a Red Hat Enterprise Linux maintenance release. Product Management has 
requested further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed 
products. This request is not yet committed for inclusion in an Update release.
Comment 4 Aristeu Rozanski 2010-11-17 14:43:36 EST
Patch(es) available on kernel-2.6.32-83.el6
Comment 8 errata-xmlrpc 2011-05-23 16:40:22 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2011-0542.html

Note You need to log in before you can comment on or make changes to this bug.