Switches, Hubs, and Modems
1751695 Members
4705 Online
108781 Solutions
New Discussion юеВ

PCM unusual bandwidth stats

 
RobB_8
Advisor

PCM unusual bandwidth stats

I am getting the following error from 1 of my switches, it is a 2524 running 5.52. xxx.xxx.xxx.xxx_port_25 utilization value 572% >= critical threshold 75% (global setting). I did set the 75% threshold, however every time I get the 572% error. I checked the patch cable, it appears to be good fibre, SC to ST. Using a standard HP GB SX module. Ports are set at both ends to auto and appear to be detecting at 1000. I get several dozen of these errors every day.
Any ideas?
Thanks
2 REPLIES 2
Matt Hobbs
Honored Contributor

Re: PCM unusual bandwidth stats

There's an issue with PCM that if it discovered a switch when the link was not up, it will have remembered it at it's lowest speed - which is why you can see more than 100%. There are a few posts on this topic, search for 'PCM utilization'

To summarise - delete the switch from PCM, rediscover it and then reconfigure in Traffic Monitor.

Also I believe the latest Update 3 to PCM 2.1 has changed the way traffic monitor works so I'd recommend updating that for more reliable behaviour.

http://www.hp.com/rnd/software/network_management.htm

Don't forget to assign points.
Steve Britt
Respected Contributor

Re: PCM unusual bandwidth stats

Rob,

Matt's reply is correct. PCM 2.1 does not automatically update link speeds and duplex settings in its database if they're changed after a device/port is initially discovered. This, of course, throws off the computation of traffic utilization should either link characteristic change thereafter. This is one of the top traffic issues that will be addressed in PCM 2.2 - awareness of dynamic changes within the topology, both in terms of link state (up/down) and in terms of operating characteristics.

To force a discovery with the correct speed and duplex you must delete the device from PCM and rediscover it. Unfortunately this means you must also reset your traffic thresholds if you've customized them. I know this isn't elegant, but it's the only way to correct this issue for the time being.

Just to be clear, autoupdate #3 does not fix this issue but does offer other improvements to traffic monitoring as well as traffic support for new ProCurve devices.

Regards,

SVB