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. > > 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? I 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. 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? > > 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? > However, this would prevent using provider mappings for > external networks in the future. Right. > Another option would be to say that > external networks only get a mapping if one is explicitly configured > (i.e., a provider net) but if none is configured, it gets no mapping. That doesn't really help unless the explicitly configured binding is what gets used by the l3-agent. > 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. But again, I think the best option is fix the l3-agent so real provider networks can be used as external networks when external_network_bridge is not set. -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 > > > -- Mailing list: https://launchpad.net/~quantum-core Post to : [email protected] Unsubscribe : https://launchpad.net/~quantum-core More help : https://help.launchpad.net/ListHelp
