Bug 1210440 - arp_ip_target on mode balance-xor xmit_hash_policy layer3+4
Summary: arp_ip_target on mode balance-xor xmit_hash_policy layer3+4
Keywords:
Status: CLOSED DUPLICATE of bug 126342
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 20
Hardware: x86_64
OS: Linux
unspecified
urgent
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-04-09 18:04 UTC by Nitin Sharma
Modified: 2015-04-09 18:18 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-04-09 18:18:28 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Nitin Sharma 2015-04-09 18:04:02 UTC
Description of problem:
Cannot get arp_ip_target to work on mode=2 i.e. balance-xor
layer3+4 xmit mode?

Here is my bonding_opts

mode=2 xmit_hash_policy=layer3+4 arp_ip_target=10.0.0.62 arp_interval=30000

I see from tcpdump that arp requests to 10.0.0.62 are sent to both
links, and both arp replies are got back too. However, bond0 shows
"NO-CARRIER".

Few things specific to my environment if these affect.

1. NOARP flag is set for bond0 - should it affect? I removed that
NOARP flag, and still the same behavior.
2. the arp_ip_target is also the gateway ip address of the host. There
is a default route to 10.0.0.62 on the hosts routing table.
3. Two switches reply to the same arp_tpa 10.0.0.62 arp request with different
mac-addresses. Essentially all I want from arp_ip_target is the receipt
of an ARP reply such that the bonding keeps the link on its transmit
decision, not necessary populate the arp table on the host.

Version-Release number of selected component (if applicable):
Linux 3.15.6-1 #4 SMP PREEMPT Fri Aug 1 19:53:58 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

How reproducible:
Always.


Steps to Reproduce:
1. Configure bonding_opts, mode=2 xmit_hash_policy=layer3+4 arp_ip_target=10.0.0.62 arp_interval=30000
2. Connect two NICs to two switches both responding ARPs to 10.0.0.62
3. TCPDUMP - even if the host sees arp replies, bond0 never comes up. It says NO_CARRIER
4. Try with NOARP flag on the bond0 interface, same results.

Actual results:
bond0 stays as NO_CARRIER

Expected results:
bond0 should allow the members that received arp replies to be a part of its slave interfaces.

Additional info:

Comment 1 Josh Boyer 2015-04-09 18:18:28 UTC

*** This bug has been marked as a duplicate of bug 126342 ***


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