Cloned virtualbox image gets the same IP

[Michael Pope]

Hello MLUG,

I've cloned a virtualbox image today and when it boots up it's getting
the same IP.

I've made sure that I've set the bridged network adapter to a different
MAC address and I've booted my guest Ubuntu 10.04.3 system and tried to
force the dhclient to get a new IP with the following commands:

dhclient -r eth0
dhclient eth0

and
ifconfig eth0 down
ifconfig eth0 up

This didn't work.

My DHCP server is on a FreeBSD 7.0 machine is there anything I have to
tell it to do?
Should changing the MAC address on a virtual bridged network adapter be
enough for it to ask for a new IP?
Am I missing something simple here?

from
Mick

[Chris Lange]

Maybe your DHCP server is assigning the same IP based on the hostname?

> --
> You received this message because you are subscribed to the Google Groups "mlug-au" group.
> To post to this group, send email to mlu...@googlegroups.com.
> To unsubscribe from this group, send email to mlug-au+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/mlug-au?hl=en.
>

[Michael Pope]

I just changed the hostname and it's still getting the same IP
$ sudo hostname mymachine
$ sudo dhclient eth0 -r
$ sudo dhclient eth0

from
Mick

[Chris Lange]

What does your DHCP server log say?

Maybe its gone and associated the new MAC with the old hostname?

Certainly sounds wierd. I've only ever dealt with DHCP servers that lease IP's based on MAC addresses.

[Michael Pope]

Here is the log in the dhcpd.leases file when I do a dhclient -r
command:
lease 192.168.200.212 {
starts 5 2012/10/19 05:01:15;
ends 5 2012/10/19 05:14:38;
tstp 5 2012/10/19 05:14:38;
binding state free;
hardware ethernet 08:00:27:ed:0a:68;
}

Here is when I ask for the IP again with 'dhclient eth0'
lease 192.168.200.212 {
starts 5 2012/10/19 05:16:12;
ends 6 2012/10/20 01:16:12;
binding state active;
next binding state free;
hardware ethernet 08:00:27:ed:0a:68;
client-hostname "mymachine";
}

from
Michael

[Chris Lange]

To me that says that .212 is being free'd back into the pool of available IP's and just being dished out again once "another" client asks for a lease. Seems like your DHCP server isn't configured for persistent leases.

[Michael Pope]

Got it working, I freed it up on one server then shutdown both servers.
Then I booted the server I wanted to be on 212, it got that as I
haven't changed anything on that server at all.

Then on the second server I booted that up and it got a new IP.

I think when I first booted both servers and they had the same MAC
address then it had the same IP. Then I was spending time getting the
new server on a new IP but I was just booting that one server up so it
was always grabbing the next available IP which was always 212.

from
Mick

[Gary Pope]

In all my dealings with FreeBSD  since   v4.2,   4.5,   4.7,  5.1,  5.3,    7.0  and now 9.0   I've never been convinced that leases will 100% return the same old IP to a machine appearing with the same old MAC address.  (the opposite problem to what you're trying to solve, Michael).    It is something that has forced me for years to prefer static IP setups for anything that needs to be 'reached' like a printer, server or major workstation acting as a p[oor-mans application server.     Despite having FreeBSD  DNS settings trying to associate a range of DHCP numbers to a formalised range of workstation numbers,  I've never been comfortable assuming that wsXX will always be the same simple client machine on DHCP XX+yy either!   We used to dream of making workstations be say:  ws1  thru ws32   with dhcp of .11 thru .42  and that they would remain the same (so long as you never exceeded the number of machines in the dhcp range over a really long period of time (like a few years I mean).      So it does not surprise me to hear similar dilemmas in reverse,  whereby a machine with a different MAC address is awarded a previously used IP of a recently released virtual machine.

 

Simply put,   I'm not surprised by Chris' comment that a released IP from one session of running a virtual server,  and the subsequent arrival of another virtual session starting up (be--it-all masquerading as a different logical MAC)  could be passed a very recently used IP (like  .112)

 

Gaz