Configuring after upgrade

This topic describes the tasks that you need to perform after the BMC Network Automation upgrade is complete.

Clearing the browser cache

Since there have been changes to the software, you must clear the browser cache to ensure that stale downloaded code does not interfere with the presentation of web pages. Refer to the browser's documentation for instructions on clearing the cache. If you neglect to do so, web pages might appear mangled or might behave incorrectly.

Updating ciphers in the TLS protocol

If you have modified the bna.connector.ciphers property before upgrade, follow these steps to update the list of ciphers in the TLS protocol to make the application server more secure:

1. Stop the enatomcat service.
2. Open the BCAN_HOME/tomcat/conf/catalina.properties file with a text editor.
3. Find the bna.connector.ciphers property in the file.
4. Copy the latest value of this property from the Comments section of the property.
5. Replace the existing value with the copied value.
6. Start the enatomcat service.

Upgrading Cisco Wireless LAN Controller

BMC Network Automation version 8.9.x uses the run-config command command to back up the configuration of Cisco Wireless LAN Controller devices (earlier named as Cisco 4400/2100 Wireless LAN Controller). Versions earlier than 8.6 use the running-config command.

If you use this device type, after you upgrade to version 8.9.x from versions earlier than 8.6, you must make a snapshot and mark the snapshot as trusted.

You also must check any related compliance rules and configuration profiled (CAP) dynamic fields to make sure the syntax matches that found in the new running configuration.

Updating the traceroute details for the Find Endpoint span action (Windows)

If you have modified the tracerouteLastLine property in the global.properties file before upgrade, follow these steps to update its value so that the Find endpoint job can locate the managing switch properly (see the related corrected issue, DRCAN-22699):

1. Open the BCAN_DATA/global.properties file with a text editor.

2. Search for the word trace.
   The following code snippet is an excerpt of the global.properties file:

   # Following are the values for Windows
   #tracerouteCmd=tracert -d
   #tracerouteRegex=^\\d+[\\s*|\\S*]*?(\\S*)$
   tracerouteLastLine=4

3. Comment tracerouteLastLine by adding '#' and set its value to 3.

4. Save the file.
5. Restart the BMC Network Automation web service.

Reusing guest devices

In BMC Network Automation versions 8.5.00 and later, the <guestDeviceNamePrefix> and <guestDeviceNameBase> tags are clubbed into a single tag, <guestDeviceName> in the container blueprint. <guestDeviceName> refers to the name of an existing guest device in the system when the <useExistingGuestDeviceFlag> flag is set to true. When you upgrade to version 8.9.x from versions earlier than 8.5.00, and if you did not specify a value for <guestDeviceNamePrefix> in the earlier version, BMC Network Automation uses a default prefix value of "${container.name}-".

To reuse guest devices, perform the following tasks as applicable:

• Initialize <useExistingGuestDeviceFlag> to true for F5 VLBs, and also set the value of <guestDeviceName> to refer to the name of the host node's device in the relevant container instances and container blueprints.
• Initialize <useExistingGuestDeviceFlag> to true for guest nodes where you declare a guest device in the underlying pod host node. For example, for the Fortigate containers which share VDOMs, or VMDC 2.3 copper containers, set the <guestDeviceNameBase> tags to refer symbolically to the name of the guest device in the pod in the relevant container instances and where possible in the container blueprints as well.
  You can make these changes in the blueprints if there are container instances already  provisioned which refer back to them.
• Initialize <useExistingGuestDeviceFlag> to false for other blueprints, which might cause subsequent uses of the blueprint to provision a container to fail, if it was expecting to reuse a guest device from the pod. In such a case, the administrator must manually change this flag in the blueprint.
  

Regenerating and importing an SSL certificate

When you upgrade to version 8.9.x, the .keystore file located in the BCAN_DATA directory is regenerated and the key size is upgraded to 4096-bits if any one of the following conditions is satisfied:

• The existing .keystore file was generated with a key size less than 2048-bits
• The existing .keystore file was generated with the SHA1WithRSA encryption algorithm

If the .keystore file is regenerated, your existing certificate will not work and you need to generate and import the certificate as described in Generating and importing an SSL certificate for the application server.

Generating initial device attributes configurations

When you upgrade to version 8.9.x, BMC recommends that you perform a Refresh Device Status action to refresh only the Device Attributes Configuration on all your devices. This generates an initial version of the configurations containing your current device settings. Thereafter, the system generates a new configuration as the device settings change. The initial configurations ensure that if you begin to develop and use compliance rules against this trail, the data actually exists to make the rules useful.

Back to top

Preserving the device adapter customizations

If you made any modifications to configuration trails, custom actions, device types, or external script actions located on the Admin > Network Admin > Device Adapters page, or if there are changes between your existing adapters and upgraded adapters, the adapters show up as Modified in the BMC Network Automation GUI.

During an upgrade, the latest versions of all the supported device adapters are loaded into your BMC Network Automation system. These might include enhancements and corrections to adapters that you might have previously customized. Your customized version will be active after an upgrade, which will be missing those enhancements and corrections. You must manually merge the two sets of changes.

BMC recommends that you perform the following steps before you start using the system with scheduled job actions:

1. Navigate to Admin > Network Admin > Device Adapters.
2. In the State column, filter the adapters in the Modified state.
3. Expand the hierarchy and find any adapters that contain a Requires Merge  flag in the State column, as shown in the following figure:
   
   
4. If an adapter has the Requires Merge flag, perform the following actions:
   1. Export the Baseline version of the adapter.
   2. Export the Previous Baseline version of the adapter.
   3. Export the Modified version of the adapter.
   4. Merge your customized changes into the new baseline by performing the following substeps:
      
      1. Compare your Modified version with the Previous Baseline version to see your changes.
      2. Re-do those changes to the new Baseline version. Now you have the latest Baseline version with your customizations.
   5. Import the updated adapter.

Back to top

Enabling the Alternate Addresses dynamic field

The find endpoint algorithm uses the traceroute command to find the IP address of the managing router for the endpoint. If the router has multiple IP addresses defined within it, and the IP address output of the traceroute command does not match the IP address stored in the BMC Network Automation server database for the device, the algorithm fails.

To avoid this problem, BMC Network Automation has a Configuration Profiled dynamic field, Alternate Addresses. This field captures additional IP addresses from the configuration of Cisco IOS-based routers.

The alternate addresses are checked during endpoint actions, in addition to the primary address of the device, when searching the database for the router.

The Alternate Addresses dynamic field is created automatically during the installation of the BMC Network Automation application server. However, the field is not created when performing an upgrade on the application server. After the application server upgrade is complete, you need to add this field if it does not exist, and manually enable it.

To add and enable the Alternate Addresses dynamic field

1. In the BMC Network Automation GUI, open the Add Dynamic Field dialog box: Admin > System Admin > Dynamic Fields > Add.
2. On the Details tab, enter or select the following values:
   
   
   Fields:
   • Component: Select Device.
   • Assignment Mechanism: Select Configuration Profiled.
   • Value Type: Select Capture Attribute Values.
   • Name: Enter Alternate Addresses.
   • Enable: (Optional) Select this option to enable the feature.
3. On the Spans tab, select Entire Network.
4. On the Queries tab, enter or select the following values:
   
   
   Fields:
   • Device Type: Select Cisco, and then select Cisco IOS Switch/Router.
   • Minimum OS Version: Use the default *. *. *
   • Maximum OS Version: Use the default *. *. *
   • Applicable Trails: Select Running.
   • Subject: Select Pattern.
   • Pattern: Enter the following string:
     ^\s+ip\s+address\s+(\d+\.\d+\.\d+\.\d+)\s+\d+\.\d+\.\d+\.\d+$ s
   • Domain: Select Selected Blocks.
   • Begin: Select Pattern, and then enter the following string:
     ^interface\s+.*[a-zA-Z].+[0-9].*
   • End: Select Pattern, and then enter the following string:
     ^!$
5. Click Enter, and then click Save.

Deleting duplicate auto-groups

In version 8.7.00, the Cisco Nexus Switch device adapter has been renamed to Cisco Nexus. After you upgrade to version 8.9.02 or earlier from version 8.7.00 or earlier, duplicate auto groups are created, one with the old device type name and other with the new name. You need to delete the groups with the old names manually.

To find and delete these dupliate auto groups:

1. Go to Network > Groups.
2. Click Filter.
3. Select the Show Empty Auto Groups option.
4. In Name, enter *Cisco Nexus Switch*.
5. Click Submit.
6. Locate and delete the empty auto groups containing Cisco Nexus Switch in their names, as follows:
   • If you do not get any error while deleting an auto group, delete it.
   • If you get an error that this group is being referenced, switch to the components that refer to this group, and modify the components to use new groups. Then, delete the auto-group.
7. Run the Refresh Device Status action for the compliance violation status and configuration attribute profiles on the correctly-named auto groups.