Important

   

Starting version 8.9.03, BMC Network Automation is renamed to TrueSight Network Automation. This space contains information about BMC Network Automation 8.9.02 and previous versions. For TrueSight Network Automation 8.9.03 and later releases, see the TrueSight Network Automation documentation.

About device configuration management

The following topics provide information about managing device configurations by using BMC Network Automation.

Maintaining the trusted configuration

For each device, authorized users mark one running configuration and one startup configuration in each device's archive as trusted. When BMC Network Automation detects a difference between the current configuration and the trusted configuration, a discrepancy  is displayed on the Dashboard.

The Send Discrepancy Notification policy can be configured to send a notification (for example, SNMP, email) when a discrepancy is detected. Here are a few methods to limit when change discrepancy notifications are sent:

  • On the Policy Details tab, you can limit when (that is, day of the week, time of day) notifications should be sent if a discrepancy is detected.
  • On the Policy Condition page, you can limit the notifications to a filtered set of devices.

The following recommendations show how the trusted baseline tracking can complement your internal change process.

Case 1: For the most part, changes occur during scheduled change windows

  • Use the Dashboard during the change window to validate new changes, fix compliance violations, commit changes (copy Running to Startup) and roll back changes, as necessary.
  • At the end of the change window, use the Mark as Trusted span action to mark all current configurations as trusted.
    Between change windows, any discrepancies shown on the Dashboard are unplanned or emergency changes.

Case 2: For the most part, changes are made randomly as needed

  • At the start of the week (for example, Sunday, 1am), run a policy to Mark as Trusted all current configurations. You can also include the Mark as Trusted in your weekly snapshot policy as a second action. Use the network span filter to only Mark As Trusted those devices with a successful last snapshot status.
  • The Dashboard discrepancies track all changes made during the week to assist in troubleshooting potential problems caused by changes. Use the Dashboard during the week to review changes, commit changes (copy Running to Startup), fix compliance violations and rollback changes, as necessary.

Back to top

Creating standard provisioning templates

For each unique device model and OS image version, create one standard template content from an existing device configuration. Create the template from the Device Configuration tab for an existing model. Update the template to remove device specific commands. Use substitution parameters for template reusability (for example, ${device.host}, ${global.enablePassword}).

Back to top

Changing device configurations

You can change device configurations in the following ways:

  • Use the Deploy to Active span action to update the running configuration and the Deploy to Stored span action to update the startup configuration.

  • Use the Telnet/SSH span action to change the configuration.
  • Develop and install custom actions to change the configuration. Custom actions are useful when you need to:
    • Poll the device for state information to use for making a change.
    • Make logical decisions based on the execution status of one or more commands.

          To understand how to write and administer custom actions, see Developing a custom action adapter. 

For the Deploy to Active span action, based on the kind of change being made, one configuration selection might be better than another.

  Click here to view the best practices for the Deploy to Active span action.

Configuration

When best to use for the Deploy to Active span action

Trusted Running

Use to roll back the current running configuration to the Trusted Running configuration. For device types that support SmartMerge, BMC Network Automation builds a script of commands to rollback the device's running configuration to the trusted configuration. For device types that do not support SmartMerge, the entire Trusted Running configuration is transferred to the device's current running configuration.

Target

Warning: Verify that the Target is a full configuration. You can use the Target configuration to update a configuration. From the Network > Device pop-up , you can:

  • Assign Target (for example, current Running),
  • Edit Target for the necessary changes,
  • Audit Target for compliance with assigned Rules,
  • Deploy to Active Target to the device
    For device types that support SmartMerge, BMC Network Automation builds a script of commands to update the device's running configuration based on the edited target configuration. The script can add, delete and change command lines, including the handling of command blocks (for example, interface). If an ACL is modified, the script logic includes updating the ACL without exposure during the update. For device types that do not support SmartMerge, the entire target configuration is transferred to the device's current Running configuration.

Template

Use Templates when performing the same change on a repetitive basis. Make use of substitution parameters where necessary to customize templates for each new change request. Be sure to follow the template formatting requirements, which might include being restricted to using an injection template.

Ad-Hoc Template

Use Ad-Hoc Templates when the change is one-time and it is more efficient than using Telnet/SSH to make the change. The Ad-Hoc Template is not stored in the Template library. You can re-use the Ad-Hoc Template by copying the job.

Historical Running

Use to roll back the current running configuration to a prior running configuration.

For device types that support SmartMerge, BMC Network Automation builds a script of commands to rollback the device's running configuration to the historical running configuration. For device types that do not support SmartMerge, the entire prior running configuration is transferred to the device's running configuration.

Historical Startup

Use to roll back the current running configuration to a prior startup configuration.

For device types that support SmartMerge, BMC Network Automation builds a script of commands to rollback the device's current running configuration to the historical startup configuration. For device types that do not support SmartMerge, the entire prior startup configuration is transferred to the device's running configuration.

Remediate With...

Use to enforce any rule or rule set on the current running configuration. The rule or rule set does not need to be assigned or enabled. You might want to use a rule to take advantage of SmartMerge which creates a unique script based on each device's running configuration. For example, update a common ACL across multiple devices. Each script can be different depending on where ACL is applied.

For device types that support SmartMerge, BMC Network Automation builds a script of commands to enforce the rule(s) in the current running configuration. For device types that do not support SmartMerge, a compliant full configuration is built and transferred to the device's running configuration.

Remediate With All Assigned

Use to enforce assigned and enabled rule sets on the current running configuration.

For device types that support SmartMerge, BMC Network Automation builds a script of commands to enforce the rule(s) in the current running configuration. For device types that do not support SmartMerge, a compliant full configuration is built and transferred to the device's running configuration.

For the Deploy to Stored span action, based on the kind of change being made, one configuration selection might be better than another.

  Click here to view the best practices for the Deploy to Stored span action.

Configuration

When best to use for the Deploy to Stored span action

Trusted Startup

Use to copy the trusted Startup configuration to the device's Startup configuration.

Target

Warning: Make sure the target is a full configuration. Use to copy the target configuration to the device's Startup configuration.

Template

Warning: Make sure the template is a full configuration. Use to copy the template to the device's Startup configuration.

Historical Running

Use to copy a prior Running configuration to the device's Startup configuration.

Historical Startup

Use to copy a prior Startup configuration to the device's Startup configuration.

Remediate With

Use to enforce any rule or rule set on the current Startup configuration. The rule or rule set does not need to be assigned or enabled. Based on the current Startup configuration, BMC Network Automation builds a compliant configuration to copy to the device's Startup configuration.

Remediate With All Assigned

Use to enforce all assigned (that is, audited) rule sets on the current startup configuration. Based on the current Startup configuration, BMC Network Automation builds a compliant configuration to copy to the device's Startup configuration.

Using injection templates to change device configuration

You can create injection templates in the following ways:

  • By inserting the <injectionFlag> element in the template XML file and then importing the template into your environment
  • By using the Injection Template option in the GUI while adding a template or ad-hoc template

When changing device configuration using injection templates, consider the following limitations:

  • The Deploy to Active action with the injection template can only be run with device transfer mode as tunneled.
  • The Deploy to Active action with the injection template cannot perform syntax scan.
  • The <assign> device type command element cannot contain an embedded script in an injection template.

Perform the following steps to change device configuration using injection templates

  1. Add the injection templates to your environment by using one of following methods:
    • Import the template from an XML file. Insert the <injectionFlag> element in the template XML file with value set to true, and encapsulate the HTTP interactions in the <contents> tag with CDATA, as shown in the following sample code:

      <?xml version="1.0" encoding="UTF-8"?>
      <bbnaData>
        <version>
          <build></build>
          <lastUpgrader></lastUpgrader>
          <maint>@app.version.maint@</maint>
          <major>@app.version.major@</major>
          <minor>@app.version.minor@</minor>
          <patch>@app.version.patch@</patch>
        </version>
        <templateGroup>
          <annotation></annotation>
          <dynamicFields>
            <className>com.bmc.bcan.engine.network.scripts.TemplateGroup</className>
          </dynamicFields>
          <name>SampleInjectionTemplate</name>
          <substitutionParamCheck>false</substitutionParamCheck>
          <templates>
            <injectionFlag>true</injectionFlag>
            <contents>
      	   <![CDATA[ 
      		<httpInteraction>
      		  <put sensitive="true" sensitivePhrase="ACCEPT">/api/4.0/edges/edge-3/firewall/config/defaultpolicy</put>
      		  <response>204</response>
                <requestHeader b64Encode="true">Authorization.%username%:%password%</requestHeader>
                <requestBody>
                <![CDATA[
                <firewallDefaultPolicy>
                  <action>ACCEPT</action>
                  <loggingEnabled>true</loggingEnabled>
                </firewallDefaultPolicy>
             ]]]]>
             <![CDATA[>
               </requestBody>
              </httpInteraction>]]>
             </contents>
             <deviceTypeGuid>FA28849A-7DA8-439F-974A-36A9582CE4EF</deviceTypeGuid>
               <maxRelease>
                 <build>*</build>
                 <major>*</major>
                 <minor>*</minor>
               </maxRelease>
               <minRelease>
                 <build>*</build>
                 <major>*</major>
                 <minor>*</minor>
               </minRelease>
               <substitutionParamCheck>false</substitutionParamCheck>
          </templates>
      </templateGroup>
      </bbnaData>
    • Select the Injection Template check box while adding a template or ad-hoc template, and encapsulate the HTTP interactions in the contents with CDATA, as shown in the following figure:

  2. Export the device adapter that you want to modify. For more information, see Exporting device adapters.
  3. Edit the exported device adapter by inserting the <injectTemplate/> tag in the copy net to running device command, which has a GUID of 5421B3AE-2C94-0519-5D07-B4971BB15C7D.

    This tag will be replaced by the device command elements that are defined in the injection template.

    Use the following guidelines to insert this tag:
    • This tag must be a root level tag, and it cannot be embedded within another device type command element, such as a condition or loop.
    • The copy net to running device command cannot have this tag more than once.
  4. Import the modified device adapter. For more information, see Importing device adapters.
  5. Execute the Deploy to Active action in tunneled mode using the template or the ad-hoc template.

Back to top

About the BNA Device Attributes configuration

Most configurations contain settings obtained from a physical (or virtual) device and are settings that the device uses to perform its switching, routing, security, load balancing, and other functions. These are the settings that affect your network behavior. However, the BNA device attributes configuration is different. It contains BMC Network Automation's own device settings, the attributes that you can change via the Edit Devices page and a few attributes maintained automatically. These settings affect the system's own behavior, not your network behavior. This configuration trail helps track changes that users make and can be used to write rules against device edit values. For example, you may want to prohibit use of the TFTP transfer mode; or you may want to locate models that are supposed to be retired. You can find such settings in the device attributes configuration.

The following shows an example device attributes configuration:

Sample device attributes configuration

Back to top

Maintaining the configuration archive

When configuration changes are made by the BMC Network Automation system, the system automatically takes a snapshot after the change. To maintain an up-to-date configuration repository when changes are also made external to the BMC Network Automation system, use one or both of these methods:

  1. Enable the Auto Archive policy that performs a Snapshot span action when a syslog change event is received.

    For information about how to configure devices to send syslog events to the BMC Network Automation system or how to relay syslog events from an existing syslog service (for example, Kiwi, UNIX syslogd), see Configuring existing syslog servers to forward events.

    For devices that generate a high volume of syslog events (for example, Cisco ASA/PixOS), see filtering suggestions outlined in Managing external event filters and Configuring existing syslog servers to forward events.
  2. Schedule a policy to take a daily or weekly snapshot.

The advantage of using option 1 is that the syslog event identifies who made the change in the Change Details report.

BMC recommends that you monitor the BMC Network Automation system for failed snapshots. If real-time notifications are required, use the Snapshot Request Failed Notification policy to send an email when a failure is detected.

You can also determine which devices network-wide failed their last snapshot attempt by filtering the Device list, as shown in the following figure. (Only the Filter By Span Status pane of the Status tab is shown in this figure. For more information see Managing devices.)

Save the Filter as a favorite view.

In addition, the Device Inventory report that shows Snapshot actions and is filtered by Status shows all devices with a failed snapshot status. The report serves as a launch point to view snapshot transcripts during troubleshooting.

You can schedule a policy to periodically take snapshots of all devices with a Failed Last Snapshot status. You can also submit a Snapshot span action for all devices with a failed last snapshot status. In both cases, the Network Span is set to each realm (one action per realm) and filtered by the Status set to last snapshot failed.

Back to top

Managing devices on the Dashboard

Devices are shown on the Dashboard for three possible reasons:

Devices are removed from the Dashboard when these discrepancies and violations are cleared.

Running versus Startup

If you are suspicious of the difference, click the device (or group) and select Snapshot. If the discrepancy still exists after the snapshot, synchronize the Startup configuration with the Running configuration by clicking on the device (or group) and selecting Commit. Commit performs the equivalent of a write mem by copying the device's Running configuration to the Startup configuration. To update the archive and clear the discrepancy, BMC Network Automation automatically performs a snapshot after the commit.

Current Running versus Trusted or Current Startup versus Trusted or OS Image

Trusted discrepancies are cleared when the current running configuration and startup configuration in the archive are marked as trusted. Click the device (or group) and select Mark Running as Trusted or Mark Startup as Trusted. Either of the selections can clear one or both of the trusted discrepancies. The OS Image discrepancy is cleared when the Running versus Trusted Running discrepancy is cleared.

Only the Running configuration has a compliance violation

The current running configuration is non-compliant to one or more assigned rules under Network > Rule Sets. To fix the violation(s), click the device (or group) and select Deploy to Active Running. For Configuration, select Remediate With to fix a rule or all rules in a rule set or Remediate With All Assigned to fix all violations. When the remediation is complete, BMC Network Automation performs a snapshot to update the archive, re-runs the audit, and clears the violations.

Back to top

Only the Startup configuration has a compliance violation

The current startup configuration is non-compliant to one or more assigned Rules under Network > Rule Sets. To fix the violation(s), click the device (or group) and select Commit to copy the device's compliant running configuration to the startup. When the configuration is committed, BMC Network Automation performs a snapshot to update the archive, re-runs the audit, and clears the violations.

Both the Running and Startup configurations have a compliance violation

The current running and startup configuration are non-compliant to one or more assigned rules under Network > Rule Sets. To fix the violation(s), click the device (or group) and select Deploy to Active Running. For configuration, select Remediate With to fix a rule or all rules in a rule set, or Remediate With All Assigned to fix all violations. Select Commit on the Deploy to Active span action so that after the running configuration is fixed, it is copied to the startup configuration. Only use Commit if you want the running configuration to overwrite the Startup configuration. When the remediation is completed, BMC Network Automation performs a snapshot to update the archive, re-runs the audit, and clears the violations.

Back to top

Auditing configuration changes

A central place to audit configuration changes is the Change Summary report. The Change Summary report is generated for a selected Network Span, Time Period, and configuration type (Running or Startup). Use the following tips when auditing changes:

  • Select the Show Events option to see all events logged for the device before and after the change. Who made the change is indicated in the event directly below the change details.
  • To track who made the change when the change was made external to BMC Network Automation requires BMC Network Automation to receive syslog events.
  • You can schedule recurring Change Summary reports to be delivered by email using a time-based policy.
  • You can set up a Change Summary report URL to launch the report from a portal. See Requirements for launching reports and jobs from third-party applications. The user is authenticated.

Back to top

Importing a configuration

You can import configurations as target configurations or templates from your own repository and from external third-party management applications (for example, modeling tools). The configuration is imported in ASCII format. Multiple import tasks are queued to run once or on a recurring basis.

You can access and view the list of configuration import tasks on the Configuration Import Tasks page, as described in Viewing the configuration import task listing.

You can also create new configuration import task, as described in Adding a configuration import task.

Back to top

Exporting a configuration

You can export configurations for backup purposes or for use by another application (for example, modeling tools). The configuration is exported in ASCII or binary format as it was received from the device. Multiple export tasks can be queued to run once or on a recurring basis.

You can access and view the list of configuration export tasks in the Configuration Export Tasks page, as described in Viewing the configuration export task listing.

You can create a new configuration export task, as described in Adding a configuration export task.

Back to top

Related topics

Managing policies
Managing configuration compliance
Marking a configuration as trusted
Managing templates
Managing global substitution parameters
Creating favorite list views
Viewing a Device Inventory report
Creating a configuration snapshot
Viewing a Change Summary report


Was this page helpful? Yes No Submitting... Thank you

Comments