Table Of Contents
Release Notes for
Cisco Element Management Framework v3.2Improved Scale and Performance
Availability Improvements: Cisco EMF Backup
Cisco EMF v3.0.4 and v3.1 EMS Compatibility
Important Functionality Changes
System Requirements and Solaris Release Choice
Known Limitations in the Release
Cisco EMF CORBA Gateway Runtime component
How to remove the Orbix demon from Cisco EMF process control
Cisco EMF EMS Interoperability
Open Caveats (Application Framework)
Open Caveats (Between Release and 1st October 2001)
Resolved Between Cisco EMF v3.1 and This Release
Obtaining Technical Assistance
Contacting TAC by Using the Cisco TAC Website
Release Notes for
Cisco Element Management Framework v3.2
Contents
This document is divided into the following sections:
•
"Enhancements in This Release" section
–
–
–
–
•
–
•
–
•
•
•
Introduction
Cisco Element Management Framework (Cisco EMF) is the homogeneous element management layer of the Cisco Internet Operation Support System (OSS) building on and adding to the Cisco EMF v3.0 and v3.1 product functionality. It comprises a highly scalable framework designed to support carrier-class Element Managers (EMSs) across Cisco's service-provider product lines with network event management. A range of EMSs are available on Cisco EMF v3.0, with additional EMSs available on Cisco EMF v3.1.
Cisco EMF provides common interfaces and element management services to applications in the network and service management levels of Cisco Internet OSS.
Cisco EMF v3.2 is an update release to Cisco EMF v3.1. As well as the major feature enhancements detailed below, a large number of bug fixes and minor customer enhancements are included in this release. Please consult Cisco DDTS for full details of bugs resolved in the Cisco EMF v3.2 release.
For customers migrating to Cisco EMF v3.2 from Cisco EMF v3.0, it is advisable first to be familiar with the Cisco EMF v3.1 feature set - Cisco EMF v3.1 included significant enhancements in fault management capability as well as northbound integration interfaces. In particular, the Cisco EMF Event Manager application - available as an option on Cisco EMF 2.1.4 but not with Cisco EMF v3.0 - is now a standard part of Cisco EMF v3.1 (and above).
For more detailed information on Cisco EMF v3.2, please see the documentation available from CCO at:
http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/cemf/3_2/index.htm
Or as defined in Related Documentation
For information on the differences between Cisco EMF v3.0 and v3.1, please consult:
http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/cemf/3_1/index.htm
Enhancements in This Release
Solaris 8 Support
Cisco EMF v3.2 now supports operation on Sun Microsystem's Solaris 8 as well as 2.6 operating system.
Specifically Cisco EMF supports EMSs which have been built on Solaris 2.6, and tested on Solaris 2.6 and 8.
Note
Note
Improved Scale and Performance
Cisco EMF v3.2 includes a large number of improvements which increase Cisco EMF EMS scale and performance, including:
•
•
•
•
•
•
Availability Improvements: Cisco EMF Backup
Cisco EMF Backup, as on Cisco EMF v3.0.4-patch 9 and Cisco EMF v3.1, paused object creation operations while the backup occurred. Improvements have been made so that now in Cisco EMF v3.2 only a slight pause in object creation related occurs at the start of the backup (a `quiesce' period), to enable a consistent snapshot of all Cisco EMF and EMS databases to be taken. As part of this quiesce period, all in progress Cisco EMF object creation operations are allowed to complete, and new operations suspended until the quiesce period is over. At this time, normal Cisco EMF operation is resumed and Cisco EMF backup proceeds in tandem with normal Cisco EMF operation. This contrasts markedly with previous releases where normal operation was resumed only when the full backup was complete. This improvement is particularly significant for large databases when backup times are long.
Cisco EMF backup has been improved for Cisco EMF v3.2 EMSs, with many improvements including the following feature additions:
•
•
•
Cisco EMF v3.0.4 and v3.1 EMS Compatibility
Cisco EMF v3.0 EMSs will not run on Cisco EMF v3.2 and are not supported. Cisco EMF v3.1 EMSs will be supported running on Cisco EMF v3.2 when Cisco EMF v3.2-patch1 (or above) is available.
Usability Enhancements
A number of administration and application usability enhancements are included with Cisco EMF v3.2, including:
•
•
•
•
•
•
•
Important Functionality Changes
A number of behavior changes have been made to Cisco EMF v3.2, details as follows:
•
Note
•
System Requirements
Cisco EMF can be deployed in a number of different configurations, from a single hardware system to a multi-site management system, using Sun Solaris/SPARC hardware with Solaris, Release 2.6 or Solaris 8.
Note
Element Managers installed on Cisco EMF (versions 2.1.4, 3.0.4 and 3.1) have been tested and released for Sun's Solaris 2.6 operating system.
Note
A Sun Solaris 2.6 media pack is available for purchase from Cisco.com to enable you to run Cisco Element Management Framework element managers (Cisco EMF EMSs) in the event that you do not have access to Solaris 2.6.
Note
Sun Microsystems have given Cisco permission to ship this to you, and your Sun license permits you to install this Solaris software on Sun workstations. Note that it can be installed on both Sun desktop and server products - specifically those that support Solaris 2.6.
System Requirements and Solaris Release Choice
Cisco EMF EMSs certified to run on Solaris 8 can be deployed on the following Sun hardware models which run Solaris 8 (and above) only.
•
•
Note
Known Limitations in the Release
Cisco EMF CORBA Gateway Runtime component
Iona Orbix issue : If Cisco EMF is installed on a Sun workstation which is not running Domain Naming Service (DNS), the Cisco EMF-CORBA Gateway Runtime Server fails to start.
Workaround—either
re-install Cisco EMF, and when asked for a domain press Return, this enters an empty string. Do not re-install Orbix
or
install Cisco EMF only on workstations which run DNS.
How to remove the Orbix demon from Cisco EMF process control
Some clients may wish the CORBA Orbix demon to run constantly even after Cisco EMF has shutdown. To do this the client must execute the following commands:
> cd <CEMF_ROOT>
> mkdir backupProcessFile
> cd config/processes/
> mv S08orbixd_3.0.x /<CEMF_ROOT>/backupProcessFile/.
> cd <CEMF_ROOT>/bin
> sysmgrClient -k orbixd
> <CEMF_ROOT>/Orbix/bin/orbixd -s &
where <CEMF_ROOT> is substituted for the current installation directory.
Installation
The Cisco Element Management Framework Installation and Administration Guide Version v3.2, provides information to install, license, and configure the product and includes detailed administration tasks.
Locating Cisco EMF Patches
You must login to Cisco.com to access patches. All Cisco patches can be accessed from : http://www.cisco.com/kobayashi/sw-center/sw-netmgmt.shtml
From this location you can select the appropriate patch page depending on the version of Cisco EMF you need to patch or if you need patches for EMS Development.
Note
Solaris Patches
For information, note that Cisco EMF 3.2 was tested with the following Solaris patches, Solaris Patches and Solaris 8 Patches, which were current when Cisco EMF 3.2 was released. None of these patches is known to be mandatory, though we would recommend having this or higher revisions of any recommended Solaris patch.
The current Sun recommended patch cluster can be downloaded from http://sunsolve.Sun.COM. Please note that higher revisions of the patches may introduce dependencies on other patches which are not reflected in the following lists. You should follow the patch dependencies as recommended by Sun Microsystems, Inc.
Solaris 2.6 Patches
Solaris 8 Patches
Important Notes
Default Backup Directory
If the default installation settings were used to install v3.0, the default backup directory has changed between versions as follows:
/opt/AVBackup
/opt/Backup
Desktop Color Setup
Cisco EMF uses the color setup of your display. If your system is set up to display text in white, this may give problems in some Cisco EMF applications, for example on an event group icon in the Event Groups application. To avoid this, select the default color configuration.
Cisco EMF EMS Interoperability
Please consult your EMS documentation for certified EMS interoperability information, if you wish to run two or more EMSs on the one Cisco EMF installation.
Caveats
Note
—upto and including Cisco EMF v3.0.4 patch 14
—upto and including Cisco EMF v3.1 patch 4Cisco EMF v3.2 is constantly improving, and caveats will be resolved and workarounds provided after the release date. For the most up-to-date information refer to the Release Note and Customer Note enclosures provided in DDTS on Cisco Connection Online.
This section includes the following information:
•
•
•
•
Open Caveats (Application Framework)
•
object group access not updated for client
Symptom / Conditions—It is possible to use the Access Manager to allow certain application features to be restricted for a user. In particular, an Access Specification can be created to restrict features to objects in a particular object group.
If however, the contents of such a group changes while a particular Cisco EMF session is running, the change will not appear popup menus in, for example, the Map Viewer.
This means that, where an object is removed from a group, features will still appear to be available. Where an object is added to a group, the features may appear to be unavailable.
Workaround—This does not affect the actual security of the features when they are launched: at this point, object group membership is checked and access to features will be as intended.
The workaround to correct the popup menus is to close the session and open a new one.
•
[CSCdr15596] Default values must be re-selected to activate in menus
Symptom—Default values in various EM menus must be re-selected in order to activate them.
Conditions—This problem is seen when using some EM menus.
Workaround—No workaround is currently available.
•
(CSCat20433) AV allows TNet Radios to be re-parented to subnets
Symptom—Cisco EMF allows an object to be re-parented under another object that shouldn't be a valid parent.
Conditions—This problem is seen when, for example, an object has been deployed under a site and that same object is subsequently allowed to be placed under a Proxy or a subnet.
Workaround—There is currently no workaround for this problem.
•
Reparent/remove services fail for a containment-independant map
Symptom—Reparent and remove services fail for a containment-independent map.
Conditions—This problem occurs when a service is invoked from the right-hand side of the Map Viewer, and an object is passed to the service as the parent of another object.
Workaround—No workaround is currently available for this problem.
•
Event Browser: printing fails silently when lp is not installed
Symptom—When using the Event Browser to print the list of events displayed it can be the case that nothing prints, and no message is apparent to explain that the print operation has failed.
The sysmgr.log file (located in <CEMF ROOT>/logs [typically /opt/cemf/logs]) should show the message -
"sh: lp: execute permission denied"which indicates the nature of the problem.
Condition—This condition occurs if you are running the Event Browser on a machine which does not have the lp command installed or if your user account on Unix does not have access to the lp command. The Event Browser attempts to use this command to print with, but gives no message back to the user if it is not found or cannot be accessed.
Workaround—Contact your system administrator to request that the lp command if made available with the correct permissions on your Unix machine.
•
ATM core dump occurs on creation of profile.
Symptom—When an object is created the dialog on which the object is created exits unexpectedly.
Conditions—This problem occurs when an object is created with a name that is more than a hundred characters long.
Workaround—Do not create an object with a name that is more than a hundred characters long.
•
Sub-dialogs launch with incorrect list population
Symptom—Child dialog launches with previous object list's objects.
Conditions—This happens when the user changes the selection on a parent dialog's object list prior to launching the child dialog.
Workaround—Do not change the selection on the parent dialog prior to launching the child dialog.
•
1st time launch of EvBrw from LaunchPad with CDM too long
Symptom—The first time the user launches the Event Browser from the Launch Pad, it may take at least 30 seconds for the query editor to display.
Condition—The length to time it takes the query editor to display depends upon the internal complexity of the element manager you are using, and can vary between element managers.
This only affects the first time launch, subsequent launching of the Event Browser, will result in it being displayed in the region of 5 seconds.
Workaround—There is no workaround.
•
Multi-line text field attribute cannot be saved.
Symptom—After modifying an attribute represented by a multi-line text field within an element manager dialog you may find that the save button on the dialog remains greyed out and you have no way of saving your changes. Changing the contents of another attribute on the dialog to then activate the save functionality and then saving will not save the changes made on the multi-line text field.
Condition—This problem occurs when an a multi-line text field attribute is on a dialog outwith a notebook page.
Workaround—There is no workaround for EM end users.
•
Busy pointer (cursor) disappears before action complete.
Symptom—While an Element Manager dialog is performing a large operation such as auto discovering 30 devices with 1500 managed objects under each, the dialog may move from a busy state (i.e. the cursor is a small clock) to a busy off state (i.e. the cursor becomes a small arrow) before the operation has completed.
Condition—This occurs when the Dialog is performing an operation that takes a long period of time and occurs because EM dialogs have a built in timeout period for operations. This timeout busies off the dialog if it has been waiting a configurable time period (default is 20 seconds).
Workaround—There is no workaround for the CEMF end user.
•
Closing rename dialog before rename complete causes map exit
Symptom—Map Viewer exits unexpectedly when the Rename Object dialog which can be opened by accessing the Tools->View Manipulation->Rename Object ... menu is closed before the rename operation has completed.
Condition—Select the Rename Object menu option from the View Manipulation Menu. Perform an operation that loads the CEMF manager server (e.g. Commissioning a number of objects). Change the name of the object in the Rename Object Dialog then quickly press Apply and then Close. The Map Viewer will exit unexpectedly.
Workaround—When the Apply button has been pressed, wait until the Map Viewer updates with the renamed object before selecting close.
•
Session exits unexpectedly on a client while installing an EM.
Symptom—The user observes a warning dialog appearing which states communications with the server have been lost. Shortly after the appearance of this dialog the session closes.
Condition—If the user has an open session while an EM is being installed (removed) the session will be forcefully closed.
Workaround—The solution to this problem lies with the Systems Administration team. A procedure needs to be put in place which ensures CEMF sessions are closed prior to the installation or removal of an EM.
•
Shouldn't be able to deploy snmpManageable objects without ipaddr
Symptom—SNMP Manageable objects which are deployed using the objectFileParser do not appear in the Network view.
Conditions—If IP addressable objects (which includes SNMP Manageable) are deployed using the objectFileParser but their IP address attribute is not setup within the object specifications file then the deployed objects will not appear in the Network view.
Workaround—Delete the incorrectly deployed objects, correct their objectSpecifications file, and re-deploy the objects using the objectFileParser.
•
Alarm propagation is wrong in mapViewer after reparenting objects
Symptom—In the map viewer application, the alarm propagation circle is grey when it should be green or it is green when it should be grey.
Condition—This problem will occur when objects are reparented either from a propagating view to a non-propagating view or from a non-propagating view to a propagating view.
Workaround—The problem can be resolved by reopening the map viewer application.
•
User can type in EM dialog text boxes when dialog is busied on
Symptom—The user can enter text into an EM dialog whilst the cursor indicates the dialog is busy (i.e. the cursor appears as a small clock).
Condition—This occurs when the user performs an operation that leads to the dialog becoming busy. For example, when choosing save, a dialog box will be displayed asking you to confirm. At this point, even though the original dialog correctly appears as busy, you are able to modify fields within it.
Workaround—There is no workaround to this problem. The user should refrain from interacting with the dialog while it is displayed as busy.
•
Map Viewer not updating with newly deployed objects
Symptom—On deploying objects the user observes
a.
b.
Condition—This situation occurs if the machine being used as the CEMF manager server runs so low on disk space that the map database cannot update itself by adding nodes for newly deployed objects.
Workaround
a.
b.
c.
•
Modal dialogs end up behind parent window
Symptom—Sometimes a dialog will appear to have frozen with the busy cursor displayed, as if the dialog is waiting to do something.
Condition—This occurs when a dialog has opened a further dialog and become busy itself until the new dialog is dealt with. It is possible that this new dialog can be hidden behind the original parent dialog giving the impression that the original dialog is frozen, whereas it is actually waiting for you to do something with the (hidden) new dialog.
For Example, launch the EventBrowser from the Launchpad. EventBrowser opens with QueryEditor on top. Click on the title bar of the EventBrowser window. The QueryEditor goes behind the EventBrowser and the EventBrowser remains busied on.
Workaround—There is no workaround. However, if you minimize or move the busy dialog you should find the hidden dialog.
•
Application screens do not show the server they are connected to.
Symptom—Looking at an application screen you cannot tell which CEMF manager server the application is connected to.
Condition—If the user opens the same application from multiple sessions which in turn are connected to multiple CEMF manager servers, the user cannot tell to which CEMF manager server an application is connected. It is only the launch pad which shows the CEMF manager server the session belongs to and the name of the session user.
Workaround—There is a Window menu on every screen. The user will be able to use this to navigate to the Launch Pad for this session to check the CEMF manager server they are logged into.
•
Startup errors in partitioningTool & sessionMgrServer log files.
Symptom—The partitioningTool log file contains :-
general : ERROR EventChannelManager : multiple creations attemptedThe sessionMgrServer log file contains :-
Session : ERROR sysmgrEventHandler.cc:82 SysmgrEventHandler::openFeedResultFailed to open event feed for sysmgr channelCondition—Both of these error messages are logged during startup of CEMF manager server.
Workaround—There is no workaround. These messages can safely be ignored.
•
Rename object in MapViewer displays error even though successful
Symptom—When renaming an object within the Physical view in the MapViewer you may receive an error messages stating that the rename operation has failed, yet the object will still have been successfully renamed.
Condition—As an example, consider the following deployment:
Physical:/Bay-1/SomeName1
Physical:/Bay-2/SomeName2
Should you attempt to rename the SomeName1 object to SomeName2 within the
Physical view you will be returned an error explaining that a non-unique name was specified. However, underneath the Physical:/Bay-1/ the object will have been successfully renamed to SomeName2.
Workaround—There is no workaround for this problem. The object has been successfully renamed and the error message should be ignored.
•
Sub-dialogs do not multi-select when launched from parent
Symptom—Sub-dialog does not select all objects selected prior to launching.
Conditions—This happens when objects are multi-selected on a parent dialog and another dialog is launched from the same parent dialog.
Workaround—No workaround is currently available for this problem.
•
Its possible to deploy SNMP agent without defining community strs
Symptom—User can deploy an SNMP manageable object leaving the SNMP community strings as undefined.
Condition—User initiates deployment of a generic object by selecting Deployment -> Deploy Generic Objects ... from an objects service menu. This brings up the list of generic templates. User then selects from SNMP Agent or SNMP-2 Agent SNMP Proxied Device
A subsequent deployment wizard screen prompts user for SNMP community string. User can change this value to undefined (ie. delete the default string leaving field blank). User is not forced to enter a value for the community strings. User is then able to deploy the SNMP object.
Workaround—Following deployment of SNMP agent user can change the community string value using Object Configuration dialog. This can be accessed by right clicking on the object and selecting Tools -> Open Object Configuration. On Object Configuration dialog, select either "Community Strings (SNMPv1)" or "Community Strings (SNMPv2)" from "Object Types" menu. These selections bring up the community tabs which allow the community string to be entered.
Note
Further problem description
If the user attempts to access SNMP object using Object Configuration, the Object Configuration dialog will display "Error" for all its attributes. This indicates the fetching of the attributes from the device has failed.
•
Popup menu not available for ObjectGroup on Client machine
Symptom—Sometimes when right-clicking on the objectGroups item within Object Group Manager the resultant menu is empty, and only displays the menu title. "Create Object Group" and "Create Folder" are expected to appear, but they do not.
Condition—This can happen on an installation where there are several Element Managers installed, and relates to timing. It can occur on both CEMF client and manager server installations, but may be more likely on a client.
Workaround—The following steps should be followed to work around this problem -
a.
b.
c.
d.
•
Event Groups Application view object count incorrect post delete
Symptom—When the user deletes an event group the event group hierarchy object count does not update. The object count will remain as it was before the deletion.
Condition—This occurs whenever the user deletes an event group.
Workaround—Closing and then relaunching the Event Groups Application. This causes Event Groups Application to correctly refresh its event group view.
•
Deploy Wiz. handling of 64bit Integers incorrect
Symptom—When a user attempts to deploy an object an error message similar to following is displayed by the deployment wizard :-
Parse ERRORDetails :-Parsing file :- /opt/cemf/config/templates/myEM.myClassError description :- DEFAULT expression is incompatible with the parameter type which as been specified.Near line:- 29Last text parsed :- END_PARAMETERCondition—If a deployment template prompts for a 64 bit integer using following :-
PARAMETER myController.myModule.my64Integer
PROMPT "Please enter my64Integer: "
DEFAULT 500
TYPE INTEGER_64
END_PARAMETER
template will fail parsing. When the user selects the template which contains this prompt the deployment wizard will fail to parse the template with an error message similar to above displayed in its results screen. This parse failure will be seen when a 64 bit integer is defaulted in a parameter prompt specification (as above).
Workaround—Remove the DEFAULT line. Above would be changed to :-
PARAMETER myController.myModule.my64Integer
PROMPT "Please enter my64Integer: "
TYPE INTEGER_64
END_PARAMETER
•
Dynamic Update Toggle in Obj Conf doesnt work
Symptom—When the object Configuration dialog is displayed for an object which is in a polling state it should be possible to choose whether the displayed attributes are automatically updated by using the dynamic update on/off menu item. This menu option does not work correctly and displayed attributes will always be updated automatically.
Condition—This problem occurs when the object configuration dialog is open on an object which is being polled.
Workaround—No workaround currently identified.
•
EM screen exit if screen closed before object list population end
Symptom—Some EM dialogs that use Object Lists which are populated when the Dialog is launched may exit unexpectedly when that particular dialog is closed.
Condition—This occurs when a user launches a dialog and then immediately closes it by double clicking on the top left of the Window, before the Dialog has been fully populated.
Workaround—There is no workaround.
Open Caveats (Applications)
•
AUtoDiscovery does not always log expected error messages
Symptom— The expected error messages are not logged by the auto-discovery application.
Condition— This problem happens when using the Discovery Scheduler and the user enters negative or invalid numbers in the discoverySchedules file.
Workaround— There is currently no workaround for this problem.
•
Wrongly configured Solaris hostname on client hangs session startup
Symptom— If the Solaris hostname of a Cisco EMF client is wrongly configured, then the CEMF session can hang, i.e. the splash screen and login will open but freeze after the username and password have been entered.
Condition— This is due to the clients machine name being mismatched with its name in DNS.
On the client machine, hostame will return 'nameA' but on the Manager, doing an nslookup for 'nameA' fails. In DNS, the client machine is called 'nameB'.
Workaround— This problem can be resolved by changing the files:/etc/hostname.hme0, /etc/hosts and /opt/cemf/config/env/avCore.sh to use 'nameB'.
•
SNMP comm strings always entrd in V2 fields of SNMP Mgmt screen
Symptom— SNMP Community Strings always appear in the SNMP V2 fields of the SNMP Management, no matter which version of SNMP the user has selected.
Condition— This problem is seen when the user enters an SNMP Community string in the Deployment Wizard.
Workaround— No workaround is currently available for this problem.
•
After use cdm to delete FCAP,remove&insert back,cdm does not disc
Symptom— The icon representing an object is not displayed.
Condition—This problem occurs after an object has been removed and re-inserted into its container and the object is discovered automatically.
Workaround— Manually deploy the object instead of waiting for the device to automatically deploy when traps are received due to the insertion of an object.
•
Autodiscover 1000s of devices makes system unusable
Symptom— If the user attempts to discover a network with many thousands of possible devices then the CEMF system will be unusable.
Condition— The Auto Discovery application within CEMF allows the user to set up a range as large as he requires. If the range is sufficiently large, then the performance of CEMF will degrade.
Workaround— The user should only attempt a discovery of a manageable size of network.
•
If LaunchPad exits unexpectedly, the session will not be closed
Symptom— In the unusual circumstance that the Launch Pad were to close unexpectedly then the other applications will remain open.
Condition— The open applications will continue to function however, since the Launch Pad is the main way to navigate in CEMF, then applications that can only be launched from the Launch Pad and are not already open will not be able to be launched.
Also, the licence that the current session is using will still be in use.
Workaround— The workaround to free up the licence in this unusual occasion would be to run the following command :
CEMFROOT/bin/sysmgrClient -r 20000
This will stop the relevant processes, including any running applications and will therefore free up the licence that is currently in use.
It should then be followed by running the command :
CEMFROOT/bin/sysmgrClient -r 100000
This will return CEMF to the appropriate run level and normal operation can be continued.
•
EvntBrwsr: deleted objects results in incorrect display of alarms
Symptom— When viewing Events in the Event Browser Application, there is a rare condition, that makes it possible for the Event Browser to display incorrect full object names for some Events, or display Events which do not match a query on "Object Scope".
Condition— This is due to the fact that the Event Browser does not update with respect to descendant objects when their parent objects are deleted. In addition the Event Browser does not update when objects are renamed or reparented. This can cause the following problems:
A. In the case of an object being renamed, the new name will not take effect in any of the open Event Browsers displaying this object or descendants of this object.
B. In the case when the Event Browser Application is opened with an "Object Scope" query, (e.g. launched from an object in the Map Viewer), and that object has descendant objects with Events raised against them. The Event Browser displays all of the Events currently on the object and it's descendants.
In such a scenario the above problem can manifest itself in the following ways:
(i) If any object which matches the Event Browsers "Object Scope" query is deleted then its own Events are deleted but it's descendent object's Events are not. If this occurs then the Event Browser will continue to display the Events on the child objects even though they no longer match the Event Browser's "Object Scope" query.
(ii) If any object which matches the Event Browser's "Object Scope" query is reparented or its parent relationship removed (using the Map Viewer Application) then that object's Events and any of it's descendent object's Events will remain in the Event Browser. This is true, even if the Events no longer satisfy the Event Browser's "Object Scope" query.
(iii) If the "Add Object(s) to" or "Reparent Object(s)" services in the Map Viewer cause any object with Events to match an already open Event Browser's "Object Scope" query, the Event Browser will not update to the new Events which now match its current query.
Workaround— If any of these problems occur, the user can close the current Event Browser and open a new one with the same Query. This will force the query to be re-run and ensure that we get all of the current correct Object Names and Events which match the query.
•
Connection lost to CEMF when autodiscovering
Symptom— Discovering network devices causes the process to exit unexpectedly.
Condition— This problem occurs when certain subnet masks are used to discover network devices.
Workaround— There is currently no workaround for this problem.
•
eventBrowser cores when opening it...
Symptom— The Event Browser application exits unexpectedly upon startup.
Condition— This problem occurs when the user attempts to launch more than one Event Browser dialog from the same CEMF session in quick succession. The second Event Browser must be launched before the first one has finished initialising.
Workaround—
1. Avoid starting Event Browser dialogs in quick succession (short delay is sufficient)
2. If the problem occurs then restart the Event Browser.
•
Should not be able to remove parent relationship of generic object
Symptom—If a CEMF object is created, such as a chassis and it's parent relationship is removed, then the object subsequently cannot be seen in any view, and thus is effectively invisible to the user.
Similarly, if a CEMF object is deleted and it has descendents then, if those descendents are not located in any other view, then they will also be invisible to the user.
Condition— Consider the following containments, assuming the objects are only in the views specified:
ComponentManaged:/Site-1/Shelf-1/Chassis-1
Physical:/Region-1/Site-1/Shelf-1/Chassis-1
If the user selects Region-1 in the Map Viewer, then right-clicking on the "Deployment->Delete Objects ..." menu option , they will be informed they are deleting 1 object and asked to confirm this. In doing this, the user will no longer see the following objects in the Physical view : Site-1, Shelf-1 and Chassis-1 but they will still see them in the ComponentManaged view. However, if the Site-1 is then selected and deleted then the Shelf-1 and Chassis-1 objects will never be able to be viewed.
Workaround— No workaround currently identified.
•
technolgy views not being removed when physical views removed
Symptom— When the user selects an object and requests to delete it, then CEMF will only delete that object.
Condition— If the user selects to delete an object that has children in that view, then the child objects may still be present in other views, or may not be seen in any other view but will still exist within CEMF.
Workaround— The only workaround is to select all the objects that you want to delete and then request to delete them.
•
Objectgui core dump on object deployment
Symptom— The Map Viewer exits unexpectedly.
Condition— This may happen when deploying objects.
Workaround— There is currently no workaround.
•
Race conditions in ObjectGui. DA vs Events. Grey smartie.
Symptom— The mapViewer displays a grey propagated status and no plus sign to indicate that a tree (object) view has children.
Condition— This problem happens when the system is very busy and the children of a tree view are being changed rapidly, whilst the tree view is being expanded at the same time. For example, when the system is very busy and objects are being deployed under a particular tree view whilst that view is being expanded.
Workaround— Close and re-open the viewer.
•
SOAKtest: EventQueryEditor launch from launchpad takes 15secs+
Symptom— Launch time of Event Browser increases when CEMF servers are busy with a complex operation.
Condition— Install CEMF and set up a large system. Create traps in the system by generating a sustained trap rate. Leave the system to run for at least a day, then perform a complex operation that will cause the system to become very busy. The first time launch of the Query Editor from an Event Browser, can take over 15 seconds.
Workaround— No workaround currently identified.
•
alarm count at bottom of screen is misleading
Symptom— In the Event Browser Application, in "Automatic Update Mode", on rare occasions the Event Group - Event Count (displayed in the Event Browser's status footer) may become out of sync with the actual Event Group count. For example, this can be observed when Event Group count seems to imply:
(i) that we are viewing more Events than exist in the Group (i.e. say "321 of 311").
(ii) that we are viewing less Events than exist in the Group (i.e. say "301 of 311").
Condition— This can occur when the browser is viewing a large number of Events (say around 50,000), and an operation has been performed which adds or removes a large number of Events (say around 5,000).
Workaround— If this situation occurs then pressing the "Refresh" button on the Event Browser Toolbar will refresh the Browser, ensuring that it's Event Count is correct.
•
cannot view active, unacknowledged alarms
Symptom—The CEMF Event Browser does not allow users to view events that are both active and unacknowledged.
Condition— The CEMF Event Browser allows users to view active and cleared events and also ones that have been acknowledged and unacknowledged. An event can be
–
–
–
–
The Event Browser cannot be refined to only show either of these four. If the query is refined to be active and unacknowledged then it will show all active events or all unacknowledged events which means it would show all events that were:
–
–
–
Workaround— No workaround currently identified.
The Event Browser will clearly show which events are active and unacknowledged but the user cannot refine the query to only show such events.
•
Chassis map doesn't function correctly after Module name-change
Symptom— In the Map Viewer Application, changing the name of a Module on some types of Chassis may lead to that Chassis' Modules being moved in the Map View and possibly obscured behind other modules.
Condition— This only occurs for Chassis in which their depiction in the Map Viewer is as a large picture icon containing its modules within this icon. And is only noticeable when the new name used contains around 20 characters or more.
Workaround— This will not be a problem for these types of Chassis if the user limits the size of any module names, that are renamed.
•
Assigned NP don't run when TRs breech on COM based attributes?
Symptom— If the user has an Element Manager screen open and right clicks with the mouse on an attribute value, and uses the popup to set up or edit a thresholding regime, then it may not actually check the threshold condition that has been set up.
Condition— There are certain circumstances, with particular CEMF EMSs, that the assigned notification profile will not fire when thresholds are breached. This case is EMS specific - please consult your EMS release note for details.
Workaround— No workaround currently identified.
Open Caveats (Infrastructure)
•
First time CEMF start takes too long with CDM installed.
Symptom—After installing Cisco EMF and Element Manager (EM) packages, doing a "cemf start" will take a considerable amount of time if no databases already exist for this system.
This problem is also present if a "cemf stop" followed by a "cemf reset" and "cemf start" is performed.
Condition—This will only happen on first time startup, or if a "cemf reset" is performed.
Workaround—The first time that Cisco EMF system is started and after all EM packages have been installed, ensure that a backup is performed - i.e. type the command:
"cemf backup -l <InitDBBackupDirectory>"
This will save a copy of all the initialized databases to the "InitDBBackupDirectory" specified. Ensure that any subsequent backups are not saved to this location.
Should a "cemf reset" be required, simply perform a restore as follows:
"cemf restore -l <InitDBBackupDirectory>"
after the "cemf reset".
Now, perform a "cemf start" and CEMF will start up substantially quicker.
This procedure can also be followed when re-installing the same version of CEMF and the EM packages.
•
Cant backup after breaking out of objectFileParser
Symptom—Object deployment fails to work after using the objectFileParser utility to create objects from a text file.
Condition—The user has used the utility 'objectFileParser' to create objects from a text file, and has exited the parser during the creation by killing the process or typing CTRL-C.
Workaround—Stop and restart the Cisco EMF server.
•
restore gives incorrect warnings about EMs not being installed
Symptom—A cemf restore will report that the current system does not have the same EM packages installed as were installed on the backup system. The restore operation completes successfully.
Condition—Element Manager (EM) packages may support two modes of installation:-
- installation with CEMF already running
- installation before CEMF is started
The problem only occurs when an EM package is able to be installed on theCEMF system while the server is not running (check your EM installation documentation to see if this is the case).
If your EM supports this mode of installation, then a backup which is made from this system will report an error if it is restored onto another CEMF system where the EM package was installed with CEMF running.
During the restore operation, a warning will be seen from the command cemf restore , as in the following example:-
> /opt/cemf/bin/cemf restore -t 08-14-2001 -l /myRestoreDir/mybackup
Validating system ...
The installed EMs do not match the installed EMs from the backup system.
<EM name+version> is not installed on the current system.
EMs installed on current system
------------------------------
<list of EM packages>
EMs installed on backup system
------------------------------<list of EM packages>
Verifying the backup file checksums...Workaround—Ignore the warning and chose to continue with the restore. Alternatively, make sure that the system being restored to has been installed using the same procedure as the original system from which the backup was made.
•
sysmgrClient bypasses normal locking processes
Symptom—After use of the 'sysmgrClient' utility, the Cisco EMF system information appears to be inconsistent. In particular, received traps have not been converted to alarms, objects which should
have been added do not exist, or objects which were being removed still exist in the system.
Condition—The user has used the 'sysmgrClient' utility to start and stop Cisco EMF server processes during deployment (object creation/ deletion) operations, or during trap reception.
Workaround—Do not use the process start/stop or run-level functionality of the 'sysmgrClient', except under the instruction of Cisco TAC or engineering personnel.
There is no workaround to recover the missed information if the processes were not running at the time the information was received, or if an in-progress operation was interrupted.
•
non-default logs directory is left when CEMF is deinstalled
Symptom—The directory for Cisco EMF log files is not removed during deinstallation.
Condition—The user has specified a non-default location for the logs directory while installing CEMF.
Workaround—The directory may be removed manually after deinstallation.
•
Objects without mandatory attributes should be rejected
Symptom—Objects can be successfully created without setting the value of mandatory attributes.
Condition—This can happen when creating objects using the objectFileParser, or when calling the Cisco EMF APIs directly.
Workaround—Strictly, there is no workaround, although additional care can be taken to ensure that any necessary attribute values are properly set.
•
Generic Trap mapping is slow for certain types of mapping
Symptom—There is a delay between traps being received from a device and an alarm being raised against that object in Cisco EMF.
Condition—This may happen when the mapping between the traps and Cisco EMF objects is complex. Traps have an IP address which corresponds to the SNMP agent against which the trap has been raised. Information in the trap can then be used to determine if the trap should be mapped to a child object in Cisco EMF.
In general, traps which map to the agent object will be mapped fastest, then traps against children with simple index-based mappings (i.e. every child has an single index value which uniquely represents it), and finally traps which have a rule involving looking up containment information.
Workaround—No workaround currently identified.
•
License file wont parse if command is run within cemf shell
Symptom—When attempting to parse in the Cisco EMF license file from a UNIX command-line session in which the 'cemf shell' command has been executed, an error is produced and the license file is not parsed.
Condition—This occurs when trying to parse in a license file from within a cemf shell
using the 'cemf license' command.
Workaround—A workaround to the problem is to parse in the license file outwith a cemf shell.
e.g. Open a new terminal
cd <CEMFROOT>/bin
Become root
Run the command 'cemf license -file <full path to license file>'
•
Large number of concurrent CEMF logins fail - server timeouts.
Symptom—Attempts to login to a Cisco EMF server will fail.
Condition—30 or more users attempt to login to the same Cisco EMF server at the same instant. Note that this is not the same as having 30 existing user sessions already logged in.
Workaround—Repeat the login until it succeeds - the issue is caused by the simultaneous login attempts.
•
Backup lock-out dialogs do not provide user with clear explanation
Symptom—While a backup is occurring, GUI operations may take a long time or fail without informing the user that a backup is in progress. This will be seen on both client and server-side GUIs.
Condition—A backup is in progress on the Cisco EMF server.
Workaround—Try to schedule backup operations at times when few GUI operations are being carried out.
•
User notification required when deployment not allowed by backup.
Symptom—While a backup is occurring operations may take a long time or fail without informing the user that a backup is in progress.
Condition—A backup is in progress.
Workaround—No workaround currently available.
•
corba event channel will not work after first time start
Symptom—No events are received on Corba event channels.
Condition—First-time start-up of Cisco EMF server.
Workaround—After first-time start-up of the Cisco EMF server has completed, stop and restart the CEMF server.
•
Network view not getting updated while many objects are added
Symptom—Using the map viewer, some objects which were just deployed do not appear in the view after the deployment has completed.
Condition—A user has a map viewer dialog open during a deployment operation which is adding a large number of objects to the system (in this case, 2000 objects at once).
The views on the left of the map viewer dialog do not appear to show all the new deployed objects, although the deployment appears to complete successfully.
Workaround—If the problem is seen, close and re-open any map viewer dialogs after the deployment operation. Alternatively, try to deploy fewer objects at one time if possible.
•
Headline : PSR reach exception in localDBServer (400 chassis databuild)
Symptom—The sysmgr.log log file contains an error message from the localDBServer process. The error message is from ObjectStore, and states that the process has 'exceeded its PSR reach'.
Condition—The CEMF system is managing a large number of chassis (in this case, 400), and the user tries to carry out an operation involving many objects, such as commissioning 50 chassis at once.
Workaround—No workaround available.
•
Removing patch doesn't roll back shared libs
Symptom—After backing out a previously-installed patch, CEMF binary and shared library files may remain as the patched versions.
Condition—Installing a CEMF patch package, then later backing it out. Under certain circumstances, the files which were updated by the patch installation process do not revert back to their original versions if the patch is subsequently backed out.
Workaround—There is currently no workaround.
•
eventChannelHost size grows after network outage with multi-users
Symptom—The process 'eventChannelHost' uses more and more memory over time.
Condition—A CEMF system which is managing a large number of chassis (in this case over 200) and has many user sessions running, and network connectivity has been lost to a substantial part of the devices on the network.
Workaround—No workaround available.
•
Backwards compatibility issue found with ATM QoS Profiles.
Symptom—This occurs when code built against CEMF version 3.1 is rerun against CEMF version 3.2 (Odin). The ProfileMonitor class contains virtual methods which will not be called unless the code is rebuilt.
Condition—Attempting to apply a profile can fail, because the underlying system cannot retrieve the profile.
Condition—The workaround is to recompile any code which uses the ProfileMonitor API.
•
Backwards compatibility issue found with ATM Upload.
Symptom—When an element manager which was compiled for Cisco EMF 3.1 is run on Cisco EMF 3.2 system, query-related functionality may not appear to give the correct results.
Condition—A query is being performed which checks for the presence of a particular attribute or attributes against one or more objects.
Workaround—If the element manager is recompiled for Cisco EMF 3.2, this problem will not occur.
Open Caveats (Between Release and 1st October 2001)
•
No security on controller operations
Symptom—A user can perform operations on their machine that should only be available to users with root permission, even if that user doesn't have root permission.
carry out root operations via controller actions, even although they do not have root privileges.
Conditions—This occurs when the user creates actions that perform root operations.
Workaround—There is currently no workaround.
•
Install script say succesfull when errors occur
Symptom—The "cemf load" command does not return an error code if processes fail to start during installation.
Conditions—Occurs when an EM is installed, but one of the processes cannot be started.
Workaround—The "<CEMF_ROOT>/bin/cemf status" command can be used to ascertain the status of all process that are supposed to be running. The output from this command can be used to determine which process failed to start.
•
Object Deletion Needs Initial User Feedback
Symptom—After the user initiates delete operation on a large number of objects the Deployment Wizard appears to hang.
Conditions—The user selects a set of objects to be deleted and invokes the delete option from the MapViewer menu "Deployment" -> "Delete Objects". This starts the delete operation. The actual set of objects deleted can automatically expand to a greater number than the user selected (In some cases reaching 50, 000 objects. Number is technology specific). This delete operation can then take a considerable amount of time during which the user receives no feedback.
Workaround—User should attempt to delete objects in as small a number as possible.
•
GUI Not Updated Following Object Deletion
Symptom—After initiating the deletion of objects via the Deployment Wizard the Deployment Wizard GUI remains busied out.
Conditions—This problem arises when a large number of objects are deleted. User selects set of objects to delete and initiates the deletion via the Deployment Wizard. Objects are automatically added to the set of objects to be deleted. If the total set of objects to be deleted is sufficiently large the deletion operation will result in the Deployment Wizard remaining busied out. Some of the objects (and perhaps all) may have been successfully deleted.
Workaround—User to delete small sets of objects.
•
sysmgr fails to handle process failures on cemf start up
Symptom—No errors are reported to the screen when a process failed to start after EM installation.
Conditions—Occurs when an EM is installed, but one of the processes cannot be started.
Workaround—The "<CEMF_ROOT>/bin/cemf status" command can be used to ascertain the status of all process that are supposed to be running. The output from this command can be used to determine which process failed to start.
•
eventChannelHost grows enourmously
Symptom—The Cisco EMF 'eventChannelHost' process grows to a large size.
Conditions—Many attributes are being polled, and their values databased for later use
by the Performance Manager.
Workaround—There are two possible workarounds:
1. Reduce the polling frequency of attributes being polled
2. Do not database the values of as many attributes. This can be achieved
by changing the history regimes for the EMS.
Guest
