Bug 1308403
| Summary: | Bridge slave interface does not up when the topo is bridge over vlan . | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Jiaochuandong <cjiao> |
| Component: | NetworkManager | Assignee: | Rashid Khan <rkhan> |
| Status: | CLOSED NOTABUG | QA Contact: | Desktop QE <desktop-qa-list> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 7.2 | CC: | aloughla, bgalvani, kzhang, lrintel, rkhan, thaller |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-02-16 10:17:26 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: | |||
|
Description
Jiaochuandong
2016-02-15 05:33:31 UTC
side-note:
#nmcli con add type eth ifname ens2f0 con-name ens2f0 mtu 1500
^^ this creates a new connection with autoconnect=yes. If the device is
currently not connected, NM will already activate this new connection.
You can pass "autoconnect no" to avoid that.
#ip link set up ens2f0
^^ why would you up the device externally from NetworkManager?
#nmcli con up ens2f0
^^ if in step 1, the connection is already about to auto-activate,
this aborts the activation and re-activates the connection anew.
Of course all this should work without issues. But especially step 2 is unnecessary.
(In reply to Jiaochuandong from comment #0) > Description of problem: > Bridge slave interface does not up when the topo is bridge over vlan . > > Version-Release number of selected component (if applicable): > 3.10.0-327.el7.x86_64 In this case is the kernel version not as important as the version of NetworkManager. I assume you are using rhel-7.2, 1:1.0.6-27? > Steps to Reproduce: > 1.setup nic > #nmcli con add type eth ifname ens2f0 con-name ens2f0 mtu 1500 If you only want a bridge with a vlan enslaved, you don't need this connection. Of course, you can activate a plain ethernet connection in ~addition~ to an (enslaved) vlan connection. But the ethernet connection doesn't matter in this scenario. > #ip link set up ens2f0 as said, all these `ip link` commands are not correct. > #nmcli con up ens2f0 > 2.setup vlan > #nmcli con add type vlan con-name ens2f0.3 dev ens2f0 id 3 mtu 1500 > #ip link set up ens2f0.3 > #nmcli con up ens2f0.3 > 3.setup bridge > #nmcli con add type bridge ifname br0 con-name br0 > #ip link set ens2f0.3 mtu 1500 > #nmcli con add type bridge-slave ifname ens2f0.3 master br0 This creates an ethernet connection which is enslaved to a bridge. That is also not what you want. You want a vlan connection enslaved to a bridge. NetworkManager 1.0 (rhel-7.2) does not support `nmcli connection add type vlan` that is a slave-type (this will be supported in 1.2/rhel-.3). Anyway, you can fix the connection after creation. I think you should do: nmcli connection add type bridge \ ifname br0 con-name c-br0 nmcli connection add type vlan \ con-name con-ens2f0.3 \ autoconnect no \ dev ens2f0 id 3 \ mtu 1500 nmcli connection modify con-ens2f0.3 \ connection.master br0 \ connection.slave-type bridge \ connection.autoconnect yes > #nmcli con add type bridge-slave ifname ens2f0.3 master br0 > #nmcli con up bridge-slave-ens2f0.3 > Error: Connection activation failed: No suitable device found for this > connection. You ask to activate an ethernet connection (as bride-slave) on ethernet device ens2f0.3 on a bridge named br0. There exists no ethernet device ens2f0.3 (only a vlan). On 1.2 you will be able to do: nmcli connection add type vlan \ con-name con-ens2f0.3 \ dev ens2f0 id 3 \ master br0 \ slave-type bridge \ mtu 1500 in one command. (In reply to Thomas Haller from comment #3) > (In reply to Jiaochuandong from comment #0) > > Description of problem: > > Bridge slave interface does not up when the topo is bridge over vlan . > > > > Version-Release number of selected component (if applicable): > > 3.10.0-327.el7.x86_64 > > In this case is the kernel version not as important as the version of > NetworkManager. I assume you are using rhel-7.2, 1:1.0.6-27? > yes,I use rhel-7.2, 1:1.0.6-27. > > > Steps to Reproduce: > > 1.setup nic > > #nmcli con add type eth ifname ens2f0 con-name ens2f0 mtu 1500 > > If you only want a bridge with a vlan enslaved, you don't need this > connection. Of course, you can activate a plain ethernet connection in > ~addition~ to an (enslaved) vlan connection. But the ethernet connection > doesn't matter in this scenario. > > > #ip link set up ens2f0 > > as said, all these `ip link` commands are not correct. Can I use follow these steps when topo is team ？ #nmcli con add type team ifname team0 con-name team0 config '{"runner":{"name":"activebackup"}}' #nmcli con add type team-slave ifname ens2f0 master team0 #nmcli con add type team-slave ifname ens2f1 master team0 #ip link set team0 mtu 9000 > > > #nmcli con up ens2f0 > > 2.setup vlan > > #nmcli con add type vlan con-name ens2f0.3 dev ens2f0 id 3 mtu 1500 > > #ip link set up ens2f0.3 > > #nmcli con up ens2f0.3 > > 3.setup bridge > > #nmcli con add type bridge ifname br0 con-name br0 > > #ip link set ens2f0.3 mtu 1500 > > #nmcli con add type bridge-slave ifname ens2f0.3 master br0 > > This creates an ethernet connection which is enslaved to a bridge. That is > also not what you want. You want a vlan connection enslaved to a bridge. > > NetworkManager 1.0 (rhel-7.2) does not support `nmcli connection add type > vlan` that is a slave-type (this will be supported in 1.2/rhel-.3). > Anyway, you can fix the connection after creation. > > > I think you should do: > > > > nmcli connection add type bridge \ > ifname br0 con-name c-br0 > > nmcli connection add type vlan \ > con-name con-ens2f0.3 \ > autoconnect no \ > dev ens2f0 id 3 \ > mtu 1500 > > nmcli connection modify con-ens2f0.3 \ > connection.master br0 \ > connection.slave-type bridge \ > connection.autoconnect yes > > > > > > > > #nmcli con add type bridge-slave ifname ens2f0.3 master br0 > > #nmcli con up bridge-slave-ens2f0.3 > > Error: Connection activation failed: No suitable device found for this > > connection. > > You ask to activate an ethernet connection (as bride-slave) on ethernet > device ens2f0.3 on a bridge named br0. There exists no ethernet device > ens2f0.3 (only a vlan). Thank you very much. I know this is not a bug. I will close it. (In reply to Jiaochuandong from comment #5) > (In reply to Thomas Haller from comment #3) > > as said, all these `ip link` commands are not correct. > Can I use follow these steps when topo is team ？ > > #nmcli con add type team ifname team0 con-name team0 config > '{"runner":{"name":"activebackup"}}' > #nmcli con add type team-slave ifname ens2f0 master team0 > #nmcli con add type team-slave ifname ens2f1 master team0 Yeah, this looks right. But be aware that the command `nmcli connection add` creates a persistent configuration (that is: a "connection", or a "profile"). This is not the same as creating a team device in kernel (which is an immediate action to the kernel). Thus: nmcli connection add type team is not really the same as ip link add team0 type team Usually you only do `nmcli connection add` once, and later use `nmcli connection up` or down. Now, if you type `nmcli connection add` without "autoconnect no" argument, the created connection defaults to "autoconnect yes". Which means, if a device is available the newly created connection will be activated right away. Thereby, your command might indeed create a team device in the kernel. > #ip link set team0 mtu 9000 That is what I mean. Just creating a connection doesn't mean you also create a team device (unless autoconnect happens). Also note, that usually you would not use iproute2 to set the MTU. Configure the MTU in the connection and let NetworkManager handle it (ok, there is bug 1303968 that in some cases it migt not work). Closing BZ. (In reply to Thomas Haller from comment #3) I find br0 and ens2f0.3 auto disappear when I follow your steps. 1.nmcli con add type bridge ifname br0 con-name c-br0 2.nmcli con add type vlan con-name con-ens2f0.3 autoconnect no dev ens2f0 id 3 mtu 1500 3.nmcli con modify con-ens2f0.3 connection.master br0 connection.slave-type bridge connection.autoconnect yes #nmcli con sh NAME UUID TYPE DEVICE con-ens2f0.3 c089b393-0f2f-4929-9e88-023b1342811e vlan -- c-br0 fe6c5ae3-fc1f-4870-aee1-6984c8fdcb54 bridge br0 4.nmcli con up c-br0 5.nmcli con up con-ens2f0.3 #nmcli con sh NAME UUID TYPE DEVICE con-ens2f0.3 c089b393-0f2f-4929-9e88-023b1342811e vlan ens2f0.3 c-br0 fe6c5ae3-fc1f-4870-aee1-6984c8fdcb54 bridge br0 a few second later #nmcli con sh NAME UUID TYPE DEVICE con-ens2f0.3 c089b393-0f2f-4929-9e88-023b1342811e vlan -- c-br0 fe6c5ae3-fc1f-4870-aee1-6984c8fdcb54 bridge -- And is this a issue? Additional info: # nmcli con show con-ens2f0.3 connection.id: con-ens2f0.3 connection.uuid: c089b393-0f2f-4929-9e88-023b1342811e connection.interface-name: -- connection.type: vlan connection.autoconnect: yes connection.autoconnect-priority: 0 connection.timestamp: 1455852686 connection.read-only: no connection.permissions: connection.zone: -- connection.master: br0 connection.slave-type: bridge br0 is configured to use auto/DHCP. Does DHCP work in your setup? Configure instead a static ip address. something like: nmcli connection modify c-br0 ipv4.method static ipv4.addresses 192.168.5.2/24 Also, check the logfile journalctl -u NetworkManager |