Bug 752097 - kernel: bond interfaces sending false arp replies
Summary: kernel: bond interfaces sending false arp replies
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel
Version: 4.9
Hardware: i686
OS: Linux
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Veaceslav Falico
QA Contact: Red Hat Kernel QE team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-11-08 14:49 UTC by michael.gruener
Modified: 2014-09-30 23:44 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-11-21 14:03:47 UTC
Target Upstream Version:


Attachments (Terms of Use)
Packet dumps of two affected systems (777 bytes, application/x-gzip)
2011-11-08 14:52 UTC, michael.gruener
no flags Details

Description michael.gruener 2011-11-08 14:49:29 UTC
Description of problem:

When configuring multiple bond interfaces (active-backup mode) on one system, all interfaces reply to arp requests for any ip adress configured on the interfaces.

example setup:

bond0 = 10.10.145.131 (00:21:5a:f3:fe:ce)
bond0:1 = 10.10.145.132
bond1 = 10.10.146.131 (00:21:5a:f3:fe:cc)

An arp request "Who has 10.10.145.131? Tell xxx.xxx.xxx.xxx" would (sometimes) be answered with two replies "10.10.145.131 is at 00:21:5a:f3:fe:ce" and "10.10.145.131 is at 00:21:5a:f3:fe:cc".

We have four systems showing this behavior and on each system the problem started after upgrading the kernel-smp from 2.6.9-89.33.1 to 2.6.9-101.

I have attached four pcap files showing the arp requests of the two bonding interfaces of two systems right after clearing the arp cache.

Version-Release number of selected component (if applicable):
kernel-smp-2.6.9-101.EL

  
Actual results:
See attached archive.


Expected results:
Only interfaces with the correct ip address should respond to arp requests asking for this ip.

Comment 1 michael.gruener 2011-11-08 14:52:03 UTC
Created attachment 532302 [details]
Packet dumps of two affected systems

Comment 2 Andy Gospodarek 2011-11-10 21:44:10 UTC
This sounds more like a chance to the sysctl option 'net.ipv4.conf.default.arp_ignore' than a bonding change, but we can take a look.

Comment 3 michael.gruener 2011-11-21 09:42:59 UTC
Setting net.ipv4.conf.default.arp_ignore = 1 solved the problem.

Comment 4 Andy Gospodarek 2011-11-21 14:03:47 UTC
Great!  Closing at NOTABUG.


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