On Tue, Sep 25, 2012 at 12:07 PM, Robert Kukura <[email protected]> wrote: > On 09/25/2012 11:23 AM, Dan Wendlandt wrote: >> On Tue, Sep 25, 2012 at 7:47 AM, Robert Kukura <[email protected]> wrote: >>> On 09/25/2012 08:32 AM, Yong Sheng Gong wrote: >>>> Hi, >>>> Yes, I am also embarrassed by it too. >>> >>> What are you embarrassed by? Is it the fact that quantum provider >>> networks cannot (easily) be used for br-ex? >>> >>>> In theory, every virtual networks in quanum will have a network bindings >>>> which is GRE, vlan, flat or local. >>>> If we don't provide --provider:network_type vlan >>>> --provider:physical_network physnet1 --provider:segmentation_id 1024 >>>> when we create virtual network, >>>> this network is a tenant network, otherwise it is a provider network. >>>> >>>> tenant network's network binding is determined by tenant_network_type. >>>> its network binding will be selected in pool of network_vlan_ranges or >>>> tunnel_id_ranges.t >>>> but the provider networks network binding is provided by user. >>> >>> The above is all correct. >>> >>>> >>>> back to external network that is used by router's gateway port and >>>> floating ips. >>>> In theory, this kind of external network should not use network binding >>>> for realization since we will have br-ex to realize them. >>> >>> I've been focusing almost exclusively on L2 during Folsom, and have not >>> had a chance yet to really understand the l3_agent and how it uses >>> br-ex. My vague understanding is that the l3_agent needs access to a >>> network with external connectivity. What's not clear to me is whether >>> this access is: >>> >>> 1) via a quantum provider network that already has external connectivity >>> >>> 2) via a bridge that has nothing to do with any quantum network >>> >>> 3) via a quantum network that the l3_agent is somehow trying to bridge >>> to an interface in order to give it external connectivity >> >> Its either #2 or #3, depending on exactly what you mean. >> >> The "internal" interfaces of routers implemented by the l3-agent are >> all plugged into quantum networks, just like the interfaces of a >> dhcp-server. These interfaces are managed by the plugin agent >> quantum-*-plugin-agent . > > Right. > >> >> The "gateway" interfaces are handled specially, being plugged into an >> "external bridge" (e.g., br-ex). The connectivity of this bridge is >> not managed by the plugin agent, it is managed manually by the >> administrator (e.g., by manually connecting eth1 to br-ex). > > The above paragraph sounds exactly like what I meant by #2. But, I now > suspect current reality is more like option #3 because there is a > corresponding quantum network. That is what had really been confusing me.
>From a data plane connectivity perspective, quantum plugs gateway interfaces into br-ex and is done with them. However, we need a network that the tenant can refer to, as well as a subnet for tracking allocations, so those items exist at a management/api layer. > >> >> I actually think provider networks are the right way to handle this. >> The reality is though, that both the l3-agent and provider networks >> were being developed at the same time and during the final cycle of >> Folsom, so making one depend on the other was too tricky. In Grizzly >> i'd like to see a model where provider networks can be used for >> gateway uplinks. In fact, this is basically the strategy for letting >> a single l3-agent take advantage of multiple upstream VLANs. > > This is my option #1, and I agree it makes sense when the plugin > supports provider networks. I guess the external bridge may still be > needed when the plugin has no support for anything like provider networks. > > It sounds like you are saying that using a provider external network > (with no special external bridge) will not work now. Is that correct? That is correct. > thought Salvatore had assured me this would work while we were both in > the midst of development. I wish I had made more of an effort to > understand the l3-agent at the time - I would have lobbied to avoid the > special handling of external networks, or at least for a way to turn it off. Yeah, given additional time in Folsom, I would actually have preferred to use provider networks completely in favor of using a static external bridge. > > It seems to me that leaving external_network_bridge unset should result > in the l3-agent just using the selected external network, with the > assumption that the external network is a properly-configured provider > network with external connectivity. Would that be doable as a quick bug > fix for Folsom? What am I missing? Based on my previous conversation with TTX, there's no chance of getting it into the initial Folsom release. He only grudgingly agreed to the two changes we talked about in yesterdays meeting and those addressed a security issue and a bug. Adding something to support additional use cases definitely wouldn't fly. If we make the patch, we can evaluate whether it is small enough to include in a later stable/folsom release, which would give us time to bake the changes (main Folsom release is confirmed as thursday). Conceptually, I agree that the change would be small, but its always good to see a diff that confirms it. > >> >> That leaves us with the question of what to do about the existing >> bindings that are created and ignored. > > This is where I had been getting confused, but I now see that the real > quantum network binding is ignored and the external bridge is used instead. > >> Originally these bindings were >> never visible via the API, but we made a decision with the provider >> stuff to show the mappings to admin users, and I think that's still >> the right thing to do. When I first read this thread I was thinking >> we could add logic to avoid populating these bindings for external >> networks. > > Was your initial idea that the plugin would check if the network being > created is external, and if so, not assign any binding for it? yes, though as I mention, I don't think its the right approach. > >> I'm personally not a huge fan of encoding such logic in. One other >> idea (not sure if this is feasible) would be to instruct admins to >> specify provider net type=local when creating the network. I think >> this would avoid a confusing allocation of a VLAN or tunnel-id, while >> still leaving us the ability in the future to make the l3-agent >> support richer provider network mappings. Bob, can you comment on >> whether this is feasible (as well as whether you think its a good >> idea). > > I don't see any problem with it, and I guess this is probably the best > option that doesn't require changing any code. At least it doesn't imply > that the external network is a real network with external connectivity. > A new "null" network_type might be better. Yes, ok, so let's make this change from a doc perspective, which will hopefully at least minimize confusion. > > -Bob > >> >> Dan >> >> >>> >>> Can someone clarify which of the above options (or others I missed) the >>> l3_agent is supposed to support for external connectivity? >>> >>>> >>>> any ideas? >>> >>> I need to understand the problem before I can contribute any ideas. >>> >>> -Bob >>> >>>> >>>> Yong Sheng Gong >>>> >>>> >>>> [email protected] wrote: >>>> ----- >>>> To: Aaron Rosen <[email protected]> >>>> From: Gary Kotton >>>> Sent by: [email protected] >>>> Date: 09/25/2012 03:56PM >>>> Cc: quantum-core <[email protected]> >>>> Subject: Re: [Quantum-core] Provider networks and br-ex bridge >>>> >>>> Hi, >>>> Sorry for the confusion. There are two networks that are created:- >>>> 1. net1 (this has the vlan tag 1024) >>>> 2. ext_net (this is the one who's tag is 1). My understanding is that I >>>> should not create a provider network here as this is specifically >>>> managed by br-ex? >>>> Am I making any sense? >>>> Thanks >>>> Gary >>>> >>>> On 09/25/2012 09:50 AM, Aaron Rosen wrote: >>>>> Sorry, what do you mean with no attributes? >>>>> >>>>> >>>>> Also you specified: --provider:segmentation_id 1024 and it returned >>>>> | provider:segmentation_id | 1 | ? >>>>> (or is that a typo?) >>>>> >>>>> Aaron >>>>> >>>>> >>>>> On Tue, Sep 25, 2012 at 3:24 AM, Gary Kotton <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>> >>>>> Hi, >>>>> I am in the process of updating the documentation for the demo >>>>> setup. I think that there is an issue with the provider networks >>>>> and the external bridge. I'll try and explain below. >>>>> >>>>> The setup is below: >>>>> >>>>> >>>>> The intention is to have an internal VLAN network ( quantum >>>>> net-create --tenant-id fbd9d50c755545a9b10228c3c4ef5d0f net1 >>>>> --provider:network_type vlan --provider:physical_network physnet1 >>>>> --provider:segmentation_id 1024 >>>>> ). >>>>> My intention was to create an external network - with no >>>>> attributes and just to add the interface to the br-ex bridge. >>>>> i.e. sudo ovs-vsctl add-br br-ex and then sudo ovs-vsctl add-port >>>>> br-ex eth2. >>>>> When I created the external network I got the following: >>>>> +---------------------------+--------------------------------------+ >>>>> | Field | Value | >>>>> +---------------------------+--------------------------------------+ >>>>> | admin_state_up | True | >>>>> | id | 96df1736-1720-407a-9cca-411895695dcb | >>>>> | name | ext_net | >>>>> | provider:network_type | vlan | >>>>> | provider:physical_network | physnet1 | >>>>> | provider:segmentation_id | 1 | >>>>> | router:external | True | >>>>> | shared | False | >>>>> | status | ACTIVE | >>>>> | subnets | | >>>>> | tenant_id | 2a215cce7a0a47d58a82f997ae5c2e28 | >>>>> +---------------------------+--------------------------------------+ >>>>> >>>>> Is this a bug? >>>>> What do you guys think? >>>>> >>>>> Thanks >>>>> Gary >>>>> >>>>> -- >>>>> Mailing list: https://launchpad.net/~quantum-core >>>>> <https://launchpad.net/%7Equantum-core> >>>>> Post to : [email protected] >>>>> <mailto:[email protected]> >>>>> Unsubscribe : https://launchpad.net/~quantum-core >>>>> <https://launchpad.net/%7Equantum-core> >>>>> More help : https://help.launchpad.net/ListHelp >>>>> >>>>> >>>> >>>> -- >>>> Mailing list: https://launchpad.net/~quantum-core >>>> <https://launchpad.net/%7Equantum-core> >>>> Post to : [email protected] >>>> Unsubscribe : https://launchpad.net/~quantum-core >>>> <https://launchpad.net/%7Equantum-core> >>>> More help : https://help.launchpad.net/ListHelp >>>> >>>> >>> >>> >>> -- >>> Mailing list: https://launchpad.net/~quantum-core >>> Post to : [email protected] >>> Unsubscribe : https://launchpad.net/~quantum-core >>> More help : https://help.launchpad.net/ListHelp >> >> >> > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dan Wendlandt Nicira, Inc: www.nicira.com twitter: danwendlandt ~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- Mailing list: https://launchpad.net/~quantum-core Post to : [email protected] Unsubscribe : https://launchpad.net/~quantum-core More help : https://help.launchpad.net/ListHelp
