From: Zoltan Kiss <zoltan.kiss@citrix.com> To: "Luis R. Rodriguez" <mcgrof@do-not-panic.com> Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>, <kvm@vger.kernel.org>, <bridge@lists.linux-foundation.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Stephen Hemminger <stephen@networkplumber.org>, <xen-devel@lists.xenproject.org> Subject: Re: [Xen-devel] [RFC v2 1/4] bridge: enable interfaces to opt out from becoming the root bridge Date: Thu, 20 Feb 2014 14:47:07 +0000 [thread overview] Message-ID: <5306156B.4070105@citrix.com> (raw) In-Reply-To: <CAB=NE6XYjOd2vRpQCZOG-S5ZW4xjam+FOPAYzribNQpb50Q5pg@mail.gmail.com> On 19/02/14 16:45, Luis R. Rodriguez wrote: > On Mon, Feb 17, 2014 at 9:52 AM, Zoltan Kiss <zoltan.kiss@citrix.com> wrote: >> On 15/02/14 02:59, Luis R. Rodriguez wrote: >>> >>> From: "Luis R. Rodriguez" <mcgrof@suse.com> >>> >>> It doesn't make sense for some interfaces to become a root bridge >>> at any point in time. One example is virtual backend interfaces >>> which rely on other entities on the bridge for actual physical >>> connectivity. They only provide virtual access. >> >> It is possible that a guest bridge together to VIF, either from the same >> Dom0 bridge or from different ones. In that case using STP on VIFs sound >> sensible to me. > > You seem to describe a case whereby it can make sense for xen-netback > interfaces to end up becoming the root port of a bridge. Can you > elaborate a little more on that as it was unclear the use case. Well, I might be wrong on that, but the scenario I was thinking: a guest (let's say domain 1) can have multiple interfaces on different Dom0 (or driver domain) bridges, let's say vif1.0 is plugged into xenbr0 and vif1.1 is in xenbr1. If the guest wants to make a bridge of this two, then using STP makes sense. I wanted to bring up CloudStack's virtual router as an example, but then I realized it's probably doesn't do such thing. However I don't think we should hardcode that a netback interface can't be RP ever. > > Additionally if such cases exist then under the current upstream > implementation one would simply need to change the MAC address in > order to enable a vif to become the root port. Stephen noted there is > a way to avoid nominating an interface for a root port through the > root block flag. We should use that instead of the MAC address hacks. > Let's keep in mind that part of the motivation for this series is to > avoid a duplicate IPv6 address left in place by use cases whereby the > MAC address of the backend vif was left static. The use case your are > explaining likely describes the more prevalent use case where address > conflicts can occur, perhaps when administrators for got to change the > backend MAC address. If we embrace a random MAC address we'd avoid > that issue, and but we'd need to update userspace to use the root > block on topologies where desired. If I understand you correctly, this is the same I suggested in my another email sent 1.5 hour ago. Zoli
WARNING: multiple messages have this Message-ID (diff)
From: Zoltan Kiss <zoltan.kiss@citrix.com> To: "Luis R. Rodriguez" <mcgrof@do-not-panic.com> Cc: kvm@vger.kernel.org, "netdev@vger.kernel.org" <netdev@vger.kernel.org>, bridge@lists.linux-foundation.org, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Stephen Hemminger <stephen@networkplumber.org>, xen-devel@lists.xenproject.org Subject: Re: [Bridge] [Xen-devel] [RFC v2 1/4] bridge: enable interfaces to opt out from becoming the root bridge Date: Thu, 20 Feb 2014 14:47:07 +0000 [thread overview] Message-ID: <5306156B.4070105@citrix.com> (raw) In-Reply-To: <CAB=NE6XYjOd2vRpQCZOG-S5ZW4xjam+FOPAYzribNQpb50Q5pg@mail.gmail.com> On 19/02/14 16:45, Luis R. Rodriguez wrote: > On Mon, Feb 17, 2014 at 9:52 AM, Zoltan Kiss <zoltan.kiss@citrix.com> wrote: >> On 15/02/14 02:59, Luis R. Rodriguez wrote: >>> >>> From: "Luis R. Rodriguez" <mcgrof@suse.com> >>> >>> It doesn't make sense for some interfaces to become a root bridge >>> at any point in time. One example is virtual backend interfaces >>> which rely on other entities on the bridge for actual physical >>> connectivity. They only provide virtual access. >> >> It is possible that a guest bridge together to VIF, either from the same >> Dom0 bridge or from different ones. In that case using STP on VIFs sound >> sensible to me. > > You seem to describe a case whereby it can make sense for xen-netback > interfaces to end up becoming the root port of a bridge. Can you > elaborate a little more on that as it was unclear the use case. Well, I might be wrong on that, but the scenario I was thinking: a guest (let's say domain 1) can have multiple interfaces on different Dom0 (or driver domain) bridges, let's say vif1.0 is plugged into xenbr0 and vif1.1 is in xenbr1. If the guest wants to make a bridge of this two, then using STP makes sense. I wanted to bring up CloudStack's virtual router as an example, but then I realized it's probably doesn't do such thing. However I don't think we should hardcode that a netback interface can't be RP ever. > > Additionally if such cases exist then under the current upstream > implementation one would simply need to change the MAC address in > order to enable a vif to become the root port. Stephen noted there is > a way to avoid nominating an interface for a root port through the > root block flag. We should use that instead of the MAC address hacks. > Let's keep in mind that part of the motivation for this series is to > avoid a duplicate IPv6 address left in place by use cases whereby the > MAC address of the backend vif was left static. The use case your are > explaining likely describes the more prevalent use case where address > conflicts can occur, perhaps when administrators for got to change the > backend MAC address. If we embrace a random MAC address we'd avoid > that issue, and but we'd need to update userspace to use the root > block on topologies where desired. If I understand you correctly, this is the same I suggested in my another email sent 1.5 hour ago. Zoli
next prev parent reply other threads:[~2014-02-20 14:47 UTC|newest] Thread overview: 156+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-02-15 2:59 [RFC v2 0/4] net: bridge / ip optimizations for virtual net backends Luis R. Rodriguez 2014-02-15 2:59 ` [RFC v2 1/4] bridge: enable interfaces to opt out from becoming the root bridge Luis R. Rodriguez 2014-02-15 2:59 ` Luis R. Rodriguez 2014-02-15 2:59 ` [Bridge] " Luis R. Rodriguez 2014-02-15 2:59 ` Luis R. Rodriguez 2014-02-16 18:56 ` Ben Hutchings 2014-02-16 18:56 ` [Bridge] " Ben Hutchings 2014-02-16 18:56 ` Ben Hutchings 2014-02-16 18:57 ` Stephen Hemminger 2014-02-16 18:57 ` Stephen Hemminger 2014-02-16 18:57 ` [Bridge] " Stephen Hemminger 2014-02-16 18:57 ` Stephen Hemminger 2014-02-18 21:02 ` Luis R. Rodriguez 2014-02-18 21:02 ` Luis R. Rodriguez 2014-02-18 21:02 ` [Bridge] " Luis R. Rodriguez 2014-02-19 9:52 ` [Xen-devel] " Ian Campbell 2014-02-19 9:52 ` [Bridge] " Ian Campbell 2014-02-19 9:52 ` Ian Campbell 2014-02-19 14:35 ` Zoltan Kiss 2014-02-19 14:35 ` [Xen-devel] " Zoltan Kiss 2014-02-19 14:35 ` [Bridge] " Zoltan Kiss 2014-02-19 17:02 ` Luis R. Rodriguez 2014-02-19 17:02 ` [Xen-devel] " Luis R. Rodriguez 2014-02-19 17:02 ` [Bridge] " Luis R. Rodriguez 2014-02-19 17:08 ` Stephen Hemminger 2014-02-19 17:08 ` [Xen-devel] " Stephen Hemminger 2014-02-19 17:08 ` [Bridge] " Stephen Hemminger 2014-02-19 17:08 ` Stephen Hemminger 2014-02-19 17:59 ` Luis R. Rodriguez 2014-02-19 17:59 ` [Xen-devel] " Luis R. Rodriguez 2014-02-19 17:59 ` [Bridge] " Luis R. Rodriguez 2014-02-19 17:59 ` Luis R. Rodriguez 2014-02-20 17:19 ` Stephen Hemminger 2014-02-20 17:19 ` [Xen-devel] " Stephen Hemminger 2014-02-20 17:19 ` [Bridge] " Stephen Hemminger 2014-02-20 17:19 ` Stephen Hemminger 2014-02-20 20:24 ` Luis R. Rodriguez 2014-02-20 20:24 ` [Xen-devel] " Luis R. Rodriguez 2014-02-20 20:24 ` [Bridge] " Luis R. Rodriguez 2014-02-20 20:24 ` Luis R. Rodriguez 2014-02-21 13:02 ` Zoltan Kiss 2014-02-21 13:02 ` [Xen-devel] " Zoltan Kiss 2014-02-21 13:02 ` [Bridge] " Zoltan Kiss 2014-02-21 16:01 ` Luis R. Rodriguez 2014-02-21 16:01 ` [Xen-devel] " Luis R. Rodriguez 2014-02-21 16:01 ` [Bridge] " Luis R. Rodriguez 2014-02-21 16:01 ` Luis R. Rodriguez 2014-02-22 1:38 ` Luis R. Rodriguez 2014-02-22 1:38 ` [Bridge] " Luis R. Rodriguez 2014-02-22 1:38 ` Luis R. Rodriguez 2014-02-22 1:38 ` Luis R. Rodriguez 2014-02-20 13:19 ` Zoltan Kiss 2014-02-20 13:19 ` [Xen-devel] " Zoltan Kiss 2014-02-20 13:19 ` [Bridge] " Zoltan Kiss 2014-02-20 20:01 ` Luis R. Rodriguez 2014-02-20 20:01 ` [Xen-devel] " Luis R. Rodriguez 2014-02-20 20:01 ` [Bridge] " Luis R. Rodriguez 2014-02-20 20:01 ` Luis R. Rodriguez 2014-02-21 13:02 ` Zoltan Kiss 2014-02-21 13:02 ` [Bridge] " Zoltan Kiss 2014-02-21 15:59 ` Luis R. Rodriguez 2014-02-21 15:59 ` [Xen-devel] " Luis R. Rodriguez 2014-02-21 15:59 ` [Bridge] " Luis R. Rodriguez 2014-02-21 15:59 ` Luis R. Rodriguez 2014-02-21 13:02 ` Zoltan Kiss 2014-02-19 9:52 ` Ian Campbell 2014-02-17 17:52 ` Zoltan Kiss 2014-02-17 17:52 ` [Xen-devel] " Zoltan Kiss 2014-02-17 17:52 ` [Bridge] " Zoltan Kiss 2014-02-19 16:45 ` Luis R. Rodriguez 2014-02-19 16:45 ` [Xen-devel] " Luis R. Rodriguez 2014-02-19 16:45 ` [Bridge] " Luis R. Rodriguez 2014-02-19 16:45 ` Luis R. Rodriguez 2014-02-20 14:47 ` Zoltan Kiss 2014-02-20 14:47 ` Zoltan Kiss [this message] 2014-02-20 14:47 ` [Bridge] [Xen-devel] " Zoltan Kiss 2014-02-20 20:28 ` Luis R. Rodriguez 2014-02-20 20:28 ` [Xen-devel] " Luis R. Rodriguez 2014-02-20 20:28 ` [Bridge] " Luis R. Rodriguez 2014-02-20 20:28 ` Luis R. Rodriguez 2014-02-15 2:59 ` [RFC v2 2/4] net: enables interface option to skip IP Luis R. Rodriguez 2014-02-15 2:59 ` Luis R. Rodriguez 2014-02-17 20:23 ` Dan Williams 2014-02-18 21:19 ` Luis R. Rodriguez 2014-02-18 21:42 ` Stephen Hemminger 2014-02-18 21:42 ` Stephen Hemminger 2014-02-19 17:13 ` Luis R. Rodriguez 2014-02-19 17:13 ` Luis R. Rodriguez 2014-02-19 16:45 ` Dan Williams 2014-02-19 16:45 ` Dan Williams 2014-02-19 17:20 ` Luis R. Rodriguez 2014-02-19 19:13 ` Zoltan Kiss 2014-02-19 19:13 ` Zoltan Kiss 2014-02-20 20:39 ` Luis R. Rodriguez 2014-02-21 13:02 ` Zoltan Kiss 2014-02-21 13:02 ` Zoltan Kiss 2014-02-22 1:40 ` Luis R. Rodriguez 2014-02-22 1:40 ` Luis R. Rodriguez 2014-02-20 20:39 ` Luis R. Rodriguez 2014-02-20 0:56 ` Dan Williams 2014-02-20 0:56 ` Dan Williams 2014-02-20 0:58 ` Hannes Frederic Sowa 2014-02-20 0:58 ` Hannes Frederic Sowa 2014-02-20 1:02 ` Dan Williams 2014-02-20 1:02 ` Dan Williams 2014-02-20 20:31 ` Luis R. Rodriguez 2014-02-20 20:31 ` Luis R. Rodriguez 2014-02-24 18:22 ` Dan Williams 2014-02-24 20:33 ` Luis R. Rodriguez 2014-02-24 20:33 ` Luis R. Rodriguez 2014-02-24 23:04 ` David Miller 2014-02-24 23:04 ` David Miller 2014-02-25 0:02 ` Ben Hutchings 2014-02-25 0:12 ` David Miller 2014-02-25 0:12 ` David Miller 2014-02-25 2:01 ` Ben Hutchings 2014-02-25 2:01 ` Ben Hutchings 2014-02-25 2:23 ` Hannes Frederic Sowa 2014-02-25 2:23 ` Hannes Frederic Sowa 2014-02-25 19:50 ` Paul Marks 2014-02-25 19:50 ` Paul Marks 2014-02-25 0:02 ` Ben Hutchings 2014-02-25 21:07 ` Dan Williams 2014-02-25 21:07 ` Dan Williams 2014-02-25 21:18 ` David Miller 2014-02-25 21:18 ` David Miller 2014-02-26 1:29 ` Hannes Frederic Sowa 2014-02-26 1:29 ` Hannes Frederic Sowa 2014-02-24 18:22 ` Dan Williams 2014-02-19 17:20 ` Luis R. Rodriguez 2014-02-18 21:19 ` Luis R. Rodriguez 2014-02-17 20:23 ` Dan Williams 2014-02-15 2:59 ` [RFC v2 3/4] xen-netback: use a random MAC address Luis R. Rodriguez 2014-02-15 2:59 ` Luis R. Rodriguez 2014-02-17 10:29 ` [Xen-devel] " David Vrabel 2014-02-18 11:22 ` Ian Campbell 2014-02-18 21:30 ` Luis R. Rodriguez 2014-02-18 21:30 ` Luis R. Rodriguez 2014-02-18 11:22 ` Ian Campbell 2014-02-17 10:29 ` David Vrabel 2014-02-15 2:59 ` [RFC v2 4/4] xen-netback: skip IPv4 and IPv6 interfaces Luis R. Rodriguez 2014-02-17 14:36 ` Zoltan Kiss 2014-02-17 14:36 ` [Xen-devel] " Zoltan Kiss 2014-02-18 20:16 ` Luis R. Rodriguez 2014-02-19 9:47 ` Ian Campbell 2014-02-19 9:47 ` Ian Campbell 2014-02-18 20:16 ` Luis R. Rodriguez 2014-02-15 2:59 ` Luis R. Rodriguez 2014-02-17 10:27 ` [Xen-devel] [RFC v2 0/4] net: bridge / ip optimizations for virtual net backends David Vrabel 2014-02-18 19:43 ` Luis R. Rodriguez 2014-02-18 19:43 ` [Xen-devel] " Luis R. Rodriguez 2014-02-19 9:48 ` Ian Campbell 2014-02-19 9:48 ` [Xen-devel] " Ian Campbell 2014-02-19 17:10 ` Luis R. Rodriguez 2014-02-19 17:10 ` [Xen-devel] " Luis R. Rodriguez 2014-02-17 10:27 ` David Vrabel
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=5306156B.4070105@citrix.com \ --to=zoltan.kiss@citrix.com \ --cc=bridge@lists.linux-foundation.org \ --cc=kvm@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mcgrof@do-not-panic.com \ --cc=netdev@vger.kernel.org \ --cc=stephen@networkplumber.org \ --cc=xen-devel@lists.xenproject.org \ /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: linkBe 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.