Cisco Works LMS Performance Management

Answered Question

I would like the capability to monitor some SNMP RO parameters on devices. The problem is that it isn't very intuitive to do this.


I am using Internet Performance Manager to check how well a device will turn around certain test packets. This application keeps historical values and can be used for a baseline.


I would also like to know and keep information on CPU and memory utilization. Cisco View gives you a 2 hour window into this but doesn't seem to keep historical data.


Another thing that would be useful is link utilization data. I would like to be able to monitor all ports on a device at 1 second intervals to see if they ever crossed a 50% utilization figure. And I need historical records for the data.


What would be very nice is a forwarding latency value for all packets.


I am trying to use DFM to poll a specified device for some of these values but can't get around the requirement to poll only interfaces or groups that don't include devices at all.


I am using LMS 2.6. I haven't decided to go the $10K to upgrade to 3.0. We have this product in a lab environment and would need to upgrade 6 other copies in the field. The primary problem in the field has been the need to use SNMP RW passwords for about half of the models of Catalyst switches. It appears that you don't need RW for the 2950s, 3550s and 3750s. There has also been an issue integrating DFM on the same box as Tivoli Netview.


Anyone know how to gather the particulars I need? thx

Correct Answer by Joe Clarke about 9 years 3 months ago

I'm not arguing that one second polling might be useful. However, most device counters aren't updated quicker than every 10 seconds. So the data might not be valid. Testing would need to be done to ensure the quick polling is returning valid data.


DFM does cover queue drops. It has an event for HighQueueDropRate which looks at the drop percentage relating to the packets forwarded. This event is enabled by default. Wether or not it is triggered depends on your queue drop threshold.

Correct Answer by Joe Clarke about 9 years 3 months ago

What you want really is not doable in LMS. We are releasing an LMS 3.0 plug-in this month called the Health and Utilization Monitor which will allow you to poll arbitrary objects such as CPU, memory, errors, throughput, etc. This add-on will require LMS 3.0, and will not work with 2.6.


That said, the minimum polling interval in HUM will be one minute, so you will not be able to do your 1 second polling (though it's not recommended to poll faster than every 10 seconds).

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Loading.
Correct Answer
Joe Clarke Thu, 12/13/2007 - 11:25
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    Founding Member

What you want really is not doable in LMS. We are releasing an LMS 3.0 plug-in this month called the Health and Utilization Monitor which will allow you to poll arbitrary objects such as CPU, memory, errors, throughput, etc. This add-on will require LMS 3.0, and will not work with 2.6.


That said, the minimum polling interval in HUM will be one minute, so you will not be able to do your 1 second polling (though it's not recommended to poll faster than every 10 seconds).

There are uses for 1 second polling granularity... It gives you a peak utilization value. I think you would need to get bulk all the mib values to reach it though.. Might be a problem.


Thanks for the help. It clarifies the situation. HUM would be a nice tool.


I am thinking that packet drop may be covered in the LMS 2.6 functionality of DFM. I haven't been able to get to that functionality in though.

Correct Answer
Joe Clarke Thu, 12/13/2007 - 12:26
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    Founding Member

I'm not arguing that one second polling might be useful. However, most device counters aren't updated quicker than every 10 seconds. So the data might not be valid. Testing would need to be done to ensure the quick polling is returning valid data.


DFM does cover queue drops. It has an event for HighQueueDropRate which looks at the drop percentage relating to the packets forwarded. This event is enabled by default. Wether or not it is triggered depends on your queue drop threshold.

Actions

This Discussion