Keepalived-sync docs and config examples

Hi there!

After a few years of usage, I am now refreshing the keepalived configuration of my routers, especially regarding the synchronisation of config and dhcp leases files. It looks Jaymin Patel has commited a nice synchronization feature about 18 month ago (, but there is so little documentation that I don't see how to configure it.

Has someone any clue or config example about it?

Thank you for your help!

Here are some details guides provided as a part of the PR review that might be helpful.




Thank you Jaymin :blush:

I am going to study that.

1 Like


After a few weeks, it is time for a summary of what I have seen with Keepalived. First, luci-app-keepalived, keepalived-sync and keepalived works, and it is pretty cool. Thank you @jempatel for your great work :slight_smile:

Nevertheless it has not been possible to support totally my needs, and a few things could also be improved:

  • Using sysupgrade -l in the script is too agressive. I suggest to synchronize only files from the user defined sync_list. In my case, the routers have different roles in MASTER and BACKUP modes, and copying all configuration files prevents such cases. Using sysupgrade -l could be kept as an option. The workaround is to modify the script locally line 46:
	for sync_file in $sync_list $(sysupgrade -l); do
  • Route specification needs to be extended with more options. In my case, metric is useful for masking the BACKUP default route, while preserving the interaction with other subsystems like mwan3.
  • The configuration of keepalived has evolved in its latest version and is not completely supported: global_track for example has been replaced by other mechanisms, max_auto_priority is not supported, etc.
  • The luci-app-keepalived+keepalived-sync Wiki page is not describing the current usage. Without the links provided by @jempatel, I would probably have resigned.
  • Action NOTIFY of type GROUP are not managed by the hotplug scripts. It raises errors in the logs.
  • The sync through ssh and rsync is very noisy, filling up the journals of low added value information. It would be nice to provide a way to reduce the verbosity:
Sun Feb 11 09:26:45 2024 dropbear[16112]: Child connection from
Sun Feb 11 09:26:45 2024 authpriv.notice dropbear[16112]: Pubkey auth succeeded for 'keepalived' with ssh-ed25519 key SHA256:5N2aUWNlcosUvHwRdobELPRuf4V0HizXCGuC27X/sLg from
Sun Feb 11 09:26:45 2024 dropbear[16112]: Exit (keepalived) from <>: Exited normally
  • dnsmasq is stopped from time to time while it is not expected. In asymetrical cases like mine, the BACKUP routers still needs dnsmasq for remaining operational (DNS resolving and concurrent fail-over DHCP service). The problem has probably be pointed out by @Blackfeather in Dnsmasq dies on boot after receiving SIGTERM.

I would be pleased to contribute to any of these topics if it can help. Comments and questions welcome :slight_smile:

In addition, here is the alternate keepalived config file I finally use, for reference:

global_defs {
	script_user root
	router_id router_1

vrrp_script rsync {
	script /etc/keepalived/scripts/
	interval 60
	weight 100

vrrp_instance VI_1 {
	authentication {
		auth_type PASS
		auth_pass XXXXXXXX
	state BACKUP
	interface lan
	virtual_router_id 1
	priority 100
	advert_int 1
	debug 2
	garp_master_delay 1
	garp_master_refresh 1
	garp_master_repeat 1
	garp_master_refresh_repeat 1
	notify_backup "/bin/busybox env -i ACTION=NOTIFY_BACKUP TYPE=INSTANCE NAME=VI_1 /sbin/hotplug-call keepalived"
	notify_master "/bin/busybox env -i ACTION=NOTIFY_MASTER TYPE=INSTANCE NAME=VI_1 /sbin/hotplug-call keepalived"
	notify_fault "/bin/busybox env -i ACTION=NOTIFY_FAULT TYPE=INSTANCE NAME=VI_1 /sbin/hotplug-call keepalived"
	notify_stop "/bin/busybox env -i ACTION=NOTIFY_STOP TYPE=INSTANCE NAME=VI_1 /sbin/hotplug-call keepalived"
	virtual_ipaddress { dev lan label lan:vip scope global dev dmz label dmz:vip scope global dev iot label iot:vip scope global dev wan label wan:vip scope global
	virtual_routes {
		src via dev wan metric 5
	track_script {
		rsync weight 100 

Thanks Pedro, I'm on that track too but I had to do other stuff and I couldn't take the job to the end. As you already have your hands on the topic, allow me to advice for you to translate this text into a code patch. If you have some more time to commit on this topic.

Because writing on the forum might end up here; and it's a pity to loose your work. If you produce a patch and attach to some issue tracker instead (ex: the one on github repo, as we are not permanent developers so we can't access the main repo), there are more chances for some of the actual developers to discuss the patch with you inside the issue you opened, and finally include your findings in the upstream.
I don't know current practices of openwrt's developers, but having a patch ready to be merged might be just a few clicks away from upstream for some of them. If you don't serve your findings in a patch, they should spend more time to implement and test if your findings are good or not...

Basically you need to git clone openwrt repo, mod and test, make the patch and attach to an issue. You can also use github's features to fork, mod and issue a pull request.


You are right @anichang. Unfortunately I have also very little free time for it. I'll do my best for proposing something in the coming weeks nevertheless. :slight_smile: