Bjoern A. Zeeb: > Am I correct that if I do want to leave the untagged packets of a trunk > connected to the bridge "untagged" I would still be able to configure > the host IP on bridge0 without any need for "untagged" if no vlanfilter > is in place?
if you aren't using 'vlanfilter', then you can't use 'untagged' at all
and all packets retain the vlan they entered the system with (which is
0 for untagged packets). in that case you would need to assign IP
addresses to the bridge itself to access "vlan 0".
if you do that, you can still create vlan interfaces on the bridge --
this isn't really how i intended that to be used but there seemed to be
no reason to prohibit it. this might be useful in some existing setups
where the only way to access the non-zero VLAN is to put an epair in the
bridge then create a vlan on that.
however be aware that in this configuration any port can send traffic on
any vlan, so this isn't very secure.
> But the moment vlanfilter is in place these untagged packets would be
> dropped and I will always need a spare VLAN ID to sacrifice (even though
> only internally to that bridge and not visible outside -- unless that
> pvid matches the vlan ID on a differnt trunk connected to the bridge)
> and need to use the 'untagged' keyword? Or is it still possible to
> directly configure the Host IP on bridge0 and leave untagged packets
> as such?
with vlanfilter, *all* packets have a (non-zero) VLAN; if you don't
configure 'untagged' on an interface, that means this interface should
not be permitted to send/receive untagged frames, so all untagged
incoming traffic will be dropped.
so yes, to receive untagged frames in that case, you must use 'untagged'
to assign them to a VLAN.
i'm not i would describe that as "sacrificing" a vlan id though, it's
more that you're simply creating N different VLANs to segment your
traffic into, and assigning VLAN IDs 1..N (or whatever) to those VLANs.
the fact that one of those VLANs is untagged on some (or all) ports is
just incidental. it's true that with the old bridge you get VLAN 0
"for free", but with 4094 [0] VLAN IDs you're not likely to run out [1].
incidentally, if the device on the other side of your trunk port (dwc0)
is 802.1Q-aware, i would always suggest tagging all traffic and never
mixing tagged and untagged traffic on the same port. however i
appreciate this isn't possible in some situations, like network boot.
[0] or 4093 if you avoid vlan 1, which is often a good idea because some
network gear treats vlan 1 as special. in that case you might also
avoid vlan 2 since that's slightly special in 802.1Q. i usually
start at 100 to avoid all that.
[1] if you do run out, you need vxlan instead, which isn't directly
supported by bridge yet... something that may or may not change
in the future.
signature.asc
Description: PGP signature
