A quick and dirty fix is on tracks here :
sorry but before the change in librenms to stp was made, everything was ok
why librenms send wrong community?
Because the code in LibreNMS is evolving, and the new implementation covers a feature that is supported by some vendors (at least Cisco) and Huawei does not accept it.
So, as already said, a few options:
- Fixing the code for LibreNMS to workaround this Huawei behaviour (this is started)
- Ask Huawei to allow disabling this behaviour.
LibreNMS is community based, so it evolves, improves, only with the help of us, you and me.
but this is not a problem only Huawei, stp discovery ends with an error for edgecore, for example. the problem is why librenms sends the wrong community
I tried to explain you. It does not send the wrong community, this is the way âcontextsâ work.
You add the context name (here the VLAN-ID) to the community. Most of the other vendors will just ignore this, and will not blacklist. Huawei does, and only the combination of âunsupported contextsâ and âauto blacklistâ ends up to the problem.
So fixing LNMS code will fix the âunsupported contextsâ attempt. And opening a case at Huawei would fix âauto blacklistâ by adding an option to disable it.
1 Like
Current master now avoids using contexts in anything other than Cisco. So you should see improvement.
1 Like
Iâm looking for information about the snmp community @ <VLAN #>, but it seems to be just a Cisco affair? or am I looking wrong?
Thatâs also what was found, which explains why only Cisco code is now doing this for STP.
1 Like
Thank you so much. I will try it and report back if it is for now fixed.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.