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: [email protected] [mailto:[email protected]] On Behalf Of > Mihajlo Manojlov > Sent: Wednesday, January 06, 2010 11:10 PM > To: [email protected] > 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 > 020a00023f00000000000000000000000200010088f180d7100103030400000004000200 > 00000000000000000000000015f7444b0000000000000000000000000400040000000000 > 000000000000000038040000000000000000000000000000040003000000000000000000 > 00000000b004000000000000000000000000000003000500000000001002000059d44c6d > 000000000000000003000600000000001002000059d45bb2000000000000000005000a00 > 01000000000000000000000038392e3231322e37362e3130392f33320000000000000000 > 05000b0001000000000000000000000038392e3231322e39312e3137382f333200000000 > 0000000004000800a00000009884229af8684722ecf09bfe79c0d8eef96b3cfb00000000 > 04000900c0000000e73eb8f1c43d90bdfaf40fb3abfe879d28e74cf8e870dd0b01001400 > 0101000001001300000000000300150000000000100200000a0000000000000000000000 > 030011000000000010020000ffffff000000000000000000030016000000000010020000 > 0a0708000000000000000000030012000000000010020000ffffff000000000000000000 > 02002100080000007465737476706e000000000000000000000000000000000000000000 > 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 > 021000021d000000000000000000000003000600000000001002000059d44c6d00000000 > 00000000010014000101000001001300000000000300150000000000100200000a000000 > 0000000000000000030011000000000010020000ffffff00000000000000000003001600 > 00000000100200000a0708000000000000000000030012000000000010020000ffffff00 > 000000000000000005000a0001000000000000000000000038392e3231322e39312e3137 > 382f3332000000000000000005000b0001000000000000000000000038392e3231322e37 > 362e3130392f33320000000000000000021000021d000000000000000000000003000600 > 000000001002000059d44c6d000000000000000001001400030200000100130000000000 > 0300150000000000100200000a0708000000000000000000030011000000000010020000 > ffffff0000000000000000000300160000000000100200000a0000000000000000000000 > 030012000000000010020000ffffff00000000000000000005000a000100000000000000 > 0000000038392e3231322e39312e3137382f3332000000000000000005000b0001000000 > 000000000000000038392e3231322e37362e3130392f3332000000000000000002100002 > 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]: pfkey_queue_message: pfkey ADD len > 504 seq 5 > 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 X_ADDFLOW > len 232 seq 6 > 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 X_ADDFLOW > len 232 seq 7 > Jan 6 22:52:11 openbsd2 sasyncd[26685]: pfkey_queue_message: pfkey X_ADDFLOW > len 232 seq 8 > Jan 6 22:52:11 openbsd2 sasyncd[26685]: pfkey_queue_message: pfkey X_ADDFLOW > len 232 seq 9 > Jan 6 22:52:11 openbsd2 sasyncd[26685]: pfkey_queue_message: pfkey X_ADDFLOW > len 232 seq 10 > Jan 6 22:52:11 openbsd2 sasyncd[26685]: pfkey_queue_message: pfkey X_ADDFLOW > len 232 seq 11 > > I've searched the web for "pfkey: msg ADD write() failed on socket 5: Invalid > argument", but I've only found openswan related info. > I went through all google results for "sasyncd", and only clue I've got from > this link: http://www.lugbe.ch/action/reports/BSDCluster.pdf > where it says for sasyncd: > Known bugs: Resynchronisation des Master nach Reboot > which, I assume, have something to do with this problem. But I couldn't find > anything else about that bug > > When a new SAD is created on the master, it is normaly synced with slave. > I am runnig 4.6-stable > I will send more info If it is needed. > > Thank you very much
