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 Wed, 26 Feb 2014 08:42:49 GMT
Cool! Thanks :)

Kind regards, 
Joris van Lieshout


Schuberg Philis
Boeingavenue 271
1119 PD  Schiphol-Rijk
schubergphilis.com 

+31 207506672
+31651428188
_____________________ 


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

Yes, that make sense.

DHCPINFORM wouldn't limited by "static", and seems Windows likes using it.

Would apply the patch.

Thanks.

--Sheng

On Mon, Feb 24, 2014 at 10:53 PM, Joris van Lieshout <JvanLieshout@schubergphilis.com>
wrote:
> 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