Am 8. April 2014 19:42, schrieb Gui Iribarren:
The L2 domain should never keep running split,
there's no clean way of merging that again.
Option 1: never split. Use a backup l2 vpn between all border gateways, so that they can
reach each other in the event of an internal mesh split. Traffic will flow between the two
segments over the internet, with limited bandwidth. It should be configured with minimum
priority so that it's never used under normal circumstances. Ninux.org
the network diagram implements this. It's on ninux blog post dated 2012 ipv6 day.
I don't thing this is realistic, imho someone could reboot a router for service or a
defect mircowave kills a good working link.
Idea 2: fencing. If one of the two segments happen to be left without gateways, it might
turn off dhcp servers, or throw away the given (temp, short-timed) leases when the split
dissolves (a gateway reappears)
Daydream 3: maybe none of this is a problem, with our hybrid setup... batman only cares
about macs (and they are unique), and bmx6 routes on the first hop out, so there's a
chance having duplicate ipv4 addresses for some time is not really a conflict? (?)
Sounds, if you make some kind of NAT between the hole network and a cloud? Is the
backroute possible with this? I thought the backroute can be over a different
network-to-cloud router. Those wouldn't know about the existing connections over
Red herring 4/6: dhcp database? I thought we were using stateless RA! I don't really
get what you people are talking about. There's no sync needed, ips are autoconfigured
by hosts themselves!
Was there an evaluation wich client devices can work with ipv6 only? Maybe your herring
isn't so far. :)
On April 8, 2014 5:49:13 AM GMT-03:00, Pau <pau(a)dabax.net> wrote:
It is a hard problem. If the L2 cloud split, you
cannot sync the DHCP
servers. And once the cloud join afain, I don't know how the dhcp
file will became.
I quick/dirty solution would be to split the DHCP servers range. So
instead of /24, give /21 or so and each DHCP server offers a different
/24. However I don't know if it makes sense to break the cleanness of
the solution to solve this case.
Maybe (maybe...) dnsmasq can solve this by detecting duplicate
and sending a DHCP renew to the affected clients.
@Gui, you are our dnsmasq guy, what do you think?
On 08/04/14 08:21, Tim Niemeyer wrote:
I heard an presentation last year in berlin about libre mesh. I was
the idea to use clounds and a l3 routing protocol. I
talked a bit later with Pau about a netsplit problem where one cloud is
split up. Then alfred isn't synchonizing, so that the dhcp can't know
wich ip is already in use. Is the problem resolved or further
> (Freifunk Franken)
> Dev mailing list
Dev mailing list