Quality of Experience für die Anwendung
Anwendungsqualität der Erfahrung (AppQoE)
- Einführung in die Anwendungsqualität
- Vorteile der Anwendungsqualität
- Einschränkungen
- Wie funktioniert die Quality of Experience für die Anwendung?
- Wie die Anwendungsleistung (Quality of Experience) die Anwendungsleistung misst
- Switching des Anwendungst datenverkehrs auf einen alternativen Pfad
Einführung in die Anwendungsqualität
Das unerbittlichen Wachstum von Cloud-Computing, Mobilität und webbasierten Anwendungen setzt voraus, dass das Netzwerk den Datenverkehr auf Anwendungsebene identifiziert und kontrolliert und jeden Anwendungstyp separat behandelt, um Benutzern eine qualitativ hochwertige Benutzererfahrung (QoE) bieten zu können. Um anwendungsspezifischen QoE (AppQoE) zu gewährleisten, müssen Sie Anwendungsverkehr 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). Sie verwendet AppID, um bestimmte Anwendungen in Ihrem Netzwerk und erweitertes richtlinienbasiertes Routing (APBR) zu identifizieren, um einen Pfad für bestimmten Datenverkehr festzulegen, indem SLA-Profile zu einer Routinginstanz verbunden werden, auf der der Anwendungdatenverkehr anhand der APBR-Regeln gesendet wird.
Eine der wichtigsten Anforderungen an ein softwaredefiniertes WAN (SD-WAN) ist die Messung der Qualität der Underlay-Netzwerkpfade und die Ermittlung der besten Pfade für die Bereitstellung jedes Pakets. AppQoE überwacht die Leistung von geschäftskritisch-Anwendungen und wählt basierend auf dem Ergebnis die beste Verbindung für diesen Anwendungstirnverkehr 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-Funktion aus. Wenn keine SLA-Profile verfügbar sind, werden die APBR-Funktionen ohne AppQoE-Trigger unterstützt.
Unterstützter Einsatzfall
Sie können AppQoE optimal mit Contrail Service Orchestration (CSO). Wir empfehlen, dass Sie CSO verwenden, um AppQoE für eine Juniper Networks Contrail SD-WAN konfigurieren. Weitere Informationen finden Sie unter "Application Quality of Experience Overview and Configure and Monitor Application Quality of Experience" (Anwendungsqualität der Benutzererfahrung),und konfigurieren und überwachen.
Unterstützte Geräte der SRX-Serie
AppQoE wird sowohl auf Hub-and-Spoke- als auch Full-Mesh-Topologien in SD-WAN unterstützt.
Sie können vSRX Instanzen, SRX300-Leitungsgeräte, SRX550M als Spoke-Geräte und SRX1500, SRX4100 und SRX4200 als Hub-Geräte konfigurieren.
Sie können eine AppQoE zwischen zwei Endpunkten der SRX-Serie (ohne Buch) konfigurieren, und beide Geräte der SRX-Serie müssen über die gleiche Version des Junos OS verfügen.
AppQoE wird ab Junos OS version 15.1X49-D160 und im Junos OS 19.1R1 unterstützten SRX4100- und SRX4200-Geräte AppQoE, wenn die Geräte sich im Gehäuse-Clustermodus befinden. Sie können das Gerät so konfigurieren, dass es sowohl im Aktiv/Aktiv- als auch im Aktiv/Passiv-Modus betrieben wird und das Gerät als Spoke-Gerät in SD-WAN Bereitstellungen bereitstellen.
Vorteile der Anwendungsqualität
Ermöglicht eine kostengünstige Dienstqualität (QoE) durch die Echtzeitüberwachung des Anwendungverkehrs, um ein einheitliches und vorhersehbares Serviceniveau zu bieten.
Erhöht die Kundenbindung und -zufriedenheit durch Bereitstellung eines garantierten SLA für die Bereitstellung bestimmten Datenverkehrs (z. B. Videodatenverkehr). AppQoE stellt sicher, dass der genehmigte Datenverkehr die entsprechende Priorität und Bandbreite erhält, die für den Benutzer die beste Quality of Experience benötigt wird.
Einschränkungen
Die Implementierung von AppQoE auf Sicherheitsgeräten hat folgende Einschränkungen:
Alle verschiedenen Routen zum Ziel müssen über unterschiedliche Schnittstellen die gleichen Vorlieben, dasselbe Gewicht und die gleichen konfigurierten Metriken haben. Alle Routen müssen als ECMP-Pfade für das Ziel hinzugefügt werden und gleichzeitig Teil der selben Weiterleitungstabelle sein.
AppQoE SLA-Service nur zwischen zwei Endgeräten für Sicherheit (book-ended) wird unterstützt. Der End-to-End-AppQoE SLA-Service wird nicht unterstützt.
AppQoE kann nur dann angewendet werden, wenn alle Schnittstellen teil der gleichen Zone sind.
AppQoE kann nicht für umgekehrten Datenverkehr angewendet werden.
AppQoE hat keinerlei Einfluss auf Änderungen am Zielort für eine Sitzung.
AppQoE unterstützt keine IPv6/UDP-Probe-Kapselung, GRES, Chassis Cluster (ISSU, hohe Verfügbarkeit, duale CPE-Hohe Verfügbarkeit, Z-Mode-Hochverfügbarkeit) und logische Systeme.
AppQoE unterstützt keine bevorzugte Pfadauswahl und virtuelles Transit-Routing und Forwarding (VRF).
AppQoE unterstützt keine passive Ausspähung in IPv6-Datenpaketen.
An den Nicht-WAN-Schnittstellen ist ein Eingangs-Firewallfilter erforderlich, um UDP-Pakete mit dem UDP-Zielport 36000 zu verwerfen.
Das Gerät SRX4600 hat folgende Einschränkungen:
Die Class-of-Service (CoS) für Generic Routing Encapsulation (GRE) wird nicht unterstützt, wenn AppQoE konfiguriert ist.
Passive Testdetails sind möglicherweise nicht für jede kurzlebige Sitzung verfügbar.
Die Synchronisierung von Sitzungszuständen kann beim Datenverkehrsverarbeitung im Z-Line-Modus unter Umständen nicht am sekundären Knoten im Z-Line-Modus geschehen, wenn das Gerät im Chassis-Clustermodus ausgeführt wird.
Wie funktioniert die Quality of Experience für die Anwendung?
AppQoE nutzt AppID- und APBR-Funktionen, um bestimmte Anwendungen/Anwendungsgruppen zu identifizieren und einen Pfad für bestimmten Datenverkehr festzulegen, indem SLA-Profile zu einer Routinginstanz assoziiert werden, auf der der Anwendungst datenverkehr wie unter APBR-Regeln gesendet wird.
AppQoE überwacht die Leistung von Anwendungen und wählt basierend auf diesem Ergebnis die beste Verbindung für diesen Anwendungstirnverkehr aus, um die in der SLA (Service Level Agreement) festgelegten Leistungsanforderungen zu erfüllen.
- Identifizieren von Anwendungen oder Anwendungsgruppen
- Angabe des Pfads für Anwendungen oder Anwendungsgruppen
- Datenverkehrspfadauswahl für Anwendungen
Identifizieren von Anwendungen oder Anwendungsgruppen
Die folgenden Schritte sind bei der Identifizierung von Anwendungen oder Anwendungsgruppen beteiligt:
Junos OS Anwendungsidentifikation identifiziert Anwendungen, und sobald eine Anwendung identifiziert wurde, werden ihre Informationen im AsC (Application System Cache) gespeichert.
APBR bewertet die Pakete basierend darauf, ob die Sitzung für anwendungsbasiertes Routing (advance policy-basiertes Routing) kandidat ist. Wenn es sich um das erste Paket der neuen Sitzung handelt und der Datenverkehr nicht für anwendungsbasiertes Routing gekennzeichnet wird, wird die normale Verarbeitung (nicht APBR-Route) zum Ziel übertragen.
Wenn die Sitzung anwendungsbasiertes Routing benötigt, fragt APBR das ASC-Modul ab, um die Anwendungsattribute (IP-Adresse, Ziel-Port, Protokolltyp und Service) zu erhalten.
-
Wenn die Anwendung in ASC gefunden wird, wird der Datenverkehr weiter zur Übereinstimmungsregel im APBR-Profil verarbeitet.
-
Wenn eine entsprechende Regel gefunden wird, wird der Datenverkehr zur Routensuche an die angegebene Routinginstanz umgeleitet.
-
AppQoE überprü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 Probes für Leistungsmessungen.
-
Wenn SLA in der APBR-Regel nicht für die Sitzung aktiviert ist, ignoriert AppQoE diese Sitzung und das Standardverhalten von APBR wird auf diese Sitzungen angewendet. Das heißt, der Datenverkehr wird über die angegebene Routinginstanz zum Ziel geroutet.
-
Wenn die Anwendung nicht in ASC entdeckt wird, fordert APBR eine tiefgehende Untersuchung des Datenflusses an. d. h. das Paket zur Anwendungssignatur wird installiert und die Anwendungsidentifizierung für die Sitzung aktiviert. So können ASC zur Nutzung durch nachfolgende Sitzungen zur APBR-Verarbeitung gefüllt werden (siehe Schritt 2).
-
Angabe des Pfads für Anwendungen oder Anwendungsgruppen
Die folgenden Schritte fassen zusammen, wie AppQoE einen Pfad für den Anwendungdatenverkehr gemäß den SLA-Regeln angibt.
APBR verwendet die Anwendungsdetails, um nach einer übereinstimmenden Regel im APBR-Profil (Anwendungsprofil) zu suchen. Datenverkehr, der den Anwendungen und Anwendungsgruppen abgleicht, wird an die statische Route und die Next-Hop-Adresse weitergeleitet, wie in der Routinginstanz angegeben.
Eine dem APBR-Profil angehängte SLA-Regel gibt Parameter an, die zur Messung der SLA und zur Identifizierung von SLA-Verstößen erforderlich sind.
Der Anwendungsdatenverkehr wird einer bestimmten Overlay-Verbindung anhand der SLA-Kennzahlen dieser Overlay-Verbindung zugewiesen, die mithilfe von aktivem Probing gemessen wird.
Der SLA-Verstoß wird durch die passive Auslotung des Live-Datenverkehrs in Anwendungs-/Anwendungsgruppen ermittelt. Der beste Pfad/Overlay-Link für die Anwendungs-/Anwendungsgruppe wird mit dem Algorithmus der Pfadauswahl ermittelt.
Datenverkehrspfadauswahl für Anwendungen
Die folgenden Schritte führen zum Routing von Datenverkehr von Quelle zu Ziel durch, insbesondere um den besten Pfad zu wählen,
Wenn die Anwendung bereits für das erste Datenpaket eines Datenstroms (den ersten Pfad) bekannt ist (aus der ASC-Suche), wird der beste Pfad für die Anwendung in der Datenbank durchsucht. Wenn die Anwendung nicht bekannt ist oder neu ist (aus der ASC-Suche), dann wird ein beliebiger Pfad oder der Standardpfad ausgewählt. Dieser Pfad wird für die gesamte Sitzung fortgesetzt. Später, nachdem der DPI die Anwendung erkannt hat, wird die Datenbank mit dem besten Pfad für die Anwendung aktualisiert.
Wenn die Anwendung zunächst nicht bekannt ist, bleibt die Sitzung im restlichen Datenpaket eines Datenflusses (Fast Path) auf dem gleichen Pfad weiter. Wenn die Anwendung zunächst bekannt ist, dann wählt AppQoE den besten Pfad für den Anwendungverkehr.
Wenn eine neue Anwendung erkannt wird, versucht der Pfadauswahlmechanismus, einen Pfad zu finden, der alle SLA-Kennzahlen erfüllt. Wenn ein solcher Pfad nicht vorhanden ist, wird der nächste beste Pfad (basierend auf der Anzahl der zufriedenen Metriken) verwendet. Wenn mehrere Pfade die Metriken erfüllen, wird ein beliebiger Pfad zwischen den verfügbaren Pfaden ausgewählt. Der SLA-Verstoß wird erkannt, wenn eine der Kennzahlen gegen eine Verstoß verstößt oder keine der Kennzahlen die Anforderungen erfüllt (basierend auf der Profilkonfiguration).
Wie die Anwendungsleistung (Quality of Experience) die Anwendungsleistung misst
Die Anwendungsleistung wird durch folgende Indikatoren bestimmt:
Latenz: Die Für das Reisen von Medien benötigte Zeit hängt von der Länge und Entfernung der zu abgedeckten Medien ab.
RTT: Für die Reise von der Quelle zum Ziel und umgekehrt wird eine Hin- und Rückreisezeit benötigt.
Paketverlust– Paketverlust spiegelt die Anzahl der verlorenen Pakete pro 100 von einem Host gesendeten Pakete wider.
Jitter: Jitter ist der Unterschied in der Latenz von Paket zu Paket. Für die Bewertung der Leistung des Links können Ingress-Jitter, Egress-Jitter und Two-Way-Jitter festgelegt werden.
AppQoE überwacht RTT, Jitter und Paketverluste auf jeder Verbindung und lenkt auf Grundlage des Punktes Anwendungen nahtlos auf den alternativen Pfad um, wenn die Leistung der primären Verbindung unter einem akzeptablen Niveau liegt, das von SLA angegeben ist. Die Messung und Überwachung der Anwendungsleistung erfolgt mit aktiven und passiven Sondierungen zur Erkennung von SLA-Verstößen und zum Auswählen eines alternativen Pfads für diese bestimmte Anwendung.
AppQoE erfasst Echtzeitdaten durch die kontinuierliche Überwachung des Anwendungsdatenverkehrs und identifiziert Netzwerk- oder Geräteprobleme durch:
Überwachung der Leistung aller konfigurierten Overlay-Links.
Verwenden passiver Probes (inline mit der Anwendungsdatenpath)- und aktiver Probes (synthetische Probes für bestimmte Anwendungen), um die Datenverkehrsleistung für die Anwendung oder Anwendungsgruppe zu überwachen.
Sie senden alle erfassten Leistungskennzahlen oder Metadaten zur Analyse an einen Protokollsammler.
Vergleichen der angegebenen Anwendung mit einer bestimmten Leistungskennzahl und dynamisches Ändern des Pfads für den Anwendungst datenverkehr im Fall eines SLA-Verstoßes.
Unterstützung flexibler SLA-Kennzahlkonfigurationen für eine bestimmte Anwendung oder Anwendungsgruppe.
AppQoE misst die Anwendungs-SLA über mehrere WAN-Verbindungen und ordnet den Anwendungverkehr einem Pfad zu den verfügbaren Links zu, d. r. dem Pfad, der die SLA-Anforderungen am besten erfüllt.
Messung der Anwendungsleistung durch Verwendung aktiver und passiver Sondierungen
Aktive und passive Probemessungen sind die beiden Ansätze, die für die End-to-End-Analyse des Netzwerks verwendet werden.
Aktive Probe: Aktive Probes messen die Dienstqualitä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-Points auf allen mehreren Routen gesendet und rtT, Latenz, Jitter und Paketverluste werden zwischen den installierten Prüfpunkten gemessen. Die aktiven Probes werden regelmäßig an allen aktiven und passiven Links gesendet. Es wird eine konfigurierte Anzahl von Mustern gesammelt und ein laufender Durchschnitt für den Testpfad jeder Anwendung gemessen. Wenn bei Anwendungsdatenverkehr ein Verstoß festgestellt wird, werden die Testkennzahlen ausgewertet, um die beste Verbindung zu bestimmen, die den SLA erfüllt.
Passive Probe: Passive Probes werden auf Verbindungen im Netzwerk installiert und überwachen den ganzen Datenverkehr, der durch diese Verbindungen fließt.
Passive Auslotung überwacht Links bei SLA-Verstößen bei Live-Datenverkehr. In einer passiven Probe werden die eigentlichen Datenpakete im Live-Datenverkehr zwischen den Book-End-Punkten der SRX-Serie in einem IP/UDP-Probe-Header eingekapselt, und RTT, Jitter und Paketverluste zwischen den Installationspunkten der Prüfsonden werden zur Berechnung der Servicequalität gemessen.
Wenn bei einer Anwendung ein Verstoß festgestellt wird, werden die synthetischen Testmetriken ausgewertet, um die beste Verbindung zu bestimmen, die den SLA erfüllt.
Hinweis:Beginnend mit Junos OS Release 18.3R1 und Junos OS Release 15.1X49-D150, auf allen unterstützten Geräten der SRX-Serie und vSRX-Instanzen, um zu erkennen, ob eine Verbindung oder ein Pfad durch passive Probes ausbraucht, müssen innerhalb eines Samplingzeitraums mindestens drei Testanfragen und 100 % Paketverluste auftreten, um für eine bestimmte Sitzung SLA-Verstöße auszulösen.
Hinweis:Wenn das Gerät im Chassis-Clustermodus ausgeführt wird, wenn der sekundäre Knoten (Knoten 1), über den der Datenverkehr weitergeleitet wird, neu gestartet wird, erfolgt mehreres Switching des Anwendungstrangs zwischen den Verbindungen über sekundäre Knotenverbindungen. Dies geschieht, wenn die verfügbaren Links auf dem primären Knoten (Knoten 0) einen weniger aktiven TEST-SLA-Pfad im Vergleich zu den sekundären Knotenverbindungen haben. Dieses Verhalten wird fortgesetzt, bis AppQoE als Ergebnisse des aktiven SLA-Pfads verfügbar sind, um anzuzeigen, dass auf allen Verbindungen auf dem sekundären Knoten ein Paketverlust von 100 % besteht.
Sie können eine SLA-Regel mit aktiven und passiven Testparametern konfigurieren und die SLA-Regel dem APBR-Profil zuordnen. Das APBR-Profil enthält auch eine APBR-Regel. Regeln werden einer oder mehrere Anwendungen oder Anwendungsgruppen zugeordnet, und der Datenverkehr, der der Regel entsprechen, wird an die Routinginstanz umgeleitet.
AppQoE löst die Testanforderungen an alle Testpfade der Anwendung aus. Aktive und passive Probes überwachen das Netzwerk auf Bereiche oder Points of Failures oder Überlastungen.
AppQoE erfasst Datenverkehrsklassenstatistiken für erlernte Anwendungen mit aktiven und passiven Probes und ergreift folgende Aktionen:
Leistungsmessung für SLA: Die von den Prüfsonden bereitgestellten Echtzeitkennzahlen werden verwendet, um die Servicequalität entsprechend der SLA einer Anwendung zu bewerten und zu bestimmen, ob der Anwendungspfad die SLA-Anforderungen nicht erfüllt. Wenn also bei einer Anwendung ein Verstoß erkannt wird, werden die synthetischen Testmetriken ausgewertet, um die beste alternative Verbindung für den Anwendungsdatenverkehr zu bestimmen, die den SLA erfüllt.
Datenverkehr umleiten: Switchen Sie den Anwendungst datenverkehr zwischen den beiden Verbindungen, d. a. bei Leistungsproblemen einer Verbindung, wird der Datenverkehr während der gleichen Sitzung an einen 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 der SLA-Regel der Anwendung beifügen.
Switching des Anwendungst datenverkehrs auf einen alternativen Pfad
Sie können das Switching des Anwendungst datenverkehrs zu einer anderen Route (lokal auf dem Gerät) während eines SLA-Verstoßes aktivieren bzw. deaktivieren. Wenn das Switching lokaler Routen aktiviert ist, wird das Switching des Anwendungst datenverkehrs auf eine alternative Route aktiviert, und es stehen auch SLA-Überwachungs- und Berichtsfunktionen zur Verfügung. Selbst wenn die Option für das Switching des Anwendungdatenverkehrs auf einen alternativen Pfad in der SLA-Regelkonfiguration deaktiviert ist, behebt AppQoE SLA-Verstöße--- z. B. durch das Switching des Anwendungdatenverkehrs auf einen neuen Pfad
Wenn das Switching lokaler Routen deaktiviert ist, stehen nur SLA-Überwachungs- und Berichtsfunktionen zur Verfügung, und das Switching des Anwendungverkehrs auf diese route aufgrund eines SLA-Verstoßes wird deaktiviert.
Wenn der Datenverkehr einer Anwendung auf einen alternativen Pfad umgeschaltet wird, wird es einen kurzen Zeitraum geben, in dem der Anwendungst datenverkehr im Fall eines SLA-Verstoßes nicht erneut auf einen anderen Pfad umgeschaltet werden kann. Dieser Zeitraum hilft ihnen dabei, zu vermeiden, dass der Datenverkehr über Verbindungen hinweg überschlagt wird.
Kenntnis über die Grenzen der AppQoE-Konfiguration
Beginnend ab Junos OS Release 15.1X49-D160 und im Junos OS Release 19.1R1 setzt AppQoE die Konfigurationsbegrenzung für Overlay-Pfade, Metrikprofile, Testparameter und SLA-Regeln pro Profil durch, wenn Sie anwendungsspezifische SLA-Regeln konfigurieren und die SLA-Regeln einem APBR-Profil zuordnen.
Wenn Sie die Parameter mehr als den zulässigen Limit konfigurieren, werden fehlermeldungen angezeigt, wenn Sie die Konfiguration festlegen.
Beispiele für Fehlermeldungen:
Die folgenden Beispiel-Fehlermeldungen wurden vom SrX4100- und SRX4200-Gerät gesendet. Der Wert der Konfigurationsbegrenzung spiegelt möglicherweise nicht die exakte unterstützte Anzahl wider. kann sich zwischen den unterstützten Geräten unterscheiden,
[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 basierend auf Linkpräferenz und Priorität
Eine der wichtigsten Anforderungen an ein softwaredefiniertes WAN (SD-WAN) ist die Messung der Qualität der Underlay-Netzwerkpfade und die Ermittlung der besten Pfade für die Bereitstellung jedes Pakets.
Beginnend ab Junos OS Release 18.4R1 und im Junos OS Release 15.1X49-D160 können Sie anwendungsspezifische Quality of Experience (AppQoE) konfigurieren, um den Anwendungspfad basierend auf der Verbindungspriorität und dem Verbindungstyp auszuwählen, wenn mehrere Pfade verfügbar sind, die die SLA-Anforderungen erfüllen.
Sie können eine MPLS oder eine Internetverbindung als bevorzugten Pfad auswählen und die Priorität zwischen 1 und 255 mit einem niedrigeren Wert zuweisen, der eine bevorzugte Verbindung angibt. Ein Wert von einer (1) gibt die höchste Priorität an. Wenn mehrere Pfade verfügbar sind, wird der Pfad mit der höchsten Priorität ausgewählt.
Wenn beispielsweise ein MPLS-Pfad für VoIP-Datenverkehr ausgewählt wird und bei einem Anruf aufgrund von Jitter oder Paketverlusten eine Beeinträchtigung der Qualität auftritt, werden die Pakete über einen anderen Pfad (Internet) gesendet, der SLA-Anforderungen erfüllt. Jetzt wird der Anwendungst datenverkehr über den Internetpfad gesendet. Wenn sich die Qualität des Internetpfads beeinträchtigt, dann wird der Pfad zurück auf MPLS.
Sie können die Verbindungspriorität und den Verbindungstyp jeder Underlay-Schnittstelle in einer erweiterten, richtlinienbasierten Routing-Regel (APBR) konfigurieren, und die gleichen Parameter werden durch das entsprechende Overlay übernommen. In diesem Fall ist eine Underlay-Schnittstelle die letzte ausgehende Schnittstelle in der Routing-Topologie für das Overlay.
Wenn das Underlay beispielsweise eine LTE-Verbindung der vierten Generation (4G) ist, kann die Dialer-Schnittstelle in einer Netzwerkinfrastruktur als Underlay-Schnittstelle für AppQoE konfiguriert werden. Wenn das Underlay eine DSL-Verbindung ist, kann auch die entsprechende Point-to-Point Protocol over Ethernet (PPPoE)-Schnittstelle als Underlay-Schnittstelle für AppQoE konfiguriert werden.
Beginnend ab Junos OS Version 21.2R1 wird der AppQoE-Pfadauswahlmechanismus mit benutzerdefinierter Link-Tag-Konfiguration, Anwendungsdatenverkehr-Switch zu der bevorzugten Link der bevorzugten Tags, nicht SLA-metrikenbasierte Bereitstellung und Einstellungsfunktionen für Overlay-Schnittstellen verbessert.
Vorteile von Anwendungspfadpräferenz und -priorität
-
Bietet die Flexibilität bei der Auswahl des besten Pfads für Anwendungdatenverkehr.
-
Routing des Anwendungst datenverkehrs über die kostengünstige Verbindungsoption bei gleichzeitiger Einhaltung der SLA-Anforderungen (Latenz und Jitter).
-
Unterstützt dynamisches Path Switching, wenn die Qualität des ausgewählten Anwendungspfads abschädiert wird.
Pfadauswahlmechanismus
Der Anwendungstr.-Datenverkehr wird über separate Links je nach Verbindungspräferenz wie folgt geroutet:
-
Der AppQoE-Pfadauswahlmechanismus enthält eine Liste der besten Pfade zu einem bestimmten Ziel, die die SLA-Anforderungen erfüllen. In dieser Liste wählt AppQoE einen Pfad aus, der der vom Benutzer konfigurierten Linkpräferenz entspricht.
-
Wenn es mehrere solche Pfade gibt, wird der Pfad ausgewählt, dem die höchste Priorität eingeräumt wird.
-
Wenn keine Priorität oder Einstellung des Linktyps konfiguriert ist, wird ein beliebiger Pfad oder der Standardpfad ausgewählt.
-
Wenn keine Links verfügbar sind, die die SLA-Anforderungen erfüllen, wird der beste verfügbare Link hinsichtlich der höchsten SLA-Punktzahl und der Präferenz des Linktyps ausgewählt, falls eine strict Affinität konfiguriert ist.
-
Wenn mehrere Verbindungen verfügbar sind, die den SLA-Anforderungen entsprechen, wird die mit der höchsten Priorität ausgewählt.
Systemprotokollmeldungen für AppQoE
Beginnend im Junos OS Veröffentlichungs-19.2R1 wird die Protokollierung auf Anwendungsebene für AppQoE auf Geräten der SRX-Serie unterstützt. Diese Funktion wird eingeführt, um die Auswirkungen auf CSO- oder Log Collector-Gerät zu reduzieren und gleichzeitig eine große Anzahl an Systemprotokollmeldungen zu verarbeiten, die auf Sitzungsebene generiert werden. Das Sicherheitsgerät verwaltet Informationen auf Sitzungsebene und stellt Systemprotokollmeldungen für die Sitzungsebene zur Verfügung. Da die Protokollierung auf Anwendungsebene die Protokollierung auf Sitzungsebene ersetzt, nimmt der Aufwand für das Sicherheitsgerät ab und der AppQoE-Protokolldurchsatz steigt.
AppQoE sendet folgende Systemprotokollmeldungen:
APPQOE_SLA_METRIC_VIOLATION: Wenn ein Verstoß für eine Sitzung erkannt wird und der Pfad einer Sitzung als Folge der Bewegung zu einer neuen Verbindung gelöst wird.
APPQOE_BEST_PATH_SELECTED: Wenn eine Sitzung den Pfad für den Datenverkehr wechselt.
Mit der Protokollierung auf Anwendungsebene werden alle Protokolle auf Sitzungsebene auf Anwendungsebene unterstützt. Die AppQoE-Funktion des Sendens von Echtzeitsonden, Messen der SLA-Kennzahlen, Erkennung von Verstößen und Pfad-Switch wird auf Sitzungsebene fortgesetzt. Als Teil der Zusammenfassungsfunktion auf Anwendungsebene benachrichtigen Datenpath-Sitzungen sla-Kennzahlen, Verletzungsinformationen und den Pfad-Switch zur AppQoE-Datenbank. Die so aus dem 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 ab der Junos OS Veröffentlichung 19.2R1 werden.
Systemprotokollnachricht |
Beschreibung |
|---|---|
APPQOE_APP_SLA_METRIC_VIOLATION |
|
APPQOE_APP_BEST_PATH_SELECTED |
|
APPQOE_APP_PASSIVE_SLA_METRIC_REPORT |
|
Die Protokollierung auf Anwendungsebene führt zu den folgenden Änderungen der AppQoE-Funktionen ein:
Active Probe behält RTT- und Jitter-Werte in Echtzeit bei und verwendet sie. Bei Paketverlusten bezieht er sich auf die Ursache der vorherigen Sitzung, da der Paketverlust nur am Ende des Fensters berechnet werden kann.
Während des Konfigurations-Commits setzt Active Probe die RTT- und Jitter-Werte auf den höchsten 32-Bit-Wert für alle Einträge.
Die aktiven Probe speichert die Werte früherer Sitzungen so lange, bis ein entsprechender Echtzeitwert der Metriken verfügbar ist.
Wenn bei der aktiven Analyse ein 100 %igen Paketverlust zu tage kommt, werden alle anderen Kennzahlen auf den höchsten 32-Bit-Wert festgelegt.
Meldung ungültiger Werte für RTT und Jitter
Wenn die Daten für RTT und Jitter nicht verfügbar sind, protokollieren Sie Nachrichten mit einem ungültigen Wert der 0xFFFFFFFF, die vom Protokollsammler ignoriert werden. Tabelle 2 enthält einige mögliche Szenarien, wenn der ungültige RTT und Jitter gesendet wird.
Szenario |
Betroffene Systemprotokolle |
|---|---|
100 % Paketverlust: |
APPQOE_APP_PASSIVE_SLA_METRIC_REPORT APPQOE_APP_SLA_METRIC_VIOLATION |
Paketverluste über 0 und weniger 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 |
AppQoE-Protokollierung deaktivieren
Standardmäßig wird der AppQoE-Protokolltyp als Systemprotokoll festgelegt. Wenn Sie AppQoE deaktivieren möchten, konfigurieren Sie den Protokolltyp in der folgenden Konfiguration als deaktiviert:
Anwendungsqualität der Benutzererfahrung (AppQoE) Basierend auf den DSCP-Bits des eingehenden Datenverkehrs
Um dieses Szenario zu überwinden, unterstützt AppQoE ab dem Junos OS Release 19.4R1 SLA-basierte Pfadauswahl für den eingehenden Datenverkehr basierend auf einem DSCP-Wert. AppQoE wählt basierend auf der Anwendungssignatur, dem DSCP-Wert oder der Kombination aus Anwendungsidentifizierung und DSCP-Wert die bestmögliche Verbindung für den Anwendungsdatenverkehr aus. Siehe
DSCP-Unterstützung in APBR
Wenn Sie DSCP und dynamische Anwendungen in einer APBR-Regel konfigurieren, wird die Regel als Übereinstimmung angesehen, wenn der Datenverkehr allen in der Regel angegebenen Kriterien entspricht. Wenn in der APBR-Regel mehrere DSCP-Werte vorhanden sind, wird diese als Übereinstimmung angesehen, wenn ein oder mehrere Kriterien übereinstimmen.
Ein APBR-Profil kann mehrere Regeln enthalten, jede Regel mit einer Vielzahl von Übereinstimmungsbedingungen.
Bei mehreren APBR-Regeln in einem APBR-Profil verwendet die Regelsuche die folgende Prioritätsgeordnet:
Regeln mit DSCP + dynamischen Anwendungen
Regeln mit dynamischer Anwendung
Regel mit DSCP-Wert
Network Service Orchestrator kann die Anwendung mit dem DSCP-Wert bei externer Servicefunktion zuordnen und das gleiche wird am Gateway-Router bereitgestellt, um das DSCP dem gewünschten SLA-Profil zuzuordnen.
Abbildung 1 zeigt ein Szenario, in dem AppQoE eine SLA-basierte Pfadauswahl für den eingehenden Datenverkehr basierend auf dem DSCP-Wert und der Anwendungssignatur in einem Gateway-Router-Anwendungsfall ausführt.
Für den auf dem DSCP-Wert basierenden Datenverkehr funktioniert AppQoE wie folgt:
-
Der sämtliche beim Gateway-Router aus dem LAN eindrungene Datenverkehr wird einer Anwendungsidentifikation unterzogen. Solange DPI eine Anwendung identifiziert, weiterleitungt das System den Datenverkehrsstrom an eine Standard-VRF-Instanz (Forwarding Virtual Routing and Forwarding). VRF umfasst eine damit verbundene ausgehende Schnittstelle.
-
Junos OS Anwendungsidentifikation identifiziert Anwendungen, und sobald eine Anwendung identifiziert wurde, werden ihre Informationen im AsC (Application System Cache) gespeichert.
-
Das System überprüft weiterhin, ob Anwendungsinformationen entweder über die DPI-Klassifizierung oder ASC verfügbar sind.
-
Der APBR-Mechanismus klassifiziert Sitzungen basierend auf bekannten Anwendungssignaturen und DSCP-Werten und verwendet Richtlinien zur Ermittlung des bestmöglichen Routens für die Anwendung. Die APBR-Richtlinie ordnet Anwendungverkehr einer bestimmten VRF zu.
-
Das Vorhandensein einer SLA-Regel in der APBR-Konfiguration löst die AppQoE-Funktion aus. AppQoE führt eine SLA-basierte Pfadauswahl für den Datenverkehr basierend auf der Anwendung oder dem DSCP-Wert durch.
Ein einzelnes DSCP umfasst mehrere Anwendungskategorien, die in dieses Paket gebündelt sind. Verschiedene Anwendungskategorien haben ihr individuelles Datenverkehrsmuster. In einem solchen Szenario kann die Erkennung von Verstößen mithilfe passiver Sondierungen und deren Anwendung auf alle Sitzungen zu falsch-negativen und falsch-positiven Alarmen führen. Vermeiden Sie als Umgehungslösung die Verwendung passiver Analyse, wenn Sie eine DSCP-basierte SLA-Regel konfiguriert haben. Sie können aktive Probes für die Zielpfadgruppe verwenden, an die der Datenverkehr weitergeleitet wird.
Einschränkungen
AppQoE-Bereitstellungen mit DSCP-basierten Regeln auf dem Gerät haben im Chassis-Clustermodus folgende Einschränkungen:
-
Wenn die Regel übereinstimmung vor dem Abschluss der Anwendungsidentifizierung abgeschlossen ist und AppQoE die Sitzung auf den anderen Knoten verschiebt, wird die Anwendungsidentifikation nicht abgeschlossen. Dieser Zustand tritt auf, wenn die DSCP-basierte Regel konfiguriert ist.
-
Wenn Sie zwei APBR-Regeln konfiguriert haben– 1) mit DSCP-Wert 2) sowohl mit DSCP als auch mit dynamischer Anwendung, und beim Empfang des ersten Pakets einen DSCP-Wert zuweisen, entspricht APBR der DSCP-Regel. Falls der beste Pfad auf dem anderen Knoten identifiziert wird, wird die Sitzung auf den anderen Knoten verschoben. In diesem Szenario werden die Anwendungssitzungen auf die DSCP-Regel und nicht auf die APP+DSCP-Regel abgestimmt.
APBR-Richtlinien für AppQoE
AppQoE beginnt Junos OS dem 20.1R1 und nutzt die granulare Regelvergleichsfunktion von APBR, um eine auf dem Anwendungstirnverkehr basierende Quality of Experience (QoE) zu bieten.
Im Junos OS-18.2R1 APBR durch das Konfigurieren von Richtlinien durch Definition von Quelladressen, Zieladressen und Anwendungen als Übereinstimmungsbedingungen unterstützt. Nach einer erfolgreichen Übereinstimmung wird das konfigurierte APBR-Profil als Anwendungsdienste für die Sitzung angewendet. Im Junos OS Release 20.1R1 nutzt AppQoE die APBR-Erweiterung und wählt die bestmögliche Verbindung für den Anwendungstirnverkehr aus, die von APBR gesendet wird, um die in SLA festgelegten Leistungsanforderungen zu erfüllen.
Sie möchten zum Beispiel telnet- und HTTPS-Datenverkehr, der in der Trust Zone einschlägt, über einen bestmöglichen Link an ein bestimmtes Gerät oder eine Schnittstelle weitergeleitet werden. Wenn der Datenverkehr in der Trust Zone ankommt, entspricht APBR dem Datenverkehr mit der in APBR-Richtlinien definierten Kriterien Quelladresse, Zieladresse und Anwendungen. Wenn der Datenverkehr mit der Richtlinie entspricht, werden entsprechende APBR-Profile angewendet.
APBR verwendet die Anwendungsdetails, um nach einer übereinstimmenden Regel im Profil zu suchen. Wenn eine übereinstimmungsgleiche Regel gefunden wird, wird der Datenverkehr an die in der Regel angegebene Routing-Instanz umgeleitet.
AppQoE Multi-Homing mit Aktiv-Aktiv-Bereitstellung
AppQoE Junos OS der 20.2R1 startende Version wird erweitert, um Multi-Homing mit aktiv-aktiver Bereitstellung zu unterstützen. Zuvor unterstützte AppQoE Multihoming mit Aktiv-Standby-Bereitstellung.
Bei einer aktiv-aktiven Bereitstellung verbindet das Spoke-Gerät mit mehreren Hub-Geräten. Der Anwendungstrat kann durch jedes Hub-Gerät übertragen werden, wenn die Verbindung zum Hub-Gerät SLA-Anforderungen erfüllt. Bei SLA-Verstößen kann der Anwendungstr.-Datenverkehr nahtlos zwischen den Hub-Geräten wechseln, oder das aktive Hub-Gerät reagiert nicht
Abbildung 1 zeigt eine Mesh-Topologie. In dieser Topologie kann ein Endpunkt über mehrere Knoten erreicht werden.
Um Multihoming im Aktiv-Aktiv-Modus zu aktivieren, müssen Sie den BGP-Multipath konfigurieren, damit das Gerät mehrere zu gleichen Kosten BGP-Pfade auswählen kann, um ein bestimmtes Ziel zu erreichen.
Wenn Sie BGP Multipath aktivieren, wählt das Gerät mehrere zu gleichen Kosten BGP-Pfade aus, um ein bestimmtes Ziel zu erreichen. Alle diese Pfade werden in der Weiterleitungstabelle installiert. AppQoE schließt die Routensuche ab und erhält die Details zur Next-Hop-Route sowie die entsprechenden Overlay-Links. AppQoE erhält die Overlay-Link-Eigenschaft von der konfigurierten Zielpfadgruppe.
Basierend auf den SLA-Anforderungen und Link-Einstellungen der Anwendung ermittelt AppQoE die beste Verbindung unter allen Links in dieser Zielpfadgruppe. Bei SLA-Verstößen, basierend auf dem SLA-Wert und den Verbindungseinstellungen, wählt AppQoE alternative Links in der gesamten konfigurierten Zielpfadgruppe aus, wenn der Endpunkt über diese Verbindungen erreichbar ist.
Weitere Informationen zur Multipath BGP konfiguration finden Sie unter Beispiele: Konfigurieren BGP Multipath.
Einschränkung
In bestimmten Szenario, wenn die Next-Hop-ID für die Routenänderungen die vorhandenen Sitzungen auf dem Link bleiben, gegen den SLA verstoßen, obwohl ein anderer Link verfügbar ist, der die SLA-Anforderungen erfüllt. Die neuen Sitzungen werden jedoch in diesem Fall nicht beeinflussen und sie werden über Verbindungen geroutet, die SLA-Anforderungen erfüllen.
Unterstützung für SaaS-Anwendungen
Wir bieten Junos OS AppQoE-Support ab dem 20.4R1 Veröffentlichungsservice (Application Quality of Experience) für SaaS-Anwendungen (Software as a Service).
AppQoE führt SLA-Messungen (Service Level Agreement) über die verfügbaren WAN-Verbindungen wie Underlay, GRE, IPsec oder MPLS über GRE durch. Dann sendet er SaaS-Anwendungsdaten über den SLA-konformsten Link, um einen konsistenten Service zu bieten.
Unterstützung von IPv6-Datenverkehr
-
Ab version Junos OS 21.3R1 können Sie IPv6-Adressen in AppQoE-Konfigurationen verwenden. Der Support umfasst Folgendes:
- IPv6-Adresse in Overlay-Pfadkonfiguration
- Aktive Ausserbung von Sitzungen mithilfe von IPv6-Adressen als Quell- und Zieladresse.
- IPv4- und IPv6-Datenverkehr von der Clientseite
- Dual-Stacking von IPv4 und IPv6 auf LAN-Seite
- IPv6-Adresse auf LAN-Seite zur SaaS-Suche (Software as a Service).
Stellen Sie bei der SaaS-Suche sicher, dass Sie sowohl IPv4- als auch IPv6-Adressen für die eingehende Schnittstelle für IPv4- und IPv6-Interoperabilität konfigurieren.
- Beginnend ab Junos OS Version 21.4R1 können Sie Dual-Stacking von IPv4 und IPv6 für Overlay- und Underlay-Netzwerke in einer AppQoE-Konfiguration verwenden.