- Preface
- Product Overview
- Administration Tasks for Internal Directory Mode
- Administration Tasks for External Directory Mode
- Directory Administration Tool
- Cisco PIX Firewall Device Support
- IMGW Device Module Development Toolkit
- Troubleshooting
- How to Use the IMGW Device Module Toolkit
- Software Licenses and Acknowlegements
Product Overview
This chapter provides a high-level overview of the Cisco CNS Configuration Engine 1.4. It is organized as follows:
•
How the Cisco CNS Configuration Engine 1.4 Works
•Dynamic ConfigID and EventID Change Synchronization
The Cisco CNS Configuration Engine 1.4 is a network management application that acts as a configuration service for automating the deployment and management of network devices and services (see Figure 1-1). The Cisco CNS Configuration Engine 1.4 runs on the Cisco CNS 2100 Series Intelligence Engine (CNS 2100 Series system) hardware platform.
Figure 1-1 Cisco CNS Configuration Engine 1.4 Architectural Overview
Each Cisco CNS Configuration Engine 1.4 manages a group of Cisco devices and services they deliver, storing their configurations and delivering them as needed. The Cisco CNS Configuration Engine 1.4 automates initial configurations and configuration updates by generating device-specific configuration changes, sends them to the device, executes the configuration change, and logs the results.
Note If you are running devices that use an earlier version of Cisco IOS, or a different operating system, such as Catalyst, you should invoke the Intelligent Modular Gateway for communicating with the device. For more information about Intelligent Modular Gateway, see "Intelligent Modular Gateway" section.
The Cisco CNS Configuration Engine 1.4 utilizes the following popular industry standards and technologies:
•eXtensible Markup Language (XML)
•Java naming directory interface (JNDI)
•Hypertext Transport Protocol (HTTP)
•Java servlets
•Lightweight Directory Access Protocol (LDAP)
The Cisco CNS Configuration Engine 1.4 supports two modes of operation (Internal Directory and External Directory) and it includes the following Cisco CNS components:
•Configuration service (web server, file manager, and namespace mapping server)
•Image Service (Cisco IOS images)
•Event service (event gateway)
•Data service directory (data models and schema)
•Intelligent Modular Gateway (IMGW)
The Cisco CNS Configuration Engine 1.4 can be used as the runtime component for deployment of customer-developed applications. These applications can be developed using the Cisco CNS SDK 1.5.4.
Cisco IOS Dependences
Table 1-1 lists Cisco IOS versions with corresponding versions of CNS Configuration Engine including feature limitations associated with each version.
Modes of Operation
There are two modes of system operation for the Cisco CNS Configuration Engine 1.4:
•Internal Directory Mode
•External Directory Mode
Internal Directory Mode
In Internal Directory mode, the Cisco CNS Configuration Engine 1.4 supports an embedded CNS Directory Service. In this mode, no external directory or other data store is required. To store device configuration information, the Cisco CNS Configuration Engine 1.4 uses the CNS data models implemented as an extended X.500 directory schema in the CNS Directory Service.
External Directory Mode
In External Directory mode, the Cisco CNS Configuration Engine 1.4 supports the use of a user-defined external directory. In this mode, the Cisco CNS Configuration Engine 1.4 supports the following directory services:
•Novell Directory Services
•Critical Path
•iPlanet
CNS Configuration Service
The CNS Configuration Service is the core component of the Cisco CNS Configuration Engine 1.4. It consists of a configuration server that works in conjunction with configuration agents located at each router. The CNS Configuration Service delivers device and service configurations to Cisco IOS devices for initial configuration and mass reconfiguration by logical groups. Routers receive their initial configuration from the CNS Configuration Service when they start up on the network the first time.
The CNS Configuration Service uses the CNS Event Service to send and receive events required to apply configuration changes and send success and failure notifications.
The configuration server consists of a web server that uses configuration templates and the device-specific configuration information stored in the embedded (Internal Directory mode) or remote (External Directory mode) directory.
Configuration templates are text files containing static configuration information in the form of command-line interface (CLI) commands. In the templates, variables are specified using lightweight directory access protocol (LDAP) URLs that reference the device-specific configuration information stored in a directory.
The configuration template includes additional features that allow simple conditional control structures and modular sub-templates in the configuration template (see the "Templates and Template Management" section).
The configuration server uses Hypertext Transport Protocol (HTTP) to communicate with the CNS Configuration Agent running on the managed Cisco IOS device. The configuration server transfers data in eXtensible Markup Language (XML) format. The configuration agent in the router uses its own XML parser to interpret the configuration data and remove the XML tags from the received configuration.
The configuration agent can also perform a syntax check on received configuration files. The configuration agent can also publish events through the event gateway to indicate the success or failure of the syntax check.
The configuration agent can either apply configurations immediately or delay the application until receipt of a synchronization event from the configuration server.
CNS Event Service
The Cisco CNS Configuration Engine 1.4 uses the CNS Event Service for receipt and generation of events. The CNS Event Agent resides on Cisco IOS devices and facilitates communication between routers and the event gateway on the Cisco CNS Configuration Engine 1.4.
The CNS Event Service is a highly-scalable publish and subscribe communication method. The CNS Event Service uses subject-based addressing to help messages reach their destination. Subject-based addressing conventions define a simple, uniform namespace for messages and their destinations.
New Event Subject Names
The base element of the CNS event subject namespace has been changed from cisco.cns.* to cisco.mgmt.cns.* in support of Cisco IOS 12.3.
The CNS event subject namespace has been modified in accordance with the new Cisco subject naming conventions. In order to keep up with the new subject naming convention, CNS agents in Cisco IOS have been modified and released with the 12.3 Cisco IOS train. The change affects the subject names that the CNS agents subscribe to and publish on.
This section lists the new event subject names that are associated with Cisco IOS 12.3.
CNS Event Agent
cisco.mgmt.cns.event.boot
cisco.mgmt.cns.event.id-changed
CNS Image Agent
cisco.mgmt.cns.image.* - Events related to the image distribution agent
cisco.mgmt.cns.image.checkServer
cisco.mgmt.cns.image.inventoryRequest
cisco.mgmt.cns.image.upgradeRequest
cisco.mgmt.cns.image.status
CNS Exec Agent
cisco.mgmt.cns.exec.* - Events related to exec command-like functions.
cisco.mgmt.cns.exec.cmd
cisco.mgmt.cns.exec.rsp
cisco.mgmt.cns.exec.reload
CNS Config Agent
cisco.mgmt.cns.config.complete
cisco.mgmt.cns.config.failure
cisco.mgmt.cns.config.warning
cisco.mgmt.cns.config.sync-status
cisco.mgmt.cns.config.reboot - deprecated. Use cisco.mgmt.cns.exec.reload instead. cisco.mgmt.cns.config.load
cisco.mgmt.cns.config.id-changed
cisco.mgmt.cns.config-changed
cisco.mgmt.cns.config-changed.lost
CNS Inventory Agent
cisco.mgmt.cns.inventory.get
cisco.mgmt.cns.inventory.device-details
cisco.mgmt.cns.inventory.oir
CNS Syslog Agent
cisco.mgmt.cns.log.emerg
cisco.mgmt.cns.log.alert
cisco.mgmt.cns.log.crit
cisco.mgmt.cns.log.err
cisco.mgmt.cns.log.warning
cisco.mgmt.cns.log.notice
cisco.mgmt.cns.log.info
cisco.mgmt.cns.log.debug
CNS MIB Access Agent
cisco.mgmt.cns.mibaccess.request
cisco.mgmt.cns.mibaccess.response
cisco.mgmt.cns.mibaccess.notification
cisco.mgmt.cns.snmp.rqst
cisco.mgmt.cns.snmp.resp
cisco.mgmt.cns.snmp.trap
CNS Event Gateway
cisco.mgmt.cns.device.connect
cisco.mgmt.cns.device.disconnect
For IMGW Device Module Development Toolkit
This section lists the new event subject names that are associated the IMGW Device Module Development Toolkit.
cisco.mgmt.cns.imgw.devicemodule.request.register
cisco.mgmt.cns.imgw.devicemodule.request.deregister
cisco.mgmt.cns.imgw.devicemodule.response.register
cisco.mgmt.cns.imgw.devicemodule.response.deregister
Legacy Subject Names
The following is a list of all the subject names in use in Cisco IOS releases prior to 12.3, and CNS Configuration Engine release 1.3.2. Starting with release 12.3 of Cisco IOS and release 1.3.2 of the CNS Configuration Engine, the prefix for all of the subjects listed below will be modified from cisco.cns to cisco.mgmt.cns.
Here is the list of subjects names in use prior to IOS 12.3:
cisco.cns.config.complete
cisco.cns.config.failure
cisco.cns.config.warning
cisco.cns.config.sync-status
cisco.cns.config.reboot
cisco.cns.config.load
cisco.cns.config.id-changed
cisco.cns.exec.cmd
cisco.cns.exec.rsp
cisco.cns.inventory.get
cisco.cns.inventory.device-details
cisco.cns.inventory.oir
cisco.cns.config-changed
cisco.cns.config-changed.lost
cisco.cns.event.boot
cisco.cns.event.id-changed
SYSLOG
cisco.cns.log.emerg
cisco.cns.log.alert
cisco.cns.log.crit
cisco.cns.log.err
cisco.cns.log.warning
cisco.cns.log.notice
cisco.cns.log.info
cisco.cns.log.debug
SAA
cisco.cns.slm
cisco.cns.customtrap
MIB Access
cisco.cns.mibaccess.request
cisco.cns.mibaccess.response
cisco.cns.mibaccess.notification
cisco.cns.snmp.rqst
cisco.cns.snmp.resp
cisco.cns.snmp.trap
CNS Event Gateway
cisco.cns.device.connect
cisco.cns.device.disconnect
NameSpace Mapper
The CNS Namespace Mapping Service (NSM) allows you to address multiple network devices by a single posting of a publish or subscribe event, and it allows your network administrator to map Cisco-standardized event names to names of his or her choosing.
For example, in a network of 100 routers, there may be 10 which the administrator wants to configure as a VPN (Virtual Private Network). In order to load a configuration into each of these devices, your client application could either publish 10 cisco.mgmt.cns.config.load events, or the administrator could associate the 10 devices with a common group name and your client application can post the event once. The administrator could rename the cisco.mgmt.cns.mgmt.config.load subject to application.load and group all the devices in the West Coast under a group called "westcoast." Then the application would just have to publish on application.load.westcoast and the devices in the "westcoast" group would get the event.
NSM Modes
The NameSpace Mappers can operate in one of two NSM modes:
•Default
•Provider
The NSM mode is set when you run the Setup program (refer to the Cisco CNS Configuration Engine 1.4 Installation & Setup Guide For Linux).
Default Mode
No directory setup is required for Default mode. In this mode, subject mappings are specified in a configuration file. The subject map can be tailored to suit the namespace that the application is using.
To set Default mode, use default for the value of the NSM Directive parameter in the Setup program (refer to the Cisco CNS Configuration Engine 1.4 Installation & Setup Guide For Linux).
Provider Mode
Directory setup is required for Provider mode. NSM looks up the directory for subject mappings for a device. This mode allows you to address a group of devices in one event.
To set Provider mode, use http for the value of the NSM Directive parameter in the Setup program.
More information about NSM can be found in the CNS SDK 1.5.4 API Reference and Programmer Guide.
Directory setup can be done using the Directory Administration Tool (see "Directory Administration Tool" section.
Event Gateway
The CNS Event Gateway acts as a relay between the CNS Integration Bus and CNS agent-enabled devices, which enables event-based communication.
The CNS Event Gateway uses NSM to map subjects. The mode of operation is determined by the value set for the NSM Directive parameter during Setup (refer to the Cisco CNS Configuration Engine 1.4 Installation & Setup Guide For Linux).
Note This mode must match the mode that your application is using for NSM.
If you choose the Provider mode (http), the Event Gateway must be given a parameter that indicates which application namespace must be used for subject mapping. The Cisco CNS Configuration Engine 1.4 prompts for this parameters value during Setup with the message:
Enter NSM directive (default, http):
The default value for this parameter is default. However, during Setup, you can override this value with one of your own.
Each Event Gateway process can support up to a maximum of 500 devices. To support more than 500 devices, you can run multiple gateway processes. During Setup, you can set the number of concurrent gateway processes to start with either one or both of the following prompts, depending on how you want to setup your SSL (see "Encryption" section) communications:
Enter number of Event Gateways that will be started with crypto operation:
Enter number of Event Gateways that will be started with plaintext operation:
Dynamic Template and Object
The original servlet, com.cisco.cns.config.Config, gets the configuration template from the attribute value of the Device Object in the configuration server data store (LDAP server), parses the template, and does string substitution on parameters inside the template. It is tightly coupled with the template that is assigned to the device and the attributes of device object.
The new servlet, DynaConfig, loosens the restriction so that the template can be assigned dynamically and the parameter values can be obtained from other objects in data store.
This servlet gets PathInfo information by means of HttpServletRequest.getPathInfo(), parse it, and gets the related template name and object reference. The structure of PathInfo is:
/<argument name>=<argument value>.
Data Structures
The feature of dynamic template and object utilizes PathInfo, which is passed from the client side to the servlets. The structure of PathInfo, which the servlet can understand is in following format:
[/<argument name>=<value>]*
The argument and format for dynamic template and object is:
[/cfgtpl=value[/object=value]]
For more information about Dynamic Template and Object, refer to the Cisco CNS SDK 1.5.4 API Reference and Programmer Guide.
CNS Image Service
The CNS Image Service is an automated, scalable, and secure mechanism designed to distribute Cisco IOS images and related software updates to Cisco IOS devices that have Cisco Intelligence Agents (CIAs).
For more information about how to use the CNS Image Service, see "CNS Image Service" section.
For those devices that do not have a CIA, non-Cisco IOS devices, and non-Cisco devices, you can use the IMGW Toolkit to create scripts that support SSH sessions between these devices and the CNS Configuration Engine 1.4.
For more information about the IMGW Device Module Toolkit, see "IMGW Device Module Development Toolkit."
PIX Firewall Support
Cisco CNS Configuration Engine 1.4 provides configuration management and image service to Cisco PIX firewall devices (PIX device).
For more information about PIX firewall support, see "Cisco PIX Firewall Device Support."
Intelligent Modular Gateway
Intelligent Modular Gateway (IMGW) allows you to run the Cisco CNS Configuration Engine 1.4 for automatically distributing configuration files to Cisco IOS network devices running Cisco IOS versions earlier than 12.2(2)T; as well as to Catalyst switches, CCS 11k devices, Cache Engines, and PIX firewalls.
Note If you are running devices that use Cisco IOS version 12.2(2)T or later, you should use the CNS Event Gateway.
The Intelligent Modular Gateway accomplishes this task by adding the ability to use alternate access methods to connect to devices that do not have CNS agents in their software. Currently, the access method is SSH.
The interface to the Intelligent Modular Gateway is the same as that of the CNS Event Gateway. It responds to the same events. The NameSpace Mapper operates in the same way. Therefore, once some initial setup work is done, applications need not know the difference between communicating with agent-enabled devices by way of the Event Gateway and non-agent devices by way of the Intelligent Modular Gateway.
Restrictions
Using the Intelligent Modular Gateway with an SSH transport creates some restrictions in terms of how the Cisco CNS Configuration Engine 1.4 architecture is used.
•When using SSH as a transport, no syntax checking can be done on the configurations before they are applied.
Syntax checking in the Cisco CNS Configuration Engine 1.4 architecture is accomplished by an intelligent agent in the device that has access to internal parser functions. An SSH interface does not provide any means to access this functionality. Therefore, any syntax checking attributes are ignored. Errors are only detected when the configuration is actually applied and applications must deal with the fact that configuration lines prior to the error were executed.
•Because all logic is external to the device, there is no way to watch for configuration changes that are done outside the scope of the network management software.
For example, if a network administrator uses a standard SSH client to directly access a network element and changes the configuration, that element would not be synchronized with the network management infrastructure, and depending on the change, might become unmanageable. This is especially true if the login mechanisms (usernames and passwords) are changed. Login mechanism changes should be handled during a maintenance window, during which event-based configuration is not occurring, so that race conditions do not occur. Any such changes must be reflected on the provisioning system's device information screen so that the Device Information Database is properly updated before any new partial configurations are sent.
•The scope of error checking upon configuration load is limited to syntax checking.
Semantic errors cannot be detected. The output is returned in a buffer that applications should log. In a case where something is not operating properly, a network administrator can manually look at the log of what the device was reporting and determine if a semantic error occurred.
•The initial configuration mechanism as defined in the Cisco CNS Configuration Engine 1.4 architecture is not supported.
This mechanism allows a router to be preconfigured with the cns config initial command, causing it to contact the configuration server to retrieve its initial configuration. However, because the legacy devices do not have the agent code in them, they can never contact the configuration server (they do not understand the configuration command). Therefore, this mechanism does not make sense when using SSH as a transport. If an initial configuration needs to be delivered by the Cisco CNS Configuration Engine 1.4, it has to be done through the partial configuration mechanism.
•Aside from the device information database, the gateway is stateless.
There is no read back of configurations to make sure they were applied, nor is there automatic rollback of configurations if a failure occurs.
•If a device is not directly connected to the management network, it must be attached through a Cisco communication servers.
The API allows you to set up an arbitrary network topology to reach the device. However, this release only supports two possible topologies: direct connection to one of the device network interfaces, or console access by way of a Cisco access server, such as a 2511.
•Device failures are only detected within a user-specified polling interval.
This is because while the standard Event Gateway requires that routers maintain a connection to the Event Gateway (so any breakage of that connection would signal a problem), the SSH interface is implemented through a transient connection. Therefore, the gateway must poll all devices at some user-specified interval to make sure they are responding, so failure detection is not immediate.
•When both agent-enabled and legacy devices are present on the same network, it is recommended that both gateways be run at the same time.
The standard (CNS) Event Gateway talks to the agent-enabled devices and the Intelligent Modular Gateway talks to the legacy devices.
Note Do not put an entry in the Device Information Database for a router that is already agent-enabled because both gateways will try to control the router and unpredictable results may occur.
IMGW Device Module Toolkit
IMGW Device Module Toolkit allows you to develop your own device modules, plug them into Cisco CNS Configuration Engine 1.4, then use them to configure devices.
For more information about the IMGW Device Module Toolkit, see "IMGW Device Module Development Toolkit" and "How to Use the IMGW Device Module Development Toolkit."
Modular Router Support
Cisco CNS Configuration Engine 1.4 supports modular routers. A modular router chassis includes slots in which you can install line and network interface cards. For example, the Cisco 3660 (see Figure 1-2) has six network module slots. You can install any module into any available slot in the chassis. Some modules like 2 Ethernet 2 WAN card slot module can in turn have sub slots to install network interface cards or line cards (see Figure 1-3). Device management supports subdevices representing these line and network cards.
Figure 1-2 Cisco 3660 Modular Router
Figure 1-3 Interface or Line Card Slots
Additional attributes representing line card type and subdevices have been added to the existing device object structure in the directory server in order to have the same structure to represent the main device or the subdevice.
For a modular router, a subdevice configuration object and configuration template is defined for every network module whose interfaces need to be configured and for which the interface number can be variable; based on the slot. Then, a device configuration object and a template is defined for the main device. Fixed interface numbers can be configured in the main device template.
Modular router events are published to the event bus and are accessible to applications connected to the bus. The Cisco IOS device publishes the system hardware configuration in the cisco.mgmt.cns.config.device-details event after hardware discovery. The Cisco CNS Configuration Engine 1.4 is configured to listen for this event, retrieve it and extract the hardware configuration of the device.
In Internal Directory mode, modular router support sessions work with NSM in both modes (see "NSM Modes" section).
Data Administration Tool
The Data Administration Tool (DAT) presents you with a web-based user interface that allows you to populate and manage the data in the directories. You can View/Add/Delete/Update devices (CNS agent-enabled devices, see "Intelligent Modular Gateway" section), groups of devices, and applications in the directory. Also, you can View/Add/Delete/Update events specific to each application.
DAT also provides you with the additional capability of bulk data upload.
Note You cannot change (extend) the schema using DAT. You have to populate the schema manually in the directory server.
For information about how to use DAT, see "Directory Administration Tool" section.
Encryption
Secure Socket Layer (SSL) method has been adopted as the encryption mechanism for HTTP sessions between the configuration agent and the configuration server, and the TCP session between the CNS Event Gateway and the event agent.
To use encryption, the Cisco IOS devices must be running a crypto image and version 12.2(11)T of the Cisco IOS.
Device Authentication
The configuration server and CNS Event Gateway are supplied with a X.509 certificate generated by a certificate authority (CA) server. It is the responsibility of the network administrator to have a CA server and to control certificate generation and revocation.
The Cisco IOS device must—to be configured—be recognize by the CA. There is no client-side certificate in the Cisco IOS device.
For the configuration server, once the Cisco IOS device has validated the certificate, it sends cns_id:cns_password over the encrypted pipe. The device uses a CNS password to be authenticated by the Cisco CNS Configuration Engine 1.4.
Note Authentication is also done when the links are in clear text.
A server configured for secure connections is also able to enact non-secure (clear-text) sessions. The password check is done regardless of whether encryption is used or not.
Once the server is secured, it is no longer be able to process requests that do not have a password. It cannot tell the difference between a clear-text request from a device in a secure environment from a device in an non-secure environment.
For the CNS Event Gateway, once the Cisco IOS device has validated the certificate, it sends a DeviceID control message over the encrypted pipe that has the CNS password of the device. The event_id:cns_password is validated using the authentication API. If it is not matched, the SSL session is terminated and an entry made to the security log. This ensures only authorized customer premises equipment (CPE) devices connect to the CNS Event Gateway and are able to use the CNS Integration Bus.
Bootstrap Password
Cisco CNS Configuration Engine 1.4 provides a bootstrap password for use where multiple devices are deployed in a batch. In this case, all devices in a particular batch are given the same (bootstrap) password to use when they each start up on the network for the first time.
The bootstrap password can be changed for different batches of devices by using the BootStrap function under Security Manager in the user interface (see "Security Manager" section).
Resynchronize cns_password
If the cns_password of a device becomes corrupted so that there is a mismatch between the device and the corresponding password information help in the CNS Configuration Engine 1.4 directory, you can resynchronize the device with the CNS Configuration Engine 1.4 by using the Resync Device function in the user interface (see "How to Resynchronize a Device" section)
How the Cisco CNS Configuration Engine 1.4 Works
The Cisco CNS Configuration Engine 1.4 dynamically generates Cisco IOS configuration files (documents), packages these file in XML format, and distributes them by means of Web/HTTP (see Figure 1-4). This takes place in response to a pull (get) operation.
Figure 1-4 Configuration Engine Functional Diagram
A Cisco IOS device initiates a get operation when it first appears on the network (cns config init...) or when notified (by subscribed event) of a configuration update (cns config partial...).
Note For more information about these and other related CLI commands, refer to the Cisco IOS configuration guide and command reference publications.
When a Cisco IOS device issues a request for a device configuration file, the request includes a unique identifier (configID = hostname) used to help locate the relevant configuration file parameters for this device on the directory server. Figure 1-5 shows the process flow for a configuration load operation.
Figure 1-5 Configuration Load Process Flow
When the web server receives a request for a configuration file, it invokes the Java Servlet and executes the embedded code. This directs the web server to access the directory server and file system to read the configuration reference for this device and template. The configuration server prepares an instantiated configuration file by substituting all the parameter values specified in the template with valid values for this device. The configuration server forwards the configuration file to the web server for transmission to the Cisco IOS device.
The configuration agent at the router accepts the configuration file from the web server, performs XML parsing, syntax checking (optional), and loads the configuration file. The router reports the status of the configuration load as an event that can be subscribed to by a network monitoring or workflow application.
Load Initial Configuration
1. The Cisco CNS Configuration Engine 1.4 reads the template files.
2. The Cisco CNS Configuration Engine 1.4 does the parameter substitution.
3. The Cisco CNS Configuration Engine 1.4 sends the device configuration to the Cisco IOS device.
4. The Cisco IOS device tries to load the initial configuration.
5. The Cisco IOS device publishes the load configuration status event to the event gateway.
Modular Router
1. The modular router posts an HTTP request containing the hardware configuration to the Cisco CNS Configuration Engine 1.4 for the initial configuration.
2. The Cisco CNS Configuration Engine 1.4 reads the hardware configuration of the device from the HTTP request and updates the directory server with the latest configuration.
3. The Cisco CNS Configuration Engine 1.4 reads the template files.
4. The Cisco CNS Configuration Engine 1.4 does the parameter substitution.
5. The Cisco CNS Configuration Engine 1.4 sends the device configuration to the Cisco IOS device.
6. The modular router tries to load the initial configuration.
7. The modular router publishes the load configuration status event to the event gateway.
Load Partial Configuration
1. The user modifies a template in the Cisco CNS Configuration Engine 1.4 user interface.
2. The template contents are passed to the Cisco CNS Configuration Engine 1.4.
3. The Cisco CNS Configuration Engine 1.4 stores the template in the file system.
4. The user clicks the update device button in the user interface.
5. The Cisco CNS Configuration Engine 1.4 publishes a cisco.mgmt.cns.config.load event.
6. The Cisco IOS device retrieves the cisco.mgmt.cns.config.load event and in response to this event requests its configuration by contacting the server.
7. The Cisco CNS Configuration Engine 1.4 reads the template files.
8. The Cisco CNS Configuration Engine 1.4 does the parameter substitution.
9. The Cisco CNS Configuration Engine 1.4 sends the device configuration to the Cisco IOS device.
10. The Cisco IOS device tries to load the partial configuration.
11. The Cisco IOS device publishes the load configuration status event to the event gateway.
Modular Router
1. The user modifies a template in the Cisco CNS Configuration Engine 1.4 user interface.
2. The template contents are passed to the Cisco CNS Configuration Engine 1.4.
3. The Cisco CNS Configuration Engine 1.4 stores the template in the file system.
4. The user clicks the update device button in the user interface.
5. The Cisco CNS Configuration Engine 1.4 publishes a cisco.mgmt.cns.config.load event.
6. The modular router retrieves the cisco.mgmt.cns.config.load event and in response to this event requests its configuration by contacting the server.
7. The Cisco IOS device posts a HTTP request containing the hardware configuration to the Cisco CNS Configuration Engine 1.4 for the partial configuration.
8. The Cisco CNS Configuration Engine 1.4 reads the template files.
9. The Cisco CNS Configuration Engine 1.4 does the parameter substitution.
10. The Cisco CNS Configuration Engine 1.4 sends the device configuration to the modular router.
11. The modular router tries to load the partial configuration.
12. The modular router publishes the load configuration status event to the event gateway.
How EventID, and ConfigID are Used
The Cisco CNS Configuration Engine 1.4 intersects two name space domains:
•Configuration Domain
•Event Domain
The CNS Configuration Engine 1.4 uses the Configuration Domain when a device communicates with the configuration server. It uses the Event Domain when a device communicates with the Cisco CNS Configuration Engine 1.4 using the publish and subscribe mechanism of the CNS Integration Bus.
The device must be uniquely identified in these namespaces. The ConfigID uniquely identifies the device in the Configuration Domain. The EventID uniquely identifies the device in the Event Domain.
Because the Cisco CNS Configuration Engine 1.4 uses both the CNS Integration Bus (event bus) and the configuration server to provide configurations to devices, both EventID and ConfigID must be defined for each configured Cisco IOS device.
The values for EventID and ConfigID for each device can be identical, or you can make them different when you add or edit device information using the user interface (see "Managing Devices" section).
Dynamic ConfigID and EventID Change Synchronization
The Cisco IOS, version 12.2.(11)T, was enhanced with new CLI ID commands that can modify the EventID and ConfigID, then reconnect the device to the Cisco CNS Configuration Engine 1.4 with the new IDs.
Network Management Tools
The CNS 2100 Series platform includes the Tivoli Management Agent (TMA). The Tivoli Product(s) is copyrighted and licensed (not sold) and therefore not transferred.
The owner of the Tivoli Product DISCLAIMS ALL WARRANTIES WITH RESPECT TO THE USE OF THE TIVOLI PRODUCT(S) INCLUDING (WITHOUT LIMITATION) ANY WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
To initialize the Tivoli Management Agent, refer to the Cisco CNS Configuration Engine 1.4 Installation & Setup Guide For Linux.
Feedback