Forum Discussion

Check1t_282465's avatar
Check1t_282465
Icon for Nimbostratus rankNimbostratus
May 14, 2018

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.

 

application delivery
BIG-IP
security

2 Replies

Sort By
  • rob_carr's avatar
    rob_carr
    Icon for Cirrostratus rankCirrostratus
    May 15, 2018

    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.

     

  • Simon_Blakely's avatar
    Simon_Blakely
    Icon for Employee rankEmployee
    May 15, 2018

    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).