Ask Your Question
0

DHCP discover requests not answered

asked 2015-04-27 11:00:52 -0500

holger-king gravatar image

updated 2015-04-27 22:43:23 -0500

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?

edit retag flag offensive close merge delete

Comments

Please, post ovs-vsctl show && ifconfig on controller node. Activate also dnsmasq logging to see what issue is.

Add line dnsmasq_config_file = /etc/neutron/dnsmasq.conf to dhcp_agent.ini
Add /etc/nentron/dnsmasq.conf
log-facility = /var/log/neutron/dnsmasq.log
log-dhcp
dbaxps gravatar imagedbaxps ( 2015-04-27 11:58:40 -0500 )edit

Restart neutron-dhcp-agent and capture /var/log/neuutron/dnsmasq.log

dbaxps gravatar imagedbaxps ( 2015-04-27 12:00:08 -0500 )edit

You may also run ovs-vsctl show | grep 4095 and check output.

dbaxps gravatar imagedbaxps ( 2015-04-27 12:03:27 -0500 )edit

The following RPM yum-package has been updated, too:

  • from "openvswitch-2.1.2-2.el7.centos.1.x86_64" to "openvswitch-2.3.1-2.el7.x86_64"

Output of above commands

holger-king gravatar imageholger-king ( 2015-04-27 14:19:20 -0500 )edit

I don't see qrouter namespace in ip netns report
br-ex has IP 10.116.62.20/24 . Is it external network ?

dbaxps gravatar imagedbaxps ( 2015-04-27 14:28:24 -0500 )edit

1 answer

Sort by ยป oldest newest most voted
1

answered 2015-04-27 22:42:23 -0500

dbaxps gravatar image

Your dnsmasq.log is OK see

Apr 27 21:38:35 dnsmasq-dhcp[4182]: 3703053355 available DHCP subnet: 123.57.10.0/255.255.255.0
Apr 27 21:38:35 dnsmasq-dhcp[4182]: 3703053355 vendor class: udhcp 1.20.1
Apr 27 21:38:35 dnsmasq-dhcp[4182]: 3703053355 client provides name: cirros
Apr 27 21:38:35 dnsmasq-dhcp[4182]: 3703053355 DHCPREQUEST(tap3121ca03-8e) 123.57.10.4 fa:16:3e:a4:c0:19
Apr 27 21:38:35 dnsmasq-dhcp[4182]: 3703053355 tags: tag0, known, tap3121ca03-8e
Apr 27 21:38:35 dnsmasq-dhcp[4182]: 3703053355 DHCPACK(tap3121ca03-8e) 123.57.10.4 fa:16:3e:a4:c0:19 host-123-57-10-4

You wrote :- Initially we just created an internal tenant network with using the following net "123.57.10.0/24". The qdhcp namespace owns an IP of that range. As both - instance and dhcp-server (dnsmasq) are within the same network (see ip netns exec <namesspace name=""> ip addr) no router is needed. Am I wrong?

Yes , you are . You are supposed to 
1. Create external network ( admin  && shared)
2. Create neutron router
3. Create interface at router to private network 123.57.10.0/24
4.Create gateway at router to external network.
5. ip netns should report qrouter-namespace

Br-ex usually has IP at external network (having eth0 as OVS port) to route packets outside.
Your br-ex has IP br-ex 10.116.62.20/24 if it belongs one of tenants networks , you won't be able to route packets outside.

You also wrote :-

DNSMASQ process running on the Neutron node of the OpenStack controller

In your case there should be just one Node working as Controller && Network Node at a time.
See standard for RDO Juno ML2&OVS&VXLAN setup matching your config here:-
http://bderzhavets.blogspot.com/2015/...

edit flag offensive delete link more

Comments

In general, I wouldn't recommend you RDO Juno VLAN setup. VXLAN tunnels work fine between Controller and Compute Nodes. Actually, ML2&OVS&VXLAN is standard solution for RDO Juno on RHEL 7.1 or CentOS 7.1

dbaxps gravatar imagedbaxps ( 2015-04-27 23:02:48 -0500 )edit

Dear "dbaxps",

I don't agree that it's essential to create a router having an external gateway linked with a provider net and an internal interface linking the tenant net to get an IP network qdhcp-<uuid> namespace being created. It's sufficient to just create a tenant net with "--enable-dhcp".

holger-king gravatar imageholger-king ( 2015-04-28 02:47:44 -0500 )edit

Otherwise, it wouldn't be possible that the ping - mentioned before - would work as only the "qdhcp-<uuid>" network namespace exists.

Nevertheless, although it would be recommended to use VXLAN in combination with Juno on RDO-based OpenStack deployments, VLAN should work, too.

holger-king gravatar imageholger-king ( 2015-04-28 02:51:18 -0500 )edit

Up to now, we do not have any clue why the DHCP problem occured - because by just enabling the logging for "dnsmasq" it started working :-(

holger-king gravatar imageholger-king ( 2015-04-28 02:55:52 -0500 )edit

Sure, VLAN would work.

dbaxps gravatar imagedbaxps ( 2015-04-28 03:05:51 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Get to know Ask OpenStack

Resources for moderators

Question Tools

Stats

Asked: 2015-04-27 09:07:50 -0500

Seen: 5,651 times

Last updated: Apr 27 '15