failover via LB - enableNetworkFailover to yes but devices are not fully configured

[Klipope]

using the latest image uploaded in marketplace: 16.1.1.0000
using template: https://github.com/F5Networks/f5-azure-arm-templates/tree/main/supported/failover/same-net/via-lb/3nic/existing-stack/byol
resources are deployed but the failover network configuration is incomplete on both devices.
failover unicast configuration is empty
if I manually configure the internal or external subnets in the configuration on both device then the cluster is up and running in Active/standby.

most likely an issue due to the new 16.1.1?
tried it 3 times and always with the same outcome.
thanks

[shyawnkarim]

Thanks for submitting this issue. I was able to duplicate the behavior with three different images:

• f5-networks:f5-big-ip-byol:f5-big-all-2slot-byol:15.1.400000

• f5-networks:f5-big-ip-byol:f5-big-all-2slot-byol:16.1.000000

• f5-networks:f5-big-ip-byol:f5-big-all-2slot-byol:16.1.100000

This issue is now being tracked internally with ID ESECLDTPLT-2918.

[Klipope]

thanks @shyawnkarim !

[shyawnkarim]

This template should work if an IP address is provided for the parameter internalIpAddressRangeStart instead of DYNAMIC. Please let me know if you are able to deploy with this change.

[Klipope]

@shyawnkarim just tested today with the change you mentioned and no.. I end up in the same situation. Both devices are standalone. the "Failover Unicast Configuration" configuration is empty on both devices. I used the 9.7.0 template with version 16.1.0. only change I made was to provision APM on top of LTM + your change in the "internalIpAddressRangeStart" field.
/var/log/cloud/azure/install.log gives the following error:
2022-01-10T08:04:30.518Z error: Onboard failed: remoteSender:172.16.100.4, method:POST
0107146f:3: Self-device unicast source address cannot reference the non-existent Self IP (172.16.20.10); Create it in the /Common folder first.
01020036:3: The requested device group (/Common/Sync) was not found.

[jmcalalang]

Is there an update on when this will get resolved in the template? We have another customer who just ran into this.

[shyawnkarim]

When engineering took a look at this issue they weren't able to reproduce the error when deploying with static IPs. @Klipope, can you send me your parameters file? s.karim@f5.com

[jmcalalang]

deploying static isnt a fix, its a work around. is there going to be a fix to continue to use dynamic?

[mikeoleary]

I have to agree, deploying with Static IP is not a fix, it's a workaround and most deployments I see will use the default value of dymanic, so this does affect us.

[shyawnkarim]

I've opened a new bug, internal ID ESECLDTPLT-2939, to investigate why DYNAMIC is not working as intended.

[Klipope]

sorry but even with static it did not work for me. @shyawnkarim will send you my parameters file.

[shyawnkarim]

Closing.

This issue was resolved with Release 9.8.0.0.