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

Answered Question
Sep 4th, 2009

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

Correct Answer by Joe Clarke about 7 years 5 months ago

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.

Correct Answer by Joe Clarke about 7 years 5 months ago

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

Correct Answer by Joe Clarke about 7 years 5 months ago

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.

Correct Answer by Joe Clarke about 7 years 5 months ago

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (4 ratings)
Loading.
Correct Answer
Joe Clarke Fri, 09/04/2009 - 09:36

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.

yjdabear Fri, 09/04/2009 - 09:54

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?

Joe Clarke Fri, 09/04/2009 - 09:56

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.

yjdabear Wed, 09/16/2009 - 11:17

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


yjdabear Wed, 09/16/2009 - 12:13

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

Joe Clarke Wed, 09/16/2009 - 12:16

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.

yjdabear Thu, 09/17/2009 - 06:29

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


Correct Answer
Joe Clarke Thu, 09/17/2009 - 08:10

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.

yjdabear Thu, 09/17/2009 - 08:56

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?

Joe Clarke Thu, 09/17/2009 - 09:00

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.

yjdabear Thu, 09/24/2009 - 05:45

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.

Joe Clarke Thu, 09/24/2009 - 08:05

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

yjdabear Thu, 09/24/2009 - 08:10

All the ops have always been configured with "ip sla monitor schedule [#] start-time now". Shouldn't they be perpetual?


Correct Answer
Joe Clarke Thu, 09/24/2009 - 08:26

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

yjdabear Thu, 09/24/2009 - 09:39

Another unexpected phenomenon: All the IP SLA configs have disappeared on the import source device. Were the configs removed as a result of the IPM importcollector process?

Correct Answer
Joe Clarke Thu, 09/24/2009 - 09:56

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.

yjdabear Thu, 09/24/2009 - 10:06

I'm not sure I follow. In this case, it's the reverse: NMSROOT/bin/ipm seemed to have removed every "ip sla *****" line from the running-config, after it's done importing. Would ticking a box in the GUI change the behavior of "ipm importcollector" as well, so it stops removing running-configs (or rather, remove anyway then put back)?

Joe Clarke Thu, 09/24/2009 - 10:10

Yes, it should allow IPM to retain them in the running config once it assumes ownership.

Actions

This Discussion