Ubuntu

netplan removes ip address that are set by other programs

Asked by Rene Bakkum

Hi,

We are using 18.04 with netplan configuration and we have a daemon keepalived running to keep an IP online between 2 servers. However if you edit the netplan yaml file and you apply this (netplan apply), netplan will remove all IP configurations (also IPs set by keepalived) and than apply it's new settings.

I would expect netplan to remove only IPs that he was / is assigned for and add new IPs / configurations accordingly and not remove IPs that are in control by other daemons. Since keepalived doesn't notice the IPs removal, this will bring down the 'IP' and will only be available once the keepalived daemon will be restarted.

Keepalived version 2.0.4 seems to have an actively monitoring on it's own IPs, but since 18.04 LTS runs with 1.3.9 this will affect current LTS versions. Should this been seen as a bug or unwanted feature?

Regards,
Rene Bakkum

Question information

Language:
English Edit question
Status:
Solved
For:
Ubuntu Edit question
Assignee:
No assignee Edit question
Solved by:
Manfred Hampl
Solved:
Last query:
Last reply:
Revision history for this message
Launchpad Janitor (janitor) said : 		#1

This question was expired because it remained in the 'Open' state without activity for the last 15 days.

Revision history for this message
Rene Bakkum (rene-true) said : 		#2

Hello,

Any idea how to counter this without building keepalived from source?

Revision history for this message
Best Manfred Hampl (m-hampl) said : 		#3

There is a PPA with keepalived 2.0.4 for Ubuntu 18.04
https://launchpad.net/~hnakamur/+archive/ubuntu/keepalived
Maybe this helps.

Revision history for this message
Rene Bakkum (rene-true) said : 		#4

Hi,

Thanks for the PPA link. Guess either that or build own package is the solution than.
Still find it odd that netplan removes IPs that are not controlled by it's configuration and that other daemons need to solve the removal of the IP address. But if that's expected behaviour...

Revision history for this message
Rene Bakkum (rene-true) said : 		#5

Thanks Manfred Hampl, that solved my question.