Open Stack

Hi George -

Thanks for that - I can see that the host file specified in the
--dhcp-hostsfile argument fed to dnsmasq
(/var/lib/neutron/dhcp/UUID/host) gets populated by openstack as follows:
---
fa:16:3e:58:17:53,host-10-20-50-202.openstacklocal.,10.20.50.202
fa:16:3e:8a:d3:f8,host-10-20-50-201.openstacklocal.,10.20.50.201
fa:16:3e:21:94:bf,host-10-20-50-205.openstacklocal.,10.20.50.205
---

- the dnsmasq process is also fed the argument
--dhcp-range=set:tag0,10.20.50.0,static,86400s

- the 'static' mode means that only hosts with MAC addresses/IPs
specified in the hosts file will get dhcp addresses - hence why no dhcp
range needs to be specified in the --dhcp-range argument, only the
network address.

Effectively, openstack is managing the dhcp ip range and IP address
allocation outside of the dnsmasq process, by writing entries into this
hosts file every time anything that needs an ip (a new VM or
port/gateway) is created.

Under this scheme, no dhcp addresses can be issued to hosts that
openstack/neutron doesn't know about (eg. on a vlan tenant network that
the tenant wants to connect other non-openstack kit to).

/usr/lib/python2.7/site-packages/neutron/agent/linux/dhcp.py has the
'static' argument for --dhcp-range hard coded into it for ipv4. I tried
a crude modification to this script as follows, to remove the optional
'static' mode from dnsmasq's --dhcp-range argument and instead insert
the network broadcast address acting as the end of the dhcp range
(without mode set to static, a range start AND END address *must* be
specified to dnsmasq).


--- dhcp.py     2016-02-29 15:59:45.591930854 +0000
+++ dhcp.py.modified    2016-03-03 11:54:35.479619644 +0000
@@ -359,7 +359,7 @@
                 if subnet.ip_version == 4:
                     cmd.append('--dhcp-range=%s%s,%s,%s,%s' %
                                ('set:', self._TAG_PREFIX % i,
-                                cidr.network, mode, lease))
+                                cidr.network, cidr.broadcast, lease))
                 else:
                     cmd.append('--dhcp-range=%s%s,%s,%s,%d,%s' %
                                ('set:', self._TAG_PREFIX % i,


This allows dnsmasq to allocate IP addresses to 'unknown' hosts, as well
as to hosts specified in the hosts file, since the 'static' mode is not
being specified. I tested it by connecting wireless devices to an AP
patched into a switch port on the tenant's vlan - the devices all got
dhcp addresses in the tenant-defined dhcp-enabled subnet and could
connect to the tenant's VM instances. Great!

The trouble with this crude hack is that dnsmasq is not aware of the
dhcp ip address allocation range set in the subnet config within
openstack, because it's not being specified in the --dhcp-range argument
(the cidr.network and cidr.broadcast addresses are being used to define
the dhcp range - ie. the whole network). So, dhcp ip's issued to
non-openstack devices can be given an ip address outside of the
specified dhcp range.

What I need is to be able to retrieve the dhcp range set in openstack
for the network, and use those ip addresses in place of
cidr.network/cidr.broadcast in the patch above. Any pointers on how best
to do that - or advice on a better way of achieving the same goal? Any
feedback much appreciated.

cheers
Iain
--


On 26/02/16 16:48, George Mihaiescu wrote:
> Hi Ian,
>
> Neutron dhcp server only serves IPs to the MACs defined in its host
> file (/var/lib/neutron/dhcp/UUID/host).
>
> You can create a port for the physical server if you know the MAC
> address and this make it work, check the help for the "neutron
> port-create" command:
> neutron help port-create
>
> Cheers,
> George
>
>
>
> On Fri, Feb 26, 2016 at 11:33 AM, iain smith <iain at 3birds.co.uk
> <mailto:iain at 3birds.co.uk>> wrote:
>
>     Hi all - I'm currently trying to get something working on my openstack
>     platform, wondering if anyone's come across this before.
>
>     On a VLAN tenant network, how can I allow an external device to
>     pick up
>     a dhcp address from neutron's dhcp service (the dhcp service
>     associated
>     with the subnet created in the tenant vlan network)?
>
>     - I'm using liberty, and have created some vlan networks as admin
>     user,
>     and assigned them to the 'demo' project.
>     - logged in as demo, I've created a dhcp-enabled subnet in one of the
>     vlan networks, and a security group that allows hosts in the same
>     subnet
>     to connect to openstack guests in that subnet.
>     - I've created some openstack guest VMs in the subnet - they came
>     up ok
>     and picked up dhcp ip addresses. I can connect to these guests from an
>     external server on the same VLAN (a server outside of openstack).
>     I can
>     connect to the external server from the openstack guest VMs. All as
>     expected.
>
>     What I'm trying to do is to get an external (non-openstack) device on
>     the same vlan to pick up a dhcp ip address from the openstack dhcp
>     service for that subnet. Using wireshark I can see the dhcp request
>     packets from my device, on the correct vlan, reaching my neutron
>     network
>     node where the dnsmasq dhcp service is running, but there's never a
>     reply. I've tried putting wide-open ingress rules in the security
>     group,
>     but haven't got it to work yet (I'm not actually sure if the security
>     group has any bearing at the subnet level as per AWS, or if it applies
>     only to guest VMs... looks to me like it just applies to VMs).
>
>     Anyone know what I need to do? I'll keep at it meantime
>
>     cheers
>     Iain
>     --
>
>
>     _______________________________________________
>     Mailing list:
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>     Post to     : openstack at lists.openstack.org
>     <mailto:openstack at lists.openstack.org>
>     Unsubscribe :
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20160309/2b366a69/attachment.html>