Bug 198297
| Summary: | Unable to add ethX to bridge if ethX.<VLAN_ID> is already present in this bridge | ||
|---|---|---|---|
| Product: | Networking | Reporter: | Alexander (alexander_cheremshinsky) |
| Component: | Other | Assignee: | Stephen Hemminger (stephen) |
| Status: | NEW --- | ||
| Severity: | normal | CC: | annawhuggins, grzegorz.halat, jille |
| Priority: | P1 | ||
| Hardware: | ARM | ||
| OS: | Linux | ||
| Kernel Version: | 4.14.2 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
Even if it is surprising, this isn't going to ever work. Not sure I understood your answer correctly.
If you mean that this bridge with only two interfaces won't work then you are right but this is not full bridge configuration there are a few more interfaces (i.e. eth1 and eth3) I just reduce them as their availability does not effect behavior. So the real bridge configuration look like:
# brctl show
bridge name bridge id STP enabled interfaces
br 8000.0024a407481a no eth1
eth2
eth3
eth2.10
If you mean something else then could you, please, explain "this isn't going to ever work"?
Hi,
the same problem exists when you try to attach vlan and parent device to VRF:
# ip link add vrf-1 type vrf table 1
# ip link add type veth
# ip link add link veth0 veth0.1 type vlan id 1
parent dev first:
# ip link set veth0 vrf vrf-1
# ip link set veth0.1 vrf vrf-1
# ip link show vrf vrf-1
21: veth0@veth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master vrf-1 state LOWERLAYERDOWN mode DEFAULT group default qlen 1000
link/ether 76:8b:79:a0:cb:55 brd ff:ff:ff:ff:ff:ff
23: veth0.1@veth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master vrf-1 state LOWERLAYERDOWN mode DEFAULT group default qlen 1000
link/ether 76:8b:79:a0:cb:55 brd ff:ff:ff:ff:ff:ff
VLAN dev first:
# ip link set veth0.1 vrf vrf-1
# ip link set veth0 vrf vrf-1
RTNETLINK answers: File exists
# ip link show vrf vrf-1
27: veth0.1@veth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master vrf-1 state LOWERLAYERDOWN mode DEFAULT group default qlen 1000
link/ether f6:69:e5:bd:c8:9f brd ff:ff:ff:ff:ff:ff
It also fails in function __netdev_upper_dev_link
The first commit which introduced this behavior is
[5d261913ca3daf6c2d21d38924235667b3d07c40] net: add lower_dev_list to net_device and make a full mesh
I have the same problem. One data point: this used to work and I think it's a valid use case. I'm using it to bridge vlan3 to untagged (vlan1) at eth0 so I can iptables/tcpdump traffic going between the vlans on this server. The bug report on Kernel.org is an issue where adding a physical Ethernet interface (ethX) to a bridge will fail if a VLAN interface (ethX.<VLAN_ID>) is already present on that bridge. This issue poses a challenge for users trying to configure a network http://www.ralinktech.com/ralink/Home/Backing/Linux.html https://geometrydash-scratch.com bridge with a VLAN because it conflicts with the intended network |
Kernel fails adding ethX to bridge if ethX.<VLAN_ID> is already present in this bridge. Steps to reproduce: # vconfig add eth2 10 # brctl addbr br # brctl addif br eth2.10 # brctl show bridge name bridge id STP enabled interfaces br 8000.0024a407481a no eth2.10 # brctl addif br eth2 can't add eth2 to bridge br: File exists # brctl show bridge name bridge id STP enabled interfaces br 8000.0024a407481a no eth2.10 But it is ok if ethX is added before ethX.<VLAN_ID> Steps to reproduce: # brctl delif br eth2.10 # brctl addif br eth2 # brctl addif br eth2.10 # brctl show bridge name bridge id STP enabled interfaces br 8000.0024a407481a no eth2 eth2.10 So the result is depending on order of interface addition, that does not looks logical as for me. This works good at least in kernel 3.10.70. From my investigation it fails in function __netdev_upper_dev_link (net/core/dev.c) on lines: if (netdev_has_upper_dev(dev, upper_dev)) return -EEXIST; I checked source code of kernel 4.14.8 but it looks the same and I think it also has this issue. I'm not so good with linux kernel to fix this by myself so it would be very nice to get a patch with fix for this issue or explanation why such behavior is correct. Thanks in advance, Alex.