cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1003
Views
0
Helpful
20
Replies

Can IPM report on IP SLA ops it didn't configure?

yjdabear
VIP Alumni
VIP Alumni

IP SLA monitors are configured via CLI manually or NetConfig, rather than through IPM itself, can it pick those up for reporting only?

4 Accepted Solutions

Accepted Solutions

Joe Clarke
Cisco Employee
Cisco Employee

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.

View solution in original post

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.

View solution in original post

Not unless you specify "life forever" as well. Else, it will only be active for 3600 seconds.

View solution in original post

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.

View solution in original post

20 Replies 20

Joe Clarke
Cisco Employee
Cisco Employee

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.

Great! Luckily, mine barely qualifies.

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?

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.

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.

ERROR - 10.x.x.x is not a valid source device

ERROR - Command Execution Failed.

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

Is this device in DCR, and managed by IPM as a source device?

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?"

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.

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 ...........

INFO -

----------------------------------------------------------------------

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

----------------------------------------------------------------------

INFO - Done with the execution of the command.

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

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.

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?

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.

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.

No, a router can be both a source and a responder. It could have been that the collectors were created with a limited lifetime.

Getting Started

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: