From: Ido Schimmel <idosch@idosch.org>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: netdev@vger.kernel.org, roopa@cumulusnetworks.com,
nikolay@cumulusnetworks.com, bridge@lists.linux-foundation.org,
jiri@mellanox.com, idosch@mellanox.com, andrew@lunn.ch,
vivien.didelot@gmail.com
Subject: Re: Correct PVID behavior with bridge's VLAN filtering on/off?
Date: Wed, 12 Dec 2018 11:02:38 +0200 [thread overview]
Message-ID: <20181212090238.GA1725@splinter.mtl.com> (raw)
In-Reply-To: <61ecaa9f-f1ba-f79e-1d8b-4ec2eba5dc11@gmail.com>
On Tue, Dec 11, 2018 at 11:48:21AM -0800, Florian Fainelli wrote:
> Hi Nikolay, Roopa, Jiri, Ido,
>
> When a bridge has vlan_filtering=0 and notifies a switch driver through
> HOST_OBJ_MDB about MC addresses that the CPU/management port is
> interested in getting MC traffic for, I am seeing that the mdb->vid is
> set to 0 because br_allowed_ingress() checks for BROPT_VLAN_ENABLED
> which is now disabled and so we never populated *vid to anything but 0
> because the caller: br_handle_frame_finish() zeroed it out.
s/br_handle_frame_finish()/br_dev_xmit()/ ? Since you're talking about
HOST_OBJ_MDB
> This creates a problem with the b53 DSA switch driver because in order
> to match the bridge's default_pvid, we did program the switch's "default
> tag" to be 1, which gets used for all untagged frames that ingress the
> switch (which AFAICT is correct behavior for PVID).
Not sure I'm following. If bridge is not VLAN-aware, then where do you
see 'default_pvid' being used?
> Despite having turned off VLAN filtering in the switch such that it does
> allow ingress of packets with a VID that is not present in the VLAN
> table (violation), Multicast addresses do behave differently and we
> really must be strictly matching the programmed PVID in order for MC
> frames to ingress the switch even with VLAN filtering turned off.
>
> So with all that being written, should the bridge still be sending MDB
> notifications and use the bridge's default_pvid even with
> vlan_filtering=0? And if we did that, what use case could we be possibly
> breaking?
>
> Let me know if this is not clear so I can provide mode details.
I think you need to provide more details about the device you're working
with. I can explain what we're doing in mlxsw for reference.
When you use a VLAN-unaware bridge w/o VLAN devices, we make sure all
untagged packets get tagged with some arbitrary VLAN (now 1, soon 4095).
You never see this VLAN on the wire, since we remove it before sending
the packets. It is only used because all packets in the ASIC must be
tagged.
After we have a VLAN we classify the packet to a FID (bridge) and it
does {FID,DMAC} lookup in the FDB (MDB).
IIUC, your problem is that you also need to tag all the packets (you
used '1', can be something else), but then you program the MDB entry
according to the VLAN passed in the notification ('0') and not use
('1'). We completely ignore the VID in this case and use the FID which
we lookup based on the ifindex of the bridge.
next prev parent reply other threads:[~2018-12-12 9:02 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-11 19:48 Correct PVID behavior with bridge's VLAN filtering on/off? Florian Fainelli
2018-12-12 9:02 ` Ido Schimmel [this message]
2018-12-12 19:52 ` Florian Fainelli
2018-12-16 7:20 ` Ido Schimmel
2018-12-15 18:10 ` Florian Fainelli
2018-12-16 7:55 ` Ido Schimmel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181212090238.GA1725@splinter.mtl.com \
--to=idosch@idosch.org \
--cc=andrew@lunn.ch \
--cc=bridge@lists.linux-foundation.org \
--cc=f.fainelli@gmail.com \
--cc=idosch@mellanox.com \
--cc=jiri@mellanox.com \
--cc=netdev@vger.kernel.org \
--cc=nikolay@cumulusnetworks.com \
--cc=roopa@cumulusnetworks.com \
--cc=vivien.didelot@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).