bigIpPeerAddr - without some kind of reverse engineering it is not 100% clear which IP is expected (IP from first device, as trust is established from second bigip).
Yes - looking at IP and reverse engineer does the trick; looking at runtime-init and see trust is established from second device does the trick, too. but it would be better to have it in the docs - stating IP of first memeber is expected (sync initiated from second member).
Documentation link
https://github.com/F5Networks/f5-azure-arm-templates-v2/tree/main/examples/failover
Describe the problem
bigIpPeerAddr - without some kind of reverse engineering it is not 100% clear which IP is expected (IP from first device, as trust is established from second bigip). Yes - looking at IP and reverse engineer does the trick; looking at runtime-init and see trust is established from second device does the trick, too. but it would be better to have it in the docs - stating IP of first memeber is expected (sync initiated from second member).
inaccuracysee above
Suggested fix
see above