All of lore.kernel.org
 help / color / mirror / Atom feed
* Confusion about (new?) bridge behavior
@ 2018-05-25 23:49 Florian Fainelli
  0 siblings, 0 replies; only message in thread
From: Florian Fainelli @ 2018-05-25 23:49 UTC (permalink / raw)
  To: netdev, nikolay, arkadis, ivecera, jiri; +Cc: vivien.didelot, andrew

Hi,

The DSA b53 driver currently (well, not quite currently, but at some
point) was forcing the CPU port VLAN membership to be tagged. The reason
for that is mostly because if we allow the CPU port to be untagged in
multiple VLANs we can't quite properly separate traffic at the CPU port
level, so we don't do that.

At some point v4.12, or maybe as far back as 4.9, I remember the
following from happening:

- it was not necessary to turn on vlan_filtering on the bridge to get
the DSA layer to program VLAN entries into the switch, I only get those
calls now if vlan_filtering is enabled, this is not a big issue, but I
do wonder if something did change here? Could be a DSA specific issue
here, I can bisect that later

- because the CPU port was configured tagged into VLAN 1, it was
necessary to either change the default bridge master device settings
(default being VID 1 pvid untagged) to pop the VLAN tag, and conversely
push the VLAN tag on egress path and/or create a network device such
that would be responsible for terminating the VLAN tag, e.g: br0.1

But now, this does not seem to be necessary and I just can't explain
why, it might very well be a switch driver configuration issue.

Now what I am seeing is the following:

1) Default configuration with vlan_filtering = 1

# bridge vlan show
port    vlan ids
gphy     1 PVID Egress Untagged

br0      1 PVID Egress Untagged

If I look at the CPU port, I can see that frames from switch to CPU have
VLAN tag 1, which is expected, yet frames that are from CPU to switch do
not have such a VLAN tag 1, and yet things work okay, dhcp + ping using
br0 work just fine. I suppose that is because of the pvid behavior which
assigns untagged frames to the default VLAN which happens to be 1 in
that case.

2) Changing the bridge to be in VLAN 1 no pvid, no untagged, still with
vlan_filtering = 1

# bridge vlan add vid 1 dev br0 self
# bridge vlan show
port    vlan ids
gphy     1 PVID Egress Untagged

br0      1

The frames from switch to CPU still have VLAN tag 1, now I need to
create a br0.1 device to insert the VLAN tag for dhcp + ping to work
using br0.1 in that case, though I still do not see the VLAN tag being
present for frames that are from CPU to switch...

Was I hallucinating before and things were equally broken, or did
something change recently?

Thank you!
-- 
Florian

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2018-05-25 23:49 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-05-25 23:49 Confusion about (new?) bridge behavior Florian Fainelli

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.