So, I've been working on an issue we noticed that at first I thought affected only a few of our switches, but as time progressed I was able to identify 4% of them as being affected. I finally had a breakthrough and was able to figure out what the cause was, and replicate it not only on the same switch platform (Cisco 3850) but on another platform/IOS also (Cisco 2960). After figuring out what the issue was and documenting it pretty well, I get a message back from tech support saying "I've discussed your findings with other members of our team to discuss if there are any other options that we have to resolve your issue. Unfortunately what you're wanting is currently not a feature of the product. You can submit a Feature Request but there is no timeline on if or when it will be implemented.". I found this to be rather insulting, so I'm curious what others think about whether this is a bug, or a feature request? And, it might be affecting you, but you just don't know it yet!!
While trying to figure out why something was missing in a report, one of the guys here noticed that on at least one switch the "VLAN" box was missing from "List Resources" on a Node Details page. You've quite likely seen it, nestled between the "Topology" and the interfaces.
So, I open a ticket trying to figure out the issue. After the exchange of some info, they tell me that the switches in question are not returning info for a critical MIB, dot1dBasePortIfIndex, who's OID is 184.108.40.206.220.127.116.11.4.1.2. I'm confused as to why this is, because there is no commonality that I can find, its the same switches, same IOS, same basic config as far as SNMP goes and other critical things. Having problems finding out what is going on! So I open a ticket with Cisco thinking I've run into a bug on their platform. Long story short, in working with them I figure out more information. This MIB returns a list of interface indexes that are in that VLAN on the switch. A light goes off in my head wondering how the interfaces are configured in terms of VLANs. All of a sudden I find my commonality. None of the switches in question have any interfaces in VLAN 1, they're all either statically assigned to another VLAN, or don't have VLAN 1 permitted on any trunk links. For those not familiar with this, if you do an SNMP scan on a Cisco switch using just the community string, such as "public", you get information returned for VLAN 1 if the information is VLAN specific, which in this case it was. So, on one of the troublesome switches, all the ports were in VLAN 144, so I run the same scan on "public@144", which tells it I want the same information for VLAN 144 instead, which instead of an error I get the indexes of all my interfaces!! Wow, I just cracked the case wide open, right?!
So, I decide to go the extra couple miles and do some more testing. To me, if its only this IOS or this switch platform that behaves this way, its a bug in the IOS. However, if the behavior is consistent across multiple platforms, or even vendors, then its Solarwinds misinterpreting the info. ie: the test their using "if the dot1dBasePortIfIndex returns information on VLAN 1, assign the VLAN poller."
So, I first test on an Arista switch. So far in my testing, the Arista switch returns the indexes of >ALL< the interfaces on the switch when queried with a simple community string with no VLAN specified. This confused me a little bit, because on the Cisco 3850 you only get back the interfaces that are in VLAN 1, not a list of all interfaces, but ok. Different results.
I then pull out a 2960 switch. Unlike our 3850's running 16.3.X, this one is running 12.2(50). I'm pretty much expecting it to behave like the Arista, which would land the problem on Cisco's lap. However, the 2960, running a much older IOS, behaves exactly like the 3850. So at least for the Cisco platform(s), the behavior seems consistent and able to easily replicate! Surprised me, but with consistent information coming back that is easy to replicate means that its Solarwinds interpreting the information wrong, not Cisco being inconsistent in sending the information.
Furthermore, in thinking about it more, I think the Cisco behavior is correct and the Arista behavior is not. Why? Simple, if you want a list of the interfaces in VLAN 1, you scan that MIB for the information. If no interfaces are in VLAN 1, you shouldn't get anything back. That's what Cisco is doing, but Arista sends back a list of every interface.
You can find more information at my post here - https://thwack.solarwinds.com/thread/128329
So, Bug or Feature Request?
**** ADDITIONAL INFO TO DO YOUR OWN TESTING BELOW ****
If you want to replicate these results yourself, to find out which (if any) of your nodes are affected by this, there is a SWQL query at the link above that can help you find the nodes. Note that query is set up for 3850's, but this problem can affect ALL Cisco switch platforms I've since found out. If you want to play around and see it for yourself, the easiest way is to configure up a switch with "switchport access vlan X" and "switchport mode access" (if needed) on all ports. Optionally you can do a "switchport trunk allowed vlans 5,10,15" and just don't include 1 in the list of VLANs.
If you want to see the results of the SNMP scan that Solarwinds does, you can either use their SNMPWalk and scan the OID 18.104.22.168.22.214.171.124.4.1.2, or use SNMPWalk from a unix box to do the same. Something like this works, just adjust for your own IP and community string.
snmpwalk -v 2c -c mycommunitystring 192.168.1.250 126.96.36.199.188.8.131.52.4.1.2
You'll get results like this if there are ports in VLAN 1
SNMPv2-SMI::mib-184.108.40.206.1.2.4 = INTEGER: 11
SNMPv2-SMI::mib-220.127.116.11.1.2.5 = INTEGER: 12
SNMPv2-SMI::mib-18.104.22.168.1.2.6 = INTEGER: 13
SNMPv2-SMI::mib-22.214.171.124.1.2.7 = INTEGER: 14
SNMPv2-SMI::mib-126.96.36.199.1.2.8 = INTEGER: 15
SNMPv2-SMI::mib-188.8.131.52.1.2.9 = INTEGER: 16
but if there are no ports in VLAN 1, you get this instead
SNMPv2-SMI::mib-184.108.40.206.1.2 = No Such Instance currently exists at this OID
The "INTEGER: 11" and such above are indexes to the interfaces on the switch. If you want to see what they correspond to, you can do a SNMP walk of the "ifName" MIB, like this:
snmpwalk -v 2c -c mycommunitystring 192.168.1.250 ifName
and you should get results like this:
IF-MIB::ifName.11 = STRING: Gi1/0/4
IF-MIB::ifName.12 = STRING: Gi1/0/5
IF-MIB::ifName.13 = STRING: Gi1/0/6
IF-MIB::ifName.14 = STRING: Gi1/0/7
IF-MIB::ifName.15 = STRING: Gi1/0/8
IF-MIB::ifName.16 = STRING: Gi1/0/9
I've discussed your findings with other members of our team to discuss if there are any other options that we have to resolve your issue. Unfortunately what you're wanting is currently not a feature of the product. You can submit a Feature Request but there is no timeline on if or when it will be implemented.