[Openstack-operators] [Neutron] where are my dhcp packets getting lost?

Lorin Hochstein lorin at nimbisservices.com
Wed Aug 14 19:56:29 UTC 2013


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. 


Take care,

Lorin
--
Lorin Hochstein
Lead Architect - Cloud Services
Nimbis Services, Inc.
www.nimbisservices.com





On Aug 14, 2013, at 12:47 PM, Jonathan Proulx <jon at jonproulx.com> wrote:

> Hi All,
> 
> My goal is to setup a network using grizzly-quantum on Ubuntu 12.04 (cloud archive) that will allow VMs direct IP (no nat) connection to an existing network and external router but use quantum-dhcp-agent for IPAM so users can easily discover their address assignments.
> 
> My current attempt at this is using the OVS plugin and a vlan based provider network.
> 
> On the compute nodes this is working, VMs get on teh correct vlan and if I configure an external DHCP server they get addresses and connection (though discovering what address they got is a challenge)
> 
> The requests get to the network controller on bond0 (what I expect) but they don't get to the dhcp interface (ip netns exec qdhcp-0a1d0a27-cffa-4de3-92c5-9d3fd3f2e74d tcpdump -i tap9bc9680d-2a)
> 
> I don't know if this is incorrect bridge setup (which has tripped me up before in ovs land), or the net namespaces which I'm also unfamiliar with.
> 
> OVS bits
> 
> the physical network "trunk" is what was specified in network creation, it's an interface with no IP addr and a small pile of tagged vlans
> 
> on the computenodes:
> # plugin ini
> bridge_mappings = trunk:eth1-br
> 
> root at nova-58:~# ovs-vsctl list-ports eth1-br 
> eth1
> phy-eth1-br
> root at nova-58:~# ovs-vsctl list-ports br-int
> int-br-eth1
> int-eth1-br
> patch-tun
> tap66012388-3a   <- this is the VM 
> 
> on network node:
> # plugin ini
> physical_interface_mappings=trunk:bond0,default:bond0.2113
> network_vlan_ranges = trunk:2112:2114
> bridge_mappings=trunk:bond0-br
> 
> root at nimbus-0:~# ovs-vsctl list-ports bond0-br
> bond0
> phy-bond0-br
> root at nimbus-0:~# ovs-vsctl list-ports br-int
> int-bond0-br
> patch-tun
> qr-08ea752e-e0
> qr-89a1efea-e9
> tap6d0145d5-72
> tap76d1b368-57
> tap9bc9680d-2a    <- this is the interface in the dhcp server namespace for this net
> 
> 
> why aren't the bits getting from bond0 to the dhcp service?
> 
> Thanks,
> -Jon
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

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


More information about the OpenStack-operators mailing list