SNMP Optimierung unter JunOS

SNMP ist für viele Network Management Systeme (NMS) die essentielle und oftmals einzige Schnittstelle. Durch die Vielzahl von Informationen die man über SNMP auslesen kann, ist es in der Praxis oftmals der Fall, dass die Performance (Antwortzeiten, Laufzeit eines Abfragezyklus) zu wünschen übrig lässt. Dieser Artikel beschreibt wie man unter JunOS Abhilfe schaffen kann und welche Dinge grundsätzlich zu beachten sind.

01: Allgemeines und Ursachen

Folgende Ursachen für mangelhafte SMMP-Performance sind in freier Wildbahn zu beobachten:

  1. Geringe CPU Leistung: Gerade bei „Embedded“ Devices wie Switches oder Routern sind nicht immer die besten und schnellsten CPUs verbaut, da es beim Design dieser Geräte oftmals neben Performance auch auf Stückkosten und hohe Zuverlässigkeit ankommt.
    Weiterhin wird dem SNMP Prozess meistens noch eine sehr niedrige Priorität eingeräumt, da er in der Regel nur zum Auslesen (und sehr selten zum Konfigurieren) verwendet wird, was durchaus im Vergleich zum eigentlichen Verwendungszweck eines Systems („Routen lernen“, „Pakete transportieren“, „XYZ bereitstellen“) weniger wichtig ist.
  2. Hohe Latenzen im WAN: Hohe Antwortzeiten (Round Trips) im WAN sind vor allem bei „serialisierten“ SNMP-Anfragen ein echter Performance Killer, da schlimmstenfalls immer nur ein Gerät mit einer SNMP-Anfrage gleichzeitig behandelt wird.
  3. Schlechte bis miserable SNMP Implementierungen
    Manche Hersteller behandeln ihre SNMP-Implementierung wie manche Menschen ihren Hausmüll nicht behandeln würden. Gerade bei proprietären Implementierungen (zum Glück wird die Zahl dank embedded Linux/Unix deutlich geringer) sind anders nicht erklärbare schlechte Performancewerte zu beobachten. Aus diesem Grund rät es sich immer, bevor solche Geräte (z.B. USV-Anlagen) massenhaft beschafft und installiert werden neben dem reinen Funktionstest, auch mal einen Blick auf die Performance zu werfen.

02: Performance Tuning seitens des NMS

Sollte man Einfluss auf das NMS nehmen können so empfiehlt Juniper folgende Maßnahmen[001].

Kurz zusammengefasst steht da:

  1. Pollingverfahren von spaltenbasiert auf zeilenbasiert umstellen.
  2. Komplexität (Bindings) der angefragte Objekte reduzieren.
  3. GetBulk Anfragen vermeiden
  4. Timeouts und Intervalle vergrößern
  5. SNMP Anfragen shapen um die RouteEngine (RE) nicht zu überlasten.

Unser Artikel richtet sich nicht an Softwareentwickler und als „Implementierer“ hat man in der Regel keinen oder nur wenig Einfluss auf die Verfahren, so dass diese Tipps von Juniper sicherlich gut gemeint aber in der Praxis eher selten Anwendung finden können. Wir empfehlen aber noch folgende, einfache Optimierungsmaßname:

  1. Parallelisieren der Anfragen
    Gerade wenn man mehrere Geräte abfragen muss, kann man dies getrost parallel machen da in der Regel seitens der NMS-CPU genug Ressourcen vorhanden sind und der Flaschenhals meistens seitens des zu pollenden Gerätes liegt. Ein Paradebeispiel hierfür ist das Observium „NMS“, welches Geräteanfragen massiv parallel ausführen kann und somit einzelne Langläufer nicht so arg ins Gewicht fallen.

03: Performance Tuning seitens JunOS

Deutlich praxisrelevanter ist jedoch folgender Artikel[002], der Tuningmaßnahmen seitens JunOS beschreibt:

  1. Option stats-cache-lifetime
    Die hidden option „set snmp stats-cache-lifetime <seconds>“ kann Performanceverbesserungen um bis zu 20% in der Praxis erreichen.
    Wichtig: Man kann auf der EX-Plattform nicht nur zwischen dem spezifizierten Werten 30-60 Sekunden sondern auch beispielsweise 90 Sekunden angeben. Bei noch größeren Werten (z.B. 300 Sekunden) ist nach dem Commit jedoch zu testen ob dieser Wert auch wirklich in die Config übernommen wurde.
  2. Filtern doppelter SNMP-Anfragen
    Diese Option hilft gerade bei „doofen“ NMS unnötige Last auf der RE zu vermeiden. Wir haben hierzu aber keine Praxiserfahrung, da wir keine solchen NMS einsetzen. 😉
  3. Interfaces die „langsam“ sind nicht angeben
    „set snmp filter-interfaces all-internal-interfaces“ und
    „set snmp filter-interfaces interfaces <interface>“  helfen nicht benötigte Interfaces (z.B. Client Access Interfaces, wo Workstations und Laptops dran hängen) einfach nicht mehr per SNMP zu exportieren.

In der Praxis konnten wir durch oben dargestellten Maßnahmen (bis auf 2.) beispielsweise auf einem 2-Node EX3300-48P VirtualChassis welches mit 200ms Latenz erreichbar ist (Europa <-> Südamerika) die SNMP Pollingzeiten von 470 Sekunden auf 108 Sekunden reduzieren (bei der Ausnahme von ca. 80 User Ports). Eine „stats-cache-lifetime“ von 90 Sekunden reduzierte die Pollingdauer immerhin von 470 Sekunden auf 370 Sekunden.

 

04: Quellen

001: Optimizing the Network Management System Configuration for the Best Results

002: Configuring Options on Managed Devices for Better SNMP Response Time

Richard Müller

Richard Müller ist Geschäftsführer der Proact Deutschland GmbH. Den "kreativen" Umgang mit Computern und Datennetzen lernte er schon im Schulalter. Bis heute hat Richard eine Begeisterung für technisch brilliante Konzepte und Lösungsansätze in den Bereichen IT-Infrastruktur - hier vor allem alles rund ums Netzwerk.

 
Kommentare
Christian Korn

Die Tipps helfen nicht nur ein bisschen.

Alleine das setzen der Lifetime auf 90 und das wegfiltern der internal Interfaces brachte bei einem VC aus 6 Members einen Zeitgewinn von ~320 Sekunden pro Durchlauf auf ~130 Sekunden.

Das nenne ich mal ordentlich. 🙂

Richard Müller
Richard Müller

Hallo Christian,
das liest man doch gerne. Ich gehe davon aus, dass Ihr eurere JunOS-Systeme relativ nah (<10ms) am NMS habt und somit schaut es so aus, als würde es in Setups wo es um die eigentliche SNMP-Latenz geht mehr bringen als wenn man dazu noch hohe WAN-Latenzen hat!

Ich habe zum Punkt 3 noch eine spannende Möglichkeit gefunden, welche hier vielleicht nicht unerwähnt bleiben sollte. Es sind unter der Direktive [edit snmp filter-interfaces interfaces] sind auch reguläre Ausdrücke möglich. Dadurch muss man nicht alle Interfaces eintragen. Zum Beispiel:

snmp filter-interfaces interfaces „!^(ge|ae|vlan).“;

Hier werden nur die Gigabit-Interfaces, LAG’s und VLANs ausgegeben. Alles andere wird weggefiltert. Ist für Observium entsprechend gut geeignet.

Jedoch scheint es dann Kollisionen mit anderen EInträgen zu geben. Sofern also ein regulärer Ausdruck gesetzt wird, sind keine anderen Interface-Angaben mehr möglich. Dann muss alles in diesem einen Ausdruck abgebildet werden.

Siehe dazu:
https://www.juniper.net/documentation/en_US/junos16.1/topics/task/configuration/snmp-filter-interfaces-configuring-junos-nm.html
https://www.juniper.net/techpubs/en_US/junos13.3/topics/concept/j-web-event-filter-regular-expressions.html

Hinterlassen Sie einen Kommentar