Dear OpenStack community,

after having updated the following RPM packages on a Red Hat Enterprise Linux (RHEL) 7.1 box using:

• OpenStack RDO Juno deployed via "packstack" (1x controller, 2 compute nodes, VLAN mode)

from:

• dnsmasq-2.66-12.el7.x86_64
• openstack-packstack-2014.2-0.18.dev1462.gbb05296.el7.noarch
• openstack-packstack-puppet-2014.2-0.18.dev1462.gbb05296.el7.noarch
• openstack-puppet-modules-2014.2.11-1.el7.noarch

to:

• dnsmasq-2.66-13.el7_1.x86_64
• openstack-packstack-2014.2-0.23.dev1468.gd049ea9.el7.noarch.rpm
• openstack-packstack-puppet-2014.2-0.23.dev1468.gd049ea9.el7.noarch.rpm
• openstack-puppet-modules-2014.2.15-1.el7.noarch.rpm

the DHCP discovery broadcast requests initiated from a newly started OpenStack KVM-instance (mac address=00:50:56:86:19:65, see "virsh dumpxml <instance_id>") do not get answered anymore by the DNSMASQ process running on the Neutron node of the OpenStack controller:

ps aux | grep -i "dns"
nobody    4275  0.0  0.0  15520   844 ?        S    15:41   0:00 dnsmasq --no-hosts --no-resolv --strict-order --bind-interfaces --interface=tap0d4968c1-22 --except-interface=lo --pid-file=/var/lib/neutron/dhcp/f2457f2b-b7a1-49d2-8e4b-8bca8eb73ae3/pid --dhcp-hostsfile=/var/lib/neutron/dhcp/f2457f2b-b7a1-49d2-8e4b-8bca8eb73ae3/host --addn-hosts=/var/lib/neutron/dhcp/f2457f2b-b7a1-49d2-8e4b-8bca8eb73ae3/addn_hosts --dhcp-optsfile=/var/lib/neutron/dhcp/f2457f2b-b7a1-49d2-8e4b-8bca8eb73ae3/opts --leasefile-ro --dhcp-range=set:tag0,123.57.10.0,static,86400s --dhcp-lease-max=256 --conf-file= --domain=openstacklocal

The DHCP broadcast does receive the controller node. This can be proven by using:

tcpdump -i eth1 -vvv -s 1500 port 67 or port 68
15:43:31.065981 IP (tos 0x0, ttl 128, id 18171, offset 0, flags [none], proto UDP (17), length 328)
0.0.0.0.bootpc > 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Request from 00:50:56:86:19:65 (oui Unknown), length 300, xid 0x4eff8141, secs 7424, Flags [none] (0x0000)
      Client-Ethernet-Address 00:50:56:86:19:65 (oui Unknown)
      Vendor-rfc1048 Extensions
        Magic Cookie 0x63825363
        DHCP-Message Option 53, length 1: Discover
        Client-ID Option 61, length 7: ether 00:50:56:86:19:65
        Hostname Option 12, length 15: "WIN-21QF963GG7N"
        Vendor-Class Option 60, length 8: "MSFT 5.0"
        Parameter-Request Option 55, length 13:
          Subnet-Mask, Domain-Name, Default-Gateway, Domain-Name-Server
          Netbios-Name-Server, Netbios-Node, Netbios-Scope, Router-Discovery
          Static-Route, Classless-Static-Route, Classless-Static-Route-Microsoft, Option 252
          Vendor-Option
        END Option 255, length 0
        PAD Option 0, length 0, occurs 5

Do you have any ideas for that problem? We also checked the firewall rules in all network namespaces and even cleared them using "iptables -F" to verify whether this could be a problem. Additionally, we restarted the DHCP service after killing it using "systemctl restart neutron-dhcp-agent.service" - without any success.

We even tried a "yum downgrade dnsmasq" to switch to the prior version - but without any improvements!

But know, we have no more ideas. If you have some?

They are really very welcome :-) Maybe it's a bug?