Interface error report filtered by config keywords or interface type

LarryJRogers​, are you familiar with SDK ( and its many canned reports)?  The SWQL queries you might build there can be used in a Custom Report or simply exporedt to CSV for use with Excel.  They are many and varied.

For starters the built-in NCM.Interfaces SWQL query table has a LOT of information that might be useful for your filtering and reporting needs.  That query looks like this:

SELECT InterfaceIndex, InterfaceDescription, InterfaceName, InterfaceAlias, InterfaceType, InterfaceTypeName, InterfaceTypeDescription, InterfaceSpeed, MACAddress, AdminStatus, OperStatus, InterfaceMTU, LastChange, PhysicalInterface, Promiscuous, InterfaceID, NodeID, LastDiscovery, FirstDiscovery, Missing, VLANID, PortStatus, VlanType, InterfaceHighSpeed

FROM NCM.Interfaces

There are also a good number of pre-built Orion.NPM.Interface queries from which you might select:

The Orion.NPM.Interfaces query from above offers a LOT of data from which to sort and generate reports:

SELECT NodeID, InterfaceID, ObjectSubType, Name, Index, Icon, Type, TypeName, TypeDescription, Speed, MTU, LastChange, PhysicalAddress, AdminStatus, OperStatus, StatusIcon, InBandwidth, OutBandwidth, Caption, FullName, Outbps, Inbps, Bps, OutPercentUtil, InPercentUtil, PercentUtil, OutPps, InPps, InPktSize, OutPktSize, OutUcastPps, OutMcastPps, InUcastPps, InMcastPps, InDiscardsThisHour, InDiscardsToday, InErrorsThisHour, InErrorsToday, OutDiscardsThisHour, OutDiscardsToday, OutErrorsThisHour, OutErrorsToday, CRCAlignErrorsThisHour, CRCAlignErrorsToday, LateCollisionsThisHour, LateCollisionsToday, MaxInBpsToday, MaxInBpsTime, MaxOutBpsToday, MaxOutBpsTime, Counter64, LastSync, Alias, IfName, Severity, CustomBandwidth, CustomPollerLastStatisticsPoll, PollInterval, NextPoll, RediscoveryInterval, NextRediscovery, StatCollection, UnPluggable, InterfaceSpeed, InterfaceCaption, InterfaceType, InterfaceSubType, MAC, InterfaceName, InterfaceIcon, InterfaceTypeName, AdminStatusLED, OperStatusLED, InterfaceAlias, InterfaceIndex, InterfaceLastChange, InterfaceMTU, InterfaceTypeDescription, OrionIdPrefix, OrionIdColumn, DuplexMode, SkippedPollingCycles, MinutesSinceLastSync, Status, InterfaceResponding, Description, DetailsUrl, ObsoleteDataCurrentSettingValue, ObsoleteDataFeatureStatus, HasObsoleteData

FROM Orion.NPM.Interfaces

Then there are the many pre-built Reports within NPM that show Interface info:

You could start with one of the canned reports and edit a copy of it and tweak it until it does exactly what you need. 

Thank you for the response, rschroeder.

I am not familiar with the sdk. I guess I didnt state my case clearly or I'm simply not seeing the forest because of all the trees.

Would you mind telling me how you accomplished creating the report labeled Critical Core, Distribution and Port-Channeled Interfaces? Is it filtered without using an interface alias or SW custom field?

Type 161 interfaces are good as they do not exist unless they were actually created in the switch configuration. Type 6 is a problem because you get all ethernet ports. Stackports are an issue because type 53 will give you all ppp interfaces, even internal links for items such as F5 communication or vpn connections and I am not concerned about those. In my limited vision, I do not see how you can use any or any combination of the variables you presented to limit the report to only links I care about without having the engineer properly add a descriptor whether on the interface description or SW custom field.

If I can filter off of port configuration, then I am filtering off exact commands that have to exist for that port to work. I can look for "ip address" to identify only those type 6 interfaces for my uplinks. It will ignore all access ports without an ip address configured. and so on for trunk, stackports, etc.

My Critical Core, Distribution and Port-Channeled Interfaces Report was originally created  around 2006 using Report Writer and manually selecting ports that met my definition of "critical" to the business.  Today I'd rebuild it using the Web GUI for building a new report, and find a way to select switches and ports through logic instead of manually adding them to this report. 

My network has grown a lot since the early 2000's, and changed in many ways that obsoleted my early Report:

• I have many fewer physical servers and many more VMs hosted in UCS environments.  That means if I monitor the port-channels between my ACI environment and the UCS chasses I have much less monitoring and selecting of interfaces to do.
• I have many more sites and switches in the organization (88 network rooms went to 250), meaning I have more port-channeled uplink/downlink ports whose physical condition must be reported lest I halve the amount of throughput and resilience any individual switch or stack can rely upon.  For this reason I must monitoring members of LACP or 802.3AD port-channels instead of only the channel groups themselves.  I want to know if one of the two uplinks between an access switch and its upstream distribution switch have lost link--that means I'm almost experiencing an outage, and one more link failure isolates everyone on that switch.

A concern with using Interface Type in a Critical Interfaces report is that when link is lost on an uplink port (that was participating in a port-channel) it looks like it would change type, and then not be counted as an 802.3AD port anymore.  That means no alert for it since it would fall out of that group in NPM's mind.  I think.

So then I'm back to selecting interfaces manually to be monitored in that Critical Interfaces report.  And that's not efficient, even though it's better than NOT being made aware of losing half of a port-channel's resilience and throughput.