Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?


Policy Assurance Operations

Incremental Access List Deployment

To minimize the potential impact on existing traffic flows of a policy deployment in operating systems that leverage instant activation and line-by-line changes, Apstra automatically performs a multistep process for deploying policy changes. This ensures that the network does not enter an open (free-flowing traffic) state while the rules are being pushed into the Tertiary Content-Addressable Memory (TCAM).

Apstra performs the following workflow during policy changes:

  1. Install temp Access List (ACL), write it to the device as previous-acl-name_TMP

  2. Switch to _TMP ACL

  3. Add original ACL with new rendering

  4. Switch to the original ACL

  5. Remove the TMP ACL


We recommend not using more than 50% of TCAM to allow for secondary ACL (some NOS can do this on their own but require TCAM to “merge” entries into an ACL). We recommend that customers leave default ACL atomic update settings as is in NX-OS and EOS. This means if an applied ACL (say, using X TCAM entries) is modified, the NOS needs 2x free TCAM space during ACK modification. Our change improves modification by enforcing policies even when the atomic update is impossible.


Changing atomic update settings is not controlled by Apstra.

Example Policy Deployment

The following is an example policy deployment object:

Policy Enable/Disable

Policies can be enabled and disabled easily through the Apstra UI or API. Switching a policy to disabled queues the change in Uncommitted, and the administrator must Commit the changes to the Blueprint for them to take effect.

Policy Export/Import

You can import and export policies via the API. The same policy objects are required for a proper import. This is especially helpful when managing multiple Blueprints with identical policies.