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.
no snmp trap link-status
– Ricky Beam Jul 8 at 15:26