Switches, Hubs, and Modems
1748169 Members
4010 Online
108758 Solutions
New Discussion юеВ

PCM 2.2, Traffic and Trunks

 
Andr├й Beck
Honored Contributor

PCM 2.2, Traffic and Trunks

Hi,

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.
5 REPLIES 5
Teknisk Drift_1
Occasional Advisor

Re: PCM 2.2, Traffic and Trunks

First of all, member ports are not supposed to have traffic, as far as I know.
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...

Matt Hobbs
Honored Contributor

Re: PCM 2.2, Traffic and Trunks

As far as I know, PCM cannot get sFlow samples for Dynamic LACP trunks, but Static LACP trunks should work fine.

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.
Andr├й Beck
Honored Contributor

Re: PCM 2.2, Traffic and Trunks

Hi folks,

> 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.
Matt Hobbs
Honored Contributor

Re: PCM 2.2, Traffic and Trunks

PCM traffic monitoring of LACP trunks was not working in PCM 2.1 Update 9. Standard trunks were working however. This is why I'm wondering if this is an existing bug that still has not been fixed. If I find some time tomorrow I'll see if I can verify this.

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.
Steve Britt
Respected Contributor

Re: PCM 2.2, Traffic and Trunks

Hi,

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