All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Fainelli <f.fainelli@gmail.com>
To: Scott Feldman <sfeldma@gmail.com>, nolan <nolan@cumulusnetworks.com>
Cc: Guenter Roeck <linux@roeck-us.net>,
	Vivien Didelot <vivien.didelot@savoirfairelinux.com>,
	Netdev <netdev@vger.kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	Andrew Lunn <andrew@lunn.ch>, Jiri Pirko <jiri@resnulli.us>,
	Jerome Oufella <jerome.oufella@savoirfairelinux.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	kernel <kernel@savoirfairelinux.com>,
	Chris Healy <cphealy@gmail.com>
Subject: Re: [RFC 3/9] net: dsa: mv88e6xxx: add support for VTU ops
Date: Wed, 03 Jun 2015 11:42:18 -0700	[thread overview]
Message-ID: <556F4A8A.60806@gmail.com> (raw)
In-Reply-To: <CAE4R7bCEqszSew4RadLoB-PcY0g74F+sLKQL42TgsfG8_89_Kg@mail.gmail.com>

On 02/06/15 23:53, Scott Feldman wrote:
> On Tue, Jun 2, 2015 at 3:31 PM, nolan <nolan@cumulusnetworks.com> wrote:
>> On 06/02/2015 12:44 AM, Scott Feldman wrote:
>>>
>>> That brings up an interesting point about having multiple bridges with
>>> the same vlan configured.  I struggled with that problem with rocker
>>> also and I don't have an answer other than "don't do that".  Or,
>>> better put, if you have multiple bridge on the same vlan, just use one
>>> bridge for that vlan.  Otherwise, I don't know how at the device level
>>> to partition the vlan between the bridges.  Maybe that's what Vivien
>>> is facing also?  I can see how this works for software-only bridges,
>>> because they should be isolated from each other and independent.  But
>>> when offloading to a device which sees VLAN XXX global across the
>>> entire switch, I don't see how we can preserve the bridge boundaries.
>>
>>
>> Scott,
>>
>> I'm confused by this.  I think you're saying this config is problematic:
>>
>> br0: eth0.100, eth1.100
>> br1: eth2.100, eth3.100
>>
>>
>> But this works fine today.
> 
> Ya, this is going to work because br0 and br1 are bridging untagged
> traffic, but br0 and br1 have different internal VLAN ids for untagged
> traffic, so there is no crosstalk between bridges.
> 
> (I'm assuming since you used the ethX.100 format, you've vconfig
> created a vlan interface on ethX and added the vlan interface to brY).
> The vlan interface eats the vlan tag and the bridge sees untagged
> traffic.
> 
>> Could you clarify the issue you're referring to?
> 
> I'm talking about bridging tagged traffic.  E.g.:
> 
> ip link add name br0 type bridge
> ip link add name br1 type bridge
> 
> ip link set dev sw1p1 master br0
> ip link set dev sw1p2 master br0
> ip link set dev sw1p3 master br1
> ip link set dev sw1p4 master br1
> 
> bridge vlan add vid 100 dev sw1p1
> bridge vlan add vid 100 dev sw1p2
> bridge vlan add vid 100 dev sw1p3
> bridge vlan add vid 100 dev sw1p4
> 
> Now the ports are trunking vlan 100 and the bridge/device see tagged
> traffic.  If the device used floods vlan 100 pkt to all ports in vlan
> 100, it'll flood to a port outside the bridge.  Oops!  For the device
> I'm using (rocker w/ OF-DPA) the bridging table matches on vlan ID and
> mac_dst.  There is no prevision to isolate vlans per bridge.
> 
> How do you solve the above case with your hardware?

For switches that support double-tagging, I suppose you could utilize
the fact that packets need to be normalized to include an internal outer
tag as well (for both tagged and untagged packets), and utilize that to
make sure there is no cross-talk. That way, you can have the same inner
VLAN tags on both of your bridges but the internal outer tag can be
different.

There might be a better solution, like having proper partitioning based
on whatever the switch is capable of?
-- 
Florian

  parent reply	other threads:[~2015-06-03 18:43 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-02  1:27 [RFC 0/9] net: dsa: mv88e6352: add 802.1q VLAN support Vivien Didelot
2015-06-02  1:27 ` [RFC 1/9] net: dsa: add basic support for switchdev obj Vivien Didelot
2015-06-02  1:27 ` [RFC 2/9] net: dsa: add basic support for VLAN operations Vivien Didelot
2015-06-02  6:52   ` Guenter Roeck
2015-06-02 14:42   ` Guenter Roeck
2015-06-03  0:45     ` Vivien Didelot
2015-06-02  1:27 ` [RFC 3/9] net: dsa: mv88e6xxx: add support for VTU ops Vivien Didelot
2015-06-02  6:50   ` Guenter Roeck
2015-06-02  7:44     ` Scott Feldman
2015-06-02 13:41       ` Guenter Roeck
2015-06-02 13:42         ` Andrew Lunn
2015-06-02 14:47           ` Guenter Roeck
2015-06-02 22:31       ` nolan
2015-06-03  6:53         ` Scott Feldman
2015-06-03 14:44           ` Guenter Roeck
2015-06-03 18:42           ` Florian Fainelli [this message]
2015-06-04 18:22           ` nolan
2015-06-03  1:39     ` Vivien Didelot
2015-06-03  2:17       ` Guenter Roeck
2015-06-03 14:56         ` Vivien Didelot
2015-06-03 15:39           ` Guenter Roeck
2015-06-02 13:05   ` Andrew Lunn
2015-06-02  1:27 ` [RFC 4/9] net: dsa: mv88e6352: add support for VLAN Vivien Didelot
2015-06-02  1:27 ` [RFC 5/9] net: dsa: mv88e6352: disable mirroring Vivien Didelot
2015-06-02 14:16   ` Guenter Roeck
2015-06-02 14:53     ` Andrew Lunn
2015-06-03  1:12       ` Vivien Didelot
2015-06-03  2:27         ` Guenter Roeck
2015-06-02  1:27 ` [RFC 6/9] net: dsa: mv88e6352: allow egress of unknown multicast Vivien Didelot
2015-06-02 14:20   ` Guenter Roeck
2015-06-03  1:52     ` Vivien Didelot
2015-06-09 22:42       ` Vivien Didelot
2015-06-02  1:27 ` [RFC 7/9] net: dsa: mv88e6352: lock CPU port from learning addresses Vivien Didelot
2015-06-02 14:24   ` Guenter Roeck
2015-06-03  1:06     ` Vivien Didelot
2015-06-03  2:24       ` Guenter Roeck
     [not found]         ` <CAFXsbZo7DAhbUErMfKas_KUtXMHTURgOxwz-GSr=fuAHLWToEQ@mail.gmail.com>
2015-06-03  4:17           ` Guenter Roeck
2015-06-03 20:51           ` Andrew Lunn
2015-06-02  1:27 ` [RFC 8/9] net: dsa: mv88e6352: set port 802.1Q mode to Secure Vivien Didelot
2015-06-02 14:31   ` Guenter Roeck
2015-06-02 23:45     ` Vivien Didelot
2015-06-02 23:28   ` Guenter Roeck
2015-06-02  1:27 ` [RFC 9/9] net: dsa: fix EDSA frame from hwaccel frame Vivien Didelot

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=556F4A8A.60806@gmail.com \
    --to=f.fainelli@gmail.com \
    --cc=andrew@lunn.ch \
    --cc=cphealy@gmail.com \
    --cc=davem@davemloft.net \
    --cc=jerome.oufella@savoirfairelinux.com \
    --cc=jiri@resnulli.us \
    --cc=kernel@savoirfairelinux.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=netdev@vger.kernel.org \
    --cc=nolan@cumulusnetworks.com \
    --cc=sfeldma@gmail.com \
    --cc=vivien.didelot@savoirfairelinux.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 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.