About device configuration management

The following topics provide information about managing device configurations by using TrueSight 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 TrueSight 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.

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

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 TSNA 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 TSNA device attributes configuration (formerly called BNA Device Attributes) is different. It contains TrueSight 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:

Name: bcan-cisco1760-02
Realm: Default
Vendor: Cisco
Device Type: Cisco IOS Switch/Router
Device Category: Router
Model: 1760
OS Image: IOS 12.3(4)T2, C1700-ADVSECURITYK9-M
Online: Yes
Created Date: 01/27/15 10:49:15
User Assigned Dynamic Fields {
    Description: Part of NAR network
    Rack Location: G86
    Reason for Outage:
    Serial Number: FOC08060PH8
}
System Assigned Dynamic Fields {
    Alternate Addresses:
}
Primary Interface {
    Host Name/IP Address/URL: 12.13.14.15
    Device Agent: Local
    Access Mode: SSH2
    File Transfer Mode: FTP
    Device Security Profile: Default
}
Static Groups {
    AAA_Cisco IOS Switch/Router
}

Back to top

Maintaining the configuration archive

When configuration changes are made by the TrueSight 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 TrueSight 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 TrueSight 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 TrueSight 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:

• The running configuration is different from the startup configuration.
• The current configuration (Running or Startup) is different from the assigned trusted.
• The current configuration ( Running or Startup or both) are non-compliant based on assigned and enabled rule sets.

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, TrueSight 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, TrueSight 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, TrueSight 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, TrueSight 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 TrueSight Network Automation requires TrueSight 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 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