Just wondering if refactoring the code by creating Dot1dSnmpPeer, CiscoVTPPeer, Dot1QSnmpPeer (together with RSTPSnmpPeer, MSTPSnmpPeer, SPBSnmpPeer) wouldn't help ???

Each of these class/interfaces would hold the behavior to help in both Bridge and STP discovery .....

By the way these slides (from the YANG W.G.) could help in structuring the code :

https://www.iab.org/wp-content/IAB-uploads/2013/01/mholness-8021-YANG-Summary.pdf

Please find trackers for both Q-BRIDGE-MIB::dot1qVlanStaticTable and Q-BRIDGE-MIB::dot1qVlanCurrentTable in pull request 1439 (https://github.com/OpenNMS/opennms/pull/1439).

Q-BRIDGE-MIB::dot1qVlanStaticTable would be needed to associate vlannames to vlan id

Q-BRIDGE-MIB::dot1qVlanCurrentTable would be needed on nodes which do not have the same values for fdbid(s) and vlanid(s)

The two tables may also be used to associate vlans to bridgeelements in a network where vdp/cisco conventions are not valid.

The Vlan information is not needed for topology discovery when using qanlking dot1dq BFT.
By the way it can be a useful information.
This can be done on the next release, were I'd like to change some information.
If you want just dot1q Vlan data you can use the snmpassetadapter and put all the data into the description.

Hi Antonio, I did some work around dot1q bridge discovering (with associated test snmpwalk files . Would you be interested ? if yes please tell from which branch/tag you would then accept a Pull request.

J.-M.
PS : as far as I know, enlinkd is only using cisco conventions for bridge discovery now, so (from the start) vlan informations are missing in the bridgeElement table for pure (non-cdp) dot1q nodes. So the idea was first to add a new "NodeDiscoveryQBridge" class ...