0

I am managing some cisco switches in my monitoring software (zabbix), and it provides useful insights that I would like to monitor:

  • Warning on link up / down
  • Warning when ports are on half duplex
  • Warning when ports change it speed

Those thing make total sense on server ports because there are no changes over time, but they are only noise for user ports, because people power off their PCs, sometimes they plug a different laptop that has lower speed ethernet and so on.

I was wondering if there is something I can configure on the switches itself to identify the port with one or another type on the style of "snmp trap link status"

|improve this question
  • 1
    If you don't want to monitor the port, then don't monitor the port. If you don't want to see link traps for specific ports, turn them off per interface -- no snmp trap link-status – Ricky Beam Jul 8 at 15:26
  • It's more about the noise of the notifications, link/speed changes on a non important interface, still, when I want to check the history of a ports it should be doable. – aseques Jul 9 at 7:57
0

At one time, I found traces in the config of a switch maintained by a large service provider:

interface GigabitEthernet 1/0/n
 description someInterfaceDescription [<MonitoringFlags>]

Since description is accessible as ifAlias (1.3.6.1.2.1.31.1.1.1.18), it can be (re)discovered and parsed by the NMS. It will be up to the NMS' admin to define the properties of interest and map it to a set of appropriate flags. Things i can think of

  • unmanaged (i.e. "ignore")
  • managed (i.e. check status of "down/up"), with addons
    • load (also check for load, collecting in/outHCoctetCounters)
    • errors (also collect error stats)
  • alarming (i.e. critical/noncritical interface)
  • speed (intended value - compare against BW property of interface)
  • accounting/billing flags (i.e. to have a daily/weekly/monthly inventory of the customer's high and low speed interfaces.

Some NMS have the notion of an unconnected instead of down port; they'll ignore the port's status for alerting, but will still collect traffic and error stats while the port is up. This comes in very handy for user access ports. That could be another flag to include in ifAlias and parsed by the NMS upon (periodic re)discovery of a port.

Check your NMS and its capabilities and concepts of an interface's status - then derive the set of encoding flags from that.

|improve this answer
  • That's really clever way to accomplish it, thanks – aseques Jul 8 at 10:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.