Resynchronizing Data

It may take a long time for load-related route changes to be implemented on prefixes with a low measurement rate--which, given the number of prefixes in a typical BGP table, could represent a significant percentage of your total load.

In order to optimize your load threshold tables without having to wait unreasonably long periods of time, you can force the decision-maker process to re-evaluate a specific set of prefixes at a shorter interval, using either of the following commands:

• resync prefix--an exec command, it forces an immediate, one-time resynchronization of data as soon as you enter it
• prefix resync--a config command that becomes part of the running configuration; the resynchronization process will be carried out at a specified interval, for a specified number of prefixes in the designated set

You can force one of the following CNA decision-maker actions for the specified prefixes:

• compute-winner-set--recomputes which links are in the winner set
• clear--withdraws all asserted routes and clears the traffic measurement counters
• clear-routes-only--withdraws all asserted routes but leaves counters set
• reassert-route--reasserts the currently selected prefixes

You should exercise caution when using the config version of the command. If the number of prefixes in the set is large (if you specify all, for example), you may need to spread the resynchronization process over a period of time, using the limit and interval arguments. With a limit of 60 and an interval of 300 seconds (the defaults), the decision-maker process will resynchronize prefixes in batches of 60 every five minutes rather than churning the entire set all at once. At each interval, the prefixes that have gone the longest time without an update will be reprocessed.

Once you are satisfied with your load optimization environment, you should remove the prefix resync command from the configuration.