Learn F5 Technologies, Get Answers & Share Community Solutions Join DevCentral

Filter by:
  • Solution
  • Technology
Answers

Any Reasons NOT to use automatic with incremental synchronization sync type

Situation: Have an active and standby pair on 5200 boxes/13.1 release. ~ 300 VIP on LTM, 20 APM policies, 50 ASM policies. Several of ASM policies with policy building in automatic mode. We have auto failover turned on if Primary goes down but Not configured to auto failback on standby device. Those items noted...

Are there any concerns about using automatic with incremental synchronization sync type? Two potential pitfalls I could see are the following a) Policy building in auto mode will result in more ASM Policy updates and trigger more syncs. Question - Will every change to counter result in policy update? b) Maximum Incremental Sync Size is 1024, and if more, will due a full syncronization. How can one determine what the sync size is for a given syncronization due to an individual ASM, LTM, or APM change?

I would prefer to use auto sync if possible to ensure backups are as up to date as possible but anecdotally am not aware of many shops using auto sync. Welcome community's thoughts on the matter. Thanks.

0
Rate this Question

Answers to this Question

placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

The biggest issue with auto-sync is that the device that receives config changes does not write the changes to disk - the change only exists in memory in MCPD. This is a deliberate design decision to prevent the BigIP spending all it's time writing config changes to disk as a number of small changes are made on the peer.

K14624: Configuring the Automatic Sync feature to save the configuration on the remote devices

This can lead to a situation where the configuration can be lost if the system where changes are made (and saved) fails, and then the peer restarts or reloads the config from disk without saving.
You can enable save-on-auto-sync but this introduces risks with very large configs.

If you are using ASM Policy Builder, then the ASM sync group should be set to automatic.
You have to make a choice about your LTM sync groups, based on the size of the configuration, the frequency of changes, and your own management policies.

Some people with auto-sync enabled use a cron task to ensure that a
tmsh save /sys config
is run at a regular interval (I'd suggest no more than hourly, as opposed to daily).

0
Comments on this Answer
Comment made 17-May-2018 by Check1t 167

Thanks for the great information! Follow up question. How does one make just an ASM (or LTM) sync group? I thought sync groups were only device.

0
Comment made 17-May-2018 by S Blakely
0
Comment made 17-May-2018 by andrew 195

The other thing with auto sync is to look at, going forward how much config are you going to build that doesn't sync. The more you do ( creation of vlans, self ips, routes etc) the more likely you will run into situations where your auto sync fails while you are deploying these types of configurations ( order of config deploy can become very important).

It will only effect you during changes but I find it quite annoying :).

0
Comment made 18-May-2018 by Check1t 167

Thanks again, all, for the information!

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

Here's a reason not to use autosync - if you don't change the default behavior, the config is sync'd to all devices, but not saved. I can see scenarios where a total DC failure results in something other than the most recent production config being deployed. Link here.

0