- Community Home
- >
- Networking
- >
- Legacy
- >
- Switches, Hubs, Modems
- >
- PCM 2.2, Traffic and Trunks
Categories
Company
Local Language
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
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
Community
Resources
Forums
Blogs
- 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
тАО11-12-2007 08:35 PM
тАО11-12-2007 08:35 PM
PCM 2.2, Traffic and Trunks
I've got this cloud of switches (5300xl, 2810 and 2600 series) where the central and most heavily loaded interconnects are LACP aggregates (aka Trunks in ProCurve land). Now PCM Traffic Monitoring (2.2 latest) happily collects data for all interfaces *BUT* trunks. The member ports appear as not having any traffic, and there is no compound traffic on the TrkX thingies either (as far as PCM is concerned they don't even seem to exist anywhere but in brown lines in the maps).
How am I supposed to monitor traffic on my most relevant backbone interconnects when PCM trafficd doesn't deal with trunks? Or is this just a malfunction?
TIA,
Andre.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-13-2007 07:26 AM
тАО11-13-2007 07:26 AM
Re: PCM 2.2, Traffic and Trunks
In fact, I think member port's don't really exist as separate ports after being trunked.
So you can take those out...
As for why you are not seeing traffic on the trunks.. hmm.. this is guessing only:
Earlier versions of PCM wasn't able to pick up changes to the ports on the switches. I.e. if you changed the speed of a port, or you created or deleted a trunk, the port changes weren't reflected in PCM properly.
Could it be that your PCM doesn't (dynamically) pick up that info from the switches? The fix used to be to delete and discover (not just re-discover) the switch.
Others here will know better than me if this was fixed in 2.2...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-13-2007 08:56 PM
тАО11-13-2007 08:56 PM
Re: PCM 2.2, Traffic and Trunks
I also agree with the previous post, if those trunks were created after the switches were discovered I would try deleting them and manually discovering them again.
Make sure you're running the latest Auto Update too (5).
If nothing else helps, one last thing I'd try is using a standard trunk instead of LACP to see if this makes any difference.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-13-2007 09:52 PM
тАО11-13-2007 09:52 PM
Re: PCM 2.2, Traffic and Trunks
> First of all, member ports are not supposed
> to have traffic, as far as I know.
Well, I see this differently (I want to see what happens on every member port as well as on the aggregate, simply to get notice of asymmetric load distribution and such problems), but of course I don't need duplicate flow data. But counters still would be nice ;)
> In fact, I think member port's don't really
> exist as separate ports after being
> trunked. So you can take those out...
I can do "show int" for them in the CLI, and PCM shows them everywhere. They are still there, and I would not like to not see them. The correct feedback by the management software would be to display all member ports as well as the virtual "port" that the trunk constitutes in a non-ambiguous way that makes clear it's an aggegate. But I'm dreaming, given that I can't even "name" a trunk on the boxes.
> Could it be that your PCM doesn't
> (dynamically) pick up that info from the
> switches? The fix used to be to delete and
> discover (not just re-discover) the switch.
The switches were newly discovered with the trunks already configured. PCM seemingly picked them up, as it shows them correctly on the network map (something that didn't work correctly for ages indeed, but here it actually worked, which got me by surprise).
> As far as I know, PCM cannot get sFlow
> samples for Dynamic LACP trunks, but Static
> LACP trunks should work fine.
These are of course static LACP trunks, as dynamic trunks are unusable on ProCurves (they drop back into the default VLAN instead of inheriting the tagging specs of the member ports).
> I also agree with the previous post, if
> those trunks were created after the
> switches were discovered I would try
> deleting them and manually discovering
> them again.
They were there before, though. And deleting switches is nothing done lightly, as it will not only wipe out all the configuration history that has piled up meanwhile, it will especially destroy my handcrafted network map (mixing up placements of any switch that connects to the deleted one just for fun, even though I told it to lock switch locations). *Sigh*, talking about this stuff easily triggers me into rant mode ;)
> Make sure you're running the latest Auto
> Update too (5).
That's what is running ;)
> If nothing else helps, one last thing I'd
> try is using a standard trunk instead of
> LACP to see if this makes any difference.
LACP is there for a reason (inter-module trunks) and I can't do this in a live network but I'll give this a try in a test setup. I don't expect it to change anything, though - and if it would, it would be a ridiculous bug (but at least we would know it)...
Thanks,
Andre.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-13-2007 10:13 PM
тАО11-13-2007 10:13 PM
Re: PCM 2.2, Traffic and Trunks
As far as PCM is concerned, HP Trunk and FEC trunks use ifType 54. LACP Trunks use ifType 161. Possibly the SNMP get/sets are not being handled correctly.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-14-2007 01:19 PM
тАО11-14-2007 01:19 PM
Re: PCM 2.2, Traffic and Trunks
PCM 2.2 traffic monitoring doesn't support collection from interfaces with ifType 161, either via statistics polling or sampling. This is something we will add to our list of enhancement requests. Switching to a regular trunk rather than an LACP trunk should allow you to collect traffic data on the aggregate.
Being able to monitor the traffic on constituent ports of a mesh or trunk is already on our wish list. As Matt mentioned, when we do implement this capability in PCM at some point there will be certain devices that even then cannot provide this data because some devices remove the constituent ports from the ifTable when they are aggregated.
Regards,
SVB