Perry_71428
Feb 06, 2012Nimbostratus
Config Sync Problem - LTM v11.1.0 Hotfix 1953.0
Hi
I have raised a F5 support case for this which is still being worked on, but has anyone else experienced any issues with config sync in LTM v11.1.0 Hotfix 1953.0 after adding a ssl certificate to an active unit in an active/passive pair?
I have 20 ssl loaded plus all required VIP's/Pool's/Nodes/Irules etc etc and after making changes to anything except adding another ssl config sync works fine.
However, adding that extra cert (and I have tried certs from different CA's but the same error occurs), causes the config sync to fail and it blows away the config sync interface
> Feb 3 12:31:07 LB01 notice logger: /usr/bin/tmipsecd --tmmcount 2 ==> /usr/bin/bigstart restart racoon
> Feb 3 12:34:54 LB01 err mcpd[29254]: 01071392:3: Background command '/usr/bin/rsync --rsync-path=/usr/bin/rsync -at --blocking-io /var/named/ rsync://192.168.0.2/var_name' failed. The command exited with status 12.
> Feb 3 12:41:35 LB01 err mcpd[29254]: 01071392:3: Background command '/usr/bin/rsync --rsync-path=/usr/bin/rsync -at --blocking-io /var/named/ rsync://192.168.0.2/var_name' failed. The command exited with status 12.
> Feb 3 12:45:55 LB01 info bcm56xxd[29185]: 012c0015:6: Link: 1.4 is DOWN
>
> Feb 3 12:49:24 LB01 notice mcpd[29254]: 0107143a:5: CMI reconnect timer: disabled, all peers are connected
> Feb 3 12:51:29 LB01 err mcpd[29254]: 01071392:3: Background command '/usr/bin/rsync --rsync-path=/usr/bin/rsync -at --blocking-io /var/named/ rsync://192.168.0.2/var_name' failed. The command exited with status 23.
> Feb 3 12:54:34 LB01 err mcpd[29254]: 01071392:3: Background command '/usr/bin/rsync --rsync-path=/usr/bin/rsync -at --blocking-io /var/named/ rsync://192.168.0.2/var_name' failed. The command exited with status 23.
> Feb 3 12:55:26 LB01 info bcm56xxd[29185]: 012c0015:6: Link: 1.4 is DOWN
>
> eb 3 13:00:41 LB01 err mcpd[29254]: 01071392:3: Background command '/usr/bin/rsync --rsync-path=/usr/bin/rsync -at --blocking-io /var/named/ rsync://192.168.0.2/var_name' failed. The command exited with status 23.
> Feb 3 13:08:11 LB01 err mcpd[29254]: 01071392:3: Background command '/usr/bin/rsync --rsync-path=/usr/bin/rsync -at --blocking-io /var/named/ rsync://192.168.0.2/var_name' failed. The command exited with status 23.
> Feb 3 13:08:35 LB01 info bcm56xxd[29185]: 012c0015:6: Link: 1.4 is DOWN
> Feb 3 13:08:38 tmm1 err tmm1[31736]: 01340002:3: HA Connection with peer 192.168.0.2:1028 lost.
Changing the config sync interface to be another self IP makes no difference (and indeed makes it harder to get out of the problem when not using the HA connection between the units)
Another bit of evidence is that under some circumstances, after the failed config sync, the config fails to load at all giving a syntax error when it finds the word "ALL" in a datagroup string value.
After removing the additional certificate, and a bit more messing around with reboots, the units sync again properly. The "ALL" in the datagroup string value is then not an issue again (so I think this is a symptom of the problem rather than the cause)
It seems to me there must be either some kind of config corruption happening when the ssl certificate is imported, or there is a bug in the config parser/loader that I am hitting.
Anyone else seen this or anything similar that may help to fix/workaround?
Thanks
Perry