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.