bridge: transparently add and remove VLAN tags
AcceptedPublic
Actions

Authored by ivy on Fri, May 23, 9:40 PM.

Details

Reviewers

des
kevans
kp

Group Reviewers

network
manpages

Summary

When an untagged frame is received on a port with a pvid configured,
set the frame's tag to the pvid.

When a tagged frame is transmitted on a port with a pvid configured,
and the pvid matches the frame's tag, strip the tag.

This allows ports on the same vlan to communicate when one port is
expecting tagged frames and the other is expecting untagged frames,
e.g. when bridging an access port to a trunk port.

Since we now set the VLAN ID in the mbuf, remove the vlan argument to
bridge_forward() and bridge_broadcast() and take it from VLANTAGOF
instead.

Remove the existing pvid_tagged tests, which no longer make sense
because a port can't receive tagged frames on its pvid anymore.
Replace them with a test for the new (de)tagging functionality.

Diff Detail

Repository

rG FreeBSD src repository

Lint

Lint Skipped

Unit

Tests Skipped

Build Status

Buildable 64395
Build 61279: arc lint + arc unit

Event Timeline

ivy created this revision.Fri, May 23, 9:40 PM

Herald added subscribers: ziaee, glebius, melifaro and 2 others. · View Herald TranscriptFri, May 23, 9:40 PM

ivy requested review of this revision.Fri, May 23, 9:40 PM

Harbormaster completed remote builds in B64395: Diff 155947.Fri, May 23, 9:40 PM

ivy added a parent revision: D49993: bridge(4): allow member interface vlan to be configured.Fri, May 23, 9:40 PM

ivy added a child revision: D50503: bridge: add vlan filtering support.Fri, May 23, 11:56 PM

I didn't see this review, and I think what I asked in D49993 belongs here.
So I would write my note here again:

I don't have access to the recent revisions of IEEE-802.1Q. However, based on observations in newer network devices, we should not accept received tagged packets on access ports, even if they have the same VLAN ID as our interface. All packets received on those interfaces should be untagged.

Even if we want to accept those, we should tag the packet on top of the existing packet. Why? 802.1Q tunneling (Q-in-Q) scenarios.

For consistency with other network devices, there should be an option to drop tagged packets on an access port or only tag on top of it.

p.mousavizadeh_protonmail.com mentioned this in D49993: bridge(4): allow member interface vlan to be configured.Sat, May 24, 9:26 AM

This looks good, but I'd like us to land the entire series at once, so we don't keep tweaking the bridge/vlan behaviour.

share/man/man4/bridge.4
279	'learned'. I had to look it up too, but apparently 'learnt' is the British variant, 'learned' the American one. We default to American English for better or worse.

In D50500#1153457, @kp wrote:

This looks good, but I'd like us to land the entire series at once, so we don't keep tweaking the bridge/vlan behaviour.

yep, i was intending to do that anyway since the changes don't really make sense individually.

guest-patmaddox added a subscriber: guest-patmaddox.Tue, May 27, 3:51 PM

update for new vlan filtering behaviour

Harbormaster completed remote builds in B64492: Diff 156156.Wed, May 28, 9:30 AM

ivy marked an inline comment as done.Wed, May 28, 9:37 AM

ivy added inline comments.