Deploying to the startup configuration
A job with the Deploy to Stored action copies a configuration to a device's Startup configuration. The Deploy to Stored action only applies to devices that support a Startup configuration and allow external systems to directly write to the Startup configuration.
You can deploy the device's Trusted Startup, or one of the device's Historical Startup, Target, or a Template to the device's Startup configuration. You can choose to reboot or to mark the restored configuration as Trusted during the deployment.
After the Deploy to Stored action, the device's Startup configuration is compared to its Trusted Startup configuration. Differences are reported as configuration discrepancies on the Dashboard and Discrepancy reports. If the Trusted Startup is Deployed to Stored, all discrepancies are cleared. If a change is detected after the Deploy to Stored action, a historical Startup configuration is created.
For more generic information about job creation, see Creating a job.
To run the Deploy to Stored action
- On the Add Job page, select Add Action > Span Actions > Deploy to Stored.
Enter information in the following fields:
(Optional) Annotation assigned to the configurations created by the action.
Select a realm, group, multiple devices, or a single device for the Deploy to Stored action. When the Network Span is Realm or Group, you can use Filter Devices to select which devices to include in the action.
When the action is triggered in an event-based Policy, additional options include: Same as Triggering Realm, Same as Triggering Group, Same as Triggering Device.
- In the Configuration field, select the configuration file to deploy to the device's Startup configuration.
- Trusted Startup: Deploy the device's Trusted Startup configuration.
- Target: Deploy the device's Target configuration.
- Template: Deploy the selected Template. If the Template uses runtime parameters, click Params and assign values to the parameters.
- Historical Running/Startup: Deploy a historical running or startup configuration.
- Remediate With: Select one or more rule sets and rules to apply to the current Startup configuration. Under certain conditions, BMC Network Automation can make the configuration compliant based on the rule grammar and device type. BMC Network Automation creates a full configuration to deploy.
- Remediate With All Assigned: Apply all assigned rule sets to the current Startup configuration, to correct rules actively in violation. Under certain conditions, BMC Network Automation can make the configuration compliant based on the rule grammar and device type. BMC Network Automation creates a full configuration to deploy.
- Historical Trail(s) By Date: Deploy the selected historical trails to the devices in the selected network span, to their stored configuration. Use this option when several different trails should always be deployed together, when they have inter-related settings. Select one or more trails, other than the startup trail from the drop-down menu of deployable trails, then choose the configuration active at that date/time. Only those trails applicable to a particular device are deployed to that device.
- Historical Trail: Deploy a selected configuration to the selected device. Select the trail to be deployed, then select the particular configuration.
Select any of the following options, as relevant:
Mark as Trusted
After the configuration is deployed, mark the current Running and Startup configurations as Trusted.
Reboot the device after the configuration is deployed.
Use Auxiliary Interface When this option is selected and the selected network span is a device, the auxiliary interface is used for connecting to the device. When this option is not selected or the span is not a device, the primary interface is used.
Ignore Any Rule Conflicts
If remediating multiple rules, ignore any conflicts between corrections in different rules. By default such conflicts are not ignored, and cause the action to fail to generate the compliant configuration, since conflicts usually lead to incorrect syntax or unexpected changes. Ignore conflicts only when you have reviewed the compliant configuration and verified it is correct in spite of conflicts.
Note that the system can detect conflicts only within a single sub-action, for sub-actions that generate a compliant configuration. The system cannot detect conflicts across different sub-actions. For example, the system cannot detect that two sub-actions, each pushing a template contain conflicting commands in the templates, or that two image deployments cancel each other out. Use the Preview feature to review the details of the sub-actions when remediating many violations at once.
Override Rule Corrective Action Options When remediating, indicates which option settings are used. When this options is selected, the option settings you choose here take effect. When not selected, the option settings in the Deploy to Stored corrective actions of the rule take effect.
- Click OK to add the action to the job.
Additional information regarding remediation
When you choose Remediate With All Assigned, a device must be actively in violation of a rule for the Deploy to Stored corrective actions of the rule to be executed. When you choose Remediate With, a device need not be in violation.
Only the Deploy to Stored corrective actions in a rule are executed by a Deploy to Stored span action. Any corrective action that is a Deploy to Active, Deploy OS Image, or custom action is ignored when running a Deploy to Stored span action.
The Deploy to Stored span action expands into one or more Deploy to Stored sub-actions, each of which performs one corrective action. For example, you might have selected to remediate some rules whose corrective action pushes a template and other rules that push a compliant configuration. These would be represented as two sub-actions under the top-level Deploy to Stored action. You can observe this action and sub-action hierarchy on the Preview Sub-Actions and Scripts page, the Job Details page, and the Job Summary report.