Implications of Applied Filters
The implications of applied filters in partial configuration management are:
Configuration Compliance
Filter modification can change managed/unmanaged portions of designed and running configuration due to which configuration compliance status of some devices may get updated. In context of partial configuration management, the following logics determine the configuration compliance status of the device:
- Managed configuration lines and Unspecified configuration lines have the same compliance implications and they have to be in sync in the designed and running configuration for configuration compliance to be true. Which means changing such configuration lines outside CVP will mark the device out of compliance. Similarly modifying the designed configuration with addition/deletion of such configuration lines will result in out of compliance until they are pushed to the running configuration.
- Unmanaged configuration lines in the designed configuration will always result in configuration out of compliance. On the other hand, such configuration lines can be added to the running configuration outside CVP without causing the device to go out of compliance.
- Conflicting filters matching device’s designed or running configuration will mark the device out of compliance.
Provisioning
- Configlet management at device level -- Applied filters of `unmanaged` type can restrict CVP to modify corresponding unmanaged configuration lines. Configlets containing unmanaged configuration lines cannot be applied to a device. Validation of such proposed configuration will result in an error.
- Configlet management at container level -- Since this flow is not associated with a configuration validation process, it can result in making some unmanaged configuration lines part of the designed configuration. Hence, applying configlets containing unmanaged lines at container level will mark the underlying devices out of compliance. This can even create configuration push tasks, but they would fail later at the time of execution.
Change Control Approval
- Change controls with execute configuration task as one of their actions cannot be approved if the task diff contains unmanaged configuration lines in the designed configuration.
- Already approved change controls may get unapproved if filters associated with the underlying devices get changed.
Task Execution
Tasks with unmanaged configuration lines in the designed configuration will fail on execution. While viewing a task diff, inline errors will indicate the problematic lines and the relevant filters associated with the error.
Reconcile
- Reconcile at device level -- Unmanaged configuration lines from running configuration cannot be reconciled (tick boxes will not appear against those lines ). Whereas managed lines from running configuration are not reconciled by default (tick boxes will be there, but not marked by default), but if the user wants, they can be reconciled explicitly by marking the tick boxes manually.
- Reconcile at container level -- Reconcile process at container level will never reconcile managed or unmanaged configuration lines from running configuration. Thus, it will only add unspecified lines from the running configuration to reconcile configlets. It can also delete existing managed lines from the reconciled configlet and thereby affect the configuration compliance status of the device. Hence it is recommended to have dedicated configlets for the managed configuration lines and not to keep them as part of the reconciled configlets.
Studios and Workspaces
- Workspace build will fail at the configuration validation step if the proposed configuration has unmanaged configuration lines or there are conflicting filters assigned to devices mapped to the workspace.
- Any change in filters mapped to affected devices in a workspace will not affect workspace submission. So any errors introduced by filter changes will only be seen in the Change Control created by workspace.
- Reverts in workspace will not change the state of filters.