<p dir="ltr">Is it compatible with overlapping IPs? i.e. Will it give two different VMs the same IP address if the reservations are setup that way? </p>
<p dir="ltr">If not, this approach won't work for many use cases so I think you will probably just have to write a new DHCP agent that operates in this distributed fashion. </p>
<div class="gmail_quot<blockquote class=" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I haven't yet had any responses to this, so reflagging it in case it was just missed in the helter skelter of activity that is the openstack-dev mailing list...<br>
<br>
On the other hand, if I need to describe more clearly what I'm on about, please don't be afraid to say that!<br>
<br>
Any comments and steer would be appreciated, even if they're more of a high level gut feel, than an exhaustive treatment.<br>
<br>
Thanks,<br>
        Neil<br>
<br>
<br>
On 16/04/15 15:12, Neil Jerram wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I have a Neutron DHCP agent patch whose purpose is to launch dnsmasq<br>
with options such that it works (=> provides DHCP service) for TAP<br>
interfaces that are _not_ bridged to the DHCP interface (ns-XXX).  For<br>
the sake of being concrete, this involves:<br>
<br>
- creating the ns-XXX interface as a dummy, instead of as a veth pair<br>
<br>
- launching dnsmasq with --bind-dynamic --listen=ns-XXX --listen=tap*<br>
--bridge-interface=ns-XXX,tap*<br>
<br>
- not running in a separate namespace<br>
<br>
- running the DHCP agent on every compute host, instead of only on the<br>
network node<br>
<br>
- using the relevant subnet's gateway IP on the ns-XXX interface (on<br>
every host), instead of allocating a different IP for each ns-XXX<br>
interface.<br>
<br>
I proposed a spec for this in the Kilo cycle [1], but it didn't get<br>
enough traction, and I'm now wondering what to do with this<br>
work/function.  Specifically, whether to look again at integrating it<br>
into Neutron during the Liberty cycle, or whether to maintain an<br>
independent DHCP agent for my project outside the upstream Neutron tree.<br>
  I would very much appreciate any comments or advice on this.<br>
<br>
For answering that last question, I suspect the biggest factor is<br>
whether routed TAP interfaces - i.e. forms of networking implementation<br>
that rely on routing data between VMs instead of bridging it - is in<br>
scope for Neutron, at all.  If it is, I understand that there could be a<br>
lot more detail to work on, such as how it meshes with other Neutron<br>
features such as DVR and the IPAM work, and that it might end up being<br>
quite different from the blueprint linked below.  But it would be good<br>
to know whether this would ultimately be in scope and of interest for<br>
Neutron at all.<br>
<br>
Please do let me now what you think.<br>
<br>
Many thanks,<br>
     Neil<br>
<br>
[1] <a href="https://blueprints.launchpad.net/neutron/+spec/dhcp-for-routed-ifs" target="_blank">https://blueprints.launchpad.net/neutron/+spec/dhcp-for-routed-ifs</a><br>
</blockquote>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div>