[rhos-list] Quantum Query:

[Shixiong Shang (shshang)]

Hi, Bob:

Thank you very much for the further clarification!

I tried both approach tonight and noticed that when "external_network_bridge" is unset, L3_agent failed to start due to the fact that I was using "br-eth3" for both tenant network and external network. L3 kept looking for "br-ex" and it didn't exist at all (br-eth3 and br-int are the only bridges).

That being said, if we try to create more than one external networks, they all must point to br-ex. If this is the case, then the only way to realize multiple external networks is to use VLAN tagging on br-ex to separate the traffic. Is my observation correct?

Thanks again!

Shixiong




On Jun 21, 2013, at 2:39 PM, Robert Kukura <rkukura at redhat.com<mailto:rkukura at redhat.com>> wrote:

On 06/21/2013 02:17 PM, Shixiong Shang (shshang) wrote:
Hi, Bob:

Thanks a ton for the reply (even I didn't raise the original question).
It is very informational and educational. I read it many many times and
it helps me clarify some confusion as you rightly pointed out. But I
still have some questions and would like to make sure I precisely
understand what you mean here.

1) In my current setup, I created external network net_ext, but later on
I realized that router cannot ping its default gateway. I have to
manually set the tag for qg- port on br-eth3 (mapped to physnet3) to 311
in order to make the ping happen. Based on your explanation, is it
because provider attributes in "quantum net-create" command are ignored
by L3 agent, so no VLAN tagging takes place?

quantum net-create --tenant-id 110ea394615d4cefa9824cf8829c841f net_ext
--provider:network_type vlan --provider:physical_network physnet3
--provider:segmentation_id 311 --router:external=True

Yes, if external_network_bridge is not empty (i.e. is its default value
of br-ex), then the provider attributes of the external network are
completely ignored. This is because l3-agent plugs directly into the
specified bridge rather than into br-int, and openvswitch-agent does not
get involved.



2) When provider attributes in "quantum net-create" command are ignored
by L3 agent, there is no linkage between external network/subnet to a
specific bridge, and that is why we need to manually put in
"external_network_bridge" in l3_agent.ini. Is that correct?

I guess I'd turn it around, and say that external_network_bridge being
set causes the provider attributes to be ignored.


3) If 1) and 2) are correct, then one limitation I can see by using
"provider external network" approach is, we can only have a single
external bridge and a single external network on quantum network node in
order to formulate 1-to-1 mapping. Is that correct?


I don't think this is a limitation of the provider external network
approach. By unsetting external_network_bridge and using the provider
attributes instead, you can use any number of external networks, and
they can even be on VLANs.

When using a non-empty external_network_bridge, you can only have one
external network (per l3-agent).


4) In "external bridge" approach, is there specific reason you recommend
using network_type of local?

Yes - to avoid confusion and avoid wasting a valuable resource. The
original upstream documentation for folsom showed creating the external
network as a normal tenant network (no provider attributes). Doing so
would allocate a tenant network that would never actually be used. If
tenant_network_type is vlan, this wastes a VLAN tag from the pool.
Creating the external network as a provider network with a network_type
of local avoids allocating a tenant network.

-Bob


Thanks a lot again!

Shixiong





On Jun 21, 2013, at 12:43 PM, Robert Kukura <rkukura at redhat.com<mailto:rkukura at redhat.com>
<mailto:rkukura at redhat.com>>
wrote:

There are two different approaches to connecting a router to an external
network. One uses an external bridge (br-ex), and bypasses the L2 agent.
The other uses a provider external network, and the interface driver and
L2 agent handle this network just like any other network (using br-int).
To use a provider external network, just set:

external_network_bridge =

in /etc/quantum/l3_agent.ini and create the external network with the
provider attributes describing it (typically provider:network_type is
flat or vlan).

The provider external network approach is more flexible - the external
network can be a VLAN and can coexist on the same physical network with
tenant networks, VMs can be connected directly to the external network,
different routers can use different external networks, etc.. Also, this
approach works with both openvswitch and linuxbridge, whereas the
external bridge approach only works with openvswitch.

I see that chapter 5 in the referenced upstream documentation may be
adding to the confusion by sort of mixing the two approaches. It is
specifying the provider details on the external network:

quantum net-create --tenant-id $tenant public01 \
--provider:network_type flat \
--provider:physical_network physnet1 \
--router:external=True

but the l3 agent is accessing it via br-ex where the provider details
don't matter because the l2 agent is bypassed. If using the external
bridge, I'd recommend creating the external network with
provider:network_type of local as is shown in appendix A:

quantum net-create Ext-Net --provider:network_type local \
--router:external true

Hope this helps,

-Bob



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/rhos-list/attachments/20130623/7870e357/attachment.htm>