There are several ways to modify an existing filter policy. A filter policy can be modified through configuration change or can have entries populated through dynamic, policy-controlled dynamic interfaces; for example, RADIUS, OpenFlow, FlowSpec, or Gx. Although in general, SR OS ensures filter resources exist before a filter can be modified, because of the dynamic nature of the policy-controlled interfaces, a configuration that was accepted may not be applied in H/W due to lack of resources. When that happens, an error is raised.
A filter policy can be modified directly—by changing/adding/deleting the existing entry in that filter policy—or indirectly. Examples of indirect change to filter policy include changing embedded filter entry this policy embeds (see the Filter policy scope and embedded filters section) or changing redirect policy this filter policy uses.
Finally, a filter policy deployed on a specific interface can be changed by changing the policy the interface is associated with.
All of the above changes can be done in service. A filter policy that is associated with service/interface cannot be deleted unless all associations are removed first.
For a large (complex) filter policy change, it may take a few seconds to load and initiate the filter policy configuration. Filter policy changes are downloaded to line cards immediately; therefore, operators should use filter policy copy or transactional CLI to ensure partial policy change is not activated.