#134 Issue closed: Clean-up bonding TODOs in network_devices¶
Labels: enhancement
jezzaaa opened issue at 2012-07-26 03:01:¶
The 31_network_devices.sh script has a number of mentions of things that need to be fixed up for bonding. I have a SLES10 bonding setup (both production and lab) and I'm happy to work on this, testing and/or submitting patches, if the problems can be specified.
I've yet to try this with a multi-bond server, but so far I haven't had a problem using the bond0 interface when in the recovery environment. I don't have SIMPLIFY_BONDING defined.
dagwieers commented at 2012-07-26 15:14:¶
Be aware that we want to support the case where bonding is using LACP (and also VLAN-tagging), and we want to auto-detect the different links by doing an ARP request to the gateway (of possible). This was discussed in issue #3.
Anything that improves the current implementation (without fixing every use-case) is also welcome, provided that it acknowledges the cases that are not supported and does not make a more complete implementation more difficult.
jezzaaa commented at 2012-07-27 03:42:¶
Hmm. This is more complicated than I anticipated and perhaps beyond my expertise in some cases. I'm not using LACP (only active-backup because we only need redundancy, and didn't want to reconfigure the switch ports), so I can't test LACP or VLAN-tagging setups.
I can confirm that on my system, the bond0 interface takes on the MAC address of the first ethernet device in the bond. But this is from experience, and I have not confirmed this from reading the bonding documentation or code.
Regarding:
# Note: Some users reported that this works only for the first bonding device
# in this case one should disable bonding by setting SIMPLIFY_BONDING
Can you provide any details on the nature/symptoms of the failure, or references to an issue number? If I can recreate the problem, I might be able to help fix it.
schlomo commented at 2012-07-29 19:04:¶
I put in some TODOs when I knew that I was dealing only with certain
"working" configurations but could see already where this code would
fail
in other configurations...
I guess with regard to bonding/vlan/... we need to slowly build up
working
scenarios and document them. The code should be also clean enough to
not
mix up link level and stuff like vlan and bonding and ip level stuff
like
ip rule and ip route and ip addr things.
gdha commented at 2015-01-14 09:54:¶
VLAN support is in rear-1.16 already - we better close this issue and if other (new) issues occur a new issue can be opened
[Export of Github issue for rear/rear.]