- Setting Up Prime Network and Using Prime Network with Cisco Prime Central
- Managing the Prime Network Software Image, Features, and Backups
- Managing Prime Network Components: Gateways, Units, and AVMs
- Configuring Device VNEs and Troubleshooting VNE Problems
- Managing Redundancy for Units and Processes
- Controlling Device Access and Authorization Using Device Scopes
- Managing User Accounts and Authentication
- Managing the Oracle Database and System Data
- Controlling Event Monitoring
- Managing Device Configuration Operations
- Managing System Security
- Changing VNE Polling, Reachability, Discovery, and Persistency and Working with Unmanaged Segments (Cloud VNEs)
- Configuring Devices So They Can Be Properly Modeled and Managed by Prime Network
- Changing System Defaults in the Registry
- Prime Network Log Files
- VNE Properties Reference
Cisco Prime Network Administrator Guide, 4.3.1
Bias-Free Language
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
- Updated:
- January 19, 2017
Chapter: Changing System Defaults in the Registry
Changing System Defaults in the Registry
The Prime Network registry contains the configuration settings for all Prime Network components and features. The following topics provide an introduction to the Prime Network registry and common settings you may want to change:
How the Global Registry Is Organized
The Prime Network registry is a collection of xml files (called hives) that comprise and control the Prime Network system configuration. The registry contains almost all definitions and configurations used by Prime Network. A copy of the registry is located on the gateway server and unit s under NETWORKHOME /Main/registry.
Registry files are made up of key names and entry names. This fragment is from pollinggroups.xml, which controls the settings for the polling groups displayed when you choose Global Settings > Polling Groups.
<key name=" pollinggroups "> default
<key name=" "> configuration
<key name=" "> interval
<entry name=" "> 900000 </entry>
</key>
</key>
</key>
In this example, the configuration polling interval for the polling group named default is set to 900000 milliseconds. The registry key path for the interval is:
pollinggroups/default/configuration/interval
The registry files on the gateway server and units are replicas of the Golden Source registry. The Golden Source registry is the master registry that is responsible for maintaining, distributing, and updating registry configuration files to all units and the gateway server. The Golden Source registry is centrally located on the gateway server. Whenever a unit or gateway restarts, it accesses the Golden Source registry to retrieve any updates to the configuration. If a unit cannot connect to the gateway, it uses its local copy of the registry files.
The master copy of the Golden Source files is centrally located on the gateway server at:
NETWORKHOME /Main/registry/ConfigurationFiles
When Prime Network is installed, the following subfolders are created. Each subfolder contains the relevant registry.xml files.
|
|
|
|---|---|
Template directory, which is used by the system. This directory on the gateway server is the Golden Source registry. |
|
All Golden Source subdirectories contain a file called site.xml which contains any registry settings that have been changed. When the system restarts, the site.xml settings are copied to (and override) all other Golden Source directories. For this reason, it is important to make change to site.xml so that in case of restart, your changes are not overwritten by the system defaults. Every key and entry in the Golden Source can be overridden by an entry in site.xml.
The Golden Source mechanism enables consistent management of the entire system. Each unit and gateway has its own set of registry configuration files and parameters. The registry files are replicated automatically during the installation of the unit and gateway.
Each time a unit and gateway process starts, it accesses the Golden Source and retrieves the updated configuration. All additions and changes to the Golden Source are automatically sent to the relevant units servers. Each unit keeps a local copy of its relevant registry files. When a unit cannot connect to the gateway, the unit’s local copy of the registry is used.
Changing Global Registry Settings Using the GUI (Registry Controller)
The Registry Controller, which runs on AVM 11, provides a GUI for adjusting the most frequently-changed registry settings. It is launched by choosing Tools > Registry Controller from the main menu in the Administration GUI client.
Blank Registry Controller fields indicates that no value exists in the registry.
When you click Apply, the Registry Controller validates your entries and, saves them to site.xml, overwriting any previous values. Changes are applied across the gateway or unit; you cannot use the Registry Controller to make changes to individual AVMs or VNEs.
In the unusual case that multiple users are using the Registry Controller at the same time, if a user changes a setting, Prime Network updates all Registry Controller windows to reflect the change.
Note
Do not click Apply unless you are absolutely sure of your changes. Once you apply your changes, you can no longer retrieve the previous settings by clicking Restore. Previous settings can only be retrieved if they have not been overwritten (which happens when you click Apply).
Table B-1 lists what you can change using the Registry Controller.
|
|
|
|
|---|---|---|
Whether users can only view maps they create or maps that others have created. |
||
The user access role required to log into the Events GUI client (the default is Administrator). |
Changing the Minimum User Access Role for the Events and Administration Clients |
|
Whether a link should be displayed on a map only when both link endpoints are in the user’s device scope. |
Displaying Links Based On Whether Endpoints Are In User’s Scope |
|
Settings that control the archiving of cleared and uncleared tickets based on the total number of tickets. |
Adjusting Ticket Auto-Archiving Based on Total Number of Tickets (Oracle Fault Database) |
|
Settings that control the archiving of cleared and uncleared tickets based on the size of the tickets. |
Adjusting Ticket Auto-Archiving Based on the Size of Tickets (Oracle Database) |
|
Configuring a Proxy Database Connection for Units Not Connected to Database |
||
Settings that control the timeout period when Change and Configuration Management is copying software images to devices in the network. |
||
How to encrypt external Oracle database connections and which algorithms can be used for encryption. |
||
Settings that control whether reduced (event-based) polling should be the default polling method and if so, whether Prime Network should generate a notification when a device does not support reduced polling. |
Changing the Default Reduced Polling Approach for a Single VNE or All VNEs |
|
The Telnet delimiter delay and terminal length used by the adaptive polling mechanism when a VNE is using slow polling. |
Adjusting Adaptive Polling for Devices with Large Configurations (and Telnet Responses) |
|
The criteria that determines when individual device protocols (HTTP, ICMP, SNMP, Telnet, and XML) are unreachable. |
||
The interval that prevents overpolling when repeated queries are sent to a device. |
Adjusting the Polling Protection Interval Between Repeated Device Queries (Smart Polling) |
|
A mechanism that controls the rate at which VNEs initiate Telnet/SSH connections to prevent degraded performance on TACACS servers. |
Improving TACACS Server Performance by Changing VNE Telnet/SSH Login Rates (Staggering VNEs) |
Changing Global Registry Settings Using the CLI (runRegTool)
Note Changes to the registry should only be carried out with the support of Cisco. For details, contact your Cisco account representative.
To change registry settings that cannot be changed using the Registry Controller, use the runRegTool.sh script, which is located in NETWORKHOME /Main. You should run this command as pnuser, using the following command format:
runRegTool.sh -gs hostname-IP command unit-IP key [ value ]
The runRegTool.sh script takes the following options.
Note Registry changes should be made to the site.xml file, except for changes being made to AVM XML files. Therefore, your command syntax should always include site as the first part of the key name (this is not required for get or list commands):
The following are some examples of how to use the runRegTool.sh script:
- This get command returns the current settings for all polling groups on the unit with the IP address unit-IP. It uses the site/ prefix in case any changes have already been configured:
# ./runRegTool.sh -gs hostname-IP get unit-IP site/pollinggroups
- This set command configures the LDP Neighbor Down event to not persist its alarm information. Note that site precedes the key so that change are made locally:
# ./runRegTool.sh -gs gateway-IP set unit-IP "site/event-persistency-application/events/LDP neighbor loss/sub-types/LDP neighbor down/alarm-persistency" unpersist
- This get command returns the current adaptive polling settings for a VNE with the ID CRS1-local, that runs on AVM 521. Because the change is made to a user-created VNE, the key is not preceded with site.
# ./runRegTool.sh -gs hostname-IP get unit-IP "avm521/agents/da/CRS1-local/dcs/type/com.sheer.metrocentral.coretech.common.dc.ManagedElement/adaptivePolling”
Feedback