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 . 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). 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. That leaves us with the question of what to do about the existing bindings that are created and ignored. 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. However, this would prevent using provider mappings for external networks in the future. 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. 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). 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
