: > /dev/null

Jul 18, 2015

Remote IPv4 address migration

I've to switch from one Debian GNU/Linux virtual machine (provided by a friend ;)) to another, but must keep the same IPv4 public address (and stay in the same broadcast domain). The new VM has as temp public IPv4 address to prepare the switch.

When ready, i had some options to use the old IPv4 address on the new VM:

  • Phone my friend to coordinates IPv4 migration
  • Poweroff the old VM and use ip binary to switch from temp to old address

As this VM is part of my sandbox machines (with real hosted services, but no impact or customers depending on them), i've choosen the later option :)

As a system administrator, i never do this kind of things @work and never try to modify single network interface without having KVM, serial over LAN or any other out-of-band management to use tty direct access. Before starting this, it's time to test your login access (yes, i mean the random chars stored on a password database that you never use because you use ssh keypair on your daily tasks).

What i've installed before started:

  • at (yes, you know, the old and venerable)
  • iputils-arping, to have arping and especially -U option to do a gratuitous ARP. This will update neighbours ARP cache (poke gateway) because the MAC address will change for an already seen IPv4 address.

Now, it's 00:23, time to do a poor backup of all files on the old machine and transfert it to new:

old# tar --exclude='/proc' --exclude='/var/cache/rsnapshot' --exclude='/sys' --exclude='/dev' --exclude='/var/cache/apt/archives' --exclude=/root/saturnaab.tar.gz --exclude='/srv/backup/kimsuflol.iroqwa.org' --exclude='/var/lib/puppet/reports' -zcvf saturnaab.tar.gz /
new# scp 192.168.0.1:saturnaab.tar.gz .

Then, i can start to poweroff the old box, bye bye...but wait, when do you born ? Let's find an installation file date that i've never edited:

old# stat /etc/nanorc | grep ^Modify
Modify: 2010-04-15 19:39:40.000000000 +0200

Enough. poweroff i say.

old# poweroff

I used halt before (but this year) to shutdown a system, since systemd is the default init system on Debian, this no more works (because halt works by accident ?).

Now that the old box is not more reachable:

new# ping -c 1 192.168.122.115 -W 2
PING 192.168.122.115 (192.168.122.115) 56(84) bytes of data.

--- 192.168.122.115 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

I can start to break the new box. Hmm, before this, maybe it's good to have a whatchdog to restart automa[tg]ically the eth0 interface by reading notyetuntouched /etc/network/interfaces (remember to remove this if all works, remember to remove this...):

new# echo 'ifdown --force eth0; ifup eth0' | at now + 15 minutes

Start the ip switch:

new# ip addr add 192.168.122.115/32 dev eth0

Note the /32 CIDR mask to be untouched by the kernel.

Try to ping the old address on the new machine:

desktop$ ping -c 1 192.168.122.115 -W 2
PING 192.168.122.115 (192.168.122.115) 56(84) bytes of data.

--- 192.168.122.115 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

Crap, the old ip isn't reachable...need to send a gratuitous ARP packet to update ARP table on the gateway (that i don't have administrative access):

new# arping -s 192.168.122.115 -U 192.168.122.115
ARPING 192.168.122.115 from 192.168.122.115 eth0
^CSent 6 probes (6 broadcast(s))
Received 0 response(s)

I've forced to use the old address (-s) and ask with ARP what is the MAC for myself (O_o)

new# ip addr del 192.168.122.116/27 dev eth0

At this time, the first shell is dead because connected through 192.168.122.116.

And now i can assign the old address with the correct mask and remove the temp the one with /32:

new# ip addr add 192.168.122.115/27 dev eth0
new# ip addr del 192.168.122.115/32 dev eth0

And voila ! Oh no, the at whatchdog command will revert all these efforts, le'ts remove it:

new# atq
1   Wed Jul 22 01:04:00 2015 a root
new# atrm 1

To finish, just need to edit configuration in /etc/network/interfaces to use the old address and remove all occurences of the temp one). Next, a reboot to validate the file confirm me that the configuration is correct. Because if i have to restart the box later, i will not suspect other things to prevent booting correctly...

Source: http://madduck.net/blog/2006.10.20:freeing-the-primary-ip-address/