NNMi 9, iSPIs und NA –
vom Netzwerkmonitoring zum
integrierten Netzwerkmanagement
15. September 201015. September 2010
Nils Baresel, IT unlimited AG
Agenda
� Vorstellung der Produkte die an einer integrierten
Netzwerkmanagement Lösung beteiligt sind
� Tipps und Tricks zu NNM 9 und NA 7.6
� Anwendungsbeispiele aus dem kombinierten Einsatz
20.09.2010 IT unlimited AG 2
� Anwendungsbeispiele aus dem kombinierten Einsatz
mehrerer Produkte
� Fragen
Integriertes Netzwerkmanagement Produkte
� NNMi 9
� iSPI‘s – Quality Assurance, Traffic und Metric SPI (früher Performance SPI)
� Network Automation
20.09.2010 IT unlimited AG 3
NNM iSPI Performance
� Kombiniertes Fehler- und Performance-Management
� Gemeinsames Pollingmit NNMi
� Überwachung von Perf.-Schwellwerten
� Interaktive, kontext-sensitive Navigation sensitive Navigation
� Vordefinierte Reports
� KPIs von Netzwerk-geräten
� Interface-Statistiken
� Visualisierung von Netz-werkpfaden auf Layer 2und Layer 3
20.09.2010 IT unlimited AG 4
NNM iSPI Performance für Traffic
� Sammlung und Darstellung von NetFlow und sFlow Traffic-Informationen
� Analyse und Reporting
� Mapping zwischen Traffic-Flows und Applikationen
� Nahtlose Navigation zwischen Daten aus dem Metrik und Traffic SPIs
� Verteilte, hoch-skalierbare Architektur zur Daten-sammlung und Analyse
20.09.2010 IT unlimited AG 5
NNM iSPI für Traffic
� Traffic Map in NNMi
NNM iSPI für QA
� Discovery und Monitoring von IP SLA Tests� Reporting von IP SLA Tests
HP Network AutomationSystemüberblick
Provisioning &ConfigurationManagement
ProcessAutomation &
Control
Real-timePolicy
Enforcement
Compliance & Security
Management
Reporting(compliance, change, visibility)
20.09.2010 IT unlimited AG 8
Telnet/SSH Proxy
Management Engine
APIGUI
(compliance, change, visibility)
Load Balancers Switches Routers Firewalls
Network Infrastructure Automated
Tipps und Tricks zu NNM 9 und NA 7.6
� Vereinfachungen im Bereich Custom Poller� Nützliche Erweiterungen im Bereich der Incident
Configuration� Topology Aware Configuration
Vereinfachungen für den Custom Poller
� Mit NNM 8.x war das Finden einer passenden MIB Filter Variable oft eine Herausforderung
Vereinfachungen für den Custom Poller
� Durch den neuen MIB Browser und die MIB Table View ist dies nun kein Problem mehr
Vereinfachungen für den Custom Poller
� Exportieren von via Custom Poller abgefragten MIB Werten – mit NNM 9 kein Problem
Incident Individualisieren – sinnvolle Management Events
� Jeder Custom Poller Event wird genau gleich angezeigt und nicht unbedingt mit einem sinnvollen Message Text.
� Durch Incident Enrichments kann dies geändert werden
Incident Individualisieren
� Beispiel: Bei einer USV wird per Custom Poller der verbleibende Batterieladestand gemessen werden.� Für den Operator soll eine sinnvolle und verständliche Meldung
ausgegeben werden.Eine Default Meldung durch den Custom Poller hätte z.B. folgendes Format: $cia.custompoller.policy/$cia.custompoller.collection for variable $cia.custompoller.variable.description($cia.custompoller.variable.expression) is in the $cia.custompoller.state state.
� Stattdessen soll für die USV Meldungen eine Meldung wie z.B. „Verbleibende Batterieleistung unter 30 Minuten“ ausgegeben werden. Andere Custom Poller Meldungen sollen auf dem Default Wert bleiben
Incident individualisieren
Topology Aware Configuration
� Die Stärke von NA ist die Konfiguration und der Policy Check von Netzwerkgeräten. NA weiß aber nichts von der Netzwerktopology.
� Die Stärke von NNM ist die Topologie- und Fehlererkennung
� Beide Produkte kombiniert bieten eine „Topology Aware Configuration“Configuration“
� Anwendungsfall: Es besteht die Anforderung, dass in der Interface Description jeweils der 1 Hop Neighbor Node inkl. Port gelistet ist. Dies soll durch eine Policy in NA geprüft und geg. angepasst werden.
Topology Aware Configuration
� Umsetzung� NNM kennt die Topologie und somit die L2 Connections
� Die Layer 2 Connection zu jedem Interface wird ausgelesen
Topology Aware Configuration
� Umsetzung� Einlesen der aus NNM exportierten L2 Neighbor Informationen
in NA. Hierzu müssen sog. Custom Attributes angelegt und dann z.B. via Perl Script mit den Daten für das jeweilige Interface befüllt werden.
Topology Aware Configuration
� Umsetzung� Über eine Policy kann nun geprüft werden, ob die Interface
Description dem Custom Attribute Wert entspricht und wenn nicht dies z.B. automatisiert korrigieren oder eine Meldung an NNM ausgeben (Policy Violation)
Anwendungsbeispiele durch den kombinierten Einsatz mehrere Produkte
� Workflow – Integriertes Netzwerkmanagement, mehr als nur eine Tool Konsolidierung
� Langsame Applikation – Traffic Analyse� Erkennung und Beseitigung von hohen Fehlerraten
Integriertes Netzwerkmanagement –mehr als nur eine Tool Konsolidierung
� Beispiel: Ein neues Netzwerkgerät wird aufgebaut
� Typische Tätigkeiten die dies zur Folge hat� Switch/Router wird aufgebaut und evtl. von externem Personal
konfiguriert� Anlage des Switches im Konfigurationswerkzeug z.B.
CiscoWorks (LMS…), CiscoWorks (LMS…), � Anlage des Switches in einem Reporting Tool z.B. MRTG� Anlage des Switches in einem Monitoring Tool z.B. NNM
� Nachfolgende Tätigkeiten� Kontrolle in allen Tools ob der Switch korrekt aufgenommen
und verwaltet wird� Bei Änderungen z.B. Access Credentials, muss diese
Information in allen Tools nachgepflegt werden.
Integriertes Netzwerkmanagement –mehr als nur eine Tool Konsolidierung
Node wird automatisch in NA angelegt
NNMi discoveredNode
Change wird an Node durchgeführt
Node wird automatisch in iSPI
Node Groups angelegt
Fallbeispiel 1: Langsame Applikation
� Anwender beschweren sich beim Helpdesk über langsame Reaktionszeiten einer Applikation – „Das Netzwerk ist langsam, meine Applikation xy reagiert kaum“
� Helpdesk eröffnet ein Troubleticket das dem Netzwerk Operating zugestellt wird.
� Vorgehen ohne integriertes Netzwerkmanagement� Vorgehen ohne integriertes Netzwerkmanagement� Operator/Network Engineer versucht z.B. über Traceroute
herauszubekommen welche Komponenten am Datenverkehr für die betroffene Applikation beteiligt sind (Server-to-Server Communication).
� Routing Tabellen werden analysiert um herauszufinden über welche Interface der Datenverkehr läuft
� Network Engineer schaltet sich auf alle Geräte um die Konfiguration und Auslastung zu prüfen
� Mit sniffern wird versucht herauszufinden welche Daten zu der hohen Auslastung führen
� Rerouting/ACL Anpassungen werden durchgeführt um das Problem zu beheben.
Fallbeispiel 1: Langsame Applikation
� Vorgehen mit Integriertem Fault, Performance und Konfigurationsmanagement� Durch den Einsatz vom Metric SPI wird die Interface
Performance von wichtigen Interfacen überwacht. In der Konsole erscheint daher eine Meldung dass eine hohe Interface Utilization von einem betroffenen Node vorliegt.
Fallbeispiel 1: Langsame Applikation
� Um herauszufinden welcher Datenverkehr für die hohe Utilization verantwortlich ist wird der Traffic SPI gestartet.
� Zusätzlich zeigt ein IPSLA Test zwischen den beteiligten Routern noch einen Paket Verlust an.
Fallbeispiel 1: Langsame Applikation
� Nachdem nun klar ist was die hohe Auslastung verursacht (z.B. ein Backup Lauf der auf die falsche Uhrzeit konfiguriert ist oder ein Internet Download oder anderer unerwünschter Datenverkehr) kann über NA eine Konfigurationsanpassung vorgenommen werden um die ACL‘s oder Routing Daten anzupassen.
� In der NNM Console wird nach der Konfigurationsänderung der Incident automatisch geschlossen da das Problem behoben ist.
Fallbeispiel 2: Hohe Fehlerraten auf einem Interface – Duplex Missmatch
� Durch den Einsatz des Metric SPI werden auf wichtigen Interfacen Performance Werte überwacht, so auch auf CRC Fehler.
� Über einen Cross Launch in die NA GUI kann nun geprüft � Über einen Cross Launch in die NA GUI kann nun geprüft werden ob bei diesem Interface Konfigurationsänderungen durchgeführt wurden
Fallbeispiel 2: Hohe Fehlerraten auf einem Interface
� Durch die ständigen Konfigurationssicherungen die NA durchführt kann direkt die Änderung zum vorherigen Stand angezeigt werden und somit auch in diesem Fall die Ursache für den Fehler ermittelt werden.
� Durch ein „Deploy to running configuration“ kann diefehlerfreie Konfiguration direkt wieder hergestellt werden.
� Der Incident in NNMi wird automatisch geschlossen wenn das Problem behoben ist.
Tipp zum Fallbeispiel 2
� Sollen z.B. Interface auf Access Switchen auf Fehler und somit mögliche defekte Netzwerkkarten der PC‘s oder falsche Duplexeinstellungen geprüft werden, so kann dies einfach über das Monitoring erfolgen.
� Umsetzung� 1. Über eine Interface Group werden die Access Interface
identifiziert� 2. Für die erstellt Interface Group wird ein spezielles Interface
Monitoring aufgesetzt das nur Performance Werte prüft und kein Fault Polling durchführt (Alarme durch einen PC Rebootsollen vermieden werden)
� 3. Durch den Performance SPI for Metrics können einfach die Fehlerraten auf den Interfacen geprüft werden.
Tipp zum Fallbeispiel 2
Fault Polling ist nicht aktiv
Performance Polling ist aktiv
PC‘s sind nicht in DB – daher sind Ports
unconnected