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 1401409 - One slave NIC can not be "ON" of bridge over 2 NICs created via cockpit
Summary: One slave NIC can not be "ON" of bridge over 2 NICs created via cockpit
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: cockpit
Version: 7.6
Hardware: Unspecified
OS: Unspecified
medium
high
Target Milestone: pre-dev-freeze
: ---
Assignee: Marius Vollmer
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks: 1400961
TreeView+ depends on / blocked
 
Reported: 2016-12-05 07:53 UTC by Huijuan Zhao
Modified: 2017-10-13 10:17 UTC (History)
15 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-10-13 10:17:09 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
all logs and all files in /etc/sysconfig/network-scripts/ (8.41 MB, application/x-gzip)
2016-12-05 07:53 UTC, Huijuan Zhao 		no flags Details
screenshot of eno2 "OFF" (129.10 KB, image/png)
2016-12-05 07:56 UTC, Huijuan Zhao 		no flags Details
screenshot of eno1 is part of bridge0 (177.84 KB, image/png)
2016-12-05 07:57 UTC, Huijuan Zhao 		no flags Details
comment5: /var/log/messages (161.42 KB, text/plain)
2017-01-03 05:22 UTC, Huijuan Zhao 		no flags Details
View All

Description Huijuan Zhao 2016-12-05 07:53:15 UTC 
Created attachment 1227992 [details]
all logs and all files in /etc/sysconfig/network-scripts/

Description of problem:
Setup bridge0 over 2 NICs(such as eno1 and eno2) via cockpit, one NIC(eno2) can not be "ON".


Version-Release number of selected component (if applicable):
redhat-virtualization-host-4.0-20161130.0
imgbased-0.8.10-0.1.el7ev.noarch
cockpit-ws-122-3.el7.x86_64
NetworkManager-1.4.0-13.el7_3.x86_64

How reproducible:
100%

Steps to Reproduce:
1. Install RHVH via interactive anaconda.
2. Reboot RHVH and login Cockpit, enter Networking page in Cockpit
3. Setup bridge0 over two NICs. One NIC eno1 is "on", the other NIC eno2 is "off"
4. Enter bridge0 page, select eno2, click "ON"

Actual results:
After step4, eno2 is still "OFF" status after click "ON"

Expected results:
After step4, eno2 should can be "ON" successful

Additional info:
Comment 1 Huijuan Zhao 2016-12-05 07:56:41 UTC 
Created attachment 1227993 [details]
screenshot of eno2 "OFF"
Comment 2 Huijuan Zhao 2016-12-05 07:57:47 UTC 
Created attachment 1227994 [details]
screenshot of eno1 is part of bridge0
Comment 4 Marius Vollmer 2017-01-02 12:13:23 UTC 
I can not reproduce this, nor can I explain it.

What happens when you activate eno2 with nmcli?

What happens when you create the bridge with nmcli?

Can you show the part of /var/log/messages that corresponds to activating eno2 while it is part of bridge0?
Comment 5 Huijuan Zhao 2017-01-03 03:41:33 UTC 
(In reply to Marius Vollmer from comment #4)
> I can not reproduce this, nor can I explain it.
> 
> What happens when you activate eno2 with nmcli?
> 
> What happens when you create the bridge with nmcli?
> 
> Can you show the part of /var/log/messages that corresponds to activating
> eno2 while it is part of bridge0?

I also can reproduce this issue with nmcli.

Test version:
RHVH-4.0-20161130.1-RHVH-x86_64-dvd1.iso
imgbased-0.8.10-0.1.el7ev.noarch
NetworkManager-1.4.0-13.el7_3.x86_64
kernel-3.10.0-514.el7.x86_64

Test Steps:
1. Install RHVH4.0 via interactive anaconda, set eno1 "ON" and onboot=yes in anaconda.
2. Reboot and login RHVH, check eno1 is up and get dhcp IP, ssh RHVH via eno1.
3. Create bridge0 over two NICs via nmcli. One slave NIC eno1 is "on", the other NIC eno2 is "off".
# nmcli connection add ifname bridge0 type bridge con-name bridge0
# nmcli connection add type bridge-slave ifname eno1 master bridge0
# nmcli connection add type bridge-slave ifname eno2 master bridge0
4. Activate eno2 with nmcli
# ifup eno2

Actual results:
After step4, eno2 is still "OFF" status. And bridge0 can not get dhcp IP.

# ip a s
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 08:94:ef:21:c0:4d brd ff:ff:ff:ff:ff:ff
    inet 10.73.130.225/23 brd 10.73.131.255 scope global dynamic eno1
       valid_lft 41599sec preferred_lft 41599sec
    inet6 2620:52:0:4982:a94:efff:fe21:c04d/64 scope global noprefixroute dynamic 
       valid_lft 2591692sec preferred_lft 604492sec
    inet6 fe80::a94:efff:fe21:c04d/64 scope link 
       valid_lft forever preferred_lft forever
3: eno2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq master bridge0 state DOWN qlen 1000
    link/ether 08:94:ef:21:c0:4e brd ff:ff:ff:ff:ff:ff
9: bridge0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN qlen 1000
    link/ether 08:94:ef:21:c0:4e brd ff:ff:ff:ff:ff:ff

# tail -n20 /var/log/messages 
Jan  3 03:40:50 ibm-x3650m5-04 kernel: bridge0: port 1(eno2) entered listening state
Jan  3 03:40:50 ibm-x3650m5-04 NetworkManager[1383]: <info>  [1483414850.3769] device (bridge0): attached bridge port eno2
Jan  3 03:40:50 ibm-x3650m5-04 NetworkManager[1383]: <info>  [1483414850.3769] device (eno2): Activation: connection 'bridge-slave-eno2' enslaved, continuing activation
Jan  3 03:40:50 ibm-x3650m5-04 NetworkManager[1383]: <info>  [1483414850.3770] device (bridge0): IPv4 config waiting until carrier is on
Jan  3 03:40:50 ibm-x3650m5-04 NetworkManager[1383]: <info>  [1483414850.3770] device (bridge0): IPv6 config waiting until carrier is on
Jan  3 03:40:50 ibm-x3650m5-04 NetworkManager[1383]: <info>  [1483414850.3774] device (eno2): state change: ip-config -> secondaries (reason 'none') [70 90 0]
Jan  3 03:40:50 ibm-x3650m5-04 NetworkManager[1383]: <info>  [1483414850.3778] device (eno2): state change: secondaries -> activated (reason 'none') [90 100 0]
Jan  3 03:40:50 ibm-x3650m5-04 lldpad: recvfrom(Event interface): No buffer space available
Jan  3 03:40:50 ibm-x3650m5-04 NetworkManager[1383]: <info>  [1483414850.3924] device (eno2): Activation: successful, device activated.
Jan  3 03:40:50 ibm-x3650m5-04 dbus-daemon: dbus[1226]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus-org.freedesktop.nm-dispatcher.service'
Jan  3 03:40:50 ibm-x3650m5-04 dbus[1226]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus-org.freedesktop.nm-dispatcher.service'
Jan  3 03:40:50 ibm-x3650m5-04 systemd: Starting Network Manager Script Dispatcher Service...
Jan  3 03:40:50 ibm-x3650m5-04 dbus-daemon: dbus[1226]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
Jan  3 03:40:50 ibm-x3650m5-04 dbus[1226]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
Jan  3 03:40:50 ibm-x3650m5-04 nm-dispatcher: req:1 'up' [eno2]: new request (4 scripts)
Jan  3 03:40:50 ibm-x3650m5-04 nm-dispatcher: req:1 'up' [eno2]: start running ordered scripts...
Jan  3 03:40:50 ibm-x3650m5-04 systemd: Started Network Manager Script Dispatcher Service.
Jan  3 03:40:50 ibm-x3650m5-04 systemd: Unit iscsi.service cannot be reloaded because it is inactive.
Jan  3 03:40:51 ibm-x3650m5-04 kernel: tg3 0000:16:00.1 eno2: Link is down
Jan  3 03:40:51 ibm-x3650m5-04 kernel: bridge0: port 1(eno2) entered disabled state

Expected results:
After step4, eno2 should can be "ON" successful.

Additional info:
Please refer to attachment for all the log in /var/log/messages
Comment 6 Huijuan Zhao 2017-01-03 05:22:16 UTC 
Created attachment 1236762 [details]
comment5: /var/log/messages
Comment 7 Marius Vollmer 2017-01-03 10:04:10 UTC 
> Jan  3 03:40:51 ibm-x3650m5-04 kernel: tg3 0000:16:00.1 eno2: Link is down
> Jan  3 03:40:51 ibm-x3650m5-04 kernel: bridge0: port 1(eno2) entered disabled state

This makes me think that eno2 can not be activated in general.  Could you try this on a different machine?  Can I get access to the machine with the problematic eno2?

It would be nice to get a clear error message, but even the journal doesn't mention anything really helpful...
Comment 8 Huijuan Zhao 2017-01-03 10:11:14 UTC 
(In reply to Marius Vollmer from comment #7)
> 
> This makes me think that eno2 can not be activated in general.  Could you
> try this on a different machine?  Can I get access to the machine with the
> problematic eno2?

If not adding eno2 to bridge0, eno2 can be activated successful.

I will send the machine info to you later via email.
Comment 9 Marius Vollmer 2017-01-03 12:33:17 UTC 
(In reply to Huijuan Zhao from comment #8)

> I will send the machine info to you later via email.

Thanks!  That has cleared things up.

The eno2 interface was in fact "On", but the On/Off button in the lists of slaves showed it as "Off" because it had no carrier.

Cockpit should not take the carrier into account when deciding whether a interface is On or Off, and the list of slaves is the only place where this is done.  I don't know why.  (It's all my fault, so I should know, but...)

If you go to the page for the eno2 interface itself, it will correctly show it as "On".


Cockpit was further confused by the existence of two connections for eno1.  It should have ignored all but the currently active connection, but decided that eno1 was a slave of bridge0 because of the existence of the second connection.


So, two bugs in Cockpit.  Thanks for finding them!  Fixes should come soon.
Comment 10 Marius Vollmer 2017-01-03 13:49:39 UTC 
https://github.com/cockpit-project/cockpit/pull/5668
Comment 11 Marius Vollmer 2017-01-03 13:50:39 UTC 
> Cockpit was further confused by the existence of two connections for eno1.

Fixed by https://github.com/cockpit-project/cockpit/pull/5667, but not at the core of this bug.
Comment 12 Marius Vollmer 2017-02-08 08:36:54 UTC 
https://github.com/cockpit-project/cockpit/pull/5668 was released in Cockpit 127.
Comment 13 Marius Vollmer 2017-02-08 08:37:35 UTC 
(In reply to Marius Vollmer from comment #11)
> > Cockpit was further confused by the existence of two connections for eno1.
> 
> Fixed by https://github.com/cockpit-project/cockpit/pull/5667, but not at
> the core of this bug.

Released in Cockpit 131.
Comment 14 Martin Pitt 2017-10-13 10:17:09 UTC 
Current RHEL 7.4 has Cockpit 138, so this bug is fixed there. Closing.
Note You need to log in before you can comment on or make changes to this bug.