Bug 1401409
| Summary: | One slave NIC can not be "ON" of bridge over 2 NICs created via cockpit | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Huijuan Zhao <huzhao> | ||||||||||
| Component: | cockpit | Assignee: | Marius Vollmer <mvollmer> | ||||||||||
| Status: | CLOSED NEXTRELEASE | QA Contact: | qe-baseos-daemons | ||||||||||
| Severity: | high | Docs Contact: | |||||||||||
| Priority: | medium | ||||||||||||
| Version: | 7.6 | CC: | bugs, cshao, dguo, dougsland, fdeutsch, huzhao, jiawu, leiwang, mpitt, qiyuan, rbarry, weiwang, yaniwang, ycui, yzhao | ||||||||||
| Target Milestone: | pre-dev-freeze | Keywords: | Extras | ||||||||||
| Target Release: | --- | ||||||||||||
| Hardware: | Unspecified | ||||||||||||
| OS: | Unspecified | ||||||||||||
| Whiteboard: | |||||||||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||||||||
| Doc Text: | Story Points: | --- | |||||||||||
| Clone Of: | Environment: | ||||||||||||
| Last Closed: | 2017-10-13 10:17:09 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: | |||||||||||||
| Bug Depends On: | |||||||||||||
| Bug Blocks: | 1400961 | ||||||||||||
| Attachments: |
|
||||||||||||
Created attachment 1227993 [details]
screenshot of eno2 "OFF"
Created attachment 1227994 [details]
screenshot of eno1 is part of bridge0
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? (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 Created attachment 1236762 [details] comment5: /var/log/messages > 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...
(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. (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. > 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. https://github.com/cockpit-project/cockpit/pull/5668 was released in Cockpit 127. (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. Current RHEL 7.4 has Cockpit 138, so this bug is fixed there. Closing. |
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: