Forum Discussion
CirrusRestore configuration to GTM Sync Group device
I am in the process of writing up a change to delete config from a GTM Sync Group which I am fine with but I am looking to confirm my thoughts on how to restore the configuration should I need to back the change out.
For an LTM F5 I would create a UCS file on the Standby device before making any changes as the first step. Then should I need to rollback I would just restore the UCS file to the Standby device, check that the configuration has restored correctly and then sync the Standby device to the Active.
I think that a similar approach will work for the devices in the GTM Sync Group but I want to avoid the restored config automatically syncing to the other devices in the GTM Sync Group so my thoughts on how to do this are as follows:
1. Log onto the Standby F5
2. Navigate to DNS > Settings > GSLB > General
3. Untick the 'Synchronize' and 'Synchronize DNS Zone Files' tick boxes
4. Change the Group Name to something unique.
5. Save the config
6. Create the UCS file
7. Reverse the changes made in Steps 3 and 4
8. Delete configuration
The thinking here is that should I need to restore the config from the UCS file there is no chance of this automatically syncing to the other devices in the GTM Sync Group since it was not part of the GTM Sync Group when this was taken. Once restored I would then update the description for one of the WideIP's (simply append something like '1234' to it) so that this has the higher 'commit-id' and then add the device back to the GTM Sync Group. Since the newly added device has the highest 'commit-id' this would then push the confog back to the GTM Sync Group and I am back where I started.
To my mind this makes sense but it would be very much appreciated if I could get a second opinion on this.
Your approach looks reasonable to me.
If it were me, I’d also include gtm_add in the rollback procedure.
Taking the UCS while the device is temporarily out of the GTM sync group is a good way to avoid any unintended sync during restore. Then, if rollback is needed, I’d restore the config on that device first and run gtm_add from the restored device toward the existing device that has the desired config / higher commit-id, so it pulls the GSLB config back in a controlled way.
So overall, I think your plan makes sense — I’d just add gtm_add as part of the backout steps as well.
https://my.f5.com/manage/s/article/K14044
5 Replies
AXI_MJAltocumulus
Your approach looks reasonable to me.
If it were me, I’d also include gtm_add in the rollback procedure.
Taking the UCS while the device is temporarily out of the GTM sync group is a good way to avoid any unintended sync during restore. Then, if rollback is needed, I’d restore the config on that device first and run gtm_add from the restored device toward the existing device that has the desired config / higher commit-id, so it pulls the GSLB config back in a controlled way.
So overall, I think your plan makes sense — I’d just add gtm_add as part of the backout steps as well.
https://my.f5.com/manage/s/article/K14044
- leemedz
Thanks for that.
Re: the following line: "Then, if rollback is needed, I’d restore the config on that device first and run gtm_add from the restored device toward the existing device that has the desired config / higher commit-id"
I have quite probably over thought this but am I not going to end up pulling back the config from one of the devices that doesn't have the removed config included due to the following:
"Impact of procedure: The following procedure replaces the configuration from the BIG-IP DNS system on which it is run, with the configuration of the remote BIG-IP DNS system in the specified synchronization group."
Just to be clear the steps I would be looking at to rollback are as follows:
- Log onto the Standby F5
- Navigate to DNS > Settings > GSLB > General
- Untick the 'Synchronize' and 'Synchronize DNS Zone Files' tick boxes
- Change the Group Name to something unique.
- Save the config
- Restore the UCS file that I took pre-change - this will then have the config with the devices that I removed during the change included.
- Update one of the WideIP's so this has the latest commit-id
- Add it back to the group - since the Standby F5 I am performing these steps on has the latest commit-id this should then synchronise the configuration one that device to the rest of the group.
Also a follow up question.
Is there a way to see the commit-id on the device that I have removed from the GTM Sync group once the configuration item has been updated for comparison purposes? I know you can see the Configuration Time and Configuration Commit ID when running the 'show gtm iquery command' and having looked at the outputs the Configuration Time seems the more likely of the two since the Configuration Commit ID returns what looks to be a file size 'Configuration Commit ID 254.2K' so that may not be ideal for my purposes here. Also if the device is not in the GTM Sync group can I get those details if the device is not in the GTM Sync group?
Thanks
- AXI_MJ
Hello, I also conducted a simple test.
The commit ID increases when there are configuration changes.
My test scenario is as follows:
1. Interface failover on Device 2
2. Change the Group name on Device 2
3. Add configuration to Device 2
In this situation, the commit ID on Device 2 was displayed as 115.
On Device 1, the commit ID on Device 2 was still displayed as 100.
The value increases when configuration changes are recognized.
I suspect that the accumulated value is high because you have been operating this for a long time.
In this situation, after connecting the interface on Device 2 and restoring the Group name on Device 2, the system synchronized with Device 2's configuration because Device 2's commit ID was higher.
I searched for a method to reset the commit ID (e.g., `reset-stats gtm iquery IP`), but I could not find one.
If the current commit ID is too high to serve as a reference, it appears you will have to rely on Configuration Time.
Thank you.
- leemedz
Ignore the questions above - I have just found the following F5 article which explains what AMI_MJ was saying: Force sync config to a specific GTM / DNS device
Thanks all for the assistance. 😁
