TQuality of Experience für Anwendungen
Sicherung der Servicequalität für die Anwendung (AppQoE)
- Einführung in Application Quality of Experience
- Vorteile der Quality of Experience für die Anwendung
- Begrenzungen
- Wie funktioniert die Quality of Experience für Anwendungen?
- Wie die Quality of Experience von Anwendungen die Anwendungsleistung misst
- Verschieben des Anwendungsdatenverkehrs auf einen alternativen Pfad
Einführung in Application Quality of Experience
Das unaufhaltsame Wachstum von Cloud-Computing, Mobilität und webbasierten Anwendungen erfordert, dass das Netzwerk den Datenverkehr auf Anwendungsebene identifiziert und kontrolliert und jeden Anwendungstyp separat verarbeitet, um den Benutzern eine qualitativ hochwertige Erfahrung (QoE) zu bieten. Um anwendungsspezifische QoE (AppQoE) zu gewährleisten, müssen Sie den Anwendungsdatenverkehr effektiv priorisieren, trennen und routen, ohne die Leistung oder Verfügbarkeit zu beeinträchtigen.
AppQoE nutzt (oder nutzt) die Funktionen von zwei Anwendungssicherheitsservices: Anwendungsidentifizierung (AppID) und erweitertes richtlinienbasiertes Routing (APBR). Es verwendet AppID, um bestimmte Anwendungen in Ihrem Netzwerk zu identifizieren, und erweitertes richtlinienbasiertes Routing (APBR), um einen Pfad für bestimmten Datenverkehr anzugeben, indem SLA-Profile einer Routing-Instanz zugeordnet werden, auf der der Anwendungsdatenverkehr gemäß den APBR-Regeln gesendet wird.
Eine der wichtigsten Anforderungen an ein softwaredefiniertes WAN (SD-WAN) besteht darin, die Qualität der Underlay-Netzwerkpfade zu messen und auf der Grundlage der Ergebnisse die besten Pfade für die Zustellung jedes Pakets zu bestimmen. AppQoE überwacht die Performance geschäftskritischer Anwendungen und wählt auf Basis der Bewertung die bestmögliche Verbindung für diesen Anwendungsdatenverkehr aus, um die in SLA (Service Level Agreement) festgelegten Leistungsanforderungen zu erfüllen.
Das Vorhandensein einer SLA-Regel in der APBR-Konfiguration löst die AppQoE-Funktionalität aus. Wenn keine SLA-Profile verfügbar sind, funktioniert der APBR, ohne AppQoE auszulösen.
Unterstützter Anwendungsfall
Mit Contrail Service Orchestration (CSO) können Sie AppQoE optimal konfigurieren. Wir empfehlen, dass Sie CSO verwenden, um AppQoE für die Contrail SD-WAN-Lösung von Juniper Networks zu konfigurieren. Weitere Informationen finden Sie unter Übersicht über die Anwendungsqualität und Konfigurieren und Überwachen der Benutzerfreundlichkeit von Anwendungen.
Unterstützte Konfigurationsoptionen
AppQoE wird sowohl auf Hub-and-Spoke- als auch auf Full-Mesh-Topologien in SD-WAN-Bereitstellungen unterstützt.
Sie können eine AppQoE zwischen zwei Junos OS-Firewall-Endgeräten (mit Buchend) konfigurieren, und beide Firewalls müssen über dieselbe Version des Junos OS-Images verfügen.
Vorteile der Quality of Experience für die Anwendung
-
Ermöglicht kostengünstige QoE durch Echtzeitüberwachung des Anwendungsdatenverkehrs, um ein konsistentes und vorhersehbares Serviceniveau zu gewährleisten.
-
Erhöht die Kundenbindung und -zufriedenheit durch die Bereitstellung eines garantierten SLA für die Bereitstellung von bestimmtem Datenverkehr (z. B. Videodatenverkehr). AppQoE stellt sicher, dass der genehmigte Datenverkehr die entsprechende Priorität und Bandbreite erhält, um die beste Qualität für den Benutzer zu gewährleisten.
Begrenzungen
Für die Implementierung von AppQoE auf Sicherheitsgeräten gelten die folgenden Einschränkungen:
-
Für alle verschiedenen Routen zum Ziel über unterschiedliche Schnittstellen müssen die gleichen Präferenzen, Gewichtungen und Metriken konfiguriert sein. Alle Routen müssen als ECMP-Pfade für das Ziel hinzugefügt werden und auch Teil derselben Weiterleitungstabelle sein.
-
AppQoE SLA-Service nur zwischen zwei Sicherheitsgeräten Endgeräte (book-end) werden unterstützt. End-to-End-AppQoE-SLA-Service wird nicht unterstützt.
-
AppQoE kann nur angewendet werden, wenn alle Schnittstellen Teil derselben Zone sind.
-
AppQoE kann nicht für umgekehrten Datenverkehr angewendet werden.
-
AppQoE hat keinen Einfluss auf die Änderung des Ziels für eine Sitzung.
-
AppQoE unterstützt keine IPv6/UDP-Probekapselung, GRES, Gehäuse-Cluster (ISSU, Hochverfügbarkeit, Dual-CPE-Hochverfügbarkeit, Z-Mode-Hochverfügbarkeit) und logische Systeme.
-
AppQoE unterstützt die Auswahl bevorzugter Pfade nicht, und virtuelles Transit Routing und Forwarding (VRF) werden nicht unterstützt.
-
AppQoE unterstützt kein passives Sondieren von IPv6-Datenpaketen.
-
An den Nicht-WAN-Schnittstellen ist ein Eingabe-Firewall-Filter erforderlich, um UDP-Pakete mit dem UDP-Zielport 36000 zu verwerfen.
Wie funktioniert die Quality of Experience für Anwendungen?
AppQoE nutzt AppID- und APBR-Funktionen, um bestimmte Anwendungen/Anwendungsgruppen zu identifizieren und einen Pfad für bestimmten Datenverkehr anzugeben, indem SLA-Profile einer Routing-Instanz zugeordnet werden, auf der der Anwendungsdatenverkehr gemäß den APBR-Regeln gesendet wird.
AppQoE überwacht die Performance von Anwendungen und wählt basierend auf der Bewertung den bestmöglichen Link für diesen Anwendungsdatenverkehr aus, um die in SLA (Service Level Agreement) festgelegten Leistungsanforderungen zu erfüllen.
- Identifizieren von Anwendungen oder Anwendungsgruppen
- Angeben des Pfads für Anwendungen oder Anwendungsgruppen
- Pfadauswahl für Anwendungsdatenverkehr
Identifizieren von Anwendungen oder Anwendungsgruppen
Die folgenden Schritte sind zum Identifizieren von Anwendungen oder Anwendungsgruppen erforderlich:
-
Die Junos OS-Anwendungsidentifizierung identifiziert Anwendungen, und sobald eine Anwendung identifiziert wurde, werden ihre Informationen im System-Cache der Anwendung (ASC) gespeichert.
-
APBR wertet die Pakete basierend darauf aus, ob die Sitzung für anwendungsbasiertes Routing (erweitertes richtlinienbasiertes Routing) geeignet ist. Wenn es sich um das erste Paket der neuen Sitzung handelt und der Datenverkehr nicht für anwendungsbasiertes Routing gekennzeichnet ist, wird es normal zum Ziel verarbeitet (Nicht-APBR-Route).
-
Wenn die Sitzung anwendungsbasiertes Routing benötigt, fragt APBR das ASC-Modul ab, um die Anwendungsattribute (IP-Adresse, Zielport, Protokolltyp und Dienst) abzurufen.
-
Wenn die Anwendung in ASC gefunden wird, wird der Datenverkehr für eine übereinstimmende Regel im APBR-Profil weiterverarbeitet.
-
Wenn eine übereinstimmende Regel gefunden wird, wird der Datenverkehr für die Routensuche an die angegebene Routinginstanz umgeleitet.
-
AppQoE prüft, ob ein SLA für eine Sitzung aktiviert ist. Wenn die Sitzung ein Kandidat für eine SLA-Messung ist, initiiert AppQoE aktive und passive Sondierungen für Leistungsmessungen.
-
Wenn SLA für die Sitzung in der APBR-Regel nicht aktiviert ist, ignoriert AppQoE diese Sitzung, und das Standardverhalten von APBR wird auf diese Sitzungen angewendet, d. h., der Datenverkehr wird über die angegebene Routinginstanz für das Ziel geleitet.
-
-
Wenn die Anwendung in nicht in ASC gefunden wird, fordert APBR eine Tiefenuntersuchung des Datenstroms an. Das heißt, das Anwendungssignaturpaket wird installiert und die Anwendungsidentifizierung für die Sitzung ist aktiviert, sodass ASC für die Verwendung durch nachfolgende Sitzungen für die APBR-Verarbeitung aufgefüllt werden kann (siehe Schritt 2).
-
Angeben des Pfads für Anwendungen oder Anwendungsgruppen
In den folgenden Schritten wird zusammengefasst, wie AppQoE einen Pfad für den Anwendungsdatenverkehr gemäß den SLA-Regeln angibt.
-
APBR verwendet die Anwendungsdetails, um im APBR-Profil (Anwendungsprofil) nach einer übereinstimmenden Regel zu suchen. Datenverkehr, der den Anwendungen und Anwendungsgruppen entspricht, wird an die statische Route und die in der Routing-Instanz angegebene Next-Hop-Adresse weitergeleitet.
-
Eine SLA-Regel, die an das APBR-Profil angehängt ist, legt Parameter fest, die erforderlich sind, um die SLA zu messen und festzustellen, ob eine SLA-Verletzung stattgefunden hat oder nicht.
-
Der Anwendungsdatenverkehr wird einem bestimmten Overlay-Link zugewiesen, basierend auf den SLA-Metriken dieses Overlay-Links, die mithilfe von aktiver Sondierung gemessen werden.
-
Der SLA-Verstoß wird durch passives Sondieren des Live-Datenverkehrs von Anwendungen/Anwendungsgruppen ermittelt. Der beste Pfad/Overlay-Link für die Anwendung/Anwendungsgruppe wird durch den Pfadauswahlalgorithmus bestimmt.
Pfadauswahl für Anwendungsdatenverkehr
Für das Routing des Datenverkehrs von der Quelle zum Ziel finden die folgenden Schritte statt, insbesondere um den besten Pfad auszuwählen,
-
Wenn für das erste Datenpaket eines Flusses (erster Pfad) die Anwendung bereits bekannt ist (aus dem ASC-Lookup), dann wird der beste Pfad für die Anwendung in der Datenbank gesucht. Wenn die Anwendung nicht bekannt oder neu ist (aus der ASC-Suche), wird ein zufälliger Pfad oder der Standardpfad gewählt. Dieser Pfad wird für die gesamte Sitzung fortgesetzt. Später, nachdem die Anwendung von der DPI erkannt wurde, wird die Datenbank mit dem besten Pfad für die Anwendung aktualisiert.
-
Wenn für das verbleibende Datenpaket eines Datenflusses (Fast Path) die Anwendung zunächst nicht bekannt ist, wird die jeweilige Sitzung auf demselben Pfad fortgesetzt. Wenn die Anwendung anfänglich bekannt ist, wählt AppQoE den besten Pfad für den Anwendungsdatenverkehr aus.
Wenn eine neue Anwendung erkannt wird, versucht der Pfadauswahlmechanismus, einen Pfad zu finden, der alle SLA-Metriken erfüllt. Wenn kein solcher Pfad vorhanden ist, wird der nächstbeste Pfad (basierend auf der Anzahl der erfüllten Metriken) verwendet. Wenn es mehr als einen Pfad gibt, der die Metriken erfüllt, wird ein zufälliger Pfad unter den verfügbaren Pfaden ausgewählt. Der SLA-Verstoß wird erkannt, wenn eine der Metriken verletzt wird oder keine der Metriken die Anforderung erfüllt, basierend auf der Profilkonfiguration.
Wie die Quality of Experience von Anwendungen die Anwendungsleistung misst
Die Anwendungsleistung wird anhand der folgenden Indikatoren bestimmt:
-
Latenz: Die Zeit, die Medien physisch für die Übertragung benötigen, abhängig von der Länge und der Entfernung, die zurückgelegt werden muss
-
RTT – Eine Hin- und Rückfahrtzeit, die für die Reise von der Quelle zum Ziel und umgekehrt erforderlich ist.
-
Paketverlust: Der Paketverlust gibt die Anzahl der Pakete an, die pro 100 von einem Host gesendeten Paketen verloren gehen.
-
Jitter: Jitter ist der Unterschied in der Latenz von Paket zu Paket. Eingangs-Jitter, Ausgangs-Jitter und bidirektionaler Jitter können angegeben werden, um die Leistung der Verbindung zu bewerten.
AppQoE überwacht RTT, Jitter und Paketverluste auf jeder Verbindung und leitet Anwendungen basierend auf der Bewertung nahtlos auf den alternativen Pfad um, wenn die Leistung der primären Verbindung unter den akzeptablen Werten liegt, die durch SLAs festgelegt sind. Die Messung und Überwachung der Anwendungsleistung erfolgt mithilfe von aktiven und passiven Sonden, um SLA-Verstöße zu erkennen und einen alternativen Pfad für die jeweilige Anwendung auszuwählen.
AppQoE sammelt Echtzeitdaten, indem es den Anwendungsdatenverkehr kontinuierlich überwacht und Netzwerk- oder Geräteprobleme identifiziert:
-
Überwachen der Leistung auf allen konfigurierten Overlay-Links
-
Verwenden von passiven Sondierungen (inline mit dem Datenpfad der Anwendung) und aktiven Sondierungen (synthetische Sondierungen für eine bestimmte Anwendung) zur Überwachung der Datenverkehrsleistung für die Anwendung oder Anwendungsgruppe.
-
Senden aller gesammelten Leistungsmetriken oder Metadaten zur Analyse an einen Protokollsammler.
-
Vergleichen der angegebenen Anwendung mit einer bestimmten Leistungsmetrik und dynamisches Ändern des Pfads für den Anwendungsdatenverkehr im Falle eines SLA-Verstoßes.
-
Unterstützung einer flexiblen SLA-Metrikkonfiguration für eine bestimmte Anwendung oder Anwendungsgruppe.
AppQoE misst die Anwendungs-SLA über mehrere WAN-Links hinweg und ordnet den Anwendungsdatenverkehr einem Pfad unter den verfügbaren Links zu, d. h. dem Pfad, der die SLA-Anforderungen am besten erfüllt.
Messung der Anwendungsleistung mithilfe aktiver und passiver Sondierungen
Aktive und passive Sondenmessungen sind die beiden Ansätze, die für die End-to-End-Analyse des Netzwerks verwendet werden.
-
Aktive Sonde: Aktive Sondierungen messen die Servicequalität der Anwendung, um eine End-to-End-Messung der Netzwerkleistung zu ermöglichen.
Bei der aktiven Sondierung werden benutzerdefinierte Pakete zwischen Spoke- und Hub-Punkten auf allen verschiedenen Routen gesendet, und RTT, Latenz, Jitter und Paketverlust werden zwischen den installierten Testpunkten gemessen. Die aktiven Sondierungen werden in regelmäßigen Abständen an alle aktiven und passiven Verbindungen gesendet. Eine konfigurierte Anzahl von Samples wird gesammelt, und ein laufender Durchschnitt für den Sondenpfad jeder solchen Anwendung wird gemessen. Wenn bei einem Anwendungsdatenverkehr ein Verstoß festgestellt wird, werden die Probe-Metriken ausgewertet, um den besten Link zu ermitteln, der das SLA erfüllt.
-
Passive Sondierung: Passive Sondierungen werden an Verbindungen innerhalb des Netzwerks installiert, und Sondierungen überwachen den gesamten Datenverkehr, der durch diese Verbindungen fließt.
Passive Sondierung überwacht Verbindungen im Live-Datenverkehr auf SLA-Verletzungen. Bei einer passiven Sondierung werden die eigentlichen Datenpakete in einem IP/UDP-Probe-Header im Live-Datenverkehr zwischen den buchseitigen Punkten des Geräts eingekapselt. Die Sondierung misst RTT, Jitter und Paketverluste zwischen den Installationspunkten der Sonden, um die Servicequalität zu berechnen.
Wenn bei einer Anwendung ein Verstoß festgestellt wird, werden die Metriken der synthetischen Sondierung ausgewertet, um den besten Link zu ermitteln, der das SLA erfüllt.
Anmerkung:Um zu erkennen, ob eine Verbindung oder ein Pfad durch passive Probes ausgefallen ist, müssen in einem Abtastzeitraum mindestens drei Probe-Anfragen und ein Paketverlust von 100 % auftreten, damit eine bestimmte Sitzung einen SLA-Verstoß auslöst.
Anmerkung:Wenn das Gerät im Chassis-Cluster-Modus betrieben wird und der sekundäre Knoten (Knoten 1), über den der Datenverkehr weitergeleitet wird, neu gestartet wird, erfolgt ein mehrfaches Umschalten des Anwendungsdatenverkehrs zwischen den Verbindungen über sekundäre Knotenverbindungen. Dies geschieht, wenn die verfügbaren Links auf dem primären Knoten (Knoten 0) im Vergleich zu den Links des sekundären Knotens einen geringeren aktiven Test-SLA-Pfadwert aufweisen. Dieses Verhalten wird so lange fortgesetzt, bis die Ergebnisse der Pfadbewertung der aktiven Test-SLA von AppQoE verfügbar sind, die darauf hinweisen, dass bei allen Links auf dem sekundären Knoten ein Paketverlust von 100 % vorliegt.
Sie können eine SLA-Regel mit aktiven und passiven Testparametern konfigurieren und die SLA-Regel mit dem APBR-Profil verknüpfen. Das APBR-Profil enthält auch eine APBR-Regel. Regeln sind einer oder mehreren Anwendungen zugeordnet, und der Datenverkehr, der der Regel entspricht, wird an die Routing-Instanz umgeleitet
AppQoE löst die Testanforderungen für alle Testpfade der Anwendung aus. Aktive und passive Sondierungen überwachen das Netzwerk auf Bereiche oder Punkte mit Ausfällen oder Überlastungen.
AppQoE sammelt Datenverkehrsklassenstatistiken für gelernte Anwendungen mithilfe aktiver und passiver Tests und führt die folgenden Aktionen aus:
-
Performance für SLA messen: Die von Probes bereitgestellten Echtzeitmetriken werden verwendet, um die Servicequalität gemäß SLA für eine Anwendung zu bewerten und festzustellen, ob der Anwendungspfad die SLA-Anforderungen nicht erfüllt. Das heißt, wenn für eine Anwendung ein Verstoß festgestellt wird, werden die synthetischen Testmetriken ausgewertet, um den besten alternativen Link für den Anwendungsdatenverkehr zu ermitteln, der die SLA erfüllt.
-
Datenverkehr umleiten: Der Anwendungsdatenverkehr wird zwischen den beiden Links umgeleitet, d. h., wenn bei einem Link Performance-Probleme auftreten, wird der Datenverkehr während derselben Sitzung an den anderen Link weitergeleitet.
Wenn der Datenverkehr der Anwendung über mehrere Links erreichbar ist, müssen Sie alle erreichbaren Pfade als Overlay-Pfade konfigurieren und die Overlay-Pfade an die SLA-Regel der Anwendung anhängen.
Verschieben des Anwendungsdatenverkehrs auf einen alternativen Pfad
Sie können das Umschalten des Anwendungsdatenverkehrs auf eine andere Route (lokal auf dem Gerät) während eines SLA-Verstoßes aktivieren oder deaktivieren. Wenn das lokale Routenswitching aktiviert ist, wird das Umschalten des Anwendungsdatenverkehrs auf eine alternative Route aktiviert, und die SLA-Überwachungs- und Berichtsfunktion ist ebenfalls verfügbar. Selbst wenn die Option zum Wechseln des Anwendungsdatenverkehrs auf einen alternativen Pfad in der SLA-Regelkonfiguration deaktiviert ist, löst AppQoE SLA-Verletzungen, indem beispielsweise der Anwendungsdatenverkehr auf einen neuen Pfad verlagert wird.
Wenn das lokale Routenswitching deaktiviert ist, stehen nur die SLA-Überwachungs- und Berichtsfunktionen zur Verfügung, und die Weiterleitung des Anwendungsdatenverkehrs auf die andere Route aufgrund eines SLA-Verstoßes wird abgeschaltet.
Wenn ein Anwendungsdatenverkehr zu einem alternativen Pfad wechselt, gibt es einen kurzen Zeitraum, in dem der Anwendungsdatenverkehr im Falle eines SLA-Verstoßes nicht wieder auf einen anderen Pfad umgeleitet werden kann. Dieser Zeitraum trägt dazu bei, ein Flattern des Datenverkehrs über Links zu vermeiden.
Grundlegendes zu AppQoE-Konfigurationslimits
AppQoE erzwingt das Konfigurationslimit für Overlay-Pfade, Metrikprofile, Prüfparameter und SLA-Regeln pro Profil, wenn Sie anwendungsspezifische SLA-Regeln konfigurieren und die SLA-Regeln einem APBR-Profil zuordnen.
Wenn Sie die Parameter mehr als den zulässigen Grenzwert konfigurieren, werden Fehlermeldungen angezeigt, wenn Sie die Konfiguration bestätigen.
Beispiele für Fehlermeldungen:
Der Wert des Konfigurationsgrenzwerts spiegelt möglicherweise nicht die genaue Anzahl der unterstützten Werte wider. Die Zahlen können je nach unterstütztem Gerät variieren
[edit security advance-policy-based-routing]
'sla-rule sla0'
Cannot configure more than 32 sla rules
error: configuration check-out failed
[edit security advance-policy-based-routing]
'overlay-path grep2'
Cannot configure more than 2000 overlay paths
error: configuration check-out failed
[edit security advance-policy-based-routing]
'metrics-profile m0'
Max metrics for this system is 32
error: configuration check-out failed
[edit security advance-policy-based-routing]
'active-probe-params pr0'
Cannot configure more than 64 probe params
error: configuration check-out failed
Auswahl des Anwendungspfads auf der Grundlage von Linkpräferenz und -priorität
Eine der wichtigsten Anforderungen an ein softwaredefiniertes WAN (SD-WAN) besteht darin, die Qualität der Underlay-Netzwerkpfade zu messen und auf der Grundlage der Ergebnisse die besten Pfade für die Zustellung jedes Pakets zu bestimmen.
Sie können die anwendungsspezifische Quality of Experience (AppQoE) konfigurieren, um den Anwendungspfad basierend auf der Verbindungspriorität und dem Linktyp auszuwählen, wenn mehrere Pfade verfügbar sind, die die SLA-Anforderungen erfüllen.
Sie können eine MPLS- oder Internetverbindung als bevorzugten Pfad auswählen und die Priorität zwischen 1 und 255 zuweisen, wobei ein niedrigerer Wert auf eine bevorzugte Verbindung hinweist. Ein Wert von eins (1) gibt die höchste Priorität an. Wenn mehrere Pfade verfügbar sind, wird derjenige mit der höchsten Priorität ausgewählt.
Wenn beispielsweise ein MPLS-Pfad für VoIP-Datenverkehr ausgewählt wird und während eines Anrufs aufgrund von Jitter oder Paketverlust zu Qualitätsverlusten kommt, werden die Pakete über einen anderen Pfad (Internet) gesendet, der die SLA-Anforderungen erfüllt. Jetzt wird der Anwendungsdatenverkehr über den Internetpfad gesendet, und wenn sich die Qualität im Internetpfad verschlechtert, wird der Pfad wieder auf MPLS umgestellt.
Sie können die Verbindungspriorität und den Linktyp jeder Underlay-Schnittstelle in einer erweiterten richtlinienbasierten Routing-Regel (APBR) konfigurieren, und dieselben Parameter werden an das entsprechende Overlay vererbt. Eine Underlayschnittstelle ist in diesem Fall die letzte ausgehende Schnittstelle in der Routing-Topologie für das Overlay.
Wenn es sich in einer Netzwerkinfrastruktur beispielsweise um eine LTE-Verbindung der vierten Generation (4G) handelt, kann die Dialerschnittstelle als Underlay-Schnittstelle für AppQoE konfiguriert werden. Wenn es sich bei dem Underlay um eine DSL-Verbindung handelt, kann die entsprechende PPPoE-Schnittstelle (Point-to-Point Protocol over Ethernet) als Underlay-Schnittstelle für AppQoE konfiguriert werden.
Der AppQoE-Pfadauswahlmechanismus wurde durch eine benutzerdefinierte Link-Tag-Konfiguration, einen Wechsel des Anwendungsdatenverkehrs zum Link mit höherer Priorität der bevorzugten Tags, eine auf Nicht-SLA-Metriken basierende Bereitstellung und Funktionen zur Einstellung von Overlay-Schnittstellenattributen verbessert.
Vorteile von Anwendungspfadpräferenz und -priorität
-
Bietet Flexibilität bei der Auswahl des besten Pfads für den Anwendungsdatenverkehr.
-
Ermöglicht das Routing von Anwendungsdatenverkehr über die kostengünstige Konnektivitätsoption und stellt gleichzeitig sicher, dass die SLA-Anforderungen (Latenz und Jitter) erfüllt werden.
-
Unterstützt dynamisches Wechseln des Pfads, wenn die Qualität des ausgewählten Anwendungspfads nachlässt.
Mechanismus zur Pfadauswahl
Der Anwendungsdatenverkehr wird über separate Links basierend auf der Linkpräferenz wie folgt weitergeleitet:
-
Der Pfadauswahlmechanismus von AppQoE umfasst eine Liste der besten Pfade zu einem bestimmten Ziel, das die SLA-Anforderungen erfüllt. Aus dieser Liste wählt AppQoE einen Pfad aus, der der vom Benutzer konfigurierten Linkeinstellung entspricht.
-
Wenn mehrere solcher Pfade verfügbar sind, wird der Pfad ausgewählt, der unter allen Pfaden die höchste Priorität hat.
-
Wenn keine Prioritäts- oder Linktypeinstellung konfiguriert ist, wird ein zufälliger Pfad oder der Standardpfad ausgewählt.
-
Wenn keine Links verfügbar sind, die die SLA-Anforderungen erfüllen, wird der beste verfügbare Link in Bezug auf den höchsten SLA-Score und die Präferenz für den Linktyp ausgewählt, falls eine strikte Affinität konfiguriert ist.
-
Wenn mehrere Links verfügbar sind, die die SLA-Anforderungen erfüllen, wird derjenige mit der höchsten Priorität ausgewählt.
Ein Konfigurationsbeispiel finden Sie unter Konfigurieren der WAN-Verbindung mit LTE-Sicherung im Aktiv/Aktiv-Modus.
Systemprotokollmeldungen für AppQoE
Die Protokollierung auf Anwendungsebene wird eingeführt, um die Auswirkungen auf das CSO- oder Protokollsammlungsgerät zu verringern, während eine große Anzahl von Systemprotokollmeldungen verarbeitet wird, die auf Sitzungsebene generiert werden. Das Sicherheitsgerät verwaltet Informationen auf Sitzungsebene und stellt Systemprotokollmeldungen für die Sitzungsebene bereit. Da die Protokollierung auf Anwendungsebene die Protokollierung auf Sitzungsebene ersetzt, verringert sich der Overhead für Sicherheitsgeräte und der Durchsatz der AppQoE-Protokolle steigt.
AppQoE sendet die folgenden Systemprotokollmeldungen:
-
APPQOE_SLA_METRIC_VIOLATION: Wenn ein Verstoß für eine Sitzung erkannt wird und wenn der Pfad einer Sitzung durch das Verschieben zu einem neuen Link aufgelöst wird.
-
APPQOE_BEST_PATH_SELECTED: Wenn eine Sitzung den Pfad für ihren Datenverkehr wechselt.
Bei der Protokollierung auf Anwendungsebene werden alle Protokolle auf Sitzungsebene auf Anwendungsebene unterstützt. Die AppQoE-Funktionalität des Sendens von Echtzeit-Sonden, Messen der SLA-Metriken, der Erkennung von Verstößen und des Pfadwechsels wird auf Sitzungsebene fortgesetzt. Als Teil der Zusammenfassungsfunktion auf Anwendungsebene melden Datenpfadsitzungen jedoch die SLA-Metriken, die Verletzungsinformationen und den Pfadwechsel zur AppQoE-Datenbank. Die auf diese Weise von datapath empfangenen Informationen werden auf Anwendungsebene aggregiert und dann in Form von Systemprotokollen an das Collector-Gerät gesendet.
Tabelle 1 enthält Details zu neuen Protokollen auf Anwendungsebene, die unterstützt werden.
| Systemprotokollmeldung |
Beschreibung |
|---|---|
| APPQOE_APP_SLA_METRIC_VIOLATION |
|
| APPQOE_APP_BEST_PATH_SELECTED |
|
| APPQOE_APP_PASSIVE_SLA_METRIC_REPORT |
|
Mit der Protokollierung auf Anwendungsebene werden die folgenden Änderungen an der AppQoE-Funktionalität eingeführt:
-
Die aktive Sondierung verwaltet und verwendet nur Echtzeit-RTT- und Jitter-Werte. Bei Paketverlusten wird auf die Ursache der vorherigen Sitzung verwiesen, da der Paketverlust erst am Ende des Fensters berechnet werden kann.
-
Während des Konfigurationscommits setzt der aktive Test die RTT- und Jitter-Werte für alle Einträge auf den höchsten 32-Bit-Wert.
-
Die aktive Probe behält die Werte der vorherigen Sitzung bei, bis ein geeigneter Echtzeitwert der Metriken verfügbar ist.
-
Wenn bei aktiver Sondierung ein Paketverlust von 100 % auftritt, werden alle anderen Metriken auf den höchsten 32-Bit-Wert festgelegt.
Melden ungültiger Werte für RTT und Jitter
Wenn die Daten für RTT und Jitter nicht verfügbar sind, werden Meldungen mit dem ungültigen Wert 0xFFFFFFFF gesendet, der vom Protokollsammler ignoriert werden kann. Tabelle 2 enthält einige mögliche Szenarien, wenn die ungültige RTT und der Jitter gesendet werden.
| Szenario |
Betroffene Systemprotokolle |
|---|---|
| 100 % Paketverlust: |
APPQOE_APP_PASSIVE_SLA_METRIC_REPORT APPQOE_APP_SLA_METRIC_VIOLATION |
| Paketverluste größer als 0 und kleiner als 100 %: |
APPQOE_APP_PASSIVE_SLA_METRIC_REPORT APPQOE_APP_SLA_METRIC_VIOLATION |
| Kein Paketverlust |
APPQOE_APP_SLA_METRIC_VIOLATION APPQOE_APP_PASSIVE_SLA_METRIC_REPORT |
Deaktivieren der AppQoE-Protokollierung
Standardmäßig ist der AppQoE-Protokolltyp als Systemprotokoll festgelegt. Wenn Sie AppQoE deaktivieren möchten, konfigurieren Sie den Protokolltyp in der folgenden Konfiguration als deaktiviert:
Application Quality of Experience (AppQoE) basierend auf den DSCP-Bits des eingehenden Datenverkehrs
AppQoE unterstützt die SLA-basierte Pfadauswahl für den eingehenden Datenverkehr auf der Grundlage des DSCP-Werts. AppQoE wählt den bestmöglichen Link für den Anwendungsdatenverkehr basierend auf der Anwendungssignatur oder dem DSCP-Wert oder einer Kombination aus Anwendungsidentifizierung und DSCP-Wert aus.
DSCP-Unterstützung in APBR
Wenn Sie sowohl DSCP als auch dynamische Anwendung in einer APBR-Regel konfigurieren, wird die Regel als Übereinstimmung betrachtet, wenn der Datenverkehr alle in der Regel angegebenen Kriterien erfüllt. Wenn mehrere DSCP-Werte in der APBR-Regel vorhanden sind, wird ein Kriterium als Übereinstimmung betrachtet.
Ein APBR-Profil kann mehrere Regeln enthalten, wobei jede Regel eine Vielzahl von Übereinstimmungsbedingungen aufweist.
Bei mehreren APBR-Regeln in einem APBR-Profil wird bei der Regelsuche die folgende Prioritätsreihenfolge verwendet:
-
Regel mit DSCP + dynamischer Anwendung
-
Regel mit dynamischer Anwendung
-
Regel mit DSCP-Wert
Network Service Orchestrator kann die Anwendung dem DSCP-Wert bei der externen Servicefunktion zuordnen, und dasselbe wird auf dem Gateway-Router bereitgestellt, um den DSCP dem gewünschten SLA-Profil zuzuordnen.
Abbildung 1 zeigt ein Szenario, in dem AppQoE eine SLA-basierte Pfadauswahl für den eingehenden Datenverkehr auf der Grundlage des DSCP-Werts und der Anwendungssignatur in einem Anwendungsszenario für Gatewayrouter vornimmt.
Für den Datenverkehr, der auf dem DSCP-Wert basiert, funktioniert AppQoE wie folgt:
-
Der gesamte Datenverkehr, der über das LAN in den Gateway-Router eingeht, wird einer Anwendungsidentifikation unterzogen. Bis DPI eine Anwendung identifiziert, leitet das System den Datenverkehrsstrom an eine standardmäßige VRF-Instanz (Forwarding Virtual Routing and Forwarding) weiter. VRF enthält eine zugeordnete ausgehende Schnittstelle.
-
Die Junos OS-Anwendungsidentifizierung identifiziert Anwendungen, und sobald eine Anwendung identifiziert wurde, werden ihre Informationen im System-Cache der Anwendung (ASC) gespeichert.
-
Das System prüft weiterhin, ob Anwendungsinformationen aus der DPI-Klassifizierung oder ASC verfügbar sind.
-
Der APBR-Mechanismus klassifiziert Sitzungen basierend auf bekannten Anwendungssignaturen und DSCP-Werten und verwendet Richtlinien, um die bestmögliche Route für die Anwendung zu ermitteln. Die APBR-Richtlinie ordnet den Anwendungsdatenverkehr einem bestimmten VRF zu.
-
Das Vorhandensein einer SLA-Regel in der APBR-Konfiguration löst die AppQoE-Funktionalität aus. AppQoE führt eine SLA-basierte Pfadauswahl für den Datenverkehr basierend auf der Anwendung oder dem DSCP-Wert durch.
Ein einzelner DSCP umfasst mehrere Anwendungskategorien, die gebündelt sind. Unterschiedliche Anwendungskategorien haben ihr individuelles Datenverkehrsmuster. In einem solchen Szenario kann die Erkennung eines Verstoßes mit passiven Sondierungen und deren Anwendung auf alle Sitzungen zu falsch negativen und falsch positiven Ergebnissen führen. Um dieses Problem zu umgehen, vermeiden Sie die Verwendung passiver Sondierungen, wenn Sie eine DSCP-basierte SLA-Regel konfiguriert haben. Sie können aktive Tests für die Zielpfadgruppe verwenden, an die der Datenverkehr weitergeleitet wird.
Begrenzungen
Für AppQoE-Bereitstellungen mit DSCP-basierten Regeln auf dem Gerät gelten im Chassis-Cluster-Modus die folgenden Einschränkungen:
-
Wenn die Regelübereinstimmung abgeschlossen ist, bevor die Anwendungsidentifizierung abgeschlossen ist, und AppQoE die Sitzung auf den anderen Knoten verschiebt, wird die Anwendungsidentifizierung nicht abgeschlossen. Diese Bedingung tritt auf, wenn die DSCP-basierte Regel konfiguriert wird.
-
Wenn Sie zwei APBR-Regeln konfiguriert haben – 1) mit dem DSCP-Wert 2) mit DSCP und dynamischer Anwendung – und in beiden Regeln einen gleichen DSCP-Wert zugewiesen haben, stimmt APBR beim Empfang des ersten Pakets mit der DSCP-Regel überein. Falls der beste Pfad auf dem anderen Knoten identifiziert wird, wird die Sitzung auf den anderen Knoten verschoben. In diesem Szenario werden die Anwendungssitzungen mit der DSCP-Regel und nicht mit der APP+DSCP-Regel abgeglichen.
APBR-Richtlinien für AppQoE
AppQoE nutzt die APBR-Erweiterung und wählt die bestmögliche Verbindung für den von APBR gesendeten Anwendungsdatenverkehr aus, um die in SLA festgelegten Leistungsanforderungen zu erfüllen. AppQoE nutzt die granularen Regelabgleichsfunktionen von APBR, um die Quality of Experience (QoE) auf Basis des Anwendungsdatenverkehrs bereitzustellen.
Sie möchten z. B. Telnet- und HTTPS-Datenverkehr, der in der Vertrauenszone eingeht, über eine optimale verfügbare Verbindung an ein bestimmtes Gerät oder eine bestimmte Schnittstelle weiterleiten. Wenn Datenverkehr in der Vertrauenszone eintrifft, gleicht APBR den Datenverkehr mit den in den APBR-Richtlinien definierten Kriterien Quelladresse, Zieladresse und Anwendungen ab. Wenn der Datenverkehr mit der Richtlinie übereinstimmt, werden die entsprechenden APBR-Profile angewendet.
APBR verwendet die Anwendungsdetails, um im Profil nach einer übereinstimmenden Regel zu suchen. Wenn eine übereinstimmende Regel gefunden wird, wird der Datenverkehr an die angegebene Routinginstanz umgeleitet, wie in der Regel definiert.
AppQoE Multihoming mit Aktiv-Aktiv-Bereitstellung
AppQoE wurde erweitert, um Multi-Homing mit Aktiv-Aktiv-Bereitstellung zu unterstützen. Bisher unterstützte AppQoE Multihoming mit Aktiv-Standby-Bereitstellung.
Bei der Aktiv-Aktiv-Bereitstellung stellt das Spoke-Gerät eine Verbindung mit mehreren Hub-Geräten her. Anwendungsdatenverkehr kann über jedes der Hub-Geräte geleitet werden, wenn die Verbindung zum Hub-Gerät die SLA-Anforderungen erfüllt. Anwendungsdatenverkehr kann im Falle eines SLA-Verstoßes oder der Nichtreaktion des aktiven Hub-Geräts nahtlos zwischen den Hub-Geräten wechseln
Abbildung 1 zeigt eine Mesh-Topologie. In dieser Topologie ist ein Endpunkt über mehr als einen Knoten erreichbar.
Um Multihoming im Aktiv/Aktiv-Modus zu aktivieren, müssen Sie den BGP-Multipath so konfigurieren, dass das Gerät mehrere BGP-Pfade zu gleichen Kosten auswählen kann, um ein bestimmtes Ziel zu erreichen.
Wenn Sie BGP-Multipath aktivieren, wählt das Gerät mehrere BGP-Pfade zu gleichen Kosten aus, um ein bestimmtes Ziel zu erreichen, und alle diese Pfade werden in der Weiterleitungstabelle installiert. AppQoE schließt die Routensuche ab und ruft die Details der Next-Hop-Route zusammen mit den entsprechenden Overlay-Links ab. AppQoE ruft die overlay-link-Eigenschaft aus der konfigurierten Zielpfadgruppe ab.
Basierend auf den SLA-Anforderungen und Link-Einstellungen der Anwendung bestimmt AppQoE den besten Link unter allen Links in dieser Zielpfadgruppe. Im Falle eines SLA-Verstoßes wählt AppQoE basierend auf dem SLA-Score und den Link-Einstellungen alternative Links in der gesamten konfigurierten Zielpfadgruppe aus, wenn der Endpunkt über diese Links erreichbar ist.
Weitere Informationen zur BGP-Multipath-Konfiguration finden Sie unter Beispiele: Konfigurieren von BGP-Multipath.
Einschränkung
In bestimmten Szenarien, wenn sich die Next-Hop-ID für die Route ändert, verbleiben die vorhandenen Sitzungen auf dem SLA-verletzten Link, obwohl ein anderer Link verfügbar ist, der die SLA-Anforderungen erfüllt. Die neuen Sitzungen sind in diesem Fall jedoch nicht betroffen und werden über die Links geleitet, die die SLA-Anforderungen erfüllen.
Support für SaaS-Anwendungen
Wir haben die AppQoE-Unterstützung (Application Quality of Experience) für SaaS-Anwendungen (Software-as-a-Service) erweitert.
AppQoE führt SLA-Messungen (Service Level Agreements) über die verfügbaren WAN-Verbindungen wie Underlay, GRE, IPsec oder MPLS über GRE durch. Anschließend werden die Daten der SaaS-Anwendung über die SLA-konformste Verbindung gesendet, um einen konsistenten Service bereitzustellen.
Unterstützung für IPv6-Datenverkehr
-
Sie können IPv6-Adressen in AppQoE-Konfigurationen verwenden. Der Support umfasst:
- IPv6-Adresse in Overlay-Pfadkonfiguration
- Aktive Sondierungssitzungen mit IPv6-Adressen als Quell- und Zieladresse.
- IPv4- und IPv6-Datenverkehr von der Client-Seite
- Dual Stacking von IPv4 und IPv6 auf der LAN-Seite
- IPv6-Adresse auf der LAN-Seite für SaaS-Tests (Software as a Service).
Stellen Sie für SaaS-Tests sicher, dass Sie sowohl IPv4- als auch IPv6-Adressen für die eingehende Schnittstelle für IPv4- und IPv6-Interoperabilität konfigurieren.
Zusätzliche Plattforminformationen
Verwenden Sie den AppQoE-Funktions-Explorer, um die Plattform- und Releaseunterstützung für bestimmte Funktionen zu bestätigen.
Verwenden Sie die folgende Tabelle, um das plattformspezifische Verhalten für Ihre Plattform zu überprüfen:
| Bahnsteig |
Unterschied |
|---|---|
| SRX-Serie |
Die Spoke-Gerätekonfiguration wird für SRX300, SRX320, SRX345, SRX340, SRX550M und vSRX empfohlen. |
| SRX-Serie |
Die Hub-Gerätekonfiguration wird für SRX1500, SRX4100 und SRX4200 empfohlen. |
| SRX-Serie |
Auf SRX4600 unterstützt AppQoE CoS für GRE nicht, passive Testdetails sind für kurzlebige Sitzungen möglicherweise nicht verfügbar, und die Sitzungsstatussynchronisierung kann auf dem sekundären Knoten in der Datenverkehrsverarbeitung im Z-Modus im Chassis-Cluster-Modus fehlschlagen. |
Tabellarischer Änderungsverlauf
Die Unterstützung der Funktion hängt von der Plattform und der Version ab, die Sie benutzen. Verwenden Sie Funktionen entdecken , um festzustellen, ob eine Funktion auf Ihrer Plattform unterstützt wird.