[Kea-users] Running Kea with unreliable interfaces?

[Shane Kerr]

Francis,

At 2016-02-15 18:00:04 +0000
Francis Dupont <fdupont at isc.org> wrote:

> Shane Kerr writes:
> > I had a problem with Kea on a server that has 2 interfaces. One of the
> > interfaces did not survive a reboot (due to a bogus USB cable, but it
> > could be any reason). 
> > 
> > Kea did not start because the interface was missing:
> > 
> > 2016-02-15 15:03:24.366 ERROR [kea-dhcp4.dhcp4/510] DHCP4_INIT_FAIL failed to
> >  initialize Kea server: configuration error using file '/opt/kea-git/etc/kea/
> > kea.conf': Failed to select interface: interface 'wlan-awus036ac' doesn't exi
> > st in the system (/opt/kea-git/etc/kea/kea.conf:14:20) (/opt/kea-git/etc/kea/
> > kea.conf:14:20)  
> 
> => I am afraid this is axactly what you should have expected...  

Some software will run on interfaces that are available and poll
periodically to see if the remaining interfaces come up. In general I
prefer the behavior of failing, but the ideal case lets the
administrator decide.

Of course, that doesn't necessarily mean that Kea has to do anything.
We can just let the network tools start Kea the same way that they
would start a DHCP client on an interface. :)
 
> > What's the best way to deal with this potential problem? Should I run
> > two separate instances of Kea, using different configuration files, one
> > per interface? Or...?  
> 
> => if the unreliability is only between reboots IMHO the simplest is  
> to check if the interface is available in a script. If it can happen
> at any time you need two independent instances (2 processes, 2 config
> files, 2 lease files, 2 log files, etc, and bind the service socket
> to the served interface (i.e., SO_BINDTODEVICE & co are your friends).

Note that I am not using the same address pool on these interfaces, but
they do use the same database.

So I guess the only real question is if it is safe to have two instances
using the same database backend. In principle this can be done safely,
but if the software doesn't use transactions properly or relies on
in-memory copy of the state in tables, then maybe not.

Cheers,

--
Shane