[openstack-dev] [Neutron] Why doesn't ml2-ovs work when it's "host" != the dhcp agent's host?

Kevin Benton blak111 at gmail.com
Tue Oct 21 03:17:47 UTC 2014


The current suggested way for DHCP agent fault tolerance is multiple agents
per network. Is there a reason you don't want to use that option?
On Oct 20, 2014 5:13 PM, "Noel Burton-Krahn" <noel at pistoncloud.com> wrote:

> Thanks, Robert.
>
> So, ML2 needs the host attribute to match to bind the port.  My other
> requirement is that the dhcp agent must be able to migrate to a new host on
> failover.  The issue there is that if the dhcp service starts on a new host
> with a new host name, then it will not take over the networks that were
> served by the old host name.  I'm looking for a way to start the dhcp agent
> on a new host using the old host's config.
>
> --
> Noel
>
>
> On Mon, Oct 20, 2014 at 11:10 AM, Robert Kukura <kukura at noironetworks.com>
> wrote:
>
>>  Hi Noel,
>>
>> The ML2 plugin uses the binding:host_id attribute of port to control port
>> binding. For compute ports, nova sets binding:host_id when
>> creating/updating the neutron port, and ML2's openvswitch mechanism driver
>> will look in agents_db to make sure the openvswitch L2 agent is running on
>> that host, and that it has a bridge mapping for any needed physical network
>> or has the appropriate tunnel type enabled. The binding:host_id attribute
>> also gets set on DHCP, L3, and other agents' ports, and must match the host
>> of the openvswitch-agent on that node or ML2 will not be able to bind the
>> port. I suspect your configuration may be resulting in these not matching,
>> and the DHCP port's binding:vif_type attribute being 'binding_failed'.
>>
>> I'd suggest running "neutron port-show" as admin on the DHCP port to see
>> what the values of binding_vif_type and binding:host_id are, and running
>> "neutron agent-list" as admin to make sure there is an L2 agent on that
>> node and maybe "neutron agent-show" as admin to get that agents config
>> details.
>>
>> -Bob
>>
>>
>>
>> On 10/20/14 1:28 PM, Noel Burton-Krahn wrote:
>>
>> I'm running OpenStack Icehouse with Neutron ML2/OVS.  I've configured the
>> ml2-ovs-plugin on all nodes with host = the IP of the host itself.
>> However, my dhcp-agent may float from host to host for failover, so I
>> configured it with host="floating".  That doesn't work.  In this case, the
>> ml2-ovs-plugin creates a namespace and a tap interface for the dhcp agent,
>> but OVS doesn't route any traffic to the dhcp agent.  It *does* work if the
>> dhcp agent's host is the same as the ovs plugin's host, but if my dhcp
>> agent migrates to another host, it loses its configuration since it now has
>> a different host name.
>>
>>  So my question is, what does host mean for the ML2 dhcp agent and host
>> can I get it to work if the dhcp agent's host != host for the ovs plugin?
>>
>>  Case 1: fails: running with dhcp agent's host = "floating", ovs
>> plugin's host = IP-of-server
>> dhcp agent is running in netns created by ovs-plugin
>> dhcp agent never receives network traffic
>>
>>  Case 2: ok: running with dhcp agent's host = ovs plugin's host =
>> IP-of-server
>>  dhcp agent is running in netns created by ovs-plugin (different tap
>> name than case 1)
>>  dhcp agent works
>>
>>  --
>> Noel
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing listOpenStack-dev at lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141020/9f806522/attachment.html>


More information about the OpenStack-dev mailing list