[Dnsmasq-discuss] Best way to assign different static IPs on different VLANs?
ronf at timeheart.net
Wed Jul 8 01:48:34 BST 2009
On 7/6/09 12:56 PM, richardvoigt at gmail.com wrote:
> On Mon, Jul 6, 2009 at 1:38 PM, Ron Frederick<ronf at timeheart.net> wrote:
>> On 7/4/09 6:47 PM, richardvoigt at gmail.com wrote:
>>> dnsmasq will only consider address matches from the same subnet as the
>>> local IP address(es) on the interface where the request arrived.
>>> But you may have to use dnsmasq configuration (dhcp-host) instead of
>>> /etc/ethers, because as you say /etc/ethers doesn't provide space for
>>> multiple IPs. dhcp-host can match based on MAC address instead of
>>> client id.
>> Thanks for the suggestion. This is actually the first thing I tried, but
>> it didn't work. I think the reason is that the later dhcp_host line
>> overrides the earlier one when they both have the same MAC address
>> listed. What you suggest would have worked fine (with no special
>> configuration) if I was willing to accept a dynamic IP, but it won't
>> work for static IPs. It worked with client IDs because I was able to
>> make the names different, preventing the rules from clashing with one
>> After doing some more reading, I think the option I need is the
>> "dhcp-fqdn" option in dnsmasq 2.46, possibly combined with the support
>> there for the ability to associate domains with specific subnets.
>> Unfortunately, I'm currently running an older release of dnsmasq (2.35)
>> on my Linksys router, so I've been unable to try this yet. If I'm
>> reading things right, though, this would let me put the unqualified name
>> in /etc/ethers and have qualified names in two different domains in
>> /etc/hosts and have dnsmasq assign the right IP depending on which
>> domain was associated with the subnet the request arrived on. Can anyone
>> confirm this for me?
>> Is there any way to get this kind of behavior with pre-2.46 dnsmasq? It
>> looked to me at one point like "localise-queries" might have been enough
>> here, but that didn't seem to be enough.
> Worst case scenario, you could run separate instances of dnsmasq, one
> for each VLAN. Then each would have its own configuration file and
> distinct sets of dhcp-host settings.
That's true, but I'd then have to split things out into multiple hosts
files for each instance, or just move away from that entirely and keep
everything in the config file. I was really hoping to be able to stick
with the simplicity of getting mappings out of /etc/hosts and /etc/ethers.
I compiled my own version of dnsmasq 2.49 for my Linksys today so that I
could try out the new domain features, but I'm still not able to get it
to work right when using /etc/hosts...
After reading through the source code and adding some debugging info, I
think I have figured out at least one issue. It seems that address
information in /etc/hosts is only read in for config entries which
already exist. So, if you have a short name in /etc/ethers and then you
add fully qualified names in /etc/hosts, those fully qualified names are
not added to the config. However, if you add similar entries directly in
the config file using dhcp-host directives, things work correctly and IP
addresses associated with those fully qualified names are properly
assigned as static IPs. In order for dnsmasq to do what I want here, it
would need to add entries for everything it finds in /etc/hosts, whether
it matched an existing config entry or not, the way it currently does
when reading ethers.
I'm also seeing another problem which I haven't fully tracked down yet.
The entries being written to the DHCP leases file still only have the
short name in them. As a result, only one entry in the leases file is
added for my multi-homed host. Whenever it tries to renew its other
address, it gets back a NAK the first time and has to go through another
DISCOVER phase. At that point, the proper address is assigned, but
dnsmasq deletes the other address in the process, causing the leases
table to thrash back and forth instead of properly remembering that both
addresses are legitimately assigned to this host.
A quick look at the lease_update_file routine tells me that it isn't
even trying to write out the fqdn, even when one is stored in the lease
entry. It appears to only ever write the hostname. The in-memory data
structure should still be correct at least until dnsmasq restarts,
though, so that doesn't fully explain the NAK problem I mention above...
ronf at timeheart.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Dnsmasq-discuss