[Dnsmasq-discuss] 'shared-network' behavior would be huge

Mon Apr 1 17:55:49 BST 2019

On 01/04/2019 16:33, Ryan Gray wrote:
> Update on testing the new shared-network configuration:  My lab
> network is the happiest network right now. This is great.
> 
> A few clarifications: I needed to set the source part of the
> shared-network parameter to the IP of my relay, not the IP or
> interface of my dnsmasq server. 

That's expected (and documented) if you're running a relay. In this
case, the only information about which physical network the client is on
is the relay address inserted into the DHCP request by the relay.

> My dnsmasq server is at 10.200.200.1
> which is bound to its br0 interface. My dhcp relay (Brocade switch)
> holds the gateways for VLANs that need DHCP. The one I'm testing is a
> vlan with an IP interface of 192.168.127.254/24 and a subinterface
> 192.168.128.254/24, so all requests from that VLAN are coming from
> 192.168.127.254.
> 
> I added this to my config:
> 
> shared-network=192.168.127.254,192.168.128.0
> 
> And it works!  I am even successfully handing out some addresses based
> on nothing other than their subscriber-id (whole different talk show),
> and it's now working.
> 
> What if I know that an interface is going to have multiple 'gateway'
> IPs, but I'm not sure which one the switch/router will be using as its
> source. In the example above, if I don't know whether or not the
> requests will be coming from .127.254 or .128.254, can I safely just
> have a 'shared-network' config line for each even though one will be a
> bit redundant (shared-network=192.168.127.254,192.168.127.0)?

Yes, that should work fine.

Cheers,

Simon.

> 
> So far, this is really great. Thank you so much.
> 
> 
> Regards,
> Ryan Gray
> 
> On Sun, Mar 31, 2019 at 5:13 PM Simon Kelley <simon at thekelleys.org.uk> wrote:
>>
>>
>>
>> On 30/03/2019 18:33, Ryan Gray wrote:
>>> TLDR; How do I use "shared-network" exactly?  :)
>>>
>>> Everything compiled and is up and running with no changes to my
>>> existing configs or method of execution. I'm a little unclear about
>>> how to hold this tool.
>>>
>>> Assuming a router interface of 192.168.4.126/25 and no sub interfaces,
>>> I typically do something like this:
>>>
>>> dhcp-range=set:"internet-192_168_4_0_25",192.168.4.1,192.168.4.125,255.255.255.128,1h
>>> tag-if=set:internet-pool,tag:internet-192_168_4_0_25
>>> dhcp-option=tag:"internet-192_168_4_0_25",3,192.168.4.126
>>> dhcp-option=tag:"internet-192_168_4_0_25",1,255.255.255.128
>>> dhcp-option=tag:"internet-192_168_4_0_25",5,8.8.8.8
>>>
>>> If I add another gateway IP to that router interface (I use "gateway
>>> IP" loosely), 192.168.5.0/24 and  and assuming the router with the
>>> ip-helper configured is, by default, going to say "hey, I'm
>>> 192.168.4.126". With ISC, having ranges for 192.168.4.1-125 and
>>> 192.168.5.1-253 within the block of config that defines a
>>> shared-network would make things copacetic.
>>>
>>> The question:  In this scenario, am I to start dnsmasq with
>>> "--shared-network=192.168.4.126,192.168.5.0"    ?   If so, I'm not
>>> sure if my subnet definition strategy above is going to stay the same
>>> because I'm not sure how dnsmasq is going to treat this in regards to
>>> tags.  Perhaps I'm just looking at this sideways.
>>>
>>
>>
>> You need to have something like
>>
>> shared-network=192.168.4.1,192.168.5.0
>>
>> assuming that the interface on the machine running dnsmasq is 192.168.4.1
>>
>> or
>>
>> shared-network=eth0,192.168.5.0
>>
>> assuming that the interface is so-named.
>>
>> Either of these will allow dnsmasq to allocate addresses on the sunnet
>> that includes 192.168.5.0, but to make that happen you need a dhcp-range
>> which tells it which addresses are available. This dhcp-range MUST have
>> the netmask: normally dnsmasq can figure out the netmask, but it doesn't
>> have enough information in this case.
>>
>> You can set tag in the dhcp-range, as before, and use it to control the
>> DHCP options sent to the client (which should include router, as the
>> normal default route option won't be sent.
>>
>>
>> Simon.
>>
>>
>>
>>> On Fri, Mar 29, 2019 at 4:13 PM Simon Kelley <simon at thekelleys.org.uk> wrote:
>>>>
>>>> On 29/03/2019 20:36, Ryan Gray wrote:
>>>>> Hello other humans,
>>>>>
>>>>> First, Simon Kelly, thank you for dnsmasq.
>>>>>
>>>>> I noticed here
>>>>> http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2018q4/012700.html
>>>>> that there was discussion of the possibility of supporting behavior like
>>>>> ISC's 'shared-network'. Did this go anywhere? I would absolutely use
>>>>> this and would be happy to perform any testing that would help. I didn't
>>>>> see other mentions of this so I thought I'd ask.
>>>>>
>>>>> Dead serious, this would be spectacular.
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> Today (actually, yesterday) is your lucky day:
>>>>
>>>> http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=ae5b7e04a1025167f1b80840e61432a3cea9625c
>>>>
>>>> Do please test!
>>>>
>>>>
>>>> Simon
>>>>
>>>>
>>>>> Regards,
>>>>> Ryan Gray
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Dnsmasq-discuss mailing list
>>>>> Dnsmasq-discuss at lists.thekelleys.org.uk
>>>>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Dnsmasq-discuss mailing list
>>>> Dnsmasq-discuss at lists.thekelleys.org.uk
>>>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>>>
> 