Delay in bringing up additional external ip addresses from /etc/network/interfaces

Hi,
I've configured rednundant (VRRP) router based on two 16.04.1 Ubuntu. Everything except one thing is working as expected.

I have a few additional external IP addresses defined in /etc/network/interfaces:

auto eth0
iface eth0 inet static
        address x.x.x.53
        netmask 255.255.255.224
        network x.x.x.32
        broadcast x.x.x.63
        gateway x.x.x.33
        dns-nameservers 127.0.0.1 10.171.3.56 10.172.3.247
        dns-search domain.com

        up ip addr add x.x.x.34 dev $IFACE
        down ip addr del x.x.x.34 dev $IFACE
        up ip addr add x.x.x.39 dev $IFACE
        down ip addr del x.x.x.39 dev $IFACE
        up ip addr add x.x.x.40 dev $IFACE
        down ip addr del x.x.x.40 dev $IFACE
        up ip addr add x.x.x.48 dev $IFACE
        down ip addr del x.x.x.48 dev $IFACE
        up ip addr add x.x.x.50 dev $IFACE
        down ip addr del x.x.x.50 dev $IFACE

For obvious reason additional external addresses are the same for both routers, and are starting on boot. I've made a script running every 5 seconds on both routers to check if router is active, and in case if it is not then bring additional addresses down. This is working fine, but for some time after additional addresses on non-active router were up, I can't use these IP's on active router.

My idea is to remove that list from /etc/network/interfaces file and put them to the /etc/rc.local:
i.e. ip a a x.x.x.x/32 dev eth0 with delay of about 20 seconds.

But I am not sure when exactly rc.local script is running. Is it at the end of booting process or in the middle? Any idea how to sort it out?

rc.local runs after all init scripts.

You may want to investigate the arping command.

I've not used VRRP but did want to mention an issue we had wherein we were floating an IP between servers. The IP would successfully be shutdown on one server and brought up on the other but traffic coming from separate VLANs wouldn't reach it. We found the issue was we have separate switches in each of our racks and those switches were seeing the change and updating arp cache for the appropriate hardware addresses (MACs). However, our core switches weren't seeing this change so were keeping the MAC from the server where we'd stopped the IP. We found using arping from the server we had just brought the interface up made our core switches recognize the move and update to see the other MAC.

In our case we didn't add any of this to rc.local - we have it all in separate init scripts we run. Additionally the init script checks to see if the IP is already in use and refuses to bring it up if so (on the assumption it was already started on the other host).