Explains how policy verification checks definitions, parameters, references, recursion, and attached objects to ensure policies are valid, consistent, and safe to activate.
Policy verification and integrity is a set of checks that
-
validates that policies are well formed, internally consistent, and safe to attach to protocol configuration
-
enforces value and parameter validation during policy definition and policy attachment, and
-
prevents invalid configurations such as recursive policy references and removal of policies or sets that are in use at an attach point.
Range checking
As policies are defined, the system performs simple verifications such as range checking of values. For example, when setting the Multi-Exit Discriminator (MED) attribute, the system verifies whether the value is within the proper range for the attribute.
Range checking cannot validate parameter specifications at definition time if parameter values are not defined. These are verified later when the policy is attached at an attach point.
At attach time, all policies must be well formed. All referenced sets and policies must be defined and contain valid values. Each parameter value must be within its proper range.
Validation at policy attach time
When you attach a policy, the system validates parameter specifications. Review these validation points:
-
Define all referenced policies and sets.
-
Make sure parameter values are valid.
-
Confirm that all policies are well-defined.
-
Verify recursive definitions.
-
Make sure the number of parameters is correct.
Parameter validation ensures that a policy is complete and valid before it becomes active at an attach point.
Recursive definition checks
The policy repository checks for recursive definitions. This prevents policies from directly or indirectly being applied in a way that causes invalid configuration.
The system enforces recursive definition checks before it allows policies to be attached.
Incomplete policy and set references
If you have not attached a policy, you can refer to sets or policies that do not exist yet. This gives you flexibility to define policies that refer to sets or policies you plan to create later.
For example, a policy may reference another policy using the apply statement even if the referenced policy does not yet exist. Similarly, a policy statement may refer to a set that has not been defined.
However, when you attach a policy, the system enforces the existence of all referenced policies and sets. If a policy references an undefined set or policy at attach time, the system rejects the configuration attempt.
Example:
If policy sample references policy bar , and bar does not exist, attempting to attach sample at an inbound BGP policy results in an error.
Null policy behavior
A null policy is a policy block that exists but contains no statements, actions, or dispositions.
Example:
route-policy bar
end-policy
This is a valid policy block. However, because it neither modifies the route nor includes a pass statement, the default drop disposition applies. As a result, the system drops all routes evaluated by this policy.
Protection for referenced policies and sets
You cannot remove a route policy or set that is currently in use at an attach point. If you try to remove a policy or set that is in use, the system displays an error message.
This behavior helps you avoid undefined references and keeps your configuration consistent.