Brocade ICX7750 wrong VLANs on Port shown

Help
1

Our Core Switch is a two unit Stack of two Brocade (Ruckus) ICX7750. I am using SNMP v2c.

My main problem is, that the vlan information is wrong for the ports. I don’t know if there are any other information that do not match. However - when I compare the port - vlans with the actual switch config, they don’t match at all.

At the begining, I did not enable MIBs, but after doing so, there was no MIB associated with that Switch Stack - even when I deleted it in Librenms and re-created it.

I already tried to change Port Assotiaton Mode to any other than ifIndex. That did change the VLAN information per port, but sadly never to the correct values.

I have a Port with two tagged Vlans (10 and 30). In librenms, depending on the Port Assotioation Mode, it shows me VLAN 1 or VLANS:8 (showing me that the port were in 8 vlans, but not in the ones it should be)

First I thought that might come from old MIB-Info until I recognized that MIBs were not enabled yet on that device. Where does librenms take the information from, when NOT using MIBs?

How can this issue be corrected?

Many thanks in advance,
Rainer

2

I’m sorry, I can’t be helpful, however, if you find a solution, I would be interested in knowing it.

3

If somebody could explain how the discovery process works (without MIB) I might find out some more information. The strange thing is, that we have lot’s of brocade / ironware switches running in our network, but currently it seems the problem only exists with the ICX7750. So if I had a clue “climb down” the process, I might be able to find out what’s different to my other switches. (Finally it could be an issue with the switch firmware, but updating our core stack just in order to find that out is not the way I wanna go)

Thanks,
Rainer

4

Hi

MIB support is something else. Enable it or not does not impact standard polling.

That being said, you can install a test instance of LibreNMS on another machine, and start playing with it.

The VLAN discovery process takes place here :
includes/discovery/vlans.inc.php
includes/discovery/vlans/*.inc.conf

As no file seems to handle the Ruckus case, then the default Q-BRIDGE mib is certainly used. So you could start debugging this and try to understand why the device is not mapped correctly…
Could be

  • Device is not compliant to the MIB
  • Bugs in the code
  • Somewhere in between the two first possibilities :slight_smile:

Bye
PipoCanaja

5

Hi

Thanks for the response. But I didn’t get it completely yet:

So “MIB Support” is something else → So what does it, when enabled?

Ok - but are we now back at MIB support, or is standard polling just using a special type of mib file? Because, Ruckus used to be Brocade and even Foundry before - and there are some foundry mib files under the mibs folder.

How would you start debugging? Just with analyzing the logs, or is there any thin IDE that could be used to do that?

Thanks,
Rainer

6

Hello

MIB support is something completely different, and is not at all involved in standard polling, like VLANs etc.
So basically, debug mode (./discovery.php -h -v -d and ./poller.php -h -v -d ) should be a start.
The files I already mentionned are the one that are most probably involved in the process, so you could start debugging them to check how it behaves on your devices. If you have another switch that works correctly (another brand) you can start comparing as well.
You should also snmpwalk the QBridge MIB on Ruckus device as well as standard and look at the differences.
There is no “standard” receipe but these points should put you on the way.

Bye

7

hi there,

thanks, is there any link you could provide where I find some details explaining difference between standard polling and MIB support? That’s still somehow confusing to me…

Thanks,
Rainer

8

Hi

Just forget about MIB Support … It is absolutely not related to standard polling of devices. MIB Support would allow you to graph an arbitrary OID.

PipoCanaja