|
|
This chapter introduces the concept of synchronization and describes the synchronization functionality that Cisco 7000 Manager (C7kM) provides.
Synchronization provides a mechanism to update configuration details stored in C7kM from the current configuration on a device. This is necessary if a device is updated, for example, if a new line card is added (or removed) then C7kM should be able to re-read from the device and update the C7kM objects, creating new objects if necessary.
Synchronization is split between physical synchronization which is for synchronizing C7kM with the physical configuration of the device, and logical synchronization where configurations on the device are represented by C7kM objects that do not relate directly to the physical hardware. Synchronization is explained in more detail in the following sections:
Physical synchronization is the automatic creation of objects to represent physical components of a device, such as modules and interfaces. C7kM automatically synchronizes when the hardware is changed, it can also be forced to synchronize.
C7kM provides the ability to automatically discover 7000 chassis and the linecards that are present and create objects to represent them within the C7kM model based on the class/type of the 7000 chassis and the linecards that are detected.
Once the 7k chassis have been introduced into C7kM the next step is to discover the internal topology (modules and interfaces) of the device.
C7kM provides the ability to automatically synchronize the object model with the internal topology of the 7k chassis, deploying modules and interfaces to represent those present.
In C7kM this process is known as commissioning the chassis as it is the process which brings the chassis into a managed state. The actual process of discovering and updating the topology is referred to as discovery. The object states which bear these names represent the fact that the topology synchronization is currently underway for those objects.
The prescribed method of invoking a chassis discovery is to use the virtual:CiscoPlatformCommands.commissionCmdAttribute command attribute . This will result in exactly the same operation as if a user had pressed the "Commission" button on the chassis configuration window.
To invoke the action through the command attribute, use the northbound interface to perform a set on the attribute: virtual:CiscoPlatformCommands.commissionCmdAttribute against the chassis which requires to be synchronized. No value needs to be supplied for this data abstractor set.
The set will return after the request for a discovery has been dispatched. In this case the set does not wait for completion of discovery before calling back the client.
It is only possible to perform the operation as described above against a chassis which is in the decommissioned state as this process is associated with bringing the chassis from an unmanaged to a managed state.
Although C7kM has mechanisms for detecting when a chassis rediscovery is required, it is possible for a northbound client to force a rediscovery. There are two mechanisms for doing this depending upon the actual usage scenario.
The first option is to stimulate the chassis into a decommissioned state and then re-commission it. This will mean that the inventory discovery process will be redone and the chassis inventory will be realigned with that of the device.
To Decommission a chassis (that is, remove it from active management) the command attribute: virtual:CiscoPlatformCommands.decommissionCmdAttribute, should be used. Again no value needs to be associated with the set but the success or otherwise can be determined as outlined above.
The re-commission of the chassis would be performed as outlined above.
The second and prescribed method of invoking a rediscovery is to issue a "change" stimulus to the chassis's state manager. This will cause the chassis to rediscover without the need to traverse the decommissioned state. The chassis can be issued with the stimulus by performing a set on the attribute: virtual:CiscoCommon-MIB.stateChange, against the chassis. The set should have an AttrOctetStringValue as its value which contains the string "change". This action will cause the chassis to go through the discovery process again and cause the chassis to recommission.
 |
Note After the discovery/commissioning cycle has finished the attribute: ciscoPlatformCon:CiscoPlatformCon-MIB.lastCommissionFailure can be queried to assess whether the result of the commission was a success or otherwise. The value will be an AttrOctetStringValue containing a textual note of any problems encountered. |
There are three attributes which affect the discovery process in terms of deployment of modules. These attributes govern the validity of deploying a module into a specific slot, subslot etc. These attributes are:
The discovery process retrieves the inventory information from the chassis and processes it to determine what physical elements are present within the chassis. This primarily yields a set of line cards and their interfaces. In the case of an initial discovery, this information will be translated into a set of C7kM objects which will be deployed to model those physical elements. In the case of a re-discovery the difference between the current C7kM model and the physical inventory is calculated and objects are deployed/deleted/updated to realign with the hardware.
As well as deploying the objects, the C7kM discovery process will set up indexing information against the objects to tie them to the physical objects the represent. The modules which are deployed will be of class CiscoERModule or ConcreteCiscoModule and the interfaces will be of class mentioned in the Interface Configuration.
It is possible to perform the discovery process at the individual module level. This will discover any interfaces which are deployed under the module. The process behaves in the same manner as at the chassis level with the command attribute being: virtual:CiscoModuleCommands.commissionCmdAttribute.
The constraints specified in the chassis description also apply at the module level. This brings the module into a managed state.
During the discovery process the chassis state flow will progress as follows:
1. Decommissioned: Chassis is in an unmanaged state.
2. Discovery-C7kM retrieves inventory information from the hardware and deploys modules and interfaces within C7kM to model the configuration.
3. Commissioning-C7kM determines the most appropriate state for the chassis (to enter) to represent the state of the physical hardware.
4. Initial managed state-The commissioning task will move the chassis to the most appropriate state.
After the discovery/commissioning cycle has finished the attribute: ciscoPlatformCon:CiscoPlatformCon-MIB.lastCommissionFailure can be queried to assess whether the result of the commission was a success or otherwise. The value will be an AttrOctetStringValue containing a textual note of any problems encountered.
Logical synchronization is the act of updating the C7kM model to reflect the logical configuration of a device. This may mean different things with regards to different areas of the system. C7kM can become out of synchronization with the hardware in a number of ways. For example:
The logical synchronization that C7kM supports are:
Discrepancies can also arise when data is provisioned onto a device using C7kM, but no WriteMem operation takes place on the device before a reboot. In this kind of situation, the newly modelled data is present within the C7kM, but not in the device.
To illustrate the problem, take the management of ATM connections in the Cisco 7000 Manager (C7kM) EM. C7kM caches the device ATM connection configuration information and represents each ATM connection in the containment tree. If an operator adds or deletes an ATM connection using IOS, C7kM would have no record of these changes and has no method of detecting that a change has occurred.
The synchronization framework is the mechanism by which such changes are detected and modelled within the C7kM, it provides a centralized and coordinated means of managing the synchronization of the data held in C7kM with the equivalent data on the device.
Changes (as discussed in the Synchronizing with Individual Network Elements) that might result in a need to synchronize from various sources. Each source leads to a different set of attributes to be polled to check whether or not a synchronization is due.
The synchronization process is initiated by performing a set on the command attribute: ciscoPlatformCon:SyncFrameworkAttrs.syncRequest against the chassis which requires a sync. The format of the value which should be set is an attr vector value containing three columns which specify the type of synchronization which is required. The columns of the vector are comprised of the following attributes:
Sync requests on the low priority queue will only be serviced if there are no requests on the high priority queue. This means that high priority requests will always be serviced first.
The logical flow of a chassis synchronization proceeds as follows:
1. Sync request for a particular chassis is raised and placed in the queue.
2. When a synchronization window becomes available (the request reaches the head of the queue).
3. Any heuristics required are performed and the chassis is moved to the "synchronizing" state.
4. All of the registered synchronization modules are notified one by one that the synchronization is required (according to the above rules).
5. When all synchronization modules have completed their syncs, the chassis is re-commissioned so that it may derive the most appropriate state and return to being actively managed.
Posted: Thu Oct 2 12:28:26 PDT 2003
All contents are Copyright © 1992--2003 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.