linux-kernel - Re: [PATCH net-next] bridge: Make the FDB consider inner tag for Q-in-Q

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20241202100635.hkowskequgsrqqkf@skbuf>
Date: Mon, 2 Dec 2024 12:06:35 +0200
From: Vladimir Oltean <vladimir.oltean@....com>
To: Andrew Strohman <andrew@...rewstrohman.com>
Cc: Nikolay Aleksandrov <razor@...ckwall.org>,
	Tony Nguyen <anthony.l.nguyen@...el.com>,
	Przemek Kitszel <przemyslaw.kitszel@...el.com>,
	Andrew Lunn <andrew+netdev@...n.ch>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Ido Schimmel <idosch@...dia.com>, Petr Machata <petrm@...dia.com>,
	Claudiu Manoil <claudiu.manoil@....com>,
	Alexandre Belloni <alexandre.belloni@...tlin.com>,
	UNGLinuxDriver@...rochip.com, Shahed Shaikh <shshaikh@...vell.com>,
	Manish Chopra <manishc@...vell.com>, GR-Linux-NIC-Dev@...vell.com,
	Simon Horman <horms@...nel.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Masami Hiramatsu <mhiramat@...nel.org>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	Roopa Prabhu <roopa@...dia.com>, intel-wired-lan@...ts.osuosl.org,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-trace-kernel@...r.kernel.org, bridge@...ts.linux.dev
Subject: Re: [PATCH net-next] bridge: Make the FDB consider inner tag for
 Q-in-Q

On Sat, Nov 30, 2024 at 02:28:34PM -0800, Andrew Strohman wrote:
> My personal use case is about simulating ethernet connections and VLAN aware
> bridges, so that I can test networking equipment that provides VLAN
> functionality with IVL.
> https://github.com/andrewstrohman/topology-sim/raw/refs/heads/main/docs/Topology%20Simulation%20for%20Mesh%20Testing.pdf?download=
> describes it, if you're interested in more information about it.
> 
> https://docs.google.com/drawings/d/1FybJP3UyCPxVQRGxAqGztO4Qc5mgXclV4m-QEyfUFQ8
> is a diagram that shows what I'm thinking about. This case is not about
> duplicate macs, but rather a frame being bridged in a way, such that it passes
> through the same bridge twice via different ports depending on the inner
> VLAN. In the commit message, this is what I meant by the poorly worded:
> "L2 hairpining where different VLANs are used for each side of the hairpin".
> 
> The diagram depicts a network where a layer 2 segment is partitioned by a
> L2 (bridging) firewall. I admit that this is contrived and not a typical
> way of constructing networks.
> 
> In this case, my testing system would use a 802.1ad bridge to simulate a
> VLAN aware bridge between .1q #1 and .1q #2. The problem is that the .1ad
> bridge would get confused about which ports hosts A and B are behind.
> The bridge would see them behind different ports depending on whether the
> packet was heading to, or returning from the bridge mode firewall.
> 
> If these nodes were connected with an IVL .1q bridge instead of the .1ad
> bridge, this topology would work. So it's a scenario where connectivity
> failure would be due to my testing system (topology-sim) instead of the
> networking equipment being tested.

What stops you from changing the 802.1ad bridge port pvids to unique
values, like 3, 4, 5... instead of 3, 3, 3, and making each other
j != i bridge port be a non-pvid member of port i's pvid?

That would keep the MAC address isolation per 802.1ad bridge port, and
would offer the same level of communication using 100% standard and
available tools.