You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Joris van Lieshout <jv...@schubergphilis.com> on 2014/02/20 15:01:23 UTC
Review Request 18310: dnsmasq fix for bridged networks
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/18310/
-----------------------------------------------------------
Review request for cloudstack, daan Hoogland, Hugo Trippaers, and Sheng Yang.
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.
Diffs
-----
systemvm/patches/debian/config/etc/dnsmasq.conf.tmpl 07c5902
Diff: https://reviews.apache.org/r/18310/diff/
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.
Thanks,
Joris van Lieshout
Re: Review Request 18310: dnsmasq fix for bridged networks
Posted by Sheng Yang <sh...@yasker.org>.
> On Feb. 20, 2014, 6:17 p.m., 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!
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?
- Sheng
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/18310/#review35021
-----------------------------------------------------------
On Feb. 20, 2014, 2:01 p.m., Joris van Lieshout wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/18310/
> -----------------------------------------------------------
>
> (Updated Feb. 20, 2014, 2:01 p.m.)
>
>
> Review request for cloudstack, daan Hoogland, Hugo Trippaers, and Sheng Yang.
>
>
> 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.
>
>
> Diffs
> -----
>
> systemvm/patches/debian/config/etc/dnsmasq.conf.tmpl 07c5902
>
> Diff: https://reviews.apache.org/r/18310/diff/
>
>
> 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.
>
>
> Thanks,
>
> Joris van Lieshout
>
>
RE: Review Request 18310: dnsmasq fix for bridged networks
Posted by Joris van Lieshout <Jv...@schubergphilis.com>.
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 <Jv...@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
> <Jv...@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
>>
>>
Re: Review Request 18310: dnsmasq fix for bridged networks
Posted by Sheng Yang <sh...@yasker.org>.
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
<Jv...@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
> <Jv...@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
>>
>>
RE: Review Request 18310: dnsmasq fix for bridged networks
Posted by Joris van Lieshout <Jv...@schubergphilis.com>.
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
<Jv...@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
>
>
Re: Review Request 18310: dnsmasq fix for bridged networks
Posted by Sheng Yang <sh...@yasker.org>.
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
<Jv...@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
>
>
Re: Review Request 18310: dnsmasq fix for bridged networks
Posted by Joris van Lieshout <Jv...@schubergphilis.com>.
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<https://reviews.apache.org/r/18310/diff/>
Re: Review Request 18310: dnsmasq fix for bridged networks
Posted by Joris van Lieshout <Jv...@schubergphilis.com>.
Hi Sheng,
First of thank you for reviewing my first attempt to contribu
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<https://reviews.apache.org/r/18310/diff/>
Re: Review Request 18310: dnsmasq fix for bridged networks
Posted by Sheng Yang <sh...@yasker.org>.
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 <https://reviews.apache.org/r/18310/diff/>
>
Re: Review Request 18310: dnsmasq fix for bridged networks
Posted by Sheng Yang <sh...@yasker.org>.
> On Feb. 20, 2014, 6:17 p.m., 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!
>
> 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
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/18310/#review35021
-----------------------------------------------------------
On Feb. 20, 2014, 2:01 p.m., Joris van Lieshout wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/18310/
> -----------------------------------------------------------
>
> (Updated Feb. 20, 2014, 2:01 p.m.)
>
>
> Review request for cloudstack, daan Hoogland, Hugo Trippaers, and Sheng Yang.
>
>
> 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.
>
>
> Diffs
> -----
>
> systemvm/patches/debian/config/etc/dnsmasq.conf.tmpl 07c5902
>
> Diff: https://reviews.apache.org/r/18310/diff/
>
>
> 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.
>
>
> Thanks,
>
> Joris van Lieshout
>
>
Re: Review Request 18310: dnsmasq fix for bridged networks
Posted by Sheng Yang <sh...@yasker.org>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/18310/#review35021
-----------------------------------------------------------
Ship it!
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!
- Sheng Yang
On Feb. 20, 2014, 2:01 p.m., Joris van Lieshout wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/18310/
> -----------------------------------------------------------
>
> (Updated Feb. 20, 2014, 2:01 p.m.)
>
>
> Review request for cloudstack, daan Hoogland, Hugo Trippaers, and Sheng Yang.
>
>
> 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.
>
>
> Diffs
> -----
>
> systemvm/patches/debian/config/etc/dnsmasq.conf.tmpl 07c5902
>
> Diff: https://reviews.apache.org/r/18310/diff/
>
>
> 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.
>
>
> Thanks,
>
> Joris van Lieshout
>
>
Re: Review Request 18310: dnsmasq fix for bridged networks
Posted by Sheng Yang <sh...@yasker.org>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/18310/#review35020
-----------------------------------------------------------
Ship it!
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!
- Sheng Yang
On Feb. 20, 2014, 2:01 p.m., Joris van Lieshout wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/18310/
> -----------------------------------------------------------
>
> (Updated Feb. 20, 2014, 2:01 p.m.)
>
>
> Review request for cloudstack, daan Hoogland, Hugo Trippaers, and Sheng Yang.
>
>
> 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.
>
>
> Diffs
> -----
>
> systemvm/patches/debian/config/etc/dnsmasq.conf.tmpl 07c5902
>
> Diff: https://reviews.apache.org/r/18310/diff/
>
>
> 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.
>
>
> Thanks,
>
> Joris van Lieshout
>
>
Re: Review Request 18310: dnsmasq fix for bridged networks
Posted by Sheng Yang <sh...@yasker.org>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/18310/#review35481
-----------------------------------------------------------
Ship it!
After discussion, we found it's due to ack to DHCPINFORM request, not DHCPREQUEST/DHCPDISCOVER. And the option would stop that ack.
Applied to MASTER. Thanks!
- Sheng Yang
On Feb. 20, 2014, 2:01 p.m., Joris van Lieshout wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/18310/
> -----------------------------------------------------------
>
> (Updated Feb. 20, 2014, 2:01 p.m.)
>
>
> Review request for cloudstack, daan Hoogland, Hugo Trippaers, and Sheng Yang.
>
>
> 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.
>
>
> Diffs
> -----
>
> systemvm/patches/debian/config/etc/dnsmasq.conf.tmpl 07c5902
>
> Diff: https://reviews.apache.org/r/18310/diff/
>
>
> 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.
>
>
> Thanks,
>
> Joris van Lieshout
>
>