Cisco IP SLA vs. Juniper RPM

Die Überwachung Service Level Agreements gewinnt im Netzwerkbetrieb immer mehr Bedeutung. Cisco bietet hierzu die Funktion IP SLA, früher bekannt als Realtime Responder (RTR) an. Auch Mitbewerber Juniper bietet eine solche ähnliche Funktion. Im folgenden möchte ich einen kurzen Vergleich anstellen, bei dem ich jedoch im Wesentlichen die Implementierung von Juniper RPM eingehen werde.

1. Einführung

1.1. Zielsetzung

Es soll evaluiert werden, inwiefern die Funktion Juniper Real-time Performance Monitor (RPM) zur Überwachung des Service Levels in IP-Netzen eingesetzt werden kann. Vergleichsweise wird die Funktion IP Service Level Agreements (IP SLA) von Cisco herangezogen.

1.2. Testumgebung

Für die Evaluierung steht ein Gerät der Juniper J-Serie JSR 2350 zur Verfügung. Es wird Junos Enhanced Services 8.5R1.13 eingesetzt. Als Responder kommt zunächst ein Fonero WLAN-Router zum Einsatz. Weiterhin dienen ein Cisco ME 3400 sowie ein Cisco 1841 als Responder.

2. Mögliche Messungen

Derzeit lassen sich mit dem Real-time Performance-Monitor folgende Messungen durchführen und analysieren:

• httg-get
• http-metadata-get
• icmp-ping
• icmp-ping-timestamp
• tcp-ping
• udp-ping
• udp-ping-timestamp

Die Messungen können über verschiedene Optionen angepasst werden. So können beispielsweise DSCP-Werte gesetzt oder die Paketgröße eingestellt werden. Damit kann der Datenverkehr eingeschränkt dem realen Datenaufkommen nachempfunden werden. Hervorzuheben ist die Option Hardware Timestamp, mit der die Timestamps der generierten Pakete bei der Verarbeitung durch die Forwarding-Engine aktualisiert werden. Dies erhöht die Genauigkeit der Messungen. Als Responder für Ping-basierte Messungen können alle IP-fähigen Endgeräte dienen, für http-get-Anfragen muss auf dem Gerät ein http-Server gestartet sein. Die Ergebnisse der Messungen beinhalten unter anderen folgenden Angaben:

• Round-Trip-Time – Minimum, Maximum, Durchschnitt
• Round-Trip-Time – Standardabweichung
• Round-Trip-Time – Zeitpunkt des aktuellen Maximal- bzw. Minimalwertes
• Jitter – Minimum, Maximum, Durchschnitt
• Jitter – Standardabweichung
• Jitter – Zeitpunkt des aktuellen Maximal- bzw. Minimalwertes

Die Version 9.1 von Junos Enhanced Services bietet im Vergleich zur vorliegenden Version 8.5 laut Dokumentation keine weitergehenden Funktionen.

3. Konfiguration über das Command Line Interface

Die Konfiguration über das Command Line Interface (CLI) ist ebenfalls möglich. Der Zweig set services rpm erlaubt das Anlegen von Messungen und auch deren nachträgliche Konfiguration. Über den Befehl show services rpm probe-results können die Ergebnisse angesehen werden. Die Konfigurationsdatei enthält nach Abschluss der Konfiguration einen entsprechen Abschnitt, der sowohl die allgemeinen Einstellungen als auch die individuellen Parameter der einzelnen Messungen enthält. Im Folgenden ist ein entsprechender Auszug der Konfigurationsdatei dargestellt.

services {

rpm {

probe Evaluation {

test ping_wlan_konsole {

probe-type icmp-ping;

target address 10.10.10.1;

probe-count 5;

test-interval 30;

history-size 50;

data-size 1024;

data-fill 1;

thresholds {

successive-loss 5;

total-loss 10;

}

traps [ jitter-exceeded probe-failure rtt-exceeded std-dev-exceeded test- completion test-failure ];

}

test ping_wlan_konsole_cs1 {

probe-type icmp-ping;

target address 10.10.10.1;

probe-count 15;

test-interval 30;

history-size 255;

dscp-code-points 001000;

traps [ jitter-exceeded probe-failure rtt-exceeded std-dev-exceeded test- completion test-failure ];

}

test ping_wlan_konsole_cs7 {

probe-type icmp-ping;

target address 10.10.10.1;

probe-count 15;

test-interval 30;

history-size 255;

dscp-code-points 111000;

traps [ jitter-exceeded probe-failure rtt-exceeded std-dev-exceeded test- completion test-failure ];

}

}

probe-server {

tcp {

port 7;

}

udp {

port 7;

}

}

probe-limit 100;

}

}

4. Monitoring

4.1. Monitoring über die Web-Oberfläche

Über die Web-Oberfläche können die ermittelten Informationen komfortabel eingesehen werden. Es werden neben statistischen Informationen auch Graphen dargestellt. Diese sind jedoch in ihrer zeitlichen Auflösung stark begrenzt und nicht modifizierbar. So kann beispielsweise bei Messungen der Round Trip Time nur der Verlauf der letzten Minuten dargestellt werden.

4.2. Monitoring über externe Werkzeuge

Juniper schafft durch die Management Information Base (MIB) JUNIPER-RPM-MIB die Möglichkeit, die Messergebnisse mittels SNMP externen Werkzeugen zugänglich zu machen. Ebenfalls über SNMP kann mit Hilfe von Traps eine Überschreitung von zuvor definierten Schwellenwerten gemeldet werden. Die Messergebnisse des Real-time Performance Monitor können derzeit mit verschiedenen Programmen verarbeitet werden, unter anderem bieten Spectrum (ab Version 8.1) und InfoVista entsprechende Unterstützung. Freie Templates für Cacti oder Nagios sind derzeit nicht verfügbar.

5. Real-time Performance Monitoring für BGP

Neben den allgemeinen Messungen bietet Juniper eine spezialisierte Variante für die Überwachung von BGP. Über dieses Verfahren kann automatisiert überprüft werden, ob ein Pfad zwischen dem Router und den konfigurierten Border Gateway Protocol (BGP) Nachbarn besteht. Die Konfiguration kann derzeit nicht über die Web-Oberfläche erfolgen sondern muss über die CLI geschehen. Die Syntax entspricht dabei im Wesentlichen der oben aufgeführten, lediglich die Hierarchie-Ebene muss angepasst werden edit services rpm bgp. Die Web-Oberfläche stellt jedoch die zur Auswertung benötigten Tabellen und auch entsprechende Graphen bereit. Eine entsprechende Konfigurationssyntax lautet beispielsweise: set services rpm bgp probe-type icmp-ping test-interval 30 data-fill 1. Zieladressen o. ä. müssen nicht konfiguriert werden, da dies bereits über BGP-Konfiguration geschehen ist. Der Konfiguration ist dementsprechend um folgenden Abschnitt erweitert:

services {

rpm {

bgp {

probe-type icmp-ping;

test-interval 30;

data-fill 1;

}

…

}

}

Der dazugehörige Graph wird automatisch generiert:

6. Vergleich zu Cisco IP Service Level Agreements

Zunächst scheinen sich die Funktionen Juniper Real-time Performance Monitor und IP SLA von Cisco stark zu ähneln, doch gibt es bedeutende Unterschiede. Funktionsumfang Während Cisco eine Vielzahl von möglichen Messungen anbietet, darunter auch simulierte Sprachübertragung mit Voice over IP und DNS-Anfragen, hält sich Juniper hier zurück. Angeboten werden ICMP-, UDP- und TCP-Pings sowie http-get-Anfragen. Dies schränkt die Möglichkeit, den generierten Datenverkehr dem tatsächlichen Datenverkehr anzunähern erheblich ein.

Konfiguration Derzeit wird Cisco IP SLA ausschließlich über die CLI konfiguriert, Juniper bietet hingegen für RPM zusätzlich eine übersichtliche Web-Oberfläche. Eine Ausnahme ist die Konfiguration von RPM für BGP, die (derzeit) nur mittels CLI konfigurierbar ist. Um Messungen zu ändern, müssen diese unter Cisco zunächst gelöscht und dann neu angelegt werden. Juniper erlaubt hingegen das Editieren bestehender Konfigurationen. Für einige Funktionen, beispielsweise die VoIP-Simulation, erfordert Cisco zudem die Konfiguration der Responder. Diese müssen dabei die Funktion IP SLA implementiert haben und explizit als IP SLA Responder konfiguriert werden. Für die Standardmessungen (Ping etc.) setzen jedoch weder Cisco noch Juniper Konfigurationen auf den Respondern voraus. Dies erleichtert die Implementierung in bestehende Umgebungen erheblich. Auswertung Beide Hersteller speichern die Messergebnisse für einen beschränkten Zeitraum auf den entsprechenden Geräten. Hier können sie in Tabellenform ausgewertet werden. Zusätzlich bietet Junipers Web-Oberfläche eine Visualisierung in Form rudimentärer Graphen. Diese sind jedoch für Langzeitverläufe oder umfangreiche Messungen ungeeignet. Für die dauerhafte Speicherung und Auswertung mit Hilfe externer Werkzeuge wie beispielsweise Nagios und Cacti können die Messergebnisse mittels SNMP übertragen werden.

7. Fazit

Abschließen betrachtet bietet Juniper mit Real-time Performance Monitor ein sinnvolles Werkzeug zur Überwachung des Service Levels in IP-Netzen. Jedoch ist durch den eingeschränkten Umfang an Messungen der Einsatz nur für grundlegende Überwachungsaufgaben geeignet.

Insbesondere die derzeit nur von Cisco bereitgestellten Möglichkeiten zur Simulation von VoIP-Verbindungen, DNS- und FTP-Datenverkehr erlauben eine Annäherung an das reale Datenaufkomme. Dadurch ermittelte Messergebnisse wie der Mean Opinion Score (MOS) zur Bewertung der Sprachqualität oder eine differenzierte Auswertung des Jitters auf dem Weg von Router zum Poller und zurück zeigen die derzeitigen Vorteile von Cisco IP SLA gegenüber Juniper RPM.