- Community Home
- >
- Networking
- >
- Legacy
- >
- Switches, Hubs, Modems
- >
- Re: PCM+ Traffic Monitor
Switches, Hubs, and Modems
1748043
Members
4823
Online
108757
Solutions
Forums
Categories
Company
Local Language
юдл
back
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
юдл
back
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Blogs
Information
Community
Resources
Community Language
Language
Forums
Blogs
Go to solution
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-26-2005 01:46 AM
тАО10-26-2005 01:46 AM
I monitor eight ProCurve switches in a flat network with PCM+ 2.0, 2524's, 2650's and 2848's. I selected one port from each switch for traffic monitoring, based on stats. Traffic monitor updates every 60 seconds, but always reports a varying number on 'segments responding'. Often 5 or 6 out of 8, sometimes 8 of 8. Is this normal behaviour?
Also, i would like to alter the broadcasts/sec gauge scale. I can adjust warning and alarm value with tresholds, but not the 20k max, which is ridiculously high. Is there a workaround to fix the scale?
Also, i would like to alter the broadcasts/sec gauge scale. I can adjust warning and alarm value with tresholds, but not the 20k max, which is ridiculously high. Is there a workaround to fix the scale?
Solved! Go to Solution.
3 REPLIES 3
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-26-2005 07:26 AM
тАО10-26-2005 07:26 AM
Solution
Hans,
In PCM+ 2.0 the "segments responding" count indicates the number of segments for which data was retained during the just-completed minute. There was a restriction in PCM+ 2.0, however, that strictly limited the segments for which data was retained to those that returned data in 60.000 or fewer seconds. In your case, with so few segments to poll, PCM+ won't send any polling requests to the 8 segments until 57 seconds after that last minute has begun - meaning that if the request/response cycle to and from the device doesn't complete in 3.000 seconds or less then the late responses will be ignored and you'll see fewer than 8 segments responding for that minute.
This restriction has been relaxed in PCM+ 2.1, which will be releasing within a couple of weeks. This release will this solve your issue by providing a bit more response-time leeway for stats polling. The upgrade from PCM+ 2.0 to PCM+ 2.1 is free and should be available on the ProCurve website within that time frame. You may find in the meantime that you can get better responsiveness and skirt this issue somewhat with PCM+ 2.0 by specifying Sampler rather than Stats collection on your 2524s and 2848s. The sampled sFlow data is not polled by PCM+ as I described earlier and thus runs no risk of having such a timeout issue; rather, this data is "pushed" to PCM+ every 5 seconds by the device itself.
Another Traffic-Monitor-specific benefit you'd get by upgrading to PCM+ 2.1 is much friendlier presentation of addresses within the 11 different Top 5 Views. Whereas with PCM+ 2.0 and its predecessors you always see MAC addresses shown on the Source and Destination tabs within these views, now you will see IP addresses or DNS names if PCM+ has discovered the nodes involved (and thus can associate each MAC to an IP address). For the Connections tabs within these views you will even see DNS names for nodes that PCM+ hasn't discovered as long as a DNS server is accessible by PCM+. Finally, a bit of extra protocol decoding has been added to PCM+ 2.1 including RTP (to identify voice and video traffic).
Regarding the second question you have about the broadcasts/sec gauge scale, there is currently no way to modify this. Basically the values shown as maximums are scaled proportionally to those that were set for a 10Mbps link. So if you have a 100Mbps link the limit would be scaled from the 2k broadcasts/sec limit used for 10Mbps ports to 20k as the 100Mbps link speed is 10x higher. I will add your suggestion to make the maximums configurable to our list of investigation topics for subsequent PCM+ releases, but for now this will not change in the upcoming PCM+ 2.1 release.
Regards,
SVB
In PCM+ 2.0 the "segments responding" count indicates the number of segments for which data was retained during the just-completed minute. There was a restriction in PCM+ 2.0, however, that strictly limited the segments for which data was retained to those that returned data in 60.000 or fewer seconds. In your case, with so few segments to poll, PCM+ won't send any polling requests to the 8 segments until 57 seconds after that last minute has begun - meaning that if the request/response cycle to and from the device doesn't complete in 3.000 seconds or less then the late responses will be ignored and you'll see fewer than 8 segments responding for that minute.
This restriction has been relaxed in PCM+ 2.1, which will be releasing within a couple of weeks. This release will this solve your issue by providing a bit more response-time leeway for stats polling. The upgrade from PCM+ 2.0 to PCM+ 2.1 is free and should be available on the ProCurve website within that time frame. You may find in the meantime that you can get better responsiveness and skirt this issue somewhat with PCM+ 2.0 by specifying Sampler rather than Stats collection on your 2524s and 2848s. The sampled sFlow data is not polled by PCM+ as I described earlier and thus runs no risk of having such a timeout issue; rather, this data is "pushed" to PCM+ every 5 seconds by the device itself.
Another Traffic-Monitor-specific benefit you'd get by upgrading to PCM+ 2.1 is much friendlier presentation of addresses within the 11 different Top 5 Views. Whereas with PCM+ 2.0 and its predecessors you always see MAC addresses shown on the Source and Destination tabs within these views, now you will see IP addresses or DNS names if PCM+ has discovered the nodes involved (and thus can associate each MAC to an IP address). For the Connections tabs within these views you will even see DNS names for nodes that PCM+ hasn't discovered as long as a DNS server is accessible by PCM+. Finally, a bit of extra protocol decoding has been added to PCM+ 2.1 including RTP (to identify voice and video traffic).
Regarding the second question you have about the broadcasts/sec gauge scale, there is currently no way to modify this. Basically the values shown as maximums are scaled proportionally to those that were set for a 10Mbps link. So if you have a 100Mbps link the limit would be scaled from the 2k broadcasts/sec limit used for 10Mbps ports to 20k as the 100Mbps link speed is 10x higher. I will add your suggestion to make the maximums configurable to our list of investigation topics for subsequent PCM+ releases, but for now this will not change in the upcoming PCM+ 2.1 release.
Regards,
SVB
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-05-2005 11:02 PM
тАО12-05-2005 11:02 PM
Re: PCM+ Traffic Monitor
Hello Steve,
Thanks for clearing things up. Unfortunately the 26xx's do not support traffic sampler. I'll look forward to PCM+ 2.1.
Regards,
Hans
Thanks for clearing things up. Unfortunately the 26xx's do not support traffic sampler. I'll look forward to PCM+ 2.1.
Regards,
Hans
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-06-2005 01:06 AM
тАО12-06-2005 01:06 AM
Re: PCM+ Traffic Monitor
I am running the latest 2.1 code and still get a few "not Reporting" for 45 "sampler" segments but can probably dismiss those for below threshold traffic. What I cannot dismiss though are the gaps on the graph for my busiest port where I do get the Top 5 stats but no graph for 1 to 6 second intervals. On an average hour, about half of the timeslots are empty. This is a change in behavior from 2.0 where I was getting graphs but bogus or no Top 5 details.
I don't mean to hijack this topic. I have been working with Hector at HP for some time now.
I don't mean to hijack this topic. I have been working with Hector at HP for some time now.
The opinions expressed above are the personal opinions of the authors, not of Hewlett Packard Enterprise. By using this site, you accept the Terms of Use and Rules of Participation.
News and Events
Support
© Copyright 2024 Hewlett Packard Enterprise Development LP