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:sh...@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 <jvanliesh...@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" <sh...@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 <sh...@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 > >
