What listen-address should dnsmasq use?

Asked by Adrian Smith

Looking at the code it appears that nova uses the network's gateway address as the 'listen-address' for dnsmasq. It get's this gateway address from the database.

In my setup the network is 192.168.42.0/24. This results in nova starting dnsmasq with the listen-address 192.168.42.1.

The dnsmasq processes look like this,

dnsmasq --strict-order --bind-interfaces --conf-file= --domain=novalocal --pid-file=/var/lib/nova/networks/nova-br100.pid --listen-address=192.168.42.1 --except-interface=lo --dhcp-range=192.168.42.2,static,120s --dhcp-hostsfile=/var/lib/nova/networks/nova-br100.conf --dhcp-script=/usr/bin/nova-dhcpbridge --leasefile-ro

Using this setup I can see DHCP requests coming in (using tcpdump) but there's no response going out. I'm not sure why dnsmasq doesn't see these packets but as an experiment I changed the 'gateway' in the database to the IP addres of the machine running dnsmasq, i.e. '192.168.110.10'.

After killing all the dnsmasq processes and restarting nova-network here's what dnsmasq looks like,

dnsmasq --strict-order --bind-interfaces --conf-file= --domain=novalocal --pid-file=/var/lib/nova/networks/nova-br100.pid --listen-address=192.168.110.10 --except-interface=lo --dhcp-range=192.168.42.2,static,120s --dhcp-hostsfile=/var/lib/nova/networks/nova-br100.conf --dhcp-script=/usr/bin/nova-dhcpbridge --leasefile-ro

Using this setup dnsmasq does return an ip address. Ot at least it appears to. Here's the output of 'tcpdump -i br100 port 67 or 68',

16:28:22.971744 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 02:16:3e:33:52:b8 (oui Unknown), length 280
16:28:22.972356 IP 192.168.42.1.bootps > 192.168.42.4.bootpc: BOOTP/DHCP, Reply, length 315

The problem is the compute node, and hence the VM, isn't receiving this response. I'm not sure is this is due to my messing about with dnsmasq or (more likely) a network issue. In either case I'm stumped.

Any ideas?

Question information

Language:
English Edit question
Status:
Solved
For:
OpenStack Compute (nova) Edit question
Assignee:
No assignee Edit question
Solved by:
Vish Ishaya
Solved:
Last query:
Last reply:
Revision history for this message
Tim Lawrence (tim-lawrence-d) said :
#1

What OS is the instance you are launching?
 I see the same behaviour with an Windows instance but not with my UEC-Ubuntu instance.. It's really weird!
Also there is a DHCP server on my public network which is leasing addresses to the Windows instances but not to the Ubuntu ones (which succesfully lease an address from DNSMASQ)

It's driving me crazy!

Revision history for this message
Adrian Smith (adriansmith) said :
#2
Revision history for this message
Vish Ishaya (vishvananda) said :
#3

If the response comes from a different ip than the gateway it will be blocked by the compute host firewall rules. My guess is your ips were out of order on br100. Nova attempts to make the gateway address the first ip on the bridge, but in some situations they will be reversed. Usually this happens when you manually add the ip to the bridge instead of letting nova move it from the eth device. When the addresses are out of order, dnsmasq doesn't respond properly.

You should be able to fix it by changing the gateway back and ensuring that 192.168.42.1/24 is the first ip listed on the bridge.

Vish
On Jun 27, 2011, at 7:46 AM, Adrian Smith wrote:

> New question #162919 on OpenStack Compute (nova):
> https://answers.launchpad.net/nova/+question/162919
>
> Looking at the code it appears that nova uses the network's gateway address as the 'listen-address' for dnsmasq. It get's this gateway address from the database.
>
> In my setup the network is 192.168.42.0/24. This results in nova starting dnsmasq with the listen-address 192.168.42.1.
>
> The dnsmasq processes look like this,
>
> dnsmasq --strict-order --bind-interfaces --conf-file= --domain=novalocal --pid-file=/var/lib/nova/networks/nova-br100.pid --listen-address=192.168.42.1 --except-interface=lo --dhcp-range=192.168.42.2,static,120s --dhcp-hostsfile=/var/lib/nova/networks/nova-br100.conf --dhcp-script=/usr/bin/nova-dhcpbridge --leasefile-ro
>
> Using this setup I can see DHCP requests coming in (using tcpdump) but there's no response going out. I'm not sure why dnsmasq doesn't see these packets but as an experiment I changed the 'gateway' in the database to the IP addres of the machine running dnsmasq, i.e. '192.168.110.10'.
>
> After killing all the dnsmasq processes and restarting nova-network here's what dnsmasq looks like,
>
> dnsmasq --strict-order --bind-interfaces --conf-file= --domain=novalocal --pid-file=/var/lib/nova/networks/nova-br100.pid --listen-address=192.168.110.10 --except-interface=lo --dhcp-range=192.168.42.2,static,120s --dhcp-hostsfile=/var/lib/nova/networks/nova-br100.conf --dhcp-script=/usr/bin/nova-dhcpbridge --leasefile-ro
>
> Using this setup dnsmasq does return an ip address. Ot at least it appears to. Here's the output of 'tcpdump -i br100 port 67 or 68',
>
> 16:28:22.971744 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 02:16:3e:33:52:b8 (oui Unknown), length 280
> 16:28:22.972356 IP 192.168.42.1.bootps > 192.168.42.4.bootpc: BOOTP/DHCP, Reply, length 315
>
> The problem is the compute node, and hence the VM, isn't receiving this response. I'm not sure is this is due to my messing about with dnsmasq or (more likely) a network issue. In either case I'm stumped.
>
> Any ideas?
>
>
> --
> You received this question notification because you are a member of Nova
> Core, which is an answer contact for OpenStack Compute (nova).

Revision history for this message
Adrian Smith (adriansmith) said :
#4

That's exactly what I ended up doing Vish.

The machines IP, 192.168.110.10, was the first IP on br100. By deleting it and adding it back in it went to the bottom leaving the gateway address as the first.

ip addr d 192.168.110.10/16 dev br100
ip addr a 192.168.110.10/16 dev br100

The only problem is I need to do this each time I reboot. I'm letting nova do everything itself but it's still not setting up the order of the IPs correctly.

Revision history for this message
Best Vish Ishaya (vishvananda) said :
#5

Well that is odd. It usually does it fine when it moves it from the eth device. You can always set up /etc/network interfaces to manually create br100 and move the ip when it comes up like i suggested here:

https://answers.launchpad.net/nova/+question/162494

just put in 192.168.110.10/16 for the 188.x address and set the netmask properly

You could also probably save a del command by adding the .42 address as the main address and just adding the 110 address on if up.

Vish

On Jul 7, 2011, at 8:11 AM, Adrian Smith wrote:

> Question #162919 on OpenStack Compute (nova) changed:
> https://answers.launchpad.net/nova/+question/162919
>
> Adrian Smith posted a new comment:
> That's exactly what I ended up doing Vish.
>
> The machines IP, 192.168.110.10, was the first IP on br100. By deleting
> it and adding it back in it went to the bottom leaving the gateway
> address as the first.
>
> ip addr d 192.168.110.10/16 dev br100
> ip addr a 192.168.110.10/16 dev br100
>
> The only problem is I need to do this each time I reboot. I'm letting
> nova do everything itself but it's still not setting up the order of the
> IPs correctly.
>
> --
> You received this question notification because you are a member of Nova
> Core, which is an answer contact for OpenStack Compute (nova).

Revision history for this message
Adrian Smith (adriansmith) said :
#6

Thanks Vish Ishaya, that solved my question.