Re: sasyncd syncs only newly created sad's
Thank you very much for you reply Markus, I think I saw that page once on the beginning of my research, but I tought that it must have been fixed by today, since it is almost 5 years old. I am very suprised by the fact that it hasn't been fixed in all this years. You are right, this would really be a killer app. I tought it was, since there is no way to know about this bug until you implement the whole redundant system. This problem should be clearly stated in the man page, it would save me a week. It looks like some trivial bug, since it is clear from the logs that master sends the sad's, but slave is not able to install them: sasyncd[26685]: pfkey_queue_message: pfkey ADD len 504 seq 2 sasyncd[26685]: pfkey: msg ADD write() failed on socket 5: Invalid argument but later when renegotiation occurs, it installs them succesfully: sasyncd[26685]: pfkey_queue_message: pfkey ADD len 416 seq 149 sasyncd[26685]: pfkey_queue_message: pfkey ADD len 416 seq 150 I wonder what could be different in the first try? Do you still use sasyncd? Have you found any workaround for this? I have advskew 10 on master and 20 on slave. If I want to reboot the master, I demote its carp group and while it reboots, I do: for i in `ls /etc/ | grep carp | cut -d . -f 2`; do ifconfig $i advskew 1; done on the slave. That way, master doesnt take over when it comes back. Maybe it could be done with turning off the preemtion, but haven't tried that yet. Anyhow, after that, I have to wait for all tunnels to renegotiate so I can demote the slave and make the master - master, again. Since you reported problem 5 years ago, are we the only ones who use sasyncd? :) Thanks again -Original Message- From: Markus Wernig [mailto:liste...@wernig.net] Sent: Tuesday, January 12, 2010 9:24 PM To: M ihajlo Manojlov Cc: misc@openbsd.org Subject: Re: sasyncd syncs only newly created sad's Hi Mihajlo Yes, this feature (re-sychronization after master failure) has been missing from the day sasyncd came out (http://archives.neohapsis.com/archives/openbsd/2005-09/0818.html). When I gave that speech in Switzerland (the one you found the PDF of), I was confident that it would be implemented within a couple of months or so ... the whole thing being a sponsored development, I figured that the sponsor would want this program to be usable. But, alas, it wasn't. Pity, really. With a little more time at my hands and a little more wit in my brains I would love to pick this up. It would be SUCH a killer application. Hakan Olsson, the original developper, did once say he would look into it, butI haven't heard of him since. krgds & sorrynohelphere /markus Mihajlo Manojlov wrote: > Hi again, > > there is no feedback.. could someone who runs sasyncd check this for me? > Please, just restart sasyncd on slave(or master), and see if it syncs the > SAD's? > > This behaviour renders my redundant routers - non redundant. If I reboot > master, when it comes back and become master again, all VPN tunnels are down > because no SAD's are synced. > > Thank you very much. > > -Original Message- > From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of > Mihajlo Manojlov > Sent: Wednesday, January 06, 2010 11:10 PM > To: misc@openbsd.org > Subject: sasyncd syncs only newly created sad's > > Hi to all, > > I have two carped boxes and I want to use sasyncd for vpn redundancy, but > only > newly created sad's get synced. For example, I reboot the slave box, and when > it comes up again, sasyncd only sets flows, not the sad's. Maybe this is > normal behaviour? > > log from master: > Jan 6 21:59:23 openbsd1 sasyncd[25895]: net: peer "10.23.6.2" connected > Jan 6 21:59:23 openbsd1 sasyncd[25895]: net_ctl: peer "10.23.6.2" state > change to SLAVE > Jan 6 21:59:25 openbsd1 sasyncd[25895]: monitor_get_pfkey_snap: got 2016 > bytes SADB, 1392 bytes SPD > Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_send_flush: sending FLUSH to > peer 10.23.6.2 > Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: SADB data > 020a00023f000200010088f180d710010303040004000200 > 15f7444b04000400 > 380404000300 > b00403000500100259d44c6d > 03000600100259d45bb205000a00 > 010038392e3231322e37362e3130392f3332 > 05000b00010038392e3231322e39312e3137382f3332 > 04000800a0009884229af8684722ecf09bfe79c0d8eef96b3cfb > 04000900c000e73eb8f1c43d90bdfaf40fb3abfe879d28e74cf8e870dd0b01001400 > 01010
Re: sasyncd syncs only newly created sad's
Hi Mihajlo Yes, this feature (re-sychronization after master failure) has been missing from the day sasyncd came out (http://archives.neohapsis.com/archives/openbsd/2005-09/0818.html). When I gave that speech in Switzerland (the one you found the PDF of), I was confident that it would be implemented within a couple of months or so ... the whole thing being a sponsored development, I figured that the sponsor would want this program to be usable. But, alas, it wasn't. Pity, really. With a little more time at my hands and a little more wit in my brains I would love to pick this up. It would be SUCH a killer application. Hakan Olsson, the original developper, did once say he would look into it, butI haven't heard of him since. krgds & sorrynohelphere /markus Mihajlo Manojlov wrote: > Hi again, > > there is no feedback.. could someone who runs sasyncd check this for me? > Please, just restart sasyncd on slave(or master), and see if it syncs the > SAD's? > > This behaviour renders my redundant routers - non redundant. If I reboot > master, when it comes back and become master again, all VPN tunnels are down > because no SAD's are synced. > > Thank you very much. > > -Original Message- > From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of > Mihajlo Manojlov > Sent: Wednesday, January 06, 2010 11:10 PM > To: misc@openbsd.org > Subject: sasyncd syncs only newly created sad's > > Hi to all, > > I have two carped boxes and I want to use sasyncd for vpn redundancy, but > only > newly created sad's get synced. For example, I reboot the slave box, and when > it comes up again, sasyncd only sets flows, not the sad's. Maybe this is > normal behaviour? > > log from master: > Jan 6 21:59:23 openbsd1 sasyncd[25895]: net: peer "10.23.6.2" connected > Jan 6 21:59:23 openbsd1 sasyncd[25895]: net_ctl: peer "10.23.6.2" state > change to SLAVE > Jan 6 21:59:25 openbsd1 sasyncd[25895]: monitor_get_pfkey_snap: got 2016 > bytes SADB, 1392 bytes SPD > Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_send_flush: sending FLUSH to > peer 10.23.6.2 > Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: SADB data > 020a00023f000200010088f180d710010303040004000200 > 15f7444b04000400 > 380404000300 > b00403000500100259d44c6d > 03000600100259d45bb205000a00 > 010038392e3231322e37362e3130392f3332 > 05000b00010038392e3231322e39312e3137382f3332 > 04000800a0009884229af8684722ecf09bfe79c0d8eef96b3cfb > 04000900c000e73eb8f1c43d90bdfaf40fb3abfe879d28e74cf8e870dd0b01001400 > 0101010013000300150010020a00 > 030011001002ff00030016001002 > 0a070800030012001002ff00 > 0200210008007465737476706e00 > Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: sync SA 0x88cca800 > len 504 to peer 10.23.6.2 > Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: sync SA 0x88cca9f8 > len 504 to peer 10.23.6.2 > Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: sync SA 0x88ccabf0 > len 504 to peer 10.23.6.2 > Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: sync SA 0x88ccade8 > len 504 to peer 10.23.6.2 > Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: SPD data > 02121d0003000600100259d44c6d > 010014000101010013000300150010020a00 > 030011001002ff0003001600 > 10020a070800030012001002ff00 > 05000a00010038392e3231322e39312e3137 > 382f333205000b00010038392e3231322e37 > 362e3130392f333202121d0003000600 > 100259d44c6d01001400030201001300 > 0300150010020a070800030011001002 > ff000300160010020a00 > 030012001002ff0005000a000100 > 38392e3231322e39312e3137382f333205000b000100 > 38392e3231322e37362e3130392f33320212 > Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: sync FLOW 0x88cca000 > len 232 to peer 10.23.6.2 > J
Re: sasyncd syncs only newly created sad's
Hi again, there is no feedback.. could someone who runs sasyncd check this for me? Please, just restart sasyncd on slave(or master), and see if it syncs the SAD's? This behaviour renders my redundant routers - non redundant. If I reboot master, when it comes back and become master again, all VPN tunnels are down because no SAD's are synced. Thank you very much. -Original Message- From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of Mihajlo Manojlov Sent: Wednesday, January 06, 2010 11:10 PM To: misc@openbsd.org Subject: sasyncd syncs only newly created sad's Hi to all, I have two carped boxes and I want to use sasyncd for vpn redundancy, but only newly created sad's get synced. For example, I reboot the slave box, and when it comes up again, sasyncd only sets flows, not the sad's. Maybe this is normal behaviour? log from master: Jan 6 21:59:23 openbsd1 sasyncd[25895]: net: peer "10.23.6.2" connected Jan 6 21:59:23 openbsd1 sasyncd[25895]: net_ctl: peer "10.23.6.2" state change to SLAVE Jan 6 21:59:25 openbsd1 sasyncd[25895]: monitor_get_pfkey_snap: got 2016 bytes SADB, 1392 bytes SPD Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_send_flush: sending FLUSH to peer 10.23.6.2 Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: SADB data 020a00023f000200010088f180d710010303040004000200 15f7444b04000400 380404000300 b00403000500100259d44c6d 03000600100259d45bb205000a00 010038392e3231322e37362e3130392f3332 05000b00010038392e3231322e39312e3137382f3332 04000800a0009884229af8684722ecf09bfe79c0d8eef96b3cfb 04000900c000e73eb8f1c43d90bdfaf40fb3abfe879d28e74cf8e870dd0b01001400 0101010013000300150010020a00 030011001002ff00030016001002 0a070800030012001002ff00 0200210008007465737476706e00 Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: sync SA 0x88cca800 len 504 to peer 10.23.6.2 Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: sync SA 0x88cca9f8 len 504 to peer 10.23.6.2 Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: sync SA 0x88ccabf0 len 504 to peer 10.23.6.2 Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: sync SA 0x88ccade8 len 504 to peer 10.23.6.2 Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: SPD data 02121d0003000600100259d44c6d 010014000101010013000300150010020a00 030011001002ff0003001600 10020a070800030012001002ff00 05000a00010038392e3231322e39312e3137 382f333205000b00010038392e3231322e37 362e3130392f333202121d0003000600 100259d44c6d01001400030201001300 0300150010020a070800030011001002 ff000300160010020a00 030012001002ff0005000a000100 38392e3231322e39312e3137382f333205000b000100 38392e3231322e37362e3130392f33320212 Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: sync FLOW 0x88cca000 len 232 to peer 10.23.6.2 Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: sync FLOW 0x88cca0e8 len 232 to peer 10.23.6.2 Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: sync FLOW 0x88cca1d0 len 232 to peer 10.23.6.2 Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: sync FLOW 0x88cca2b8 len 232 to peer 10.23.6.2 Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: sync FLOW 0x88cca3a0 len 232 to peer 10.23.6.2 Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: sync FLOW 0x88cca488 len 232 to peer 10.23.6.2 It looks to me like everything is ok? log from slave: Jan 6 22:52:09 openbsd2 sasyncd[3384]: config: add peer 10.23.6.3 Jan 6 22:52:09 openbsd2 sasyncd[3384]: config: interface carp3 Jan 6 22:52:09 openbsd2 sasyncd[3384]: config: group carp Jan 6 22:52:09 openbsd2 sasyncd[3384]: config: 32 byte shared hex key Jan 6 22:52:09 openbsd2 sasyncd[3384]: config: shared key set Jan 6 22:52:09 openbsd2 sasyncd[3384]: carp_init: initializing runstate to SLAVE Jan 6 22:52:09 openbsd2 sasyncd[3384]: listening on 0.0.0.0 port 500 fd 6 Jan 6 22:52:09 openbsd2 sasyncd[3384]: net_connect: peer "10.23.6.3" connected, fd 7 Jan 6 22:52:09 openbsd2
sasyncd syncs only newly created sad's
Hi to all, I have two carped boxes and I want to use sasyncd for vpn redundancy, but only newly created sad's get synced. For example, I reboot the slave box, and when it comes up again, sasyncd only sets flows, not the sad's. Maybe this is normal behaviour? log from master: Jan 6 21:59:23 openbsd1 sasyncd[25895]: net: peer "10.23.6.2" connected Jan 6 21:59:23 openbsd1 sasyncd[25895]: net_ctl: peer "10.23.6.2" state change to SLAVE Jan 6 21:59:25 openbsd1 sasyncd[25895]: monitor_get_pfkey_snap: got 2016 bytes SADB, 1392 bytes SPD Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_send_flush: sending FLUSH to peer 10.23.6.2 Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: SADB data 020a00023f000200010088f180d710010303040004000200 15f7444b04000400 380404000300 b00403000500100259d44c6d 03000600100259d45bb205000a00 010038392e3231322e37362e3130392f3332 05000b00010038392e3231322e39312e3137382f3332 04000800a0009884229af8684722ecf09bfe79c0d8eef96b3cfb 04000900c000e73eb8f1c43d90bdfaf40fb3abfe879d28e74cf8e870dd0b01001400 0101010013000300150010020a00 030011001002ff00030016001002 0a070800030012001002ff00 0200210008007465737476706e00 Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: sync SA 0x88cca800 len 504 to peer 10.23.6.2 Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: sync SA 0x88cca9f8 len 504 to peer 10.23.6.2 Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: sync SA 0x88ccabf0 len 504 to peer 10.23.6.2 Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: sync SA 0x88ccade8 len 504 to peer 10.23.6.2 Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: SPD data 02121d0003000600100259d44c6d 010014000101010013000300150010020a00 030011001002ff0003001600 10020a070800030012001002ff00 05000a00010038392e3231322e39312e3137 382f333205000b00010038392e3231322e37 362e3130392f333202121d0003000600 100259d44c6d01001400030201001300 0300150010020a070800030011001002 ff000300160010020a00 030012001002ff0005000a000100 38392e3231322e39312e3137382f333205000b000100 38392e3231322e37362e3130392f33320212 Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: sync FLOW 0x88cca000 len 232 to peer 10.23.6.2 Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: sync FLOW 0x88cca0e8 len 232 to peer 10.23.6.2 Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: sync FLOW 0x88cca1d0 len 232 to peer 10.23.6.2 Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: sync FLOW 0x88cca2b8 len 232 to peer 10.23.6.2 Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: sync FLOW 0x88cca3a0 len 232 to peer 10.23.6.2 Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: sync FLOW 0x88cca488 len 232 to peer 10.23.6.2 It looks to me like everything is ok? log from slave: Jan 6 22:52:09 openbsd2 sasyncd[3384]: config: add peer 10.23.6.3 Jan 6 22:52:09 openbsd2 sasyncd[3384]: config: interface carp3 Jan 6 22:52:09 openbsd2 sasyncd[3384]: config: group carp Jan 6 22:52:09 openbsd2 sasyncd[3384]: config: 32 byte shared hex key Jan 6 22:52:09 openbsd2 sasyncd[3384]: config: shared key set Jan 6 22:52:09 openbsd2 sasyncd[3384]: carp_init: initializing runstate to SLAVE Jan 6 22:52:09 openbsd2 sasyncd[3384]: listening on 0.0.0.0 port 500 fd 6 Jan 6 22:52:09 openbsd2 sasyncd[3384]: net_connect: peer "10.23.6.3" connected, fd 7 Jan 6 22:52:09 openbsd2 sasyncd[26685]: net_ctl: peer "10.23.6.3" state change to MASTER Jan 6 22:52:11 openbsd2 sasyncd[26685]: pfkey_queue_message: pfkey FLUSH len 16 seq 1 Jan 6 22:52:11 openbsd2 sasyncd[26685]: pfkey_queue_message: pfkey ADD len 504 seq 2 Jan 6 22:52:11 openbsd2 sasyncd[26685]: pfkey_queue_message: pfkey ADD len 504 seq 3 Jan 6 22:52:11 openbsd2 sasyncd[26685]: pfkey: msg ADD write() failed on socket 5: Invalid argument Jan 6 22:52:11 openbsd2 sasyncd[26685]: pfkey_queue_message: pfkey ADD len 504 seq 4 Jan 6 22:52:11 openbsd2 sasyncd[26685]: pfkey: msg ADD write() failed on socket 5: Invalid argument Jan 6 22:52:11 openbsd2 sasyncd[26685]: pfk
