[openstack-dev] [neutron] multiple agents with segment access

Legacy, Allain Allain.Legacy at windriver.com
Tue Nov 14 16:02:06 UTC 2017

Is it a known limitation that the ML2 plugin and associated drivers do not properly handle cases where there are multiple agents running on the same host?   That is, two or more agents that reside on the same host and both report device/interface mappings  for physical networks?    One such setup is a set of nodes that are both running an L2 agent and a NIC SRIOV agent.   

We have found two problems specific to this configuration and are wondering if these are known limitations, or simply not supported.   

For example, in a configuration where a host has L2, DHCP, and SRIOV agents running on it, then:

1)   The DHCP scheduler can schedule a network to be hosted by that DHCP agent even if the physical network is only supported by the SRIOV agent and not by the L2 agent.  This can end up isolating the DHCP server as it will not have access to the underlying physical segment.   This is happening because "filter_hosts_with_network_access" in the Ml2Plugin will include the host because the SRIOV mech driver reports that it has access to that segment.   

2)   The Segment Plugin "segmenthostmappings" table gets overwritten with tuples for whichever agent reports in last.  For example, if the L2 agent has physical network mappings for 2 different physical networks (physnet0, physnet1), but the SRIOV NIC agent only has 1 physical network reported (physnet2), the segmenthostmappings table will have data for only physnet2 if the SRIOV NIC agent reported last, or data for only both physnet0 and physnet1 if the L2 agent reported last.  Data for physical networks belonging to the other agent will be erroneously removed as stale entries.

If it has been discussed before is there a plan to address this type of configuration?  


Allain Legacy, Software Developer, Wind River
direct 613.270.2279  fax 613.492.7870 skype allain.legacy
350 Terry Fox Drive, Suite 200, Ottawa, Ontario, K2K 2W5


More information about the OpenStack-dev mailing list