[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201011153055.gottyzqv4hv3qaxv@skbuf>
Date: Sun, 11 Oct 2020 18:30:55 +0300
From: Vladimir Oltean <olteanv@...il.com>
To: Kurt Kanzenbach <kurt@...utronix.de>
Cc: Andrew Lunn <andrew@...n.ch>,
Vivien Didelot <vivien.didelot@...il.com>,
Florian Fainelli <f.fainelli@...il.com>,
"David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
Rob Herring <robh+dt@...nel.org>, devicetree@...r.kernel.org,
Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
Richard Cochran <richardcochran@...il.com>,
Kamil Alkhouri <kamil.alkhouri@...offenburg.de>,
ilias.apalodimas@...aro.org
Subject: Re: [PATCH net-next v6 2/7] net: dsa: Add DSA driver for Hirschmann
Hellcreek switches
On Sun, Oct 11, 2020 at 02:29:08PM +0200, Kurt Kanzenbach wrote:
> On Tue Oct 06 2020, Vladimir Oltean wrote:
> > It would be interesting to see if you could simply turn off VLAN
> > awareness in standalone mode, and still use unique pvids per port.
>
> That doesn't work, just tested. When VLAN awareness is disabled,
> everything is switched regardless of VLAN tags and table.
That's strange, do you happen to know where things are going wrong?
I would expect:
- port VLAN awareness is disabled, so any packet is classified to the
port-based VLAN
- the port-based VLAN is a private VLAN whose membership includes only
that port, plus the CPU port
- the switch does not forward packets towards a port that is not member
of the packets' classified VLAN
When VLAN awareness is disabled, are you able to cause packet drops by
deleting the pvid of the ingress port? Therefore, can you confirm that
lan1 is not a member of lan0's pvid, but the switch still forwards the
packets to it?
> Therefore, the implementation could look like this:
>
> * bridge without filtering:
> * vlan_awareness=0
> * drop private vlans
> * bridge with vlan filtering:
> * vlan_awareness=1
> * drop private vlans
> * standalone:
> * vlan_awareness=1
> * use private vlans
> * forbid other users to use private vlans to allow
> configure_vlans_while_not_filtering behavior in .vlan_prepare()
> * forbid use of lan0.<X> and lan1.<X> in .port_prechangeupper()
>
> So, this should work, or?
Yes, this is an alternative that could work.
Powered by blists - more mailing lists