|Summary:||Should not permit add 2 bridges on same one NIC via cockpit|
|Product:||Red Hat Enterprise Linux 7||Reporter:||Huijuan Zhao <huzhao>|
|Component:||cockpit||Assignee:||Marius Vollmer <mvollmer>|
|Status:||CLOSED NOTABUG||QA Contact:||qe-baseos-daemons|
|Version:||7.2||CC:||bugs, cshao, dguo, fdeutsch, jiawu, leiwang, mgoldboi, rbarry, weiwang, yaniwang, ycui, yzhao|
|Fixed In Version:||Doc Type:||If docs needed, set a value|
|Doc Text:||Story Points:||---|
|Last Closed:||2016-08-04 09:12:12 UTC||Type:||Bug|
|oVirt Team:||Node||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:|
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 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