cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joris van Lieshout <JvanLiesh...@schubergphilis.com>
Subject RE: Review Request 18310: dnsmasq fix for bridged networks
Date Tue, 25 Feb 2014 06:53:52 GMT
Hi Sheng,

Based on your feedback I did some testing and it appears that the issue is not with offering
addresses but with dhcp-options. The static option indeed prevents addresses being leased
to unknown macs but it does not prevent other dhcp-options, like dns servers, to be handed
out. So far I have not been able to find any supporting documentation on this behavior but
perhaps this explanation is sufficient.

What happens is that dhcp client on the other side of the bridge (physical Lan) don't get
addresses from dnsmasq on the RVM but do get dhcp-option 6 from the dnsmasq on the RVM.

This is a bit of (scrutinized) logging where "dhcp-ignore=tag:!known" has been disabled (so
here non ACS hosts are getting dns server settings from the RVM):
Feb 25 00:00:00 dnsmasq-dhcp[5017]: DHCPINFORM(eth0) 10.xxx.xxx.104 xx:xx:xx:xx:xx:xx 
Feb 25 00:00:00 dnsmasq-dhcp[5017]: DHCPACK(eth0) 10.xxx.xxx.104 xx:xx:xx:xx:xx:xx LAPTOP001

And here with "dhcp-ignore=tag:!known" enabled:
Feb 25 00:00:00 dnsmasq-dhcp[5079]: DHCPINFORM(eth0) 10.xxxx.xxxx.104 xx:xx:xx:xx:xx:xx ignored

In both cases the dhcp-range option is set to by ACS:
dhcp-range=10.xxx.xxx.1,static

Kind regards, 
Joris van Lieshout

-----Original Message-----
From: Sheng Yang [mailto:sheng@yasker.org] 
Sent: maandag 24 februari 2014 23:30
To: Joris van Lieshout
Cc: daan Hoogland; Hugo Trippaers; cloudstack
Subject: Re: Review Request 18310: dnsmasq fix for bridged networks

Yes, it would provide extra failsafe.

But the issue is if there is anything wrong, this patch may or may not
prevent it. So I think it's necessary to identify the root cause
first.

The dhcp-range option already specified as "static" which means:

<quote>
The optional <mode> keyword may be static which tells dnsmasq to
enable DHCP for the network specified, but not to dynamically allocate
IP addresses: only hosts which have static addresses given via
dhcp-host or from /etc/ethers will be served. A static-only subnet
with address all zeros may be used as a "catch-all" address to enable
replies to all Information-request packets on a subnet which is
provided with stateless DHCPv6, ie --dhcp=range=::,static
</quote>

So it should already served the purpose.

--Sheng

On Sat, Feb 22, 2014 at 9:28 AM, Joris van Lieshout
<JvanLieshout@schubergphilis.com> wrote:
> Hi Sheng,
>
> First of thanks you for reviewing my first attempt to contribute :) and
> sorry for my late response. I want to gadder a bit more info because I've
> seen it hand out adresses. Besides that this setting should at least provide
> an extra failsafe.
>
> Regards, Joris
>
> Sent from my iPhone
>
> On 21 feb. 2014, at 20:00, "Sheng Yang" <sheng@yasker.org> wrote:
>
> Hi Joris,
>
> This patch hasn't been applied yet, sorry for my second thought.
>
> Could you comment on it?
>
> --Sheng
>
>
> On Thu, Feb 20, 2014 at 10:29 AM, Sheng Yang <sheng@yasker.org> wrote:
>>
>> This is an automatically generated e-mail. To reply, visit:
>> https://reviews.apache.org/r/18310/
>>
>> On February 20th, 2014, 6:17 p.m. UTC, Sheng Yang wrote:
>>
>> Looks good to me.
>>
>> Also I've confirmed that even with this option, the MAC would show in
>> dnsmasq.log, which is necessary for debug.
>>
>> Applied to MASTER. Thanks!
>>
>> On February 20th, 2014, 6:28 p.m. UTC, Sheng Yang wrote:
>>
>> One moment, on a second thought, even with current setup, dnsmasq won't
>> hand out IP to unknown host. So why this option is needed?
>>
>> And the log would show "DHCPDISCOVER(eth0) 02:01:3a:d9:00:02 no address
>> available" instead of "DHCPDISCOVER(eth0) 02:01:3a:d9:00:02 ignored" with
>> the option.
>>
>> Is there anything I missed?
>>
>> And the patch hasn't been applied yet...
>>
>>
>> - Sheng
>>
>>
>> On February 20th, 2014, 2:01 p.m. UTC, Joris van Lieshout wrote:
>>
>> Review request for cloudstack, daan Hoogland, Hugo Trippaers, and Sheng
>> Yang.
>> By Joris van Lieshout.
>>
>> Updated Feb. 20, 2014, 2:01 p.m.
>>
>> Repository: cloudstack-git
>>
>> Description
>>
>> When a ACS network is bridged to another non-ACS network (for instance
>> using a NSX Bridge) this will prevent dnsmasq from responding to requests
>> from the other network that have traversed the bridge.
>>
>> Testing
>>
>> We have been running this fix on our own version of the 4.2 and 3.0 SVM
>> for a couple months with success.
>>
>> Diffs
>>
>> systemvm/patches/debian/config/etc/dnsmasq.conf.tmpl (07c5902)
>>
>> View Diff
>
>

Mime
View raw message