Bridged nodes sharing local IP to be used as gateway for LXC

[Mike Machuidel]

That is what I noticed as well. The switch would occur mostly at night
when the backups are running what caused the backups to fail. Actually
I know this is what would occur when there are conflicting IP's in the
same network segment. I thought maybe Tinc would take care of this ;)

Had been playing with static ARP entries on the node, but of course
that did nothing as for the LXC containers the node is just another
machine. Each LXC container is running its networking in another
context.
Before when I was using Vserver this was not a problem. The IP
addresses where configured in the context of the node. Now with LXC
every node should act as the gateway for the LXC containers that are
running on it.
On every node this IP address will be different meaning that the LXC
should change its default gateway.

P.S. sorry Guus if you get this post twice. send the first one from
the wrong email address and was rejected

On Thu, Mar 14, 2013 at 2:00 PM, Guus Sliepen <guus at tinc-vpn.org> wrote:
> On Tue, Mar 12, 2013 at 12:21:33AM +0100, Mike Machuidel wrote:
>
>> I am running multiple nodes each having multiple LXC containers. On
>> those nodes I am using Tinc to share the subnet 10.20.0.0. The LXC
>> containers may migrate between nodes and should keep the same
>> configuration.
>> On all nodes traffic from the external interfaces (connected to the
>> internet) is forwarded to the bridge interfaces and masqueraded. The
>> LXC containers are using 10.20.0.1 as their default gateway which
>> should stay the same independent of the node they are running on.
>
> [...]
>
>> on Node A:
>>
>>   ip addr add 10.20.0.1/16 dev br0   # using same IP on node as node B
>> so the LXC containers can use same gateway IP
>>
>> on Node B:
>>
>>   ip addr add 10.20.0.1/16 dev br0   # using same IP on node as node A
>> so the LXC containers can use same gateway IP
>
> [...]
>
>> meaning that both nodes will share the same IP which the LXC container
>> can use as their default gateway?
>>
>> To be honest I already tried this configuration. It ran well for about
>> 2 days till I noticed that sometimes LXC containers on Node B were
>> using the default gateway on Node A and the other way around.
>
> 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.
>
> You could use ebtables to filter ARP requests/replies going to/coming from the
> remote gateway. There might be other solutions, but I cannot think of any right
> now.
>
>> Is it possible to force the 10.20.0.1 on the local interface to be
>> used instead of the traffic being bridged over to the other side? Like
>> setting some metrics?
>
> I think the problem happens on the MAC layer, not on the IP layer, in which
> case metrics will not help much.
>
> --
> Met vriendelijke groet / with kind regards,
>      Guus Sliepen <guus at tinc-vpn.org>
>
> _______________________________________________
> tinc mailing list
> tinc at tinc-vpn.org
> http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
>