[Pacemaker] Dnsmasq

Gregg Stock gregg at damagecontrolusa.com
Sat Mar 24 16:43:44 EDT 2012

Thank you for the responses.

It turned out to be pilot error. I had a virtual machine that was 
running dnsmasq on the same IP address that was not part of the cluster. 
I had entered poweroff at the command line and then started bringing up 
the new DNS server. It turns out that the old server was still running. 
I was able to grab a wire shark message about duplicate IP addresses 
that led me to the answer.

Strange that the Linux hosts didn't care. I don't know enough to say if 
that's a bug or a feature.

Best regards,
Gregg Stock

On 3/23/2012 7:27 PM, Trevor Hemsley wrote:
> I'd guess that your replies are going back with the wrong source IP
> address on them and the Windows clients are being picky about accepting
> them. Perhaps you need to investigate ocf:heartbeat:IPsrcaddr
> On 24/03/12 01:35, Gregg Stock wrote:
>> I'm have some "interesting" behavior with a pacemaker managed DNS
>> server.  Here is the basic setup:
>> primitive p_dnsmasq lsb:dnsmasq \
>>           op monitor interval="60s" timeout="30s"
>> primitive p_ip_dnsmasq ocf:heartbeat:IPaddr2 \
>>           params ip="" cidr_netmask="24" \
>>           op monitor interval="10s"
>> order o_ip_before_dns inf: p_ip_dnsmasq p_dnsmasq
>> The cluster seems to manage the resource ok.
>> If the dnsmasq server is running on the hosts regular ip address,
>> everything is fine. When switching to the cluster managed ip address, I
>> get the following behavior on our network. The behavior was the same for
>> various permutation of the listening addresses in the dnsmasq.conf file.
>> 1. Linux hosts are fine.
>> 2. Windows and Mac hosts can ping the DNS server but don't get DNS
>> service. I was able to verify that the requests were getting to the DNS
>> server but the replies were getting and ICMP destination unreachable on
>> the way back.
>> I was able fine a tidbit of information here
>> http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2010q2/003906.html
>>           A destination unreachable ICMP reply is normally generated by
>> the kernel
>>           when there is nothing listening on that port. The most likely
>> reason for
>>           that is that the dnsmasq process no longer exists. If that's
>> the case
>>           the problem changes into "find why the dnsmasq daemon is exiting".
>> This doesn't seem to be completely applicable because the dnsmasq daemon
>> is running.
>> Any additional information required?
>> Thanks in advance.
>> Best regards,
>> Gregg Stock
>> _______________________________________________
>> Pacemaker mailing list: Pacemaker at oss.clusterlabs.org
>> http://oss.clusterlabs.org/mailman/listinfo/pacemaker
>> Project Home: http://www.clusterlabs.org
>> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
>> Bugs: http://bugs.clusterlabs.org

More information about the Pacemaker mailing list