Open Stack

Bad form to self-reply but it's off hours for most and this is probably
useful new information..

the vm's tap device on the compute node is being put in the bridge
"int-br", if I remove it and put in the "trunk" bridge with the correct tag
it works as I want:

root at nova-0:~# ovs-vsctl del-port br-int tapd2799dad-27
root at nova-0:~# ovs-vsctl add-port trunk tapd2799dad-27 tag=2113

This what I wanted to happen but clearly I have something confused, can
quantum/neutron do this & if so how do I tell it to?


On Sun, Aug 11, 2013 at 8:07 AM, Jonathan Proulx <jon at jonproulx.com> wrote:

> HI All,
>
> My maintenance window is closing and I haven't yet managed the transition
> I planned from nova-network to quantum/neutron with ovs plugin.  Using
> Ubuntu 12.04 Cloud archive packages (and puppetlabs openstack modules,
> though I had the same results by hand so likely confusion on my part rather
> than a typo)
>
> I want to create a provider network that plugs instances directly into an
> existing vlan which already has a router, dhcp (and other non-openstack)
> hosts.  Previously this is where nova-network got it's "floating ip"
> ranges.  I have interfaces on compute nodes and network controller with
> this vlan trunked, also their public IPs are on this vlan so they have
> another interface i could use to provide "flat" access, but I'd rather go
> vlan as I have other nets I want to implement too.
>
> I created the network with:
> quantum net-create public-inet --shared --provider:network_type vlan
> --provider:physical_network trunk --provider:segmentation_id 2113
>
> on network controller and compute node 'ovs-vsctl list-ifaces trunk' shows
> a single physical interface as a member (bond0, and eth1 respectively)
> these interfaces are up and are the ones with trunks defined on the
> attached switch.  Neither has an IP addr (though bond0.2113 on the
> controller is the primary public interface, perhaps this is an issue?) an
> other possible issue is that this is jumbo frames network so I need to set
> MTU...but I expect that problem comes after the current one.
>
> in the config I have set:
> bridge_mappings=trunk:<bond0|eth1>-br
>
> should I have not set them to
>
> when I launch an instance with this network it does get an interface but
> is seems not to be connected to the outside.
>
> the quantum-server log complains:
> 2013-08-11 07:32:30  WARNING [quantum.db.agentschedulers_db] Fail
> scheduling network {'status': u'ACTIVE', 'subnets':
> [u'7dd56379-90f5-4c79-b127-954c0fcbdca1'], 'name': u'public-inet',
> 'provider:physical_network': u'trunk', 'admin_state_up': True, 'tenant_id':
> u'6f9adccbd03e4d2186756896957a14bf', 'provider:network_type': u'vlan',
> 'router:external': False, 'shared': True, 'id':
> u'2c3ee609-ff51-4650-8541-737b0ca72f0c', 'provider:segmentation_id': 2113L}
>
> The compute node shows
> 2013-08-11 07:32:30     INFO [quantum.agent.securitygroups_rpc] Security
> group member updated [u'e4ad30f9-e50b-49fc-9d81-26c875ac15b8',
> u'e5209cd6-b881-4633-b955-fdde1fefea58']
> 2013-08-11 07:32:39     INFO [quantum.agent.securitygroups_rpc] Preparing
> filters for devices set(['96555a4a-d6c1-4c8a-a65e-31317370c08d'])
> 2013-08-11 07:32:40     INFO
> [quantum.plugins.openvswitch.agent.ovs_quantum_agent] Port
> 96555a4a-d6c1-4c8a-a65e-31317370c08d added
> 2013-08-11 07:32:40     INFO
> [quantum.plugins.openvswitch.agent.ovs_quantum_agent] Port
> 96555a4a-d6c1-4c8a-a65e-31317370c08d updated. Details: {u'admin_state_up':
> True, u'network_id': u'2c3ee609-ff51-4650-8541-737b0ca72f0c',
> u'segmentation_id': 2113, u'physical_network': u'trunk', u'device':
> u'96555a4a-d6c1-4c8a-a65e-31317370c08d', u'port_id':
> u'96555a4a-d6c1-4c8a-a65e-31317370c08d', u'network_type': u'vlan'}
> 2013-08-11 07:32:40     INFO
> [quantum.plugins.openvswitch.agent.ovs_quantum_agent] Assigning 5 as local
> vlan for net-id=2c3ee609-ff51-4650-8541-737b0ca72f0c
>
> Can anyone see what I'm misunderstanding?
>
> Thanks,
> -Jon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20130811/ad89776d/attachment.html>