Loading...
I like those ideas. I would love to see them carry 3X clothing items for larger folks like myself. A SolarWinds Hydro Flask or an insulated coffee mug would be cool too.
User Polls
Looking to create a poll? Post it here!
Should this be a "Bug" or a "Feature Request", what do you think?
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 1.3.6.1.2.1.17.1.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 1.3.6.1.2.1.17.1.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 1.3.6.1.2.1.17.1.4.1.2
You'll get results like this if there are ports in VLAN 1
SNMPv2-SMI::mib-2.17.1.4.1.2.4 = INTEGER: 11
SNMPv2-SMI::mib-2.17.1.4.1.2.5 = INTEGER: 12
SNMPv2-SMI::mib-2.17.1.4.1.2.6 = INTEGER: 13
SNMPv2-SMI::mib-2.17.1.4.1.2.7 = INTEGER: 14
SNMPv2-SMI::mib-2.17.1.4.1.2.8 = INTEGER: 15
SNMPv2-SMI::mib-2.17.1.4.1.2.9 = INTEGER: 16
but if there are no ports in VLAN 1, you get this instead
SNMPv2-SMI::mib-2.17.1.4.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.
Bug (58%)
Feature Request (34%)
Other - please leave comment (6%)
Recent Activity
I loved having to drop things for a network emergency because the network was down... only to find out the owner could not print... lol...
143 total votes
At first I thought it was a Cisco bug also, but in doing it on both a Cisco 2960 running a 12.2(55) IOS and a Cisco 3850 running a 16.3.(x) IOS and having both behave the same way, I realized that Cisco is returning consistent information across multiple switch lines and multiple IOS's. I've since confirmed with Cisco that >all< of their…
I've used Nagios in the past. It can be touchy at times. Mess up a single monitored node and the whole system failed to start.
One product: NAM. It contains the following modules: NPM, NCM, NTA, UDT, IPAM, VNQM, HA. I'm nicely satisfied with using the variables I've set up in Alerts and Actions. I don't hate sleep at all. Thankfully, Solarwinds lets me sleep MUCH better at night because I know the network is running well, has been running well, and that I won't…
Thank you for the reply! Good idea putting a unique ID in a custom field for matching and reconciliation. We are in the initial phases of trying to bring in our isolated environments into Service Now using SolarWinds as the source. Since we don't have direct access, we will probably do a direct SWIS query and export the results to a file to…
(to I didn't want to "like" like this, but I wanted to show support. I'm sorry you went through/go through this. I hope you are in a place where it's no longer the case. I'm gratified that the majority of voices here on THWACK are supportive and inclusive, but I know that's not always the case. Thank you for staying strong and giving your voice…
-
solaruser99
Joined Jun 13, 2019
-
jfaldmo
Joined Jun 11, 2019
-
jpgarcia
Joined Jun 10, 2019