FS#36165 - [netctl] Support for bridging with iproute2

Attached to Project: Arch Linux
Opened by Jason Hall (cakersq) - Monday, 15 July 2013, 23:57 GMT
Last edited by Jouke Witteveen (jouke) - Thursday, 25 July 2013, 08:18 GMT
Task Type Feature Request
Category Packages: Core
Status Closed
Assigned To Thomas Bächler (brain0)
Jouke Witteveen (jouke)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Currently, netctl requires bridge-utils for bridging profiles, listed as an optional dependency. As iproute2 supports bridging, and it's already a required dependency. I would suggest updating the bridging profile to use iproute2 and remove the optional dependency on bride-utils.

Patch attached.
   netctl-bridge.udiff (1.2 KiB)
This task depends upon

Closed by  Jouke Witteveen (jouke)
Thursday, 25 July 2013, 08:18 GMT
Reason for closing:  Implemented
Additional comments about closing:  20c66
Comment by Jouke Witteveen (jouke) - Tuesday, 16 July 2013, 08:37 GMT
Good idea. You also need to update the documentation (and change your indentation to spaces). Do we need/want to retain the FwdDelay and MaxAge parameters? If so, how? Is setting the bridge members into promiscuous mode still necessary? And how about flushing their addresses?

I added Thomas, because he is listed as the author of the current bridge connection type.
Comment by Thomas Bächler (brain0) - Tuesday, 16 July 2013, 08:46 GMT
I don't remember why specifically, but I am pretty sure bridge slaves behave weird if they are not promiscuous. Flushing bridge slaves seems like a very good idea, although flushing their IPv6 link-local address is a bad idea, since they will be unusable for IPv6 until after a reboot (or after someone readds a link-local) - didn't we have a function that flushed interfaces properly?

I don't know if the other parameters are supported by ip - I only ever used fwddelay, but don't need it anymore now. Setting FwdDelay to 0 is useful if you want to use a dhcp client on a bridge interface btw.
Comment by Jouke Witteveen (jouke) - Monday, 22 July 2013, 10:31 GMT
It looks like brctl implements (R)STP, which is responsible for the Forwarding Delay. Using ip, I do not observe a delay. Does iproute2 implement (R)STP? Using iproute2 version 3.10.0 (not yet in [core]), I can set a slave interface to the forwarding (active) state using `bridge link set dev <member> state 3`.

Is it meaningful and sufficient to introduce a SkipForwardingDelay option, which, when set to 'yes', makes netctl set all members of the bridge to the active state immediately?
Comment by Thomas Bächler (brain0) - Monday, 22 July 2013, 11:09 GMT
Yes, probably.
Comment by Jouke Witteveen (jouke) - Thursday, 25 July 2013, 08:17 GMT
Support is now implemented and will be available in netctl 1.3.
I will wait at least until iproute2 version 3.10.0 is in our repositories before I release it.

Loading...