I assigned the IP address 192.168.1.1 to eth0
That's where this setup went wrong. eth0
has been set as a bridge member interface (layer 2) and therefore should not have any IP (layer 3) address.
(You probably ended with a sort of broken configuration involving two direct routes both to 192.168.1.0/24) via 2 different interfaces, only one of which worked. But the exact details of the incorrect setup don't really matter.)
Why is that?
I expected eth0 to send an ARP request into all Ethernet segments it's part of. This is the physical one, but also the one defined by br0.
eth0 won't send any ARP. It's no longer a layer 3 interface once it's part of a bridge.
- The (layer 2) ports on this bridge are
eth0
,
tap0
, and
- the bridge itself.
- The (layer 3) participants on this bridge are (in the same order)
- All of the devices that can be reached through
eth0
(most likely: a bunch of other devices on your local network)
- Whatever is at the other and of
tap0
(which is likely one thing)
- The
br0
interface
When using the bridge vlan
command, you can add (or delete) a range of VLAN IDs in a single shot. For example:
# bridge vlan add vid 2-4094 dev eth0
will add all available VLANs to the trunk interface eth0 (0 and 4095 are reserved in the protocol and must not (nor can) be used, 1 is by default set as PVID untagged VLAN ID, so should be avoided or perhaps better, removed).
# bridge vlan show dev eth0
eth0 1 PVID Egress Untagged
2
3
[...]
4093
4094
# bridge -c vlan show dev eth0
port vlan ids
eth0 1 PVID Egress Untagged
2-4094
Here -c
stands for -c[ompressvlans]
rather than -c[olor]
: the bridge man page (at least up to iproute2-ss191125) completely lacks information about this option.
Deleting a range works as one could expect:
# bridge vlan del vid 100-200 dev eth0
# bridge -c vlan show
port vlan ids
bridge0 1 PVID Egress Untagged
eth1 1 Egress Untagged
10 PVID Egress Untagged
eth0 1 PVID Egress Untagged
2-99
201-4094
Internally all are handled using a (hashed) list of individual VLANs.
Note 1
Cumulus Networks (known to mostly use Linux' native network stack on their network equipments) has some old (and newer) examples about this:
Consider the following example bridge:
auto bridge
iface bridge
bridge-vlan-aware yes
bridge-ports swp1 swp9
bridge-vids 2-100
bridge-pvid 101
bridge-stp on
Here is the VLAN membership for that configuration:
cumulus@switch$ bridge -c vlan show
portvlan ids
swp1 101 PVID Egress Untagged
2-100
swp9 101 PVID Egress Untagged
2-100
bridge 101
The configuration file used is the interfaces file from ifupdown2 (and its addons), actually developed by Cumulus Networks to replace ifupdown, with a mostly compatible syntax, but much improved bridge and VLAN support.
Note 2
I didn't find any evidence of some special flag automatically flooding all VLANs to a bridge port. This kernel commit tells VID 4095 is documented in IEEE 802.1Q to have restrictions but allowed to be used for management operations as a wildcard match for the VID, but Linux doesn't seem to use such method.
Best Answer
Yes: you can set the bridge to be VLAN aware.
The bridge will then handle VLAN IDs attached to frames crossing it, including tagging and untagging them according to configuration, and will send a frame belonging to a given VLAN only to ports configured to accept it. This moves all the settings to the bridge itself rather than having to use VLAN sub interfaces (those sub interfaces can still be used in some settings of course).
This feature is not available through the obsolete
brctl
command, but requires the newer replacementbridge
command (along with the usualip link
command). It is a simpler setup (one bridge, no sub-interface).The method is to configure
tap1
as a tagged bridge port with VLAN ID (VID) 5, andeth0
also with VID 5, but set as untagged: output gets untagged, and with this VID as PVID (Port VLAN ID): input gets tagged with it inside the bridge. There can be only one PVID per port.At the same time optionally remove VLAN ID of 1 assigned by default to each port (unless a more complex setup would require multiple VLANs of course) to keep a clean configuration.
your setup, so far, with newer commands only should look like this:
The specific VLAN aware bridge settings, starting by activating the feature:
Note that the bridge's self implicit port is still using VID 1, so assigning an IP directly on the bridge as is done on some settings will now fail to communicate properly. If such configuration is really needed, you can set the bridge's self port in VLAN 5 too, with a slightly different syntax (
self
) because it's the bridge itself:It's usually cleaner to (still delete the default VID 1 of the bridge to prevent it from any possible interaction,) add a veth pair, plug one end on the bridge, configure its bridge vlan settings the same as
eth0
and assign an IP on the other end.Good blog series on this topic: