[ovs-dev] [RFC] ofproto/bond: operational vs administratively disabled bond interface

Ben Pfaff blp at ovn.org
Wed Jan 18 20:35:49 UTC 2017

On Wed, Jan 18, 2017 at 09:57:00AM +0100, Eelco Chaudron wrote:
> On 17/01/17 20:12, Ben Pfaff wrote:
> >On Tue, Jan 17, 2017 at 12:10:59PM -0200, Flavio Leitner wrote:
> >>On Tue, 17 Jan 2017 09:34:19 +0100
> >>Eelco Chaudron <echaudro at redhat.com> wrote:
> >>
> >>>Currently OVS does not distinguish between a bond slave being operational
> >>>disabled, i.e. link being down, and administratively disabled.
> >>>
> >>>Take the example where the administrator disabled a link in a bond,
> >>>"ovs-appctl bond/disable-slave bond0 enp129s0f0", it's automatically
> >>>enabled again due to the fact the link is up.
> >>>
> >>>I would like to change this behavior such that when disabled trough appctl
> >>>the slave is no longer used until explicitly enabled again via appctl.
> >>Eelco and I discussed this off list and I agree that this sounds like
> >>a bug.  The slave should not be used if the admin has disabled it
> >>regardless of its link state.
> >The behavior matches the documentation:
> >
> >        bond/enable-slave port slave
> >        bond/disable-slave port slave
> >               Enables (or disables) slave on the given bond port, skipping any
> >               updelay (or downdelay).
> >
> >               This  setting  is not permanent: it persists only until the car‐
> >               rier status of slave changes.
> So to administratively disable a link, you should either force the link to
> be down (and don't forget after system reboot), or remove the slave from the
> bond? If so, no re-work is needed here.

I guess that I would rather say that OVS does not currently have a
concept of a slave being administratively disabled while it is part of a
bond.  If it's useful to have such a concept, then I'm open to the
discussion.  Part of the discussion needs to be a rationale for why this
new concept is valuable, given the other possibilities that you mention.

More information about the dev mailing list