08-02-2007 12:10 PM
Receiving log4j errors with the UT CLI command:
/opt/CSCOpx/campus/bin/ut -cli -query all -export /path/ut.txt -u admin -p password
log4j:ERROR No appenders could be found for category (com.cisco.nm.ani.clients.utng.application.UTDataManager).
log4j:ERROR Please initialize the log4j system properly.
Operation has been completed successfully
Is this related the following problem?
Process= DeviceDiscovery
State = Transient terminated
Pid = 0
RC = 0
Signo = 0
Start = 08/01/07 11:39:08
Stop = 08/01/07 11:40:15
Core = Not applicable
Info = Application started by administrator request.
Process= UTMajorAcquisition
State = Transient terminated
Pid = 0
RC = 0
Signo = 0
Start = 08/02/07 00:00:00
Stop = 08/02/07 00:28:06
Core = Not applicable
Info = Application started by administrator request.
Process= FDRewinder
State = Transient terminated
Pid = 0
RC = 0
Signo = 0
Start = 08/01/07 11:41:45
Stop = 08/01/07 11:41:45
Core = Not applicable
Info = Application started by administrator request.
tail -f /var/adm/CSCOpx/log/ut.log
...
2007/08/02 00:19:30 EvalTask-vmpsadmin-07 ani WARNING C6KIOSVmpsAdminSMFGetBridgeTable: VladSMFGetVlanPorts.getData() returns null for device xx.xx.xx.xx, no CAM table read.
2007/08/02 00:25:38 main ani MESSAGE DBConnection: Created new Database connection [hashCode = 5742829]
08-02-2007 12:46 PM
These log4j errors are normal, and do not cause any problem. ut -cli should always display the log4j errors, but still complete the desired operation. Nothing in the output you have provided is necessarily problematic.
08-03-2007 09:21 AM
There's another factor that makes me think something went wrong--CM status as of this moment:
Device Discovery 01 Aug 2007, 11:40:14 EDT xxxx Devices Idle Start Device Discovery
where xxxx is over a hundred devices shy of the total number of devices in the DCR.
08-03-2007 10:55 AM
This is not necessarily a problem. You can add devices to DCR outside of discovery, and Discovery can also use filters to prevent it from counting devices that are in DCR. In order to determine if this is a real problem, you will need to find one device that is in DCR, but missing from Discovery's last sweep, then look through the discovery.log (assuming devdiscovery debugging was enabled) to see why that device might be missing. Look for that device's name and address as well as its neighbors names and addresses.
08-03-2007 11:15 AM
Device Discovery had always had more devices than what's in DCR (equal to the device number in CM's Data Collection) until this juncture. Most of the extraneous ones found by Device Discovery are "unreachable", and I disabled the Device Discovery=>DCR synchronization. Since I don't have debug on for discovery, should I still bother looking for a device? I did just see the following:
tail -f discovery.log
2007/08/01 11:40:13 EvalTask-Devdiscovery-07 WARNING DevdiscoverySMFGetDeviceType: SNMP unreachable device at: xx.xx.xx.xx will not remap SMFFactory
2007/08/01 11:40:14 main ERROR DevdiscoverySMFEnd: Error in add Device: CSTM Error Code [-23] CSTM Comm Type [0] - Error in reading/Error in received response,, Binary encoding InputStream does not contain a serialized object
2007/08/01 11:40:14 main MESSAGE DiscoveryMain: Properties will be read from /opt/CSCOpx/campus/etc/cwsi/DiscoveryStatus.properties
2007/08/01 11:40:14 main MESSAGE DiscoveryMain: Properties will be read from /opt/CSCOpx/campus/etc/cwsi/DiscoveryStatus.properties
2007/08/01 11:40:14 main MESSAGE DCRDevWrapper: Closing DCRProxy
08-03-2007 03:30 PM
How did you disable DCR synchronization? The CSTM error here is a problem. This could indicate a problem with DCRServer or with the Campus CTM server (which should be ANIServer). The easiest thing to try to correct this would be a restart of dmgtd.
08-06-2007 11:22 AM
I stopped the CM=>DCR device sync by deleting the Device Discovery schedule in CM completely.
Bouncing dmgtd is ok for a one-time anomaly, but I'm concerned the same problem might recur. Even though I've disabled Device Discovery and don't need it, I'm uncomfortable with the fact the "ut -cli" export also got affected by this problem--the output of the full ut dump was completely empty.
08-06-2007 11:32 AM
If you've completely disable Discovery, then the CSTM error may be nothing to worry about. I still don't know what the problem with UT is. So far, you've only talked about Discovery numbers. These have no bearing on what is in User Tracking, and will not affect ut -cli.
08-06-2007 11:46 AM
Never mind UT. I was looking at the wrong output file. The UT CLI dumps were successful.
Now I believe the Device Discovery that's stuck at 01 Aug 2007, 11:40:14 EDT has nothing to do with UT, but I just find the numbers of Physical and Logial Discrepancies are all zeros, whereas they had been in the thousands normally. Are these related to the CSTM error or Device Discovery (that's been stopped months ago)?
08-06-2007 11:58 AM
Discrepancies have nothing to do with Discovery, either. Data Collection is solely responsible for detecting discrepancies. If the count suddenly dropped to 0, ANI either found a perfect network, or there was a problem with the last Data Collection. To debug discrepancy problems, enable dcrp debugging under Campus Manager > Admin > Campus Data Collection > Debugging Options, then re-run Campus Data Collection.
08-07-2007 11:29 AM
Debugging was enabled, but no ani-trace.log was created as a result. I did not enalbe device-level debugging. Data Collection ran as usual, though it took ~34 mins last night compared to the ~25 mins the night before. The discrepancies are back once again. Strange.
08-07-2007 12:26 PM
Indeed. If dcrp debugging was enabled, you should have seen something in ani.log related to discrepancies.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: