[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <7c046a25-1f84-5dc6-02ad-63cb70fbe0ec@arinc9.com>
Date: Sun, 13 Mar 2022 14:23:47 +0300
From: Arınç ÜNAL <arinc.unal@...nc9.com>
To: Jakub Kicinski <kuba@...nel.org>,
Florian Fainelli <f.fainelli@...il.com>,
Vladimir Oltean <olteanv@...il.com>,
Alvin Šipraga <ALSI@...g-olufsen.dk>,
Linus Walleij <linus.walleij@...aro.org>,
Andrew Lunn <andrew@...n.ch>,
Luiz Angelo Daros de Luca <luizluca@...il.com>,
DENG Qingfang <dqfext@...il.com>, erkin.bozoglu@...ont.com
Cc: "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Isolating DSA Slave Interfaces on a Bridge with Bridge Offloading
Hi all,
The company I work with has got a product with a Mediatek MT7530 switch.
They want to offer isolation for the switch ports on a bridge. I have
run a test on a slightly modified 5.17-rc1 kernel. These commands below
should prevent communication between the two interfaces:
bridge link set dev sw0p4 isolated on
bridge link set dev sw0p3 isolated on
However, computers connected to each of these ports can still
communicate with each other. Bridge TX forwarding offload is implemented
on the MT7530 DSA driver.
What I understand is isolation works on the software and because of the
bridge offloading feature, the frames never reach the CPU where we can
block it.
Two solutions I can think of:
- Disable bridge offloading when isolation is enabled on a DSA slave
interface. Not the best solution but seems easy to implement.
- When isolation is enabled on a DSA slave interface, do not mirror the
related FDB entries to the switch hardware so we can keep the bridge
offloading feature for other ports.
I suppose this could only be achieved on switch specific DSA drivers so
the implementation would differ by each driver.
Cheers.
Arınç
Powered by blists - more mailing lists