cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sheng Yang <sh...@yasker.org>
Subject Re: Review Request 18310: dnsmasq fix for bridged networks
Date Tue, 25 Feb 2014 22:51:22 GMT
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