Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 1355648

Summary: Should not permit add 2 bridges on same one NIC via cockpit
Product: Red Hat Enterprise Linux 7 Reporter: Huijuan Zhao <huzhao>
Component: cockpitAssignee: Marius Vollmer <mvollmer>
Status: CLOSED NOTABUG QA Contact: qe-baseos-daemons
Severity: high Docs Contact:
Priority: medium    
Version: 7.2CC: bugs, cshao, dguo, fdeutsch, jiawu, leiwang, mgoldboi, rbarry, weiwang, yaniwang, ycui, yzhao
Target Milestone: betaKeywords: Extras
Target Release: 7.3   
Hardware: Unspecified   
OS: Unspecified   
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-08-04 09:12:12 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Node RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 1329957    
Description Flags
kickstart file
screenshot of "ip a s" on rhvh
screenshot of add second bridge via cockpit
All logs none

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):

How reproducible:

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: