Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1373528

Summary:	[OVS-DPDK] cannot disable a slave
Product:	Red Hat Enterprise Linux 7	Reporter:	Flavio Leitner <fleitner>
Component:	openvswitch	Assignee:	Eelco Chaudron <echaudro>
Status:	CLOSED NOTABUG	QA Contact:	ovs-qe
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.3	CC:	aloughla, atragler
Target Milestone:	rc
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-01-20 14:10:04 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Flavio Leitner 2016-09-06 14:10:54 UTC

Description of problem:

<copy&paste from email>

In brief, there are four cases:
(1)when one slave is enabled, I changed it to disable by using disable-slave command, it will became disabled, but it will return to enabled after the updelay expired.
(2)When one slave from up to down by using ip link command, it will became disabled after the updelay expired.
(3)when one slave is disabled, I changed it to enable by using enable-slave command, it will became enabled, but it will return to disabled after the downdelay expired.
(4)When one slave from down to up by using ip link command, it will became enabled after the downdelay expired.

I can understand the (2) and (4) cases, but the (1) and (3) cases makes me confused, the state of
the change is valid only before the delay time. Should it like this? If it should be like this, What
scene is it used for?


I added a bond as below.
ovs-vsctl add-bond br0 bond0 ens5f0 ens5f1 bond_updelay=5000 bond_downdelay=10000


Then check it:
[root@ibm-x3650m5-02 ~]# ovs-vsctl show
bd880e8f-a556-4ff0-8986-68547cac87e7
    Bridge "br0"
        Port "br0"
            Interface "br0"
                type: internal
        Port "bond0"
            Interface "ens5f0"
            Interface "ens5f1"
    ovs_version: "2.5.0"

[root@ibm-x3650m5-02 ~]# ovs-appctl bond/show
---- bond0 ----
bond_mode: active-backup
bond may use recirculation: no, Recirc-ID : -1
bond-hash-basis: 0
updelay: 5000 ms
downdelay: 10000 ms
lacp_status: off
active slave mac: 00:0e:1e:ba:28:e0(ens5f0)

slave ens5f0: enabled
        active slave
        may_enable: true

slave ens5f1: enabled
        may_enable: true

Then I use command disable ens5f0, the ens5f0 changed to the disabled.

[root@ibm-x3650m5-02 ~]# ovs-appctl bond/disable-slave bond0 ens5f0
disabled

[root@ibm-x3650m5-02 ~]# ovs-appctl bond/show
---- bond0 ----
bond_mode: active-backup
bond may use recirculation: no, Recirc-ID : -1
bond-hash-basis: 0
updelay: 5000 ms
downdelay: 10000 ms
lacp_status: off
active slave mac: 00:0e:1e:ba:28:e2(ens5f1)

slave ens5f0: disabled
        updelay expires in 3193 ms
        may_enable: true

slave ens5f1: enabled
        active slave
        may_enable: true

After the updelay expired, ens5f0 return to enabled.
[root@ibm-x3650m5-02 ~]# ovs-appctl bond/show
---- bond0 ----
bond_mode: active-backup
bond may use recirculation: no, Recirc-ID : -1
bond-hash-basis: 0
updelay: 5000 ms
downdelay: 10000 ms
lacp_status: off
active slave mac: 00:0e:1e:ba:28:e2(ens5f1)

slave ens5f0: enabled
        may_enable: true

slave ens5f1: enabled
        active slave
        may_enable: true



I put the ens5f1 down, the ens5f1 became disable after the downdelay expired. It is easy to
understand.

[root@ibm-x3650m5-02 ~]# ip link set ens5f0 down
[root@ibm-x3650m5-02 ~]# ovs-appctl bond/show
---- bond0 ----
bond_mode: active-backup
bond may use recirculation: no, Recirc-ID : -1
bond-hash-basis: 0
updelay: 5000 ms
downdelay: 10000 ms
lacp_status: off
active slave mac: 00:0e:1e:ba:28:e2(ens5f1)

slave ens5f0: enabled
        downdelay expires in 8838 ms
        may_enable: false

slave ens5f1: enabled
        active slave
        may_enable: true

After the downdelay expired,
[root@ibm-x3650m5-02 ~]# ovs-appctl bond/show
---- bond0 ----
bond_mode: active-backup
bond may use recirculation: no, Recirc-ID : -1
bond-hash-basis: 0
updelay: 5000 ms
downdelay: 10000 ms
lacp_status: off
active slave mac: 00:0e:1e:ba:28:e2(ens5f1)

slave ens5f0: disabled
        may_enable: false

slave ens5f1: enabled
        active slave
        may_enable: true


And I used command make ens5f0 enable,

[root@ibm-x3650m5-02 ~]# ovs-appctl bond/enable-slave bond0 ens5f0
enabled
[root@ibm-x3650m5-02 ~]# ovs-appctl bond/show
---- bond0 ----
bond_mode: active-backup
bond may use recirculation: no, Recirc-ID : -1
bond-hash-basis: 0
updelay: 5000 ms
downdelay: 10000 ms
lacp_status: off
active slave mac: 00:0e:1e:ba:28:e2(ens5f1)

slave ens5f0: enabled
        downdelay expires in 8822 ms
        may_enable: false

slave ens5f1: enabled
        active slave
        may_enable: true

After the downdelay expired, ens5f0 return to disabled.

[root@ibm-x3650m5-02 ~]# ovs-appctl bond/show
---- bond0 ----
bond_mode: active-backup
bond may use recirculation: no, Recirc-ID : -1
bond-hash-basis: 0
updelay: 5000 ms
downdelay: 10000 ms
lacp_status: off
active slave mac: 00:0e:1e:ba:28:e2(ens5f1)

slave ens5f0: disabled
        may_enable: false

slave ens5f1: enabled
        active slave
        may_enable: true


Then I make the ens5f0 up,
[root@ibm-x3650m5-02 ~]# ip link set ens5f0 up
[root@ibm-x3650m5-02 ~]# ovs-appctl bond/show
---- bond0 ----
bond_mode: active-backup
bond may use recirculation: no, Recirc-ID : -1
bond-hash-basis: 0
updelay: 5000 ms
downdelay: 10000 ms
lacp_status: off
active slave mac: 00:0e:1e:ba:28:e2(ens5f1)

slave ens5f0: disabled
        updelay expires in 3977 ms
        may_enable: true

slave ens5f1: enabled
        active slave
        may_enable: true

After updalay expired, ens5f0 became to enabled as below,
[root@ibm-x3650m5-02 ~]# ovs-appctl bond/show
---- bond0 ----
bond_mode: active-backup
bond may use recirculation: no, Recirc-ID : -1
bond-hash-basis: 0
updelay: 5000 ms
downdelay: 10000 ms
lacp_status: off
active slave mac: 00:0e:1e:ba:28:e2(ens5f1)

slave ens5f0: enabled
        may_enable: true

slave ens5f1: enabled
        active slave
        may_enable: true

The ovs-vswitchd.log as below:
2016-07-27T03:37:11.071Z|00457|bond|INFO|interface ens5f0: disabled
2016-07-27T03:37:11.071Z|00458|bond|INFO|interface ens5f0: link state up
2016-07-27T03:37:11.071Z|00459|bond|INFO|interface ens5f0: will be enabled if it stays up for 5000
ms
2016-07-27T03:37:16.071Z|00460|bond|INFO|interface ens5f0: enabled

2016-07-27T03:46:12.548Z|00461|bond|INFO|interface ens5f0: link state down
2016-07-27T03:46:12.548Z|00462|bond|INFO|interface ens5f0: will be disabled if it stays down for
10000 ms
2016-07-27T03:46:12.548Z|00463|bridge|WARN|Dropped 1 log messages in last 708 seconds (most
recently, 708 seconds ago) due to excessive rate
2016-07-27T03:46:12.548Z|00464|bridge|WARN|port bond0: Using the default bond_mode active-backup.
Note that in previous versions, the default bond_mode was balance-slb
2016-07-27T03:46:22.548Z|00465|bond|INFO|interface ens5f0: disabled

2016-07-27T04:48:36.419Z|00466|bond|INFO|interface ens5f0: enabled
2016-07-27T04:48:36.419Z|00467|bond|INFO|interface ens5f0: link state down
2016-07-27T04:48:36.419Z|00468|bond|INFO|interface ens5f0: will be disabled if it stays down for
10000 ms
2016-07-27T04:48:46.419Z|00469|bond|INFO|interface ens5f0: disabled

2016-07-27T05:37:20.458Z|00470|bridge|WARN|port bond0: Using the default bond_mode active-backup.
Note that in previous versions, the default bond_mode was balance-slb
2016-07-27T05:37:20.458Z|00471|bond|INFO|interface ens5f0: link state up
2016-07-27T05:37:20.458Z|00472|bond|INFO|interface ens5f0: will be enabled if it stays up for 5000
ms
2016-07-27T05:37:25.459Z|00473|bond|INFO|interface ens5f0: enabled

Version-Release number of selected component (if applicable):
ovs 2.4

How reproducible:
Always

Actual results:
The interface is re-enabled if there is a valid link.

Expected results:
The interface to remains disabled

Comment 2 Eelco Chaudron 2017-01-13 12:59:11 UTC

In OVS there is no difference to administratively disabling/enabling a port vs operational enabling/disabling based on the link status. Will need to create a modification distinguishing between the two.

Comment 4 Eelco Chaudron 2017-01-18 08:46:22 UTC

This behaviour is according to the documentation;

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.

Comment 5 Eelco Chaudron 2017-01-20 14:10:04 UTC

Closing BZ as this is working per design. For administratively disabling the slaves we should either remove the slave from the bundle, or bring the link down.