Forum Discussion
CirrusRestore configuration to GTM Sync Group device
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
CirrusThanks 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
AltocumulusHello, 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
Thanks for the further investigations - the GTM Sync group has been running for a long time so that would explain the high number.
I need to get a pair of GTM's built in my lab at some point so I can perform some testing like this, just to many other projects to deal with first. 😆
