Forum Discussion

drazzopardi's avatar
4 years ago

Cisco Port Channel Monitoring

Hi all

I am hoping that someone has come against this requirement.  

While I can monitor port channels, I would like to monitor the port channel interfaces but not as interfaces, as the channel group that they are.  

So ideally that if one of the interfaces in the port channel is down that we can alert on its degraded state.  As an interface, the port channel remains up and happy so doesn't cater for individual failures.

I have been hunting for a suitable MIB for this but getting varied results between Cisco devices.

Any help on this topic is appreciated.

David

9 Replies

  • I've been spinning my wheels on this same idea. Without having dug into the depths that are MIBs, I'm thinking it might be worth running an expect script to gather the port channel interface assignments directly from the devices. Then each port channel becomes its own instance group, and each interface assigned (and the portchannel interface) become instances within the group.

    The idea is plausible, but my problem doesnt demand the time-cost to build it out. I figured I'd share it here encase it helps anyone else in the future.

  • Anonymous's avatar
    Anonymous

    So, you want an alarm on the port channel when one of the members goes down? Sounds like a cluster alert.

  • Hi Stuart

    In this instance, the switch has about 20 port-channels with about 30-40 interfaces, so I would need a way to map what interfaces form the port channel before I can think about the alerting.

    But yes, in essence, that is what I am after.  With the alert being Port Channel specific.

    David

  • Anonymous's avatar
    Anonymous

    Ok, so the way to do this in the product today is cluster alerts, unless you find a mib that is indexed by port channel and gives stats about the members (number that are up/down vs. total). With cluster alerts, you'd need a simpler way of managing it so configuring them is not so much of a tedious job. I'm going to bite my tongue before i say API.

  • 37 minutes ago, Stuart Weenig said:

    Ok, so the way to do this in the product today is cluster alerts, unless you find a mib that is indexed by port channel and gives stats about the members (number that are up/down vs. total). With cluster alerts, you'd need a simpler way of managing it so configuring them is not so much of a tedious job. I'm going to bite my tongue before i say API.

    Yep, Product wise, I get that is a feature that can help.  The question was more to the Cisco peeps out there to see if they have found a MIB that can help as I am struggling to find a good one, and one that is more consistent across the product lines.

  • There is no Cisco MIB for etherchannel that I have found (in general -- may be something for some specific device types).  Same for other aggregates, like PPP multilink.  In our experience, the only safe way to detect aggregate issues is to monitor the reported speed of the bundle as the underlying link does NOT necessarily need to be down for an aggregate to lose members (seen it happen when carriers do testing and fail to put the member back into the  bundle). Unfortunately, despite previous requests, the interface datasource still does not report ifSpeed so you cannot set a threshold on that datapoint to detect out-of-spec speeds.

  • To add to this -- there is in fact a pair of datapoints in the new SNMP_Network_Interfaces datasource that could be used to detect aggregate speed problems, a proxy for channel member loss (inInterfaceSpeed and outInterfaceSpeed, set to the reported speed unless overridden by ILPs).  To use this, you would either have to set a threshold on the specific datapoints needed and deal with generic alerts, or add a virtual datapoint with a proper alert message, making future module updates painful.  I really wish that the F/R I posted years ago to allow for LogicModule inheritance was implemented...

    If you use SNMP_Network_Interfaces in any real world environments, be sure your collectors have been tuned to allow more batchscript threads!