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 1355648 - Should not permit add 2 bridges on same one NIC via cockpit
Summary: Should not permit add 2 bridges on same one NIC via cockpit
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: cockpit
Version: 7.2
Hardware: Unspecified
OS: Unspecified
medium
high
Target Milestone: beta
: 7.3
Assignee: Marius Vollmer
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks: ovirt-node-ng-platform
TreeView+ depends on / blocked
 
Reported: 2016-07-12 07:23 UTC by Huijuan Zhao
Modified: 2016-08-04 09:12 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-08-04 09:12:12 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
kickstart file (402 bytes, text/plain)
2016-07-12 07:23 UTC, Huijuan Zhao 		no flags Details
screenshot of "ip a s" on rhvh (1.32 MB, image/png)
2016-07-12 07:24 UTC, Huijuan Zhao 		no flags Details
screenshot of add second bridge via cockpit (164.72 KB, image/png)
2016-07-12 07:25 UTC, Huijuan Zhao 		no flags Details
All logs (6.03 MB, application/x-gzip)
2016-07-12 07:25 UTC, Huijuan Zhao 		no flags Details
View All

Description Huijuan Zhao 2016-07-12 07:23:01 UTC 
Created attachment 1178763 [details]
kickstart file

Description of problem:
Can add more than one bridge on same one NIC via cockpit, and all bridges can get IP from dhcp server, this will cause network unreachable.
Should not permit add more than one bridge on same one NIC via cockpit.

Version-Release number of selected component (if applicable):
redhat-virtualization-host-4.0-20160708.0.x86_64
imgbased-0.7.2-0.1.el7ev.noarch
cockpit-0.108-1.el7.x86_64
libvirt-daemon-driver-network-1.2.17-13.el7_2.5.x86_64
glib-networking-2.42.0-1.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
1. Install redhat-virtualization-host-4.0-20160708.0.x86_64 with kickstart file in attachment    
2. Login cockpit website hostIP:9090 with root account
3. Select Networking page, create bridge0 on em1.
4. Create another bridge1 on em1.

Actual results:
1. After step4, the second bridge1 is created successful and can also get IP from DHCP server, cockpit disconnected, host network disconnected.

Expected results:
1. After step4, should forbid creating another bridge1 on em1.

Additional info:
Comment 1 Huijuan Zhao 2016-07-12 07:24:15 UTC 
Created attachment 1178764 [details]
screenshot of "ip a s" on rhvh
Comment 2 Huijuan Zhao 2016-07-12 07:25:05 UTC 
Created attachment 1178765 [details]
screenshot of add second bridge via cockpit
Comment 3 Huijuan Zhao 2016-07-12 07:25:50 UTC 
Created attachment 1178767 [details]
All logs
Comment 5 Marius Vollmer 2016-07-13 09:56:51 UTC 
My expectation is that creating bridge1 on em1 would cleanly remove em1 from bridge0.

I'll check what's really happening.
Comment 6 Marius Vollmer 2016-08-03 12:07:56 UTC 
Is em1 the main network connection that is also used to serve Cockpit?

If so then wrapping it in a bridge might indeed disconnect the machine completely.
Comment 7 Marius Vollmer 2016-08-03 12:11:29 UTC 
Cockpit has a bug where it doesn not properly clean up the connection settings when a interface changes roles (from a bridge slave to a team slave, say).  Instead of doing this cleanly, a error would be shown in the Cockpit UI.

But since you don't mention this error, I think this bug isn't triggered here.
Comment 8 Marius Vollmer 2016-08-03 12:36:14 UTC 
(In reply to Marius Vollmer from comment #6)
> Is em1 the main network connection that is also used to serve Cockpit?
> 
> If so then wrapping it in a bridge might indeed disconnect the machine
> completely.

I have tried this with a VM with a single network interface.  That interface then of course is responsible for the single IP address of the machine and Cockpit connects to that IP address.

I can see what you report:

 - Creating a new bridge with the interface keeps the connection alive.  The bridge takes over responsibility for the IP address and has the same MAC as the interface.

 - Creating a second bridge that steals the interface from the first bridge disconnects the machine.  Now both bridges have the IP address of the machine, but no packets go through.

 - Deleting the first bridge with "nmcli d del bridge0" causes packets to flow again. 


This is just one example how a bad network configuration can disconnect your machine from Cockpit.  Another example is simply bringing down the interface.  

Instead of trying to know all 'wrong' changes, our general plan for this situation is to have automatic rollback of configuration changes that have not been confirmed within a certain time.
Comment 9 Marius Vollmer 2016-08-04 09:12:12 UTC 
I close this as NOTABUG since the current behavior is actually the expected one.  

It's not the desired one, and that is tracked here: https://github.com/cockpit-project/cockpit/issues/1818
Note You need to log in before you can comment on or make changes to this bug.