Bug 99191 - ARP monitoring with bonding module uses interface alias for ARP request
Summary: ARP monitoring with bonding module uses interface alias for ARP request
Status: NEW
Alias: None
Product: Networking
Classification: Unclassified
Component: Other (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Stephen Hemminger
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-05-29 17:59 UTC by benl
Modified: 2016-02-15 20:36 UTC (History)
2 users (show)

See Also:
Kernel Version: All
Subsystem:
Regression: No
Bisected commit-id:


Attachments

Description benl 2015-05-29 17:59:33 UTC
When using arp_ip_target combined with arp_validate to verify the connectivity status of a bond, the wrong IP address is used as the source of the request if multiple IP aliases are assigned to the bond0.

Example 1.

bond0   - 10.0.0.5/24 (WAN)
bond0:1 - 10.0.1.5/24 (LAN)
arp_validate - all
arp_ip_target - 10.0.0.1

Expected result: ARP, Request who-has 10.0.0.1 tell 10.0.0.5

Actual result:   ARP, Request who-has 10.0.0.1 tell 10.0.1.5

Issue:           The Layer 3 switch responsible for replying to the ARP request does not have the local interface of 10.0.1.5 configured, so the ARP request goes unanswered.

-

My expectation is that the bonding driver would use the primary IP on the bond0 interface, not a secondary IP. The solution being to be able to specify which IP the ARP should originate from in a scenario where bondX has multiple IPs assigned.

Mangling the packet in/out using arptables does not achieve the desired effect.

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