[Dnsmasq-discuss] DHCP, how to ignore the client MAC address?

john doe johndoe65534 at mail.com
Sat Jan 12 06:48:35 GMT 2019


On 1/11/2019 8:48 PM, Michael Schleicher wrote:
> Hi Geert,
> 
> thanks for you mail.
> 
> On 1/11/19 6:50 PM, Geert Stappers wrote:
>> On Fri, Jan 11, 2019 at 11:29:13AM +0100, MIchael Schleicher (smicha) wrote:
>>> On 11.01.19 10:53, john doe wrote:
>>>> On 1/11/2019 9:49 AM, MIchael Schleicher (smicha) wrote:
>>>>>
>>>>> I have just checked on my environment what's in the dnsmasq.leases file:
>>>>>
>>>>> 1547246444 00:50:56:85:23:ea 10.198.10.223 win-vm 01:00:50:56:85:23:ea
>>>>> 1547276503 00:50:56:85:f1:86 10.198.10.37 linux-vm 01:00:50:56:85:f1:86
>>>>>
>>>>> As you see the Client-ID (5th field) is the MAC + "01:" as prefix.
>>>>>
>>>>
>>>> You previously said that the hostname is always the same, as ilustrated
>>>> by the above they are not (win-vm vs linux-vm)?
>>>>
>>>
>>> That are 2 different systems. (1 Windows and 1 Linux VM). It's just a
>>> example
>>>
>>
>> Thing I would like to known is the name of the virtualisation platform.
>> Mostly because all those I seen did allow me to define MAC address.
>>
> 
> The virtual landscapes (VM's) are running on VMware ESX Cluster.
> The ESX Hosts are "controlled" by a software which called
> "eCloud-Manager". That are deploying the different clones of landscapes.
> 
> We have a bunch of master VM's and the software deploy that VM's in
> different isolated landscapes. (each landscape is isolated with vlans
> and includes a copy of the Masters (but with different MAC as the Master
> VM's have!).
> 
> So, when a cloned VM in one of the virtual landscapes are crash or have
> some other problems, the software destorys the VM and deploy a copy of
> the Master-VM, with a different MAC to that landscapes.
> 
> And that is exactly the problem, during the deployment of that cloned VM
> from the Master, the MAC will changed from the eCloud-Manager during the
> VMWare deployment.
> 
> I hope I gave you a understandable description.
> 

If the maintaner of dnsmasq has not chimed in that leav us with to options:
- To much on his plate, something could be done to answer this question.
- The issue lies elsewhere (predicting way for MAC addressing).

-- 
John Doe



More information about the Dnsmasq-discuss mailing list