DHCP Failover with CARP pfsense 2.0
-
That might be an issue of the sync code that has to handle this.
Can you please send me your config privately to verify it? eri at pfsense dot org -
any news on this? If I enable the failover peer on the dhcp server I get that state on both systems.
Failover Group My State Since Peer State Since
"dhcp0" recover 2011/02/15 17:27:21 unknown-state 2011/02/15 17:27:21Do I need any firewall rules for it to work? thanks
-
I'm seeing the same as DISA on my test boxes.
I remember there was an issue with this about a year ago, and that a manual adjustment to one of the config files fixed the issue, but I don't remember what that was at this point. If I find it before somebody else does I'll post.
-
Uhm, on the logs I see a lot of:
dhcpd: DHCPDISCOVER from 00:23:7d:2d:e2:ea via em0: peer holds all free leases
and no leases are given :-)
maybe the problem is in the config file:
master:```
default-lease-time 7200;
max-lease-time 86400;
log-facility local7;
ddns-update-style none;
one-lease-per-client true;
deny duplicates;
ping-check true;
authoritative;
failover peer "dhcp0" {
secondary;
address 10.0.10.11;
port 520;
peer address 10.0.10.12;
peer port 519;
max-response-delay 10;
max-unacked-updates 10;
mclt 600;load balance max seconds 3;
}slave:default-lease-time 7200;
max-lease-time 86400;
log-facility local7;
ddns-update-style none;
one-lease-per-client true;
deny duplicates;
ping-check true;
authoritative;
failover peer "dhcp0" {
secondary;
address 10.0.10.12;
port 520;
peer address 10.0.10.11;
peer port 519;
max-response-delay 10;
max-unacked-updates 10;
mclt 600;load balance max seconds 3;
}uhm…I've put the LAN other peer ip address and now the config looks correct: master:efault-lease-time 7200;
max-lease-time 86400;
log-facility local7;
ddns-update-style none;
one-lease-per-client true;
deny duplicates;
ping-check true;
authoritative;
failover peer "dhcp0" {
primary;
address 192.168.0.11;
port 519;
peer address 192.168.0.12;
peer port 520;
max-response-delay 10;
max-unacked-updates 10;
split 128;
mclt 600;load balance max seconds 3;
}slave:default-lease-time 7200;
max-lease-time 86400;
log-facility local7;
ddns-update-style none;
one-lease-per-client true;
deny duplicates;
ping-check true;
authoritative;
failover peer "dhcp0" {
secondary;
address 192.168.0.12;
port 520;
peer address 192.168.0.11;
peer port 519;
max-response-delay 10;
max-unacked-updates 10;
mclt 600;load balance max seconds 3;
}but I still have "dhcpd: DHCPDISCOVER from e0:cb:4e:c7:a0:0c via em0: not responding (recovering)" in my logs andd the state isFailover Group My State Since Peer State Since
"dhcp0" recover 2011/02/16 09:04:12 unknown-state 2011/02/16 09:04:12for both of them Maybe I need to open port 519/520 in the lan firewall rules? I'll try later and will let you know :-) -
Adding a firewall rules for dest port 519/520 solved it! Shouldn't this be stated somewhere?
This is what I can now see on the logs
primary:Feb 16 11:13:52 dhcpd: DHCPACK to 192.168.0.198 (00:30:18:a3:3e:74) via em0 Feb 16 11:13:52 dhcpd: DHCPINFORM from 192.168.0.198 via em0 Feb 16 11:12:50 dhcpd: DHCPACK to 192.168.0.128 (00:23:7d:2d:e2:ea) via em0 Feb 16 11:12:50 dhcpd: DHCPINFORM from 192.168.0.128 via em0 Feb 16 11:11:02 dhcpd: DHCPACK to 192.168.0.103 (18:a9:05:a0:11:2b) via em0 Feb 16 11:11:02 dhcpd: DHCPINFORM from 192.168.0.103 via em0 Feb 16 11:10:13 dhcpd: DHCPACK to 192.168.0.184 (00:16:17:3e:c4:e0) via em0 Feb 16 11:10:13 dhcpd: DHCPINFORM from 192.168.0.184 via em0 Feb 16 11:10:10 dhcpd: DHCPACK to 192.168.0.184 (00:16:17:3e:c4:e0) via em0 Feb 16 11:10:10 dhcpd: DHCPINFORM from 192.168.0.184 via em0 Feb 16 11:06:49 dhcpd: Sending updates to dhcp0. Feb 16 11:06:49 dhcpd: balanced pool 800c3b540 192.168.0.0/24 total 100 free 30 backup 30 lts 0 max-misbal 9 Feb 16 11:06:49 dhcpd: balancing pool 800c3b540 192.168.0.0/24 total 100 free 33 backup 27 lts 3 max-own (+/-)6 Feb 16 11:06:49 dhcpd: failover peer dhcp0: I move from communications-interrupted to normal Feb 16 11:06:49 dhcpd: failover peer dhcp0: peer moves from normal to normal Feb 16 11:06:44 dhcpd: failover peer dhcp0: I move from normal to communications-interrupted Feb 16 11:06:44 dhcpd: peer dhcp0: disconnected Feb 16 11:06:44 dhcpd: failover peer dhcp0: peer moves from recover-done to normal Feb 16 11:06:44 dhcpd: Sending updates to dhcp0. Feb 16 11:06:44 dhcpd: balanced pool 800c3b540 192.168.0.0/24 total 100 free 30 backup 30 lts 0 max-misbal 9 Feb 16 11:06:44 dhcpd: balancing pool 800c3b540 192.168.0.0/24 total 100 free 60 backup 0 lts 30 max-own (+/-)6 Feb 16 11:06:44 dhcpd: failover peer dhcp0: I move from recover-done to normal Feb 16 11:06:44 dhcpd: Both servers have entered recover-done! Feb 16 11:06:44 dhcpd: failover peer dhcp0: peer moves from recover to recover-done Feb 16 11:06:44 dhcpd: failover peer dhcp0: I move from recover to recover-done Feb 16 11:06:44 dhcpd: failover peer dhcp0: peer update completed. Feb 16 11:06:44 dhcpd: Sent update done message to dhcp0 Feb 16 11:06:44 dhcpd: bind update on 192.168.0.197 from dhcp0 rejected: 192.168.0.197: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.196 from dhcp0 rejected: 192.168.0.196: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.194 from dhcp0 rejected: 192.168.0.194: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.193 from dhcp0 rejected: 192.168.0.193: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.191 from dhcp0 rejected: 192.168.0.191: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.190 from dhcp0 rejected: 192.168.0.190: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.189 from dhcp0 rejected: 192.168.0.189: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.187 from dhcp0 rejected: 192.168.0.187: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.184 from dhcp0 rejected: 192.168.0.184: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.161 from dhcp0 rejected: 192.168.0.161: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.141 from dhcp0 rejected: 192.168.0.141: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.140 from dhcp0 rejected: 192.168.0.140: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.139 from dhcp0 rejected: 192.168.0.139: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.138 from dhcp0 rejected: 192.168.0.138: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.137 from dhcp0 rejected: 192.168.0.137: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.132 from dhcp0 rejected: 192.168.0.132: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.131 from dhcp0 rejected: 192.168.0.131: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.128 from dhcp0 rejected: 192.168.0.128: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.127 from dhcp0 rejected: 192.168.0.127: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.126 from dhcp0 rejected: 192.168.0.126: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.123 from dhcp0 rejected: 192.168.0.123: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.122 from dhcp0 rejected: 192.168.0.122: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.121 from dhcp0 rejected: 192.168.0.121: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.120 from dhcp0 rejected: 192.168.0.120: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.119 from dhcp0 rejected: 192.168.0.119: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.118 from dhcp0 rejected: 192.168.0.118: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.117 from dhcp0 rejected: 192.168.0.117: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.115 from dhcp0 rejected: 192.168.0.115: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.114 from dhcp0 rejected: 192.168.0.114: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.113 from dhcp0 rejected: 192.168.0.113: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.112 from dhcp0 rejected: 192.168.0.112: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.111 from dhcp0 rejected: 192.168.0.111: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.108 from dhcp0 rejected: 192.168.0.108: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.107 from dhcp0 rejected: 192.168.0.107: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.106 from dhcp0 rejected: 192.168.0.106: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.105 from dhcp0 rejected: 192.168.0.105: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.104 from dhcp0 rejected: 192.168.0.104: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.103 from dhcp0 rejected: 192.168.0.103: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.101 from dhcp0 rejected: 192.168.0.101: invalid state transition: active to free Feb 16 11:06:44 dhcpd: bind update on 192.168.0.100 from dhcp0 rejected: 192.168.0.100: invalid state transition: active to free Feb 16 11:06:44 dhcpd: Update request all from dhcp0: sending update Feb 16 11:06:44 dhcpd: failover peer dhcp0: requesting full update from peer Feb 16 11:06:44 dhcpd: failover peer dhcp0: peer moves from recover to recover Feb 16 11:06:44 dhcpd: Sent update request all message to dhcp0 Feb 16 11:06:44 dhcpd: failover peer dhcp0: I move from startup to recover Feb 16 11:06:44 dhcpd: failover peer dhcp0: requesting full update from peer Feb 16 11:06:44 dhcpd: failover peer dhcp0: peer moves from unknown-state to recoversecondary:
Feb 16 11:12:50 dhcpd: DHCPACK to 192.168.0.128 (00:23:7d:2d:e2:ea) via em0 Feb 16 11:12:50 dhcpd: DHCPINFORM from 192.168.0.128 via em0 Feb 16 11:11:02 dhcpd: DHCPACK to 192.168.0.103 (18:a9:05:a0:11:2b) via em0 Feb 16 11:11:02 dhcpd: DHCPINFORM from 192.168.0.103 via em0 Feb 16 11:10:13 dhcpd: DHCPACK to 192.168.0.184 (00:16:17:3e:c4:e0) via em0 Feb 16 11:10:13 dhcpd: DHCPINFORM from 192.168.0.184 via em0 Feb 16 11:10:10 dhcpd: DHCPACK to 192.168.0.184 (00:16:17:3e:c4:e0) via em0 Feb 16 11:10:10 dhcpd: DHCPINFORM from 192.168.0.184 via em0 Feb 16 11:06:49 dhcpd: failover peer dhcp0: peer moves from communications-interrupted to normal Feb 16 11:06:49 dhcpd: Sending updates to dhcp0. Feb 16 11:06:49 dhcpd: balanced pool 800c3b540 192.168.0.0/24 total 100 free 34 backup 26 lts -4 max-misbal 9 Feb 16 11:06:49 dhcpd: balancing pool 800c3b540 192.168.0.0/24 total 100 free 33 backup 27 lts -3 max-own (+/-)6 Feb 16 11:06:49 dhcpd: failover peer dhcp0: I move from startup to normal Feb 16 11:06:49 dhcpd: failover peer dhcp0: peer moves from normal to communications-interrupted Feb 16 11:06:45 dhcpd: failover peer dhcp0: I move from normal to startup Feb 16 11:06:45 dhcpd: Sending on Socket/fallback/fallback-net Feb 16 11:06:45 dhcpd: Sending on BPF/em0/00:10:f3:1c:4b:1e/192.168.0.0/24 Feb 16 11:06:45 dhcpd: Listening on BPF/em0/00:10:f3:1c:4b:1e/192.168.0.0/24 Feb 16 11:06:45 dhcpd: Wrote 80 leases to leases file. Feb 16 11:06:45 dhcpd: Wrote 0 new dynamic host decls to leases file. Feb 16 11:06:45 dhcpd: Wrote 0 deleted host decls to leases file. Feb 16 11:06:45 dhcpd: For info, please visit https://www.isc.org/software/dhcp/ Feb 16 11:06:45 dhcpd: All rights reserved. Feb 16 11:06:45 dhcpd: Copyright 2004-2010 Internet Systems Consortium. Feb 16 11:06:45 dhcpd: Internet Systems Consortium DHCP Server 4.1.1-P1 Feb 16 11:06:44 dhcpd: bind update on 192.168.0.185 from dhcp0 rejected: incoming update is less critical than outgoing update Feb 16 11:06:44 dhcpd: bind update on 192.168.0.129 from dhcp0 rejected: incoming update is less critical than outgoing update Feb 16 11:06:44 dhcpd: bind update on 192.168.0.110 from dhcp0 rejected: incoming update is less critical than outgoing update Feb 16 11:06:44 dhcpd: bind update on 192.168.0.125 from dhcp0 rejected: incoming update is less critical than outgoing update Feb 16 11:06:44 dhcpd: failover peer dhcp0: peer moves from recover-done to normal Feb 16 11:06:44 dhcpd: Sending updates to dhcp0. Feb 16 11:06:44 dhcpd: balanced pool 800c3b540 192.168.0.0/24 total 100 free 60 backup 0 lts -30 max-misbal 9 Feb 16 11:06:44 dhcpd: balancing pool 800c3b540 192.168.0.0/24 total 100 free 60 backup 0 lts -30 max-own (+/-)6 Feb 16 11:06:44 dhcpd: failover peer dhcp0: I move from recover-done to normal Feb 16 11:06:44 dhcpd: Both servers have entered recover-done! Feb 16 11:06:44 dhcpd: failover peer dhcp0: peer moves from recover to recover-done Feb 16 11:06:44 dhcpd: failover peer dhcp0: I move from recover to recover-done Feb 16 11:06:44 dhcpd: failover peer dhcp0: peer update completed. Feb 16 11:06:44 dhcpd: Sent update done message to dhcp0 Feb 16 11:06:44 dhcpd: bind update on 192.168.0.179 from dhcp0 rejected: incoming update is less critical than outgoing update Feb 16 11:06:44 dhcpd: bind update on 192.168.0.178 from dhcp0 rejected: incoming update is less critical than outgoing update Feb 16 11:06:44 dhcpd: bind update on 192.168.0.177 from dhcp0 rejected: incoming update is less critical than outgoing update Feb 16 11:06:44 dhcpd: bind update on 192.168.0.176 from dhcp0 rejected: incoming update is less critical than outgoing update Feb 16 11:06:44 dhcpd: bind update on 192.168.0.175 from dhcp0 rejected: incoming update is less critical than outgoing update Feb 16 11:06:44 dhcpd: bind update on 192.168.0.174 from dhcp0 rejected: incoming update is less critical than outgoing update Feb 16 11:06:44 dhcpd: bind update on 192.168.0.169 from dhcp0 rejected: incoming update is less critical than outgoing update Feb 16 11:06:44 dhcpd: bind update on 192.168.0.168 from dhcp0 rejected: incoming update is less critical than outgoing update Feb 16 11:06:44 dhcpd: bind update on 192.168.0.167 from dhcp0 rejected: incoming update is less critical than outgoing update Feb 16 11:06:44 dhcpd: bind update on 192.168.0.166 from dhcp0 rejected: incoming update is less critical than outgoing update Feb 16 11:06:44 dhcpd: bind update on 192.168.0.165 from dhcp0 rejected: incoming update is less critical than outgoing update Feb 16 11:06:44 dhcpd: bind update on 192.168.0.164 from dhcp0 rejected: incoming update is less critical than outgoing update Feb 16 11:06:44 dhcpd: bind update on 192.168.0.116 from dhcp0 rejected: incoming update is less critical than outgoing update Feb 16 11:06:44 dhcpd: bind update on 192.168.0.102 from dhcp0 rejected: incoming update is less critical than outgoing update Feb 16 11:06:44 dhcpd: Update request all from dhcp0: sending update Feb 16 11:06:44 dhcpd: failover peer dhcp0: requesting full update from peer Feb 16 11:06:44 dhcpd: failover peer dhcp0: peer moves from recover to recover Feb 16 11:06:44 dhcpd: Sent update request all message to dhcp0 Feb 16 11:06:44 dhcpd: failover peer dhcp0: I move from startup to recover Feb 16 11:06:44 dhcpd: failover peer dhcp0: requesting full update from peer Feb 16 11:06:44 dhcpd: failover peer dhcp0: peer moves from unknown-state to recoverDoes everything looks on now? Thanks
-
Give this a shot:
https://rcs.pfsense.org/projects/pfsense/repos/mainline/commits/72377228a61220f1dbe62afb81e0dc7757868ea5
Should make its way into snaps soon.
-
ehehe, I'm definitely going to try it tomorrow :-D
thanks! -
I've upgrade both the systems to 2.0-BETA5 (amd64) built on Wed Feb 16 23:27:05 EST 2011 and the rule has been added!
grep DHCP /tmp/rules.debug # allow access to DHCP server on LAN pass in on $LAN proto udp from any port = 68 to 255.255.255.255 port = 67 label "allow access to DHCP server" pass in on $LAN proto udp from any port = 68 to 192.168.0.11 port = 67 label "allow access to DHCP server" pass out on $LAN proto udp from 192.168.0.11 port = 67 to any port = 68 label "allow access to DHCP server" # allow access to DHCP failover on LAN from 192.168.0.12 pass in on $LAN proto udp from 192.168.0.12 to 192.168.0.11 port = 519 label "allow access to DHCP failover" pass in on $LAN proto udp from 192.168.0.12 to 192.168.0.11 port = 520 label "allow access to DHCP failover"So now the dhcp failover works out of the box! :-)
I have 2 more questions:
- shouldn't be a way for the user to see all those "hidden" rules?
- when I deleted the rules from the master, it synced to the slave, and on the gui the rules was deleted, but if I check /tmp/rules.debug of the slave system, that rule is still there. I've also added a new test rule to the primary and it appeared on the secondary gui, but not in /tmp/rules.debug. Is this normal? Isn't this the file generated by the gui and then read by pfctl?
thanks
-
Hi Guys
Have a look at my post: http://forum.pfsense.org/index.php/topic,33403.0.html
for a possible solution…Kind regards
Aubrey -
we are speaking about dhcp firewall rules, not panics :-)
-
Hi DISA
Yes, I understand, but looking at the full discription on the topic you will see I found as part of the DHCP call info regarding MTU…
Kind regards
Aubrey -
I have 2 more questions:
- shouldn't be a way for the user to see all those "hidden" rules?
- when I deleted the rules from the master, it synced to the slave, and on the gui the rules was deleted, but if I check /tmp/rules.debug of the slave system, that rule is still there. I've also added a new test rule to the primary and it appeared on the secondary gui, but not in /tmp/rules.debug. Is this normal? Isn't this the file generated by the gui and then read by pfctl?
- It's been discussed before, but there's no easy way to do it in the GUI, if someone really wants to know they can look at the rules.debug file
- It should be kicking off a filter reload after the sync… Check the system log on both to see what it says around the time of the sync.
-
- It should be kicking off a filter reload after the sync… Check the system log on both to see what it says around the time of the sync.
yes, I can find it on the logs "check_reload_status: reloading filter" but on /tmp all files are from this morning reboot (after upgrade):
ls -lh /tmp/ total 184 -rw-r--r-- 1 root wheel 316B Feb 17 14:46 apinger.status -rw-r--r-- 1 root wheel 89B Feb 17 09:19 bootup_messages -rw-r--r-- 1 root wheel 0B Feb 17 09:18 captiveportal.lock -rw-r--r-- 1 root wheel 80K Feb 17 12:47 config.cache -rw-r--r-- 1 root wheel 0B Feb 17 12:47 config.lock -rw-r--r-- 1 root wheel 393B Feb 17 12:47 dhcpd.sh -rw-r--r-- 1 root wheel 13B Feb 17 12:47 em1_defaultgw -rw-r--r-- 1 root wheel 0B Feb 17 09:18 filter.lock drwxr-xr-x 3 root wheel 512B Feb 17 10:36 lighttpdcompress drwxr-xr-x 3 root wheel 512B Feb 17 09:18 mnt -rw-r--r-- 1 root wheel 11B Feb 17 12:47 ovpns1_router -rw-r--r-- 1 root wheel 0B Feb 17 12:47 ovpns1up -rw-r--r-- 1 root wheel 11B Feb 17 12:47 ovpns2_router -rw-r--r-- 1 root wheel 0B Feb 17 12:47 ovpns2up -rw-r--r-- 1 root wheel 29B Feb 17 09:57 pfSense_version -rw-r--r-- 1 root wheel 1.7K Feb 17 14:45 pfctl_si_out -rw-r--r-- 1 root wheel 44K Feb 17 14:45 pfctl_ss_out srwxr-xr-x 1 root wheel 0B Feb 17 09:18 php-fastcgi.socket-0 srwxr-xr-x 1 root wheel 0B Feb 17 09:18 php-fastcgi.socket-1 -rw-r--r-- 1 root wheel 82B Feb 17 09:18 pkg_delete_errors.txt -rw-r--r-- 1 root wheel 107B Feb 17 09:18 rules.boot -rw-r--r-- 1 root wheel 14K Feb 17 09:18 rules.debug -rw-r--r-- 1 root wheel 14K Feb 17 09:18 rules.debug.old -rw-r--r-- 1 root wheel 0B Feb 17 14:43 tmpHOSTS drwxrwxrwx 2 root wheel 512B Feb 17 09:17 uploadbar -
What happens if you go to Status > Filter Reload, what does the status show? What happens if you press the "Reload Filter" button?
-
I see "End of portal.pfsense.org configuration backup (success)…."
If i click on "reload filter" in the logs I see "check_reload_status: reloading filter", but on the status page I still have "End of portal.pfsense.org configuration backup (success)...." with a rotating spinner
Those are the latest restore I can see from the autobackup page:
2011-02-17 06:47:55 (system): Merged in config (system sections) from XMLRPC client.
2011-02-17 06:47:52 (system): Merged in config (filter,nat,aliases,dhcpd,wol,l7shaper,staticroutes,gateways,virtualip,load_balancer,ipsec,openvpn,cert,ca,crl,dnsmasq,schedules sections) from XMLRPC client.
2011-02-17 06:47:13 (system): Merged in config (system sections) from XMLRPC client.
2011-02-17 06:47:09 (system): Merged in config (filter,nat,aliases,dhcpd,wol,l7shaper,staticroutes,gateways,virtualip,load_balancer,ipsec,openvpn,cert,ca,crl,dnsmasq,schedules sections) from XMLRPC client.
2011-02-17 05:06:47 (system): Merged in config (system sections) from XMLRPC client. -
Hmm, ok. I haven't tried CARP sync with the Auto Config Backup on. There may be some kind of interaction there. It looks like it's saving the config OK though.
-
I setup ACB on my CARP cluster and I can't make it stick there. Rules delete OK, the filter reload shows the backup happen and then proceeds quickly to 'done'.
-
today, after an update to 2.0-BETA5 (amd64) built on Fri Feb 18 05:19:03 EST 2011 the relus.debug is updated as expected… ???
