rkukura's profile - activity

2014-07-25 01:54:22 -0500 received badge  Necromancer (source)
2014-04-25 07:22:20 -0500 received badge  Good Answer (source)
2014-04-19 18:13:31 -0500 received badge  Nice Answer (source)
2014-02-18 16:09:44 -0500 answered a question [Grizzly]how to config multiple l3 agent for quantum ? I wanna run multiple l3 agent on one network node, because I wanna multiple external network.

Just want to point out that since https://review.openstack.org/#/c/59359/ was merged, a single l3-agent can handle multiple external networks (using provider networks rather than external_network_bridge), so running multiple l3-agents on the same node should no longer be necessary.

2014-01-06 13:21:52 -0500 received badge  Necromancer (source)
2014-01-06 13:21:52 -0500 received badge  Teacher (source)
2014-01-06 13:09:23 -0500 received badge  Editor (source)
2014-01-06 12:57:17 -0500 answered a question Migrate from OVS plugin to ML2

The steps to convert an RDO installation from the openvswitch core plugin to the ml2 core plugin are documented at http://openstack.redhat.com/ML2_plugin . This includes configuration as well as DB schema initialization.

Note that these steps result in an empty neutron database. There is a blueprint ( https://blueprints.launchpad.net/neutron/+spec/ml2-deprecated-plugin-migration ) to implement a conversion tool that migrates data from the previous plugin's schema to the ml2 schema, which should preserve existing networks, ports, and other resources.

2013-10-29 18:45:15 -0500 answered a question Multiple core plugins for single neutron server instance

Please check out the ml2 plugin introduced in havana. It supports the openvswitch, linuxbridge, and hyperv L2 agents concurrently within the same deployment.

2013-05-08 00:08:25 -0500 answered a question Openstack on one NIC

Hi Keith,

I don't see any major problems with your approach. You would create br-eth0, add the eth0 interface to br-eth0 as a port, and set things up so the machine gets its "internal network" IP on the internal port of br-eth0 at boot.

If you your concern is about needing a separate OVS bridge (br-ex) for the l3-agent to access the "public network", you can use a provider network instead. Just set external_bridge to the empty string instead of "br-ex" in l3-agent.ini, and then create your external network passing "--provider:network_type vlan --provider:physical_network <whatever> --provider:segmentation_id 100". This will result in l3-agent connecting to the the public network via the normal br-int<->veth<->br-eth0 mechanism.


2013-05-02 15:38:12 -0500 answered a question How to access external network (flat mode) from VM using linux bridge plugin???

Sounds like maybe quantum-server is not reading all the right config files. Look for "config files:" near the top of the log output with debugging enabled and verify that the correct linuxbridge_conf.ini is being loaded. If not, check that they are passed via --config-file args on the quantum-server command line.

2013-04-30 18:27:06 -0500 answered a question How to access external network (flat mode) from VM using linux bridge plugin???


The "Invalid input for operation: Unknown provider:physical_network physnet1." error message indicates the plugin is not finding "physnet1" in network_vlan_ranges.

Please try setting:

[DEFAULT] debug = True verbose = True

in /etc/quantum/quantum.conf, and then restarting the server. Then look for "Network VLAN ranges: " in the quantum-server log to see if physnet1 is listed.


2013-04-30 15:35:29 -0500 answered a question How to access external network (flat mode) from VM using linux bridge plugin???

Hi Bill,

Have you set the following in /etc/quantum/plugins/linuxbridge/linuxbridge_conf.ini on your controller node?:

network_vlan_ranges = physnet1

The network_vlan_ranges configuration variable serves two related purposes: it declares the names of the available physical networks, and, optionally, declares the ranges of VLAN tags on each physical network available for allocation to tenant networks. Even if tenant VLANs are not being used, the physical network names still need to be declared in network_vlan_ranges.


2013-03-07 17:05:29 -0500 answered a question linuxbridge agent startup failure due to duplicate interface reference

Yong's comment addresses specifying a pool of VLAN tags for tenant networks. Note that you do not need to specify the ranges of VLAN tags if you are only creating provider networks.

I had just posted the following explanation as a comment on the referenced bug:


It sounds like your DEV_WDMZ ... DEV_FDMZ are all VLANs on the same physical network.

If so, you should just set something like "network_vlan_ranges = DEV_TRUNK" on the quantum server, and "physical_interface_mappings = DEV_TRUNK:bond0" on the compute and network nodes.

The linuxbridge server and agent configuration only need to know about the physical network(s), not the individual provider VLANs you are allocating on the physical network.

If you are using multiple physical networks (multiple distinct VLAN trunks), then each physical network needs to be listed, as in "network_vlan_ranges = TRUNK1,TRUNK2" and "physical_interface_mappings = TRUNK1:bond0,TRUNK2:bond1". In this case VLAN X on TRUNK1 is a different isolated L2 network than VLAN X on TRUNK2.


2013-02-21 21:31:20 -0500 answered a question non-NATed cloud network to provider network

Understood. A shared flat external network might be sufficient in some cases, possibly even combined with private networks and appropriate security group rules. I agree routing to an external network without using NAT would also be a good feature. How about filing a bug requesting this?

2013-02-21 20:37:22 -0500 answered a question non-NATed cloud network to provider network

You should be able to set up a quantum provider network that has routed (non-NAT) external connectivity (i.e. via a physical router), and create a quantum subnet on that network with a pool of IPs that quantum's DHCP service will allocate to ports. You would deploy quantum-dhcp-agent for this network, but not deploy quantum-l3-agent, and VMs using this network would have direct external connectivity. This approach basically eliminates the private network, putting the VMs right on the public network.

It sounds like you'd like to use the quantum-l3-agent, but with NAT turned off for the external network. I'm not sure if this is possible right now, but the above suggestion might work for you if you don't need the quantum-l3-agent for other purposes.

2013-02-21 18:07:48 -0500 answered a question non-NATed cloud network to provider network

The providernet extension, supported by a number of quantum plugins, is intended to address this. See http://docs.openstack.org/folsom/open... .

2013-01-08 21:08:57 -0500 answered a question VLAN and GRE provider networks at the same time with OVS plugin

Looks to me like it should work as well.

One note is that "tenant_network_type = vlan" will cause tenant networks to be allocated as vlans. If you change this to "tenant_network_type = gre" then they will be gre networks. In either case, you can allocate provider vlan and gre networks.

Also, I noticed that your ranges of vlan tags on the two physical networks don't overlap. Note that you can re-use the same vlan tags on distinct physical networks for distinct virtual networks (assuming the physical networks aren't the same network).


2013-01-04 14:16:27 -0500 answered a question ovs-quantum-agent integration bridge vs physical bridge

Hi Asif,

The reason for separate physical bridges for each physical interface is that each physical network has its own independent set of VLAN tag values. The VLAN tags on the integration bridge are locally assigned by the agent. The flow rule that passes data from the integration bridge to a physical bridge replaces the locally assigned VLAN tag used on the integration bridge with the the VLAN tag used on the physical network (or removes it for flat networks). The VLAN tags of data flowing from the physical bridge to the integration bridge are similarly translated by the flow rules. Note that multiple distinct virtual networks can use the same VLAN tag value on different physical networks.


2012-12-06 22:32:05 -0500 answered a question OpenVSwitch flows missing on newly created setup

Try running "network show <net>" with admin credentials (OS_USERNAME=admin works in devstack). If the provider:network_type is local, that would explain the lack of flows. Local networks are handled entirely within br-int, and don't require any flow rules. If so, and these are tenant rather than provider networks, you need to set tenant_network_type to something other than the default of local.


2012-10-29 15:50:35 -0500 answered a question Local vlan id range is less

The local VLAN IDs only get allocated when a port on that node needs access to a network. Local VLAN IDs are not allocated for networks that are not used on that node. Therefore, the openvswitch plugin should be able to support simultaneous access to up to 4094 different virtual networks from a single node, but these can be distributed over any number of physical networks (and/or GRE tunnels).