Hello Nick, That is indeed what happened. But those nodes are not yet in production and I was curious of what would happen. Hoped that may be Tinc would block the ARP communication, but Tinc is already doing enough. Some wishful thinking of me ;) LXC containers do not support live migration meaning they will always be stopped (if possible) and started on another node. The only thing I would need to do is sending an ARP announcement to cause (hopefully) all ARP caches to update. I wrote a sort of HA daemon to do all this for me.
Mike On Thu, Mar 14, 2013 at 2:18 PM, Nick Hibma <[email protected]> wrote: >> Well if you have two hosts with the same IP addresses on a network, the one >> which responds first to an ARP request will win. The MAC address discovered >> via ARP will be cached, so if a LXC container migrates to another node it >> will >> not automatically change to the local gateway. And even if no containers >> migrate, it could be that the local host has a higher load than the remote >> node, and the remote node's ARP replies will arrive before the local node's. > > Which will cause flapping... Using the same IP address is not recommended for > normal working setups, unless you know exactly what you do. > > Moving a container however should be trivial. If I am not mistaken an > interface that is taken down and up again will send an ARP request for its > own IP address, which will prime all connected host's ARP caches. Think > gateway failover/VRRP, they do the same. So a simple 'ifconfig eth0 down; > ifconfig eth0 up' in the container should do the trick. > > Nick > _______________________________________________ > tinc mailing list > [email protected] > http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc _______________________________________________ tinc mailing list [email protected] http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
