Open Stack

On Wed, Aug 14, 2013 at 5:26 PM, Jonathan Proulx <jon at jonproulx.com> wrote:

> On Wed, Aug 14, 2013 at 3:56 PM, Lorin Hochstein <lorin at nimbisservices.com
> > wrote:
>
>> Jon:
>>
>> This is just a stab in a dark, but perhaps it's a vlan tag issue that's
>> causing the openvswitch to not forward the packet? What's the vlan tag on
>> those packets that are arriving at band0 on the network node?
>>
>> Also, the bond0.2113 looked a little strange to me on this line:
>>
>> physical_interface_mappings=trunk:bond0,default:bond0.2113
>>
>> Is there a manually created bond0.2113 vlan device on the network node? I
>> thought openvswitch manages all of the VLANs with neutron, so there's no
>> need to manually create vlan interfaces like this.
>>
>>
> That is a little odd, it's left over from a previous stab at doing this as
> a flat network rather than tagged.  I certainly don't need it in the
> config, but the bond0.2113 device does exist and  is in use, so that may be
> a conflict.  I'm trying to reuse the vlan I had for floating IPs  folsom
> using FlatDHCP which is also where the node have their public IPs the
> controllers is on bond0.2113 (the compute nodes have eht0 untagged on this
> vlan and eth1 with , so it may be worth trying this experiment with another
> vlan or moving the IP on this vlan to the 1G eth0 interface.
>

OK I realized the controller in addition to the two 10G interfaces that
make up bond0 the host also has a couple of 1G interfaces and one of those
was already on the right vlan (in native mode), so switched the IP from
bond0.2113 to eth1 restarted everything and poof it works.

Thanks!

-Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20130814/a9cb0075/attachment.html>