09-04-2009 08:52 AM
IP SLA monitors are configured via CLI manually or NetConfig, rather than through IPM itself, can it pick those up for reporting only?
Solved! Go to Solution.
09-04-2009 09:36 AM
In IPM 4.1 and higher, you can import collectors from devices using the ipm importcollector CLI command. Once the collectors are imported, you can run all the usual reports on them.
09-17-2009 08:10 AM
No, it really wasn't successful. While eight collectors were found, none were imported. The operation status of the collectors is 5 (inactive) where as IPM is expecting either 1 or 6 (reset of active). Check the rttMonCtrlOperState for these collectors, and you should see they are not active. Define a new, active, collector, and IPM should be able to import it.
09-24-2009 08:26 AM
Not unless you specify "life forever" as well. Else, it will only be active for 3600 seconds.
09-24-2009 09:56 AM
Yes. By default, IPM does not push the collector configs to the running config. You can enable this by checking the "Copy IPSLA Configuration to running-config" box under IPM > Admin > Application Settings.
09-04-2009 09:36 AM
In IPM 4.1 and higher, you can import collectors from devices using the ipm importcollector CLI command. Once the collectors are imported, you can run all the usual reports on them.
09-04-2009 09:51 AM
Great! Luckily, mine barely qualifies.
09-04-2009 09:54 AM
Question: When would the Import From Device function become available in the GUI, so that the administrator gets freed from having to do this on the CLI for every user?
09-04-2009 09:56 AM
It has been raised, but I am not sure when the UI version will be done. It could very well be next year's release as there will be huge UI changes.
09-16-2009 11:17 AM
The IPM GUI has more config options than required by the CLI, so I want to import some of the existing IP SLA configs to find out how IPM would interpret them. I got the following error though:
* Warning * The -p option is highly insecure and *not* recommended.
* Warning * See -u option for more details.
Recommended action:
1. Check whether the given input are valid
2. Check the ipmcli.log for details
SUMMARY
========
Failed: ipm importcollector: Import of Collectors failed.
Here's ipmcli.log:
[ Wed Sep 16 15:05:28 EDT 2009 ],INFO ,[main],com.cisco.nm.ipmng.cli.framework.core.IPM,doStuff,176,Licens
e check passed...
[ Wed Sep 16 15:05:31 EDT 2009 ],INFO ,[main],com.cisco.nm.ipmng.devicemanager.DMDbAccessManager,getDbInst
ance,53,Initializin DB Interface...
[ Wed Sep 16 15:05:31 EDT 2009 ],INFO ,[main],com.cisco.nm.ipmng.devicemanager.DMDbAccessManager,init,64,G
etting DB connection...
[ Wed Sep 16 15:05:31 EDT 2009 ],INFO ,[main],com.cisco.nm.ipmng.util.db.DBClient,getDbInstance,36,Initial
izin DB Client...
[ Wed Sep 16 15:05:31 EDT 2009 ],INFO ,[main],com.cisco.nm.ipmng.util.db.DBClient,init,46,Getting DB conne
ction...
[ Wed Sep 16 15:05:31 EDT 2009 ],INFO ,[main],com.cisco.nm.ipmng.devicemanager.DMDbAccessManager,getDBConn
ection,73,Getting Connection object from DBClient
[ Wed Sep 16 15:05:31 EDT 2009 ],ERROR,[main],com.cisco.nm.ipmng.devicemanager.DMDbAccessManager,getDCRIdT
oDisplayName,1965,Error while executing query :null
Here's the IP SLA config snippet on the source device:
ip sla monitor responder
ip sla monitor 11
type jitter dest-ipaddr 10.xx.xx.15 dest-port 11020
tos 184
owner name1
ip sla monitor schedule 11 start-time now
ip sla monitor 12
type jitter dest-ipaddr 10.xx.xx.16 dest-port 11020
owner name2
ip sla monitor schedule 12 start-time now
09-16-2009 11:24 AM
Is this device in DCR, and managed by IPM as a source device?
09-16-2009 12:13 PM
The device is in DCR, but not added to IPM as a source. Is that why the import failed? I suspected that, but figured "isn't that the whole point of importing all about?"
09-16-2009 12:16 PM
Yes, the device needs to be added to IPM as a source device. The purpose of the import is to import the Collectors from an existing source. IPM needs to know the device is a valid source first.
09-17-2009 06:29 AM
It's odd that the import was only "successful" after I used the device hostname as Source. It failed against the IP addr the hostname resolves to. Both attributes were entered in DCR.
Or was it really "successful" at all? I can't seem to find any new additions under Operations or Collectors in IPM.
* Warning * The -p option is highly insecure and *not* recommended.
* Warning * See -u option for more details.
Importing collectors from device(s) may take some time.
Please wait ...........
----------------------------------------------------------------------
SUMMARY OF IMPORT COLLECTOR STATUS FROM DEVICE(s)
----------------------------------------------------------------------
Number of Collectors Imported : 0
Number of Collectors Not Imported : 8
Number of Collectors Filtered : 0
Number of adhoc devices added : 0
----------------------------------------------------------------------
SUMMARY
========
Successful: ipm importcollector: ImportCollector operation completed.
Please see ipmcli.log and ipmprocess.log files for more details
I see lots of this in ipmcli.log:
[ Thu Sep 17 10:27:55 EDT 2009 ],ERROR,[pool-2-thread-3],com.cisco.nm.ipmng.collectormgr.collector.importService.DALTask,run,112,DALTask-run()-Coll_testSAArtr1 : 13 - DALVariableNotSupported Exception exception occured - Reason - Operation status = 5 may not valid
09-17-2009 08:10 AM
No, it really wasn't successful. While eight collectors were found, none were imported. The operation status of the collectors is 5 (inactive) where as IPM is expecting either 1 or 6 (reset of active). Check the rttMonCtrlOperState for these collectors, and you should see they are not active. Define a new, active, collector, and IPM should be able to import it.
09-17-2009 08:56 AM
Would it make sense to raise an enhancement request so the importcollector function (both CLI and GUI) imports inactive collectors/ops, and store them in inactive state in IPM as well?
09-17-2009 09:00 AM
I personally don't see the benefit, as the typical usage of this import was to bring in active collectors so that reporting could be done; but if you can provide a good argument for the feature, then definitely raise the request.
09-24-2009 05:45 AM
After having all the IP SLA configs removed and then added back, except the "ip sla monitor responder" line, the 8 operations became "active" again. After that, the import worked great. I'm curious what could've made them "inactive", because AFAIK nobody had explicitly stopped the operations, nor was there any indication in the configs themselves (as seen in the config snippet posted previously) that they were inactivated. My only theory was the concurrent config of the router being both an IP SLA collector and responder, but that seems unreasonable.
09-24-2009 08:05 AM
No, a router can be both a source and a responder. It could have been that the collectors were created with a limited lifetime.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide