Ask Your Question
0

DHCP packets lost between VM and dnsmasq

asked 2015-03-25 19:43:47 -0500

savril gravatar image

updated 2015-03-28 16:36:42 -0500

Hello,

I'm using Juno on baremetal with puppet all-in-one host configuration. I have 2 NIC and one is dedicated to OpenStack tagged VLANs.

My test VM with Cirros don't get a DHCP answer. Everything seem normal in OpenStack configuration and when I do a tcpdump on the br-int interface, I can see the DHCP request from the VM. I see no errors in the log either.

However, I wasn't able to track my instance interface to OVS config (lack on knowledge on GRE, ...) but as I can see the DHCP packets from the VM, I expect it to correct. The interface binded to the dnsmasq instance seems to be correctly mapped by OVS to br-int also.

I have activated the logs on dnsmasq but it show no queries. So it seem that dnsmasq don't get the DHCP packets from the Cirros instance.

What did I miss ?

Thanks

Here is some data on my install :

libvirt:
    source: qbr606379bd-33
    target: tap606379bd-33

~# brctl show
bridge name bridge id       STP enabled interfaces
qbr606379bd-33      8000.ba7b792d9903   no      qvb606379bd-33
                            tap606379bd-33
virbr0      8000.000000000000   yes

ip a
29: qvb606379bd-33: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master qbr606379bd-33 state UP group default qlen 1000
    link/ether ba:7b:79:2d:99:03 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::b87b:79ff:fe2d:9903/64 scope link
       valid_lft forever preferred_lft forever
30: tap606379bd-33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master qbr606379bd-33 state UNKNOWN group default qlen 500
    link/ether fe:16:3e:44:ee:72 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fc16:3eff:fe44:ee72/64 scope link
       valid_lft forever preferred_lft forever

~# ps ax | grep dnsmasq
 5264 ?        S      0:00 /usr/sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf
 6312 ?        S      0:00 dnsmasq --no-hosts --no-resolv --strict-order --bind-interfaces --interface=tape24a0ace-d7 --except-interface=lo --pid-file=/var/lib/neutron/dhcp/528cb077-d7f6-488b-aa4f-f09c675b87f2/pid --dhcp-hostsfile=/var/lib/neutron/dhcp/528cb077-d7f6-488b-aa4f-f09c675b87f2/host --addn-hosts=/var/lib/neutron/dhcp/528cb077-d7f6-488b-aa4f-f09c675b87f2/addn_hosts --dhcp-optsfile=/var/lib/neutron/dhcp/528cb077-d7f6-488b-aa4f-f09c675b87f2/opts --leasefile-ro --dhcp-range=set:tag0,10.0.0.0,static,86400s --dhcp-lease-max=256 --conf-file= --domain=openstacklocal

~# ovs-vsctl show
19ecefbe-9cae-43d4-af06-2329693e159e
    Bridge brex
        Port "qg-897e2fc6-3d"
            Interface "qg-897e2fc6-3d"
                type: internal
        Port "em1_20"
            Interface "em1_20"
        Port brex
            Interface brex
                type: internal
    Bridge br-int
        fail_mode: secure
        Port "tape24a0ace-d7"
            tag: 4095
            Interface "tape24a0ace-d7"
                type: internal
        Port patch-tun
            Interface patch-tun
                type: patch
                options: {peer=patch-int}
        Port "qvo606379bd-33"
            tag: 1
            Interface "qvo606379bd-33"
        Port "qr-acf2952b-fe"
            tag: 1
            Interface "qr-acf2952b-fe"
                type: internal
        Port br-int
            Interface br-int
                type: internal
    Bridge br-tun
        Port patch-int
            Interface patch-int
                type: patch
                options: {peer=patch-tun}
        Port br-tun
            Interface br-tun
                type: internal
    ovs_version: "2.0.2"

Console for Cirros instance:
no results found for mode=local. up 0.68. searched: nocloud configdrive ec2
Starting network...
udhcpc (v1.20.1) started
Sending discover...

~# cat /etc/neutron/dnsmasq.conf
log-facility = /var/log/neutron/dnsmasq.log
log-dhcp
log-queries

~# neutron dhcp-agent-list-hosting-net private
+--------------------------------------+---------+----------------+-------+
| id                                   | host    | admin_state_up | alive |
+--------------------------------------+---------+----------------+-------+
| 5e5f2ebd-21ab-46b8-b988-a5e7b22faef5 | arkelia | True           | :-)   |
+--------------------------------------+---------+----------------+-------+

~# ip netns
qrouter-aece5a62-c67a-422d-b056-e89695363722
qdhcp-528cb077-d7f6-488b-aa4f-f09c675b87f2

Edit:

Interfaces names have changed since the first post but the layout is ... (more)

edit retag flag offensive close merge delete

2 answers

Sort by » oldest newest most voted
1

answered 2015-03-26 01:07:08 -0500

You have tag 4095

Bridge br-int
        fail_mode: secure
        Port "tape24a0ace-d7"
            tag: 4095
            Interface "tape24a0ace-d7"

Tag 4095 is dead tag, so detect which qdhcp-namespace it belongs.
or from where did it come.
If it will appear in ip netns exec qdhcp-net-id ifconfig then recreate this private network.

edit flag offensive delete link more

Comments

Thanks for your answer, I wouldn't have noticed it by myself. This problem is fixed now. I'v added a schema to my question for a better understanding of the situation. I made a tcpdump on the interfaces I can to trace the DHCP request from the VM. But packets still doesn't get to the DHCP interface.

savril gravatar imagesavril ( 2015-03-28 16:33:29 -0500 )edit
0

answered 2015-03-28 22:27:42 -0500

savril gravatar image

Well, I have deleted the private network via the Horizon interface and done a rerun of puppet to recreate this network and it worked. The cirrus journal show that it correctly receive a DHCP response.

However, doing a ip netns exec {dhcp_ns} tcpdump -i {dnsmasq_interface} doesn't work. It show no output at all. On the tcpdump -i br-int, I can see the DHCP request but not the response.

That a bit weird to debug...

edit flag offensive delete link more

Comments

Activate dnsmasq logging and see for yourself normal icmp traffic.

Run just tcpdump -vv -i tap-interface not inside NS

andrew.shvartz gravatar imageandrew.shvartz ( 2015-03-29 01:43:51 -0500 )edit

Unfortunately I can't. This tap interface is not visible outside its NS. And as my problem is solved now by recreating the private network, I can't recreate the bogus situation I was in to debug what caused that issue.

Thanks for your help.

savril gravatar imagesavril ( 2015-03-29 08:26:50 -0500 )edit

try -l with tcpdump - line buffering seems to be needed in namespaces siometimes. The dhcp request is a broadcast, so all ports in the vlan see it, and port br-int as it is trunk. The reply is a unicast so you would not see it on other ports

darragh-oreilly gravatar imagedarragh-oreilly ( 2015-03-29 13:45:35 -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

1 follower

Stats

Asked: 2015-03-25 19:43:47 -0500

Seen: 1,472 times

Last updated: Mar 28 '15