Bjoern A. Zeeb: > Now there are use cases that duing the liftime of a boot I need to add > a bridge interface to a vlanN + fanout: > physical interface > +--- vlan1 --- bridge0 ---++++ other interface[s] > +--- vlan2 > +--- vlan3 --- bridge1 ---++++ other interface[s] > > And that's where things obviously went south after the member_ifaddrs > sysctl changed (which I had missed).
member_ifaddrs should have no impact on this configuration; nothing has
changed about putting vlan(4) interfaces in a bridge.
the only thing that was briefly broken was putting a vlan(4) in a bridge
*and* putting the vlan's underlying network interface in another bridge.
that has never worked properly, but was (accidentally) broken entirely
by member_ifaddrs, but that was fixed ages ago.
also, note that vlan filtering is orthogonal to member_ifaddrs. you can
use both, or neither, or one without the other.
> (d) bridge.4 "VLAN SUPPORT" says:
> ""
> Traffic sent to or from the host is not assigned to a VLAN by default.
> To allow the host to communicate on a VLAN, configure a vlan(4) interface
> on the bridge and (if necessary) assign IP addresses there.
> ""
>
> Question: which VLAN do the addresses on the bridge interface belong
> to now?
addresses assigned to the bridge itself have always been in "VLAN 0" and
this hasn't changed with VLAN filtering. this is not very useful since
"VLAN 0" doesn't really exist and this traffic can't be tagged on the
wire, so in a VLAN filtering setup, you would want to avoid assigning
addresses to the bridge itself.
when VLAN filtering is disabled, this works because untagged traffic on
member interfaces is also on VLAN 0 (so the bridge acts like a non-VLAN
bridge, except that it still implements IVL), but with filtering enabled,
there is never any traffic on VLAN 0.
again, to be clear: nothing has changed here in the non-filtering case,
this is how bridge always worked.
> If I do (unrelated to my setup, just in general):
> ifconfig bridge0 inet6 auto_linklocal -ifdisabled up
> ping -n ff02::1%bridge0
> where do the packets go?
if you don't enable VLAN filtering, nothing has changed here. if you
enable VLAN filtering, then filtering ports will drop this traffic:
because it doesn't have a VLAN attached it is impossible to filter or
forward in a useful way.
note that i plan to remove the idea of 'filtering ports' and just make
filtering a per-bridge flag (D51228) but this hasn't landed yet. in the
mean time, if you have unfiltered ports on the bridge, the multicast
traffic will continue to be forwarded via those ports as before.
> Or in yet another way, how do you set the untagged vlan-id for the
> bridge interface itself?
you cannot do that, you should use the SVI interface instead (i.e., a
vlan on top of a bridge). i won't add this feature because it's not
necessary. in a VLAN filtering setup, it doesn't make sense to have
traffic which isn't assigned to a VLAN.
> (d.1)
> Untagged on one member interface could now with filtering be vlan-id
> 123 and on another member interface it could be vlan-id 666.
> Is that handled correctly on igress->bridge-IPs->egress?
consider the following setup:
ifconfig bridge0 create vlanfilter \
addm ix0 untagged ix0 123 \
addm ix1 untagged ix1 666
in this case, all untagged traffic entering on ix0 is assigned to VLAN
123, and all untagged traffic entering on ix1 is assigned to VLAN 666.
to communicate with hosts in those VLANs, you would create interfaces
bridge0.123 or bridge0.666. there is no need to assign any IP addresses
to the bridge itself since there is no untagged traffic.
if you are asking about "tag mapping", i.e. you want traffic on ix0 on
VLAN 123 to be mapped to VLAN 666 on ix1, this is not currently
supported and you should continue to use vlan(4) in a bridge for this
unusual configuration. i would like to add support for this, but it
definitely won't be in 15.0.
> (e) Something no one seems to have thought of was how this all aligns
> with etherswitch?
i would like bridge to be able to program etherswitch automatically so
that it automatically offloads whatever functionality the hardware is
capable of. but this is a "would be nice in the future maybe" thing,
i haven't even started to think about how it would work.
that said, based on my understanding of how typical switch chips are
programmed, the VLAN filtering bridge is conceptually closer to how
the underlying hardware works than the vlan(4)-in-a-bridge style of
bridge. (this is different to how most network cards are programmed,
which is closer to the vlan-in-a-bridge setup.)
> (f) bridge.4 says
> ""
> Attempting to assign an IP address to a bridge member
> interface, or add a member interface with an assigned IP address to a
> bridge, will return an EINVAL ("Invalid argument") error.
> ""
>
> Is this a distinct error for the addm case?
yes.
> If we can poinpoint it to that problem (along with the sysctl value), we
> should really give the user a better error message.
i have already exterrorized bridge (D51181) and it's ready to land, i
just didn't get around to it yet - depending on how a couple of other
things go i might do that today.
signature.asc
Description: PGP signature
