On 9/9/2020 10:53 AM, Vladimir Oltean wrote:
On Wed, Sep 09, 2020 at 10:22:42AM -0700, Florian Fainelli wrote:
How do you make sure that the CPU port sees the frame untagged which would
be necessary for a VLAN-unaware bridge? Do you have a special remapping
rule?
No, I don't have any remapping rules that would be relevant here.
Why would the frames need to be necessarily untagged for a VLAN-unaware
bridge, why is it a problem if they aren't?
bool br_allowed_ingress(const struct net_bridge *br,
struct net_bridge_vlan_group *vg, struct sk_buff *skb,
u16 *vid, u8 *state)
{
/* If VLAN filtering is disabled on the bridge, all packets are
* permitted.
*/
if (!br_opt_get(br, BROPT_VLAN_ENABLED)) {
BR_INPUT_SKB_CB(skb)->vlan_filtered = false;
return true;
}
return __allowed_ingress(br, vg, skb, vid, state);
}
If I have a VLAN on a bridged switch port where the bridge is not
filtering, I have an 8021q upper of the bridge with that VLAN ID.
Yes that is the key right there, you need an 8021q upper to pop the VLAN
ID or push it, that is another thing that users need to be aware of
which is a bit awkward, most expect things to just work. Maybe we should
just refuse to have bridge devices that are not VLAN-aware, because this
is just too cumbersome to deal with.
Initially the concern I had was with the use case described above which was
a 802.1Q separation, but in hindsight MAC address learning would result in
the frames going to the appropriate ports/VLANs anyway.
If by "separation" you mean "limiting the forwarding domain", the switch
keeps the same VLAN associated with the frame internally, regardless of
whether it's egress-tagged or not.
True, so I am not sure what I was thinking back then.
Tangentially, maybe we should finally add support for programming the CPU
port's VLAN membership independently from the other ports.
How?
Something like this:
https://lore.kernel.org/lkml/20180625091713.GA13442@apalos/T/
I need to take some time to understand what's going on there.
--
Florian
