Vladimir B. Grebenschikov: > % ifconfig ix0 description "trunked uplink" > % ifconfig ix1 description "another trunked link" > % ifconfig bridge0 create addm ix0 ix1 > % ifconfig bridge0.100 create description "Host interface here" > > so far everything fine - normal usage, bridge handels trunked traffic > > now I wish to have a number of jails attached to VLAN 101, so I will: > > % ifconfig bridge0.101 create up description "unwrap VLAN 101"
this is fine, but an interface of this type should only be used for
routed traffic, i.e. for the host itself to communicate on the network.
so you would not attach VMs/jails to this interface.
>[...]
> what cbsd (just another jail management software) will do underneath?
> something like:
>
> % ifconfig bridge1 addm bridge0.101 addm epair0a addm epair1a addm epair2a
you can not put bridge0.101 interface into another bridge. previously
this would panic, since Monday (or so) it's rather disallowed.
what you want to do is this:
ifconfig epair0 create
ifconfig epair1 create
ifconfig epair2 create
ifconfig bridge0 create vlanfilter \
addm epair0a untagged epair0a 101 \
addm epair1a untagged epair1a 101 \
addm epair2a untagged epair2a 101
now put the other ends of the epairs (epair0b, ...) into your vnet
jails, and the jails will be connected to VLAN 101 on the bridge.
if the host will be the router for the jails, then configure the IP
address on bridge0.101 and jails will be able to reach this via L2.
i cannot say how CBSD would/should handle this, but i expect jail/vm
management tools should be modified to support the new behaviour.
however, if your management software simply does "addm epairX",
then there is a way to cheat here:
ifconfig bridge0 create vlanfilter defuntagged 101
now, every interface you add to the bridge gets "untagged 101"
automatically unless you specify something else.
(NB: this functionality is not available until D51600 lands, but as i
said in my other mail, hopefully that's very soon.)
> But on the other hand, having something that in the real world can be
> represented as a dumb switch with no VLAN support (and no way to
> misconfigure it) to connect a room of PCs, where all unwrapping and
> ACLs are configured once on the smart switch port where the dumb
> switch is plugged in – also makes sense.
the problem is, if you want a bridge and a vlan(4) on the same
interface, the bridge can't just be a dumb switch because it needs to
know whether tagged frames should be sent to vlan(4) or handled by the
bridge itself, so it always needs at least some awareness of the
existence of vlans.
if you want a bridge that doesn't know *anything* about VLANs,
unfortunately this has not existed since 2007 when VLAN support was
first added to bridge(4). you might find ng_bridge can do this,
i don't know much about that.
signature.asc
Description: PGP signature
