On 12/05/2017 4:34 PM, Kyle Larose wrote:
-----Original Message-----
From: Declan Doherty [mailto:declan.dohe...@intel.com]
Sent: Friday, May 12, 2017 10:56 AM
To: Kyle Larose; us...@dpdk.org; dev@dpdk.org
Subject: Re: active_backup link bonding and mac address
On 12/05/2017 3:31 PM, Kyle Larose wrote:
I'm adding the dev mailing list/link bonding maintainer, because I've done
some more investigation and I'm beginning to think something is wrong.
Kyle, sorry I didn't see the post in the users list. I think the issue is
that the new primary is missing the bond MAC address on it's valid MACs
list, hence it is dropping the ingress packets after a fail-over event,
placing the all the slave devices into promiscuous mode as you suggest in
option 2 would probably make the issue go away but I don't think it's the
correct solution. I think we should just be adding the bond MAC to each
slaves devices valid MAC list. As only one bond slave is only active at any
time this won't cause any issues to the network, and will mean that fail
over is transparent to your application and there is no need for MAC
rewrites, which would invalidate existing ARP table entries at downstream
end points.
Hey Declan,
Thanks for the prompt response.
I agree with your suggestion. Does this MAC list propagate to the slave NICs'
hardware layers?
That is, even if a slave isn't in promiscuous mode, if it receives a frame
addressed to any
MAC in its list, it will accept it and deliver it to the software? Or, does it
mean we need to
put the slave into promiscuous mode, but filter any MACs not in its list
(unless the bond
interface itself is in promiscuous mode)?
Thanks,
Kyle
Yes it would be into the hw tables, rte_eth_dev_mac_addr_add() on each
slave port should achieve this, so there will be no need to run in
promiscuous mode. I'll try and setup a test for this on Monday morning
in our lab.
Declan
