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}

Der Filter für das Management Interface mit dem Index 2 ist :

{#SNMPINDEX} does not match [2]\b

Natürlich hatte ich erst nur die Zahl 2 da drin stehen.
Dann hat er aber auch alles weggeputzt was die Zahl 2 enthält.
Erklärung:

[2]       finde das Zeichen 2 (ich habe eine Menge angegeben mit nur einem Wert
\b        Wortende! Keine weiteren Zeichen!

Man könnte auch das hier nehmen, das bedeutet dann

\b[2]\b   Wortanfang! Das einzelne Zeichen 2! Wortende!

Der Filter für alles ab 1.000 sieht so aus:

{#SNMPINDEX} does not match [1-9]\d{3,}

Erklärung:

[1-9]    finde das Zeichen 1,2,3,4,5,6,7,8 oder 9 (0 ist ausgeklammert, nichts sollte mit 0 anfangen)
\d       finde danach(!) eine Zahl
{3,}     und davon 3 Stück oder mehr

Ergo muss es mindestens eine 4-stellige Zahl sein, Zahlen mit führender 0 werden ignoriert.

Beim nächsten Discovery flogen so meine nicht gewollten Interfaces raus:

Quellen

Die beiden Links brachten mich auf die richtige Idee:

Kommentare

Loading comments...