Configure snmp to show vlans in Q-BRIDGE-MIB

Installing and Using OpenWrt Network and Wireless Configuration
1

Usage szenario:

  • segmented network,
  • about 20 vlans
  • about 10 venerable HP-1810 / 1820 switches,
  • about 6 ... 10 OpenWRT AP
  • openWRT on x86 as router
  • SNMP web GUI observium to keep track of the beast

Configured my 20 vlans on the router now, but see they don't show up in SNMP.

As far as I can figure out, qBridgeMIB is located at .1.3.6.1.2.1.17.7
e.g. on a HP switch, it displays as

.1.3.6.1.2.1.17.7.1.4.3.1.1.1
Name/OID: dot1qVlanStaticName.578; Value (OctetString): cctv
Name/OID: dot1qVlanStaticName.4067; Value (OctetString): test3

On openWRT, this path is empty. (snmpd, standard config)
However, at least I can find the vlans in the ifTable of IF-MIB .1.3.6.1.2.1.2.2,
so they are listet as they were plain ethernet devices.

Name/OID: ifDescr.20; Value (OctetString): bond-bond0
Name/OID: ifDescr.22; Value (OctetString): bond-bond0.20
Name/OID: ifDescr.23; Value (OctetString): bond-bond0.21

/etc/config$ opkg list-installed | grep snmp
libnetsnmp - 5.9.1-7
luci-app-snmpd - git-24.322.79771-ee4c08d
snmp-mibs - 5.9.1-7
snmp-utils - 5.9.1-7
snmpd - 5.9.1-7

In /etc/config/snmpd I can find some engineid stanza.
Smells like there might be a door to just enable other features, but I could not find any documentation yet.

There also is an exec stanza, but I think this only is for scalar values, right?

here (and in some linux-configs) we may find pass and pass_persist

'pass' is a more general mechanism for implementing arbitrary MIB
objects. The specified command will be invoked for any request within
the named MIB subtree, and passed details of the requested OID. It
should return the information relevant to the requested OID.

Might this be a proper hook to reinvent the wheel?
But do we have to do so?
And is the the pass and pass_persist - syntax forwarded by the uci-machine?

In the forum here, I found mentioned by @NPeca75 that he has a "few custom script for q-bridge-mib emulation for vlans"

May be that's right what I'm looking for :wink: :innocent: ?

2

hi @wolfgangr

my solution was:

pass_persist .1.3.6.1.2.1.17.1.4.1.2 ${SCRDIR}/s_ifindex
pass_persist .1.3.6.1.2.1.17.7.1.1.1 ${SCRDIR}/s_vlansv
pass_persist .1.3.6.1.2.1.17.7.1.2.2.1.2 ${SCRDIR}/${FDB}
pass_persist .1.3.6.1.2.1.17.7.1.4.2.1.4 ${SCRDIR}/s_vlansm
pass_persist .1.3.6.1.2.1.17.7.1.4.2.1.5 ${SCRDIR}/s_vlansu
pass_persist .1.3.6.1.2.1.17.7.1.4.3.1.1 ${SCRDIR}/s_vlansNames

and the external programs are pure ASH scripts

problem is that OWRT operate on

  1. swconfig device
  2. DSA device

so, there was no "normal" way to implement snmp/vlans and snmp/fdb. Script need to determine first which kind of device is this, and then collect info & send to snmp

maybe once all device migrate to DSA, it could be done in normal way

1 Like
3

but it is working :slight_smile:
so nothing stops you to implement your own solution

lnms

4

so you think there is no point in posting your ASH skripts :innocent:
Never mind....

I think I got the point.
pass_persist as I see is supported.
Details is RTFM e.g. here
http://www.net-snmp.org/docs/man/snmpd.conf.html
I assume that my OpenWrt 23.05.5 runs on DSA.
I think I'll figure it out where to pull proper data.

Meanwhile I've figured out that the translation from uci config files to genuine 'close-to-metal-format' is performed here /etc/init.d/snmpd. Nothing very obscure there, and even open to 'improvement'.

But looking at your report, I hope that's not required - as long as pass_persist support is still enabled in build config of snmpd.

5

yes, you are right
for example, for FDB table, i need to use full version of sort, which is not included in standard OWRT
furthermore, i am using single SSID for multiple vlans (per password) which require predictable interface names, from this point of view, scripting is not so hard, but it is not universal for any scenario
then, there are 2 ways of setting up vlans on non-swconfig device

  1. put all vlans in one bridge (bridge filtering, my prefered way)
  2. put random vlans on top of interface, then put hese vlans in bridge

my solution covers only case 1
so no, there is no use of publishing half working solution

6

I'll try it on my router first, which is running OpenWRT on x86, so no space restriction yet.
I think for the AP', I'll try a extroot on network, maybe with sshfs.

there are 2 ways of setting up vlans on non-swconfig device

To be honest, I don't even get the point where this matches my setting :man_facepalming:

Between my router and my switches, I have an aggregated link on top of 4x1Gbit ethernet. This lists in the devices, beneath br-lan, so may be it's "some kind of" a bridge?

On top of that LAG aka trunk are the VLANs.
On each VLAN is a dedicated IP-Net. So the router by default manages traffic between VLANs, there is no layer 2 bridging between those.

My plan is to assign traffic by SSID, by passphrase and may be in some cases even by mac to the VLANs. So they have to be passed thru the switches to the access points.

there is no use of publishing half working solution

I think I slowly begin to understand and agree.

7

Still exploring/extending/gradually implementing my (somewhat functional) test setup ....

Could it be thet it's not a "either/or"-question, but more some kind of "right thing in the right place"?

May it be that this is what's supposed to happen at OSI-layer-3-or-above (i.e. aplication level proxy) nodes?

  • the router (including firewall), where all traffic is handled that does not find a shorter way at OSI 2
  • the admin proxy, where I may dial in with ssh just to reach out to the edge gadgets without requiring firewall forwarding
  • the admin proxy where I may redirect https to dumb http-only gadgets
  • some IoT processing services, receiving sensor data on one VLAN and user acces on another one
  • the VCR-server, receiving cctv input over 4x1GB and serving to users over another Gbit
  • PBX service, talking to phones in one VLAN and to the world over WAN
  • and (not really) dumb openWrt WLAN access points, delivering traffic right into the (VLAN) pathway it belongs to, without bothering the router and the the LAN towards its node

Large throughput variants will have a (mainboard)-gbit ethernet plus 2 or 4 extra Gbit-ethernets trunked. VLANs may be distributed to those - essentially at max 2 - devices per host.

This is stuff typically running on linux (openwrt for simple things, plain debian in my case for not so standard stuff) - and this is where imho we need (better) 802.1Q snmp support for.

I think this is what happens on the switches: distributing VLANs in the area.
In my case, 3x 24 Port HP 1810 series for the "backbone", a dozen of 8 port HPE 1820 series. And for very remote places, a couple of TL-SG108E - no chance to get SNMP info, but at least, we can pick off some VLANs from upstream trunk.

Essence for now:
In terms of SNMP supprot for 802.1q,

  • we forget the TL-SG108E
  • the HP 1810 and HPE 1820 switcher deliver quite fine
  • we need to focus on openWrt (central router/firewall and WLAN access points)
  • and plain debian linux (application servers, delivering OSI layer 3 ... 7 connectivity)
8

May be the solution is closer as we think?

There is a perl skript /usr/bin/snmp-bridge-mib obviously part of net-snmp package, installed and executables right on some of my machines...

9

mhhmmm... it's not that simple than it looked at first glance...

  • this script requires loads of cpan modules (aka perl libs) not available in openWrt. I might compile those on my x86, but then I end up with a a solution I cannot migrate to my access points.
  • obviously most of the sys paths are not available on my box.
    looks like this script is for a different (deprecated?) architecture
  • it does not even run on pristine debian
  • with ~1100 lines of code, it's hard to understand and adopt

So I decided to keep it as inspiration and start anew from zero.
Took a day for the first hello world level success experience on snmp.
Seems like on debian, the OID-tree ist severley checked, gracelessly silently dropping any test queries not matching the standard.

Glad to see that on openWrt, all those simple examples run like a charm.

Regarding the DSA issue, I found that x86 does NOT have DSA at all, the DAP-X1860 AP however have it.
Well, I don't see the use of a switched architecture for some singe AP supposed to forward traffic to it's single GBit ethernet port, anyway.
Gleaning over the kernel DAP docs, I understand that 802.1q-VLAN is the "last ressort" for sturdy hadware - always available.

Sounds fine: One language to rule them all:

  • my HP switches
  • my openWrt x86 router
  • a couple of openWrt APs on tiny hardware
  • some servers running OSI-7 application level gateways with two (or more) legs in different vlans

... if it were not that the work planned for a day eats up a whole week now...

10

In the end, I ended up with not much less than the 1000 lines of code, either:

At least it runs on device (x86) without any CPAN modules - just the perl package from opkg.
I think that by stripping comments and development stuff , and maybe some refactoring, we might strip it down by some 80 %.

I also added two extended views to observium:

While this is not particularly related to openWRT, I hope that it will assist me in deploying my openWRT wireless access points in the VLAN environment.

So, there will be occasion to test Q-BRIDGE-MIB script on other platform as well - first of all D-LINK DAP-X1860.