Config Sync Failure After Adding a Route-Domain Self IP
An active/standby BIG-IP pair runs in a single device group with full sync and failover. The active unit is primary for all traffic groups. An engineer adds a new VLAN and self IP 10.10.30.5/24 in route domain 1 on the active unit for an internal management network, then runs config sync. The sync fails, and the standby logs 'load failed' for the new self IP. The VLAN exists on both units with the same tag, but the standby's self IP list does not show 10.10.30.5. Route domain 1 exists on the active unit but not on the standby. The standby also has a management default route that the active unit does not have. NTP is synchronized, and the new self IP does not conflict with any existing address. The engineer wants to force a full sync from active to standby.
1. Diagnose why the sync failed and assess whether forcing a full sync is safe.
Read the worked answer
Config sync is failing on a missing dependency, not on the self IP address itself. The new self IP is in route domain 1, and that route domain does not exist on the standby. The standby cannot instantiate the self IP, so it logs 'load failed' and stops the sync. The VLAN matching is necessary but not sufficient.
Forcing a full sync is risky here. The standby has a management default route that the active unit lacks. A force-push from active to standby can remove that route and cut management access to the standby, which is exactly when you need it. Capture a qkview from both units, compare tmsh list net route-domain, net vlan, net self, and net route, and confirm the dependency mismatch before changing anything.
2. Describe the safe remediation sequence, including backups and verification points.
Read the worked answer
Take a UCS backup on both units first. On the standby, create route domain 1 with the same ID and parent as the active unit, or correct the partition and object reference if the route domain exists elsewhere. Do not start by forcing sync. Once the dependency exists, run config sync again and watch the sync status on both units. If the sync still fails, compare the exact object named in the log and resolve that dependency rather than overriding it.
After sync succeeds, verify that the standby still has its management route and that management access works. Check that the new self IP appears on the standby in the correct traffic group and that the VLAN and route domain match. Only then consider a controlled failover test.
3. How would you validate HA behavior after the change without causing an outage?
Read the worked answer
Review traffic-group ownership and sync status first. Schedule a maintenance window and run a controlled failover with tmsh run sys failover standby or by using the traffic-group commands, while monitoring management access and the new self IP. Confirm that the self IP floats to the newly active unit, that the standby remains reachable, and that config sync is still in sync after failover.
Test from a management host on the new network, not just from the BIG-IP itself. Check logs for load failures and verify that no routes were removed. After the test, fail back in a controlled way and confirm the pair returns to the expected active/standby state.