Zabbix SNMP Netzwerk Interface oder VLAN beim Discovery Filtern

Changelog:

• 03.07.2024 erste Version

---

Vorwort

Bei einem Kunden erstelle ich gerade ein Template für einen recht exotischen Switch.
Beim Anpassen der Discovery Rule für die Ethernet-Ports ist mir - wieder einmal - aufgefallen das auch sämtliche interne Schnittstellen und die VLANs als einzelne Interfaces mit aufgezählt werden.
Die Nummer dieser Interfaces sind aber alle größer als 999, das habe ich als Lösungsansatz genommen.

---

Erklärung des Lösungsansatzes

Eine typische Discovery Regel für Netzwerkschnittstellen sieht so aus:

und basiert darauf das man eine OID vorgibt hinter der dann die einzelnen Interfaces aufgezählt werden.
Wenn man einen snmpwalk mit der im Screenshot sichtbaren OID 1.3.6.1.2.1.2.2.1.8 durchführt, gibt es zum Beispiel das hier zurück:

.1.3.6.1.2.1.2.2.1.8.2 = INTEGER: up(1)
.1.3.6.1.2.1.2.2.1.8.192 = INTEGER: up(1)
.1.3.6.1.2.1.2.2.1.8.193 = INTEGER: up(1)
.1.3.6.1.2.1.2.2.1.8.194 = INTEGER: up(1)
.1.3.6.1.2.1.2.2.1.8.195 = INTEGER: up(1)
.1.3.6.1.2.1.2.2.1.8.196 = INTEGER: up(1)
.1.3.6.1.2.1.2.2.1.8.197 = INTEGER: down(2)
.1.3.6.1.2.1.2.2.1.8.198 = INTEGER: up(1)
.1.3.6.1.2.1.2.2.1.8.199 = INTEGER: down(2)
.1.3.6.1.2.1.2.2.1.8.200 = INTEGER: up(1)
.1.3.6.1.2.1.2.2.1.8.201 = INTEGER: down(2)
.1.3.6.1.2.1.2.2.1.8.202 = INTEGER: down(2)
.1.3.6.1.2.1.2.2.1.8.203 = INTEGER: down(2)
.1.3.6.1.2.1.2.2.1.8.204 = INTEGER: down(2)
.1.3.6.1.2.1.2.2.1.8.205 = INTEGER: down(2)
.1.3.6.1.2.1.2.2.1.8.206 = INTEGER: down(2)
.1.3.6.1.2.1.2.2.1.8.207 = INTEGER: down(2)
.1.3.6.1.2.1.2.2.1.8.208 = INTEGER: down(2)
.1.3.6.1.2.1.2.2.1.8.209 = INTEGER: down(2)
.1.3.6.1.2.1.2.2.1.8.210 = INTEGER: down(2)
.1.3.6.1.2.1.2.2.1.8.211 = INTEGER: down(2)
.1.3.6.1.2.1.2.2.1.8.212 = INTEGER: down(2)
.1.3.6.1.2.1.2.2.1.8.213 = INTEGER: down(2)
.1.3.6.1.2.1.2.2.1.8.214 = INTEGER: down(2)
.1.3.6.1.2.1.2.2.1.8.215 = INTEGER: down(2)
.1.3.6.1.2.1.2.2.1.8.219 = INTEGER: down(2)
.1.3.6.1.2.1.2.2.1.8.220 = INTEGER: down(2)
.1.3.6.1.2.1.2.2.1.8.221 = INTEGER: down(2)
.1.3.6.1.2.1.2.2.1.8.222 = INTEGER: down(2)
.1.3.6.1.2.1.2.2.1.8.223 = INTEGER: up(1)
.1.3.6.1.2.1.2.2.1.8.2049 = INTEGER: down(2)
.1.3.6.1.2.1.2.2.1.8.3048 = INTEGER: up(1)
.1.3.6.1.2.1.2.2.1.8.3058 = INTEGER: up(1)
.1.3.6.1.2.1.2.2.1.8.3068 = INTEGER: up(1)
.1.3.6.1.2.1.2.2.1.8.3079 = INTEGER: up(1)
.1.3.6.1.2.1.2.2.1.8.3087 = INTEGER: up(1)
.1.3.6.1.2.1.2.2.1.8.3097 = INTEGER: up(1)
.1.3.6.1.2.1.2.2.1.8.3098 = INTEGER: up(1)
.1.3.6.1.2.1.2.2.1.8.3099 = INTEGER: up(1)
.1.3.6.1.2.1.2.2.1.8.3100 = INTEGER: up(1)
.1.3.6.1.2.1.2.2.1.8.3108 = INTEGER: up(1)
.1.3.6.1.2.1.2.2.1.8.4038 = INTEGER: up(1)
.1.3.6.1.2.1.2.2.1.8.6099 = INTEGER: up(1)
.1.3.6.1.2.1.2.2.1.8.6100 = INTEGER: up(1)

Er findet also diverse Schnittstellen dahinter. Manchmal mit fortlaufenden Nummern, manchmal ein anderes System.
Die Nummer dahinter wird später in den Item Prototypes verwendet, dort als {#SNMPINDEX}:

Bei diesem Model hier ist nun .2 das - virtuelle - Management Interface und alles was vierstellig ist (also über 1.000) sind VLANs.
Je nach Modell spucken diese Schnittstellen eh keine Werte aus, bei meinem Modell hier gibt es für den Index 2 nur Fehler und bei allen VLANs sind die Werte immer 0.
Meine schnelle - schmutzige - Idee in dem Template war, dieser einfach anhand des {#SNMPINDEX} heraus zu filtern (anstatt die Macros zu pflegen).

---

Discovery Rule filtern anhand {#SNMPINDEX}

aa