Anwendungs-QoS
AppQoS ermöglicht es Ihnen, den Zugriff auf bestimmte Anwendungen zu identifizieren und zu steuern, und stellt die Granularität der Stateful-Firewall-Regelbasis bereit, um Quality of Service (QoS) auf Anwendungsebene anzupassen und durchzusetzen. Weitere Informationen finden Sie in den folgenden Themen:
Quality of Service (AppQoS) von Anwendungen verstehen
Die AppQoS-Funktion (Application Quality of Service ) erweitert die Funktionen der CoS-Klasse (Class of Service ) von Junos OS um die Markierung von DSCP-Werten basierend auf Layer-7-Anwendungstypen, die Berücksichtigung von anwendungsbasiertem Datenverkehr durch Einstellungen für die Verlustpriorität und die Steuerung von Übertragungsraten auf ausgehenden PICs basierend auf Layer-7-Anwendungstypen.
Es gibt vier Möglichkeiten, DSCP-Werte auf dem Sicherheitsgerät zu markieren:
IDP-Angriff, aktionsbasierte DSCP-Rewriter
Anwendungsbasierte DSCP-Rewriter auf Layer 7
ALG-basierte DSCP-Rewriter
Firewall-Filter-basierte DSCP-Rewriter
Die IDP-Neumarkierung wird am Eingangsport auf der Grundlage von IDP-Regeln durchgeführt. Die Neumarkierung der Anwendung erfolgt am Ausgangsport auf der Grundlage von Anwendungsregeln. Die schnittstellenbasierte Neumarkierung erfolgt auch am Ausgangsport auf der Grundlage von Firewall-Filterregeln. (Eine ausführliche Beschreibung der CoS-Funktionen von Junos OS finden Sie im Class-of-Service-Benutzerhandbuch (Sicherheitsgeräte) .)
Die Kommentarentscheidungen dieser drei Umschreiber können unterschiedlich sein. Wenn ein Paket alle drei Auslöser auslöst, basiert die Methode, die Vorrang hat, darauf, wie tief im Paketinhalt die Übereinstimmung durchgeführt wird. Die Neumarkierung von IDP hat Vorrang vor der Neumarkierung von Anwendungen, die wiederum Vorrang vor der schnittstellenbasierten Neumarkierung hat.
Wenn ein Paket sowohl AppQoS- als auch ALG-basierte DSCP-Rewriter auslöst, hat AppQoS Vorrang vor ALG-basierten DSCP-Rewritern.
Der AppQoS DSCP-Rewriter übermittelt die Servicequalität eines Pakets sowohl über die Weiterleitungsklasse als auch über eine Verlustpriorität. Die AppQoS-Ratenbegrenzungsparameter steuern die Übertragungsgeschwindigkeit und das Volumen für die zugehörigen Warteschlangen.
- Vorteil der Anwendungs-QoS
- Eindeutige Weiterleitungsklassen und Warteschlangenzuweisungen
- Anwendungsorientierte DSCP-Codepunkt- und Verlustprioritätseinstellungen
- Ratenbegrenzer und Profile
- Zuweisung von Ratenbegrenzern
- Ratenbegrenzer-Aktion
- AppQoS-Konfiguration der Sicherheitsrichtlinie
Vorteil der Anwendungs-QoS
AppQoS bietet die Möglichkeit, den Anwendungsdatenverkehr zu priorisieren und zu messen, um einen besseren Service für geschäftskritischen oder hochpriorisierten Anwendungsdatenverkehr zu gewährleisten.
Eindeutige Weiterleitungsklassen und Warteschlangenzuweisungen
Die Weiterleitungsklasse stellt drei Funktionen bereit:
Gruppiert Pakete mit ähnlichen Merkmalen
Weist Ausgabewarteschlangen zu
Löst Konflikte mit vorhandenen Junos OS Firewall-basierten Rewritern
Eindeutige Weiterleitungsklassennamen schützen die AppQoS-Remarking vor dem Überschreiben durch schnittstellenbasierte Rewrite-Regeln. Ein auf Firewall-Filtern basierender Rewriter markiert den DSCP-Wert eines Pakets, wenn die Weiterleitungsklasse des Pakets mit einer speziell für diesen Rewriter definierten Klasse übereinstimmt. Wenn die Weiterleitungsklasse des Pakets mit keiner der Klassen des auf Firewall-Filtern basierenden Rewriters übereinstimmt, wird der DSCP-Wert nicht neu markiert. Um AppQoS-Werte vor dem Überschreiben zu schützen, verwenden Sie daher Weiterleitungsklassennamen, die dem auf Firewall-Filtern basierenden Rewriter unbekannt sind.
Jede Weiterleitungsklasse wird einer Ausgangswarteschlange zugewiesen, die den entsprechenden Grad an erweiterter oder Standardverarbeitung bietet. Einer einzigen Warteschlange können viele Weiterleitungsklassen zugewiesen werden. Daher können alle für das Gerät definierten Warteschlangen von IDP-, AppQoS- und Firewall-Filter-basierten Rewritern verwendet werden. Es ist der Name der Weiterleitungsklasse, nicht die Warteschlange, der die Übertragungspriorität unterscheidet. (Informationen zum Konfigurieren von Warteschlangen und Schedulern finden Sie im Class-of-Service-Benutzerhandbuch (Sicherheitsgeräte) .)
Anwendungsorientierte DSCP-Codepunkt- und Verlustprioritätseinstellungen
Für AppQoS wird der Datenverkehr basierend auf Regeln gruppiert, die ausgewählten Anwendungen eine definierte Weiterleitungsklasse zuordnen. Das Übereinstimmungskriterium für die Regel umfasst eine oder mehrere Anwendungen. Wenn der Datenverkehr von einer übereinstimmenden Anwendung auf die Regel trifft, legt die Regelaktion die Weiterleitungsklasse fest und markiert den DSCP-Wert und die Verlustpriorität auf Werte, die für die Anwendung geeignet sind.
Ein DiffServ-Codepunktwert (DSCP) wird in der Regel entweder durch einen 6-Bitmap-Wert oder durch einen benutzerdefinierten oder Standardalias angegeben. Tabelle 1 enthält eine Liste der standardmäßigen DSCP-Aliasnamen und Bitmapwerte von Junos OS.
Alias |
Bit-Wert |
|---|---|
EF |
101110 |
AF11 |
001010 |
AF12 |
001100 |
af13 |
001110 |
AF21 |
010010 |
AF22 |
010100 |
AF23 |
010110 |
Nr. 31 |
011010 |
AF32 |
011100 |
AF33 |
011110 |
AF41 |
100010 |
AF42 |
100100 |
AF43 |
100110 |
sein |
000000 |
CS1 |
001000 |
CS2 |
010000 |
CS3 |
011000 |
CS4 |
100000 |
CS5 |
101000 |
NC1/CS6 |
110000 |
NC2/CS7 |
111000 |
Weitere Informationen finden Sie unter Standard-CoS-Werte und Aliasnamen .
Der Scheduler der Warteschlange verwendet die Verlustpriorität, um das Verwerfen von Paketen in Überlastungszeiten zu steuern, indem er Drop-Profile mit bestimmten Verlustprioritätswerten verknüpft. (Informationen zum Konfigurieren von Warteschlangen und Schedulern finden Sie im Class-of-Service-Benutzerhandbuch (Sicherheitsgeräte) .)
Die Regel wendet eine Verlustpriorität auf die Datenverkehrsgruppen an. Eine hohe Verlustpriorität bedeutet eine hohe Wahrscheinlichkeit, dass das Paket während einer Überlastung verworfen werden kann. Es stehen vier Stufen der Verlustpriorität zur Verfügung:
highmedium-highmedium-lowlow
Der Regelsatz wird im class-of-service application-traffic-control Konfigurationsbefehl definiert:
[edit class-of-service] user@host# set application-traffic-control rule-sets ruleset-name rule rule-name1 match application application-name application-name ... user@host# set application-traffic-control rule-sets ruleset-name rule rule-name1 match application-group application-group-name application-group-name ... user@host# set application-traffic-control rule-sets ruleset-name rule rule-name1 then forwarding-class fc-name user@host# set application-traffic-control rule-sets ruleset-name rule rule-name1 then dscp-code-point bitmap user@host# set application-traffic-control rule-sets ruleset-name rule rule-name1 then loss-priority loss-pri-value
Ratenbegrenzer und Profile
Wenn eine Überlastung auftritt, implementiert AppQoS eine Ratenbegrenzung für alle ausgehenden PICs auf dem Gerät. Wenn Pakete die zugewiesenen Beschränkungen überschreiten, werden sie verworfen. Ratenbegrenzer sorgen für einen gleichbleibenden Durchsatz und eine gleichbleibende Empfindlichkeit gegenüber Paketverlusten für verschiedene Datenverkehrsklassen. Alle Ausgangs-PICs verwenden dasselbe Ratenbegrenzungsschema.
Die Gesamtbandbreite eines PIC beträgt etwa 10 Gbit/s. Ratenbegrenzer-Hardware für den PIC kann bis zu 2 Gbit/s Bereitstellung. Daher liegt die obere Bandbreitengrenze für die Ratenbegrenzung bei 231 Basispunkten.
Ein Ratenbegrenzerprofil definiert die Einschränkungen. Es ist eine einzigartige Kombination aus bandwidth-limit und burst-size-limit Spezifikationen. Das bandwidth-limit definiert die maximale Anzahl von Kilobit pro Sekunde, die den Port durchlaufen können. Das burst-size-limit definiert die maximale Anzahl von Bytes, die den Port in einem einzigen Burst durchlaufen können. Dies burst-size-limit verringert das Aushungern von Datenverkehr mit niedrigerer Priorität, da sichergestellt wird, dass jeder Burst eine endliche Größe hat.
AppQoS ermöglicht bis zu 16 Profile und bis zu 1000 Ratenbegrenzer pro Gerät. Mehrere Ratenbegrenzer können dasselbe Profil verwenden. Im folgenden Beispiel werden fünf Ratenbegrenzer mit zwei Profilen definiert:
Name des Ratenbegrenzers |
Steckbrief |
|
|---|---|---|
Bandbreiten-Begrenzung |
Burst-Größenlimit |
|
Begrenzer-1 |
200 |
26000 |
Begrenzer-2 |
200 |
26000 |
Begrenzer-3 |
200 |
26000 |
Begrenzer-4 |
400 |
52000 |
Begrenzer-5 |
400 |
52000 |
Ratenbegrenzer werden mit dem class-of-service application-traffic-control Konfigurationsbefehl definiert.
[edit class-of-service] user@host# set application-traffic-control rate-limiters rate-limiter-name bandwidth-limit value-in-Kbps burst-rate-limit value-in-bytes
Zuweisung von Ratenbegrenzern
Ratenbegrenzer werden in Regeln angewendet, die auf der Anwendung des Datenverkehrs basieren. Für jede Sitzung werden zwei Ratenbegrenzer angewendet: client-to-server und server-to-client. Durch diese Verwendung kann der Datenverkehr in jede Richtung separat bereitgestellt werden.
Die Verarbeitung der Datenverkehrsbandbreite durch Ratenbegrenzer erfolgt auf Paketebene, unabhängig von der Richtung des Datenverkehrs. Beispiel: Stellen Sie sich einen Fall vor, in dem Sie nur einen Ratenbegrenzer von 10G konfiguriert haben, wenn der ein- und ausgehende Datenverkehr von derselben Linecard stammt, kann der Durchsatz (maximaler Datenverkehr von Eingangs- und Ausgangsrichtung zusammengenommen) nur bis zu 10G und nicht 20G betragen. Wenn das Gerät jedoch IOC-Unterstützung (E/A-Karten (IOCs)) hat und der eingehende Datenverkehr über einen IOC und der ausgehende Datenverkehr über einen anderen IOC erfolgt, können Sie bei einem einzigen konfigurierten Ratenbegrenzer von 10G mit einem Durchsatz von 20G rechnen.
Verschiedene AppQoS-Regeln innerhalb desselben Regelsatzes können sich einen Ratenbegrenzer teilen. In diesem Fall teilen sich die Anwendungen dieser Regeln dieselbe Bandbreite. Es gibt keine Beschränkungen für die Anzahl der Regeln in einem Regelsatz, die denselben Ratenbegrenzer zuweisen können.
Die folgenden Beispiele zeigen, wie die im vorherigen Abschnitt definierten Ratenbegrenzer zugewiesen werden können. Ein Regelsatz könnte z. B. einen Ratenbegrenzer in mehreren Regeln und in einer oder beiden Flussrichtungen wiederverwenden:
Regelsatz-1
Regel-1A
Client-zu-Server-Limiter-1
Server-zu-Client-Limiter-1
Regel-1B
Client-zu-Server-Limiter-1
Server-zu-Client-Limiter-1
Wenn dieselben Profile in mehreren Regelsätzen benötigt werden, muss eine ausreichende Anzahl von Ratenbegrenzern definiert werden, die dieselben bandwidth-limit und burst-size-limitangeben. Die beiden Regelsätze im folgenden Beispiel implementieren dieselben Profile, indem sie unterschiedliche, aber vergleichbare Ratenbegrenzer zuweisen.
Regelsatz-2
Regel-2A
Client-zu-Server-Limiter-2
Server-zu-Client-Limiter-2
Regel-2B
Client-zu-Server-Limiter-2
Server-zu-Client-Limiter-4
Regelsatz-3
Regel-3A
Client-zu-Server-Limiter-3
Server-zu-Client-Limiter-3
Regel-3B
Client-zu-Server-Limiter-3
Server-zu-Client-Limiter-5
Ein Ratenbegrenzer wird mit dem edit class-of-service application-traffic-control rule-sets Befehl auf die gleiche Weise angewendet wie eine Weiterleitungsklasse, ein DSCP-Wert und eine Verlustpriorität.
[edit class-of-service] user@host# set application-traffic-control rule-sets rule-set-name rule rule-name1 then rate-limit client-to-server rate-limiter1 server-to-client rate-limiter2
Wenn AppQoS und die auf Firewall-Filtern basierende Ratenbegrenzung beide auf dem ausgehenden PIC implementiert sind, werden beide berücksichtigt. Die AppQoS-Ratenbegrenzung wird zuerst betrachtet. Danach erfolgt die auf Firewall-Filtern basierende Ratenbegrenzung.
Wenn Pakete von einem PIC verworfen werden, sendet das Gerät keine Benachrichtigungen an den Client oder den Server. Die übergeordneten Anwendungen auf dem Client und den Servergeräten sind für die erneute Übertragung und Fehlerbehandlung verantwortlich.
Ratenbegrenzer-Aktion
Je nach Art des Sicherheitsgeräts können AppQoS-Regeln mit verschiedenen Ratenbegrenzer-Aktionen konfiguriert werden:
Verwerfen
Wenn diese Option ausgewählt ist, werden die Out-of-Profile-Pakete einfach verworfen.
Dies ist der Standardaktionstyp und muss nicht konfiguriert werden.
Diese Option wird auf allen Sicherheitsgeräten unterstützt
Verlustpriorität hoch
Wenn diese Option ausgewählt ist, wird die Verlustpriorität auf Maximum erhöht. Mit anderen Worten, es ist ein verzögerter Abfall; Das heißt, die Entscheidung über das Verwerfen wird auf der Ebene der Ausgangsausgabewarteschlange getroffen. Wenn es keine Überlastung gibt, lässt es den Datenverkehr auch mit maximaler Verlustpriorität zu. Wenn es jedoch zu einer Überlastung kommt, werden diese Pakete mit maximaler Verlustpriorität zuerst verworfen.
Diese Option muss innerhalb der AppQoS-Regel (um die Standardaktion zu überschreiben) mit dem folgenden Befehl konfiguriert werden:
[edit] user@host# set class-of-service application-traffic-control rule-sets rset-01 rule r1 then rate-limit loss-priority-high
-
Diese Option wird auf ausgewählten Geräten unterstützt. Siehe Plattformspezifische AppQoS-Verhaltenstabelle .
AppQoS-Konfiguration der Sicherheitsrichtlinie
Der AppQoS-Regelsatz kann in einer bestehenden Richtlinie oder einer bestimmten Anwendungsrichtlinie implementiert werden.
[edit security policies from-zone zone-name to-zone zone-name]
user@host# set policy policy-name match source-address IP-address
user@host# set policy policy-name match destination-address IP-address
user@host# set policy policy-name match application application-name application-name
user@host# set policy policy-name then permit application-services application-traffic-control rule-set app-rule-set-name
Siehe auch
Beispiel: Quality of Service der Anwendung konfigurieren
Dieses Beispiel zeigt, wie AppQoS-Priorisierung und Ratenbegrenzung innerhalb einer Richtlinie aktiviert werden.
Anforderungen
Vor der Konfiguration dieser Funktion ist keine spezielle Konfiguration erforderlich, die über die Geräteinitialisierung hinausgeht.
Überblick
In diesem Beispiel wird AppQoS so implementiert, dass FTP-Anwendungen auf ein Niveau unterhalb des angegebenen Durchsatzes beschränkt werden, während andere Anwendungen mit einer konventionelleren Geschwindigkeit und Verlustpriorität übertragen werden.
Konfiguration
Vorgehensweise
Um dieses Beispiel schnell zu konfigurieren, kopieren Sie die folgenden Befehle, fügen Sie sie in eine Textdatei ein, entfernen Sie alle Zeilenumbrüche, ändern Sie alle erforderlichen Details, um sie an Ihre Netzwerkkonfiguration anzupassen, und kopieren Sie dann die Befehle und fügen Sie sie dann in die CLI auf der Hierarchieebene [edit] ein.
set class-of-service forwarding-classes queue 4 my-app-fc set class-of-service application-traffic-control rate-limiters test-rl bandwidth-limit 100 set class-of-service application-traffic-control rate-limiters test-rl burst-size-limit 13000 set class-of-service application-traffic-control rate-limiters test-r2 bandwidth-limit 200 set class-of-service application-traffic-control rate-limiters test-r2 burst-size-limit 26000 set class-of-service application-traffic-control rule-sets app-test1 rule 0 match application junos:FTP set class-of-service application-traffic-control rule-sets app-test1 rule 0 match application junos:HTTP set class-of-service application-traffic-control rule-sets app-test1 rule 0 then forwarding-class my-app-fc set class-of-service application-traffic-control rule-sets app-test1 rule 0 then dscp-code-point af22 set class-of-service application-traffic-control rule-sets app-test1 rule 0 then loss-priority low set class-of-service application-traffic-control rule-sets app-test1 rule 0 then rate-limit client-to-server test-r2 set class-of-service application-traffic-control rule-sets app-test1 rule 0 then rate-limit server-to-client test-r2 set class-of-service application-traffic-control rule-sets app-test1 rule 0 then log set class-of-service application-traffic-control rule-sets app-test1 rule 1 match application-any set class-of-service application-traffic-control rule-sets app-test1 rule 1 then rate-limit client-to-server test-r2 set class-of-service application-traffic-control rule-sets app-test1 rule 1 then rate-limit server-to-client test-r2 set class-of-service application-traffic-control rule-sets app-test1 rule 1 then log set security policies from-zone trust to-zone untrust policy p1 match source-address any set security policies from-zone trust to-zone untrust policy p1 match destination-address any set security policies from-zone trust to-zone untrust policy p1 match application any set security policies from-zone trust to-zone untrust policy p1 then permit application-services application-traffic-control rule-set ftp-test1
Schritt-für-Schritt-Anleitung
So konfigurieren Sie eine AppQoS auf Ihrem Sicherheitsgerät:
-
Definieren Sie eine oder mehrere Weiterleitungsklassen für die AppQoS-Markierung. In diesem Beispiel wird eine einzelne Weiterleitungsklasse, my-app-fc, definiert und Warteschlange 4 zugewiesen.
[edit] user@host# set class-of-service forwarding-classes queue 4 my-app-fc
[edit] user@host# set class-of-service forwarding-classes class my-app-fc queue 4
Geräte von Juniper Networks unterstützen acht Warteschlangen (0 bis 7). Die Standardwarteschlangen 0 bis 3 werden Standardweiterleitungsklassen zugewiesen. Die Warteschlangen 4 bis 7 haben keine Standardzuweisungen zu FCs und sind nicht zugeordnet. Um die Warteschlangen 4 bis 7 zu verwenden, müssen Sie benutzerdefinierte FC-Namen erstellen und sie den Warteschlangen zuordnen. Weitere Informationen finden Sie unter Übersicht über Weiterleitungsklassen.
Definieren Sie Ratenbegrenzer. In diesem Beispiel sind zwei Ratenbegrenzer definiert.
[edit] user@host# set class-of-service application-traffic-control rate-limiters test-rl bandwidth-limit 100 user@host# set class-of-service application-traffic-control rate-limiters test-rl burst-size-limit 13000 user@host# set class-of-service application-traffic-control rate-limiters test-r2 bandwidth-limit 200 user@host# set class-of-service application-traffic-control rate-limiters test-r2 burst-size-limit 26000
-
Definieren von AppQos-Regeln und Kriterien für Anwendungsübereinstimmungen.
[edit] user@host# set class-of-service application-traffic-control rule-sets app-test1 rule 0 match application junos:FTP user@host# set class-of-service application-traffic-control rule-sets app-test1 rule 0 match application junos:HTTP user@host# set class-of-service application-traffic-control rule-sets app-test1 rule 0 then forwarding-class my-app-fc user@host# set class-of-service application-traffic-control rule-sets app-test1 rule 0 then dscp-code-point af22 user@host# set class-of-service application-traffic-control rule-sets app-test1 rule 0 then loss-priority low user@host# set class-of-service application-traffic-control rule-sets app-test1 rule 0 then rate-limit client-to-server test-r1 user@host# set class-of-service application-traffic-control rule-sets app-test1 rule 0 then rate-limit server-to-client test-r1 user@host# set class-of-service application-traffic-control rule-sets app-test1 rule 0 then log
In diesem Beispiel wird das Paket bei einer Übereinstimmung mit der Weiterleitungsklasse my-app-fc, dem DSCP-Wert von af22 und einer Verlustpriorität von low markiert. Wir haben für beide Richtungen den gleichen Ratenbegrenzer zugewiesen.
Sie können einen Ratenbegrenzer einer oder beiden Verkehrsrichtungen in einer einzigen Regel zuweisen. Sie können denselben Ratenbegrenzer auch anderen Regeln innerhalb eines Regelsatzes zuweisen. Sie können jedoch nicht denselben Ratenbegrenzer verschiedenen Regelsätzen zuweisen.
-
Definieren Sie eine andere Regel für die Behandlung von Anwendungspaketen, die nicht mit der vorherigen Regel übereinstimmten. In diesem Beispiel gilt eine zweite und letzte Regel für alle verbleibenden Anwendungen.
[edit] user@host# set class-of-service application-traffic-control rule-sets app-test1 rule 1 match application-any user@host# set class-of-service application-traffic-control rule-sets app-test1 rule 1 then rate-limit client-to-server test-r2 user@host# set class-of-service application-traffic-control rule-sets app-test1 rule 1 then rate-limit server-to-client test-r2 user@host# set class-of-service application-traffic-control rule-sets app-test1 rule 1 then log
-
Fügen Sie der Sicherheitsrichtlinie die AppQoS-Einstellung hinzu.
[edit] user@host# set security policies from-zone trust to-zone untrust policy p1 match source-address any user@host# set security policies from-zone trust to-zone untrust policy p1 match destination-address any user@host# set security policies from-zone trust to-zone untrust policy p1 match application any user@host# set security policies from-zone trust to-zone untrust policy p1 then permit application-services application-traffic-control rule-set app-test1
Ergebnisse
Bestätigen Sie im Konfigurationsmodus Ihre Richtlinienkonfiguration, indem Sie den show security policies Befehl and show class-of-service eingeben. Wenn die Ausgabe nicht die beabsichtigte Konfiguration anzeigt, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.
Der Kürze halber enthält diese show Befehlsausgabe nur die Konfiguration, die für dieses Beispiel relevant ist. Alle anderen Konfigurationen auf dem System wurden durch Auslassungspunkte ersetzt (...).
...
policy p1 {
match {
source-address any;
destination-address any;
application any;
}
then {
permit {
application-services {
application-traffic-control {
rule-set app-test1
}
}
}
}
}
...
user@host# show class-of-service
forwarding-classes {
queue 4 my-app-fc;
}
application-traffic-control {
rate-limiters test-rl {
bandwidth-limit 100;
burst-size-limit 13000;
}
rate-limiters test-r2 {
bandwidth-limit 200;
burst-size-limit 26000;
}
rule-sets app-test1 {
rule 0 {
match {
application [junos:FTP junos:HTTP];
}
then {
forwarding-class my-app-fc;
dscp-code-point af22;
loss-priority low;
rate-limit {
client-to-server test-r2;
server-to-client test-r2;
}
log;
}
}
rule 1 {
match {
application-any;
}
then {
rate-limit {
client-to-server test-r2;
server-to-client test-r2;
}
log;
}
}
}
}
Wenn Sie mit der Konfiguration des Geräts fertig sind, rufen Sie den Konfigurationsmodus auf commit .
Verifizierung
Bestätigen Sie, dass die Konfiguration ordnungsgemäß funktioniert.
- Überprüfen der Konfiguration der Flow-Sitzung
- Überprüfen von Sitzungsstatistiken
- Überprüfen von Ratenbegrenzer-Statistiken
- Überprüfen von Regelstatistiken
Überprüfen der Konfiguration der Flow-Sitzung
Zweck
Stellen Sie sicher, dass AppQoS aktiviert ist.
Aktion
Geben Sie im Betriebsmodus den show security flow session application-traffic-control extensive Befehl ein.
user@host> show security flow session application-traffic-control extensive
Session ID: 3729, Status: Normal, State: Active
Flag: 0x40
Policy name: p1
Source NAT pool: Null
Dynamic application: junos:FTP
Application traffic control rule-set: app-test1, Rule: rule0
Maximum timeout: 300, Current timeout: 276
Session State: Valid
Start time: 18292, Duration: 603536
In: 192.0.2.1/1 --> 203.0.113.0/1;pim,
Interface: reth1.0,
Session token: 0x1c0, Flag: 0x0x21
Route: 0x0, Gateway: 192.0.2.4, Tunnel: 0
Port sequence: 0, FIN sequence: 0,
FIN state: 0,
Pkts: 21043, Bytes: 1136322
Out: 203.0.113.0/1 --> 192.0.2.0/1;pim,
Interface: .local..0,
Session token: 0x80, Flag: 0x0x30
Route: 0xfffd0000, Gateway: 192.0.2.0, Tunnel: 0
Port sequence: 0, FIN sequence: 0,
FIN state: 0,
Pkts: 0, Bytes: 0
Bedeutung
Der Eintrag für die Steuerung des Anwendungsdatenverkehrs identifiziert den Regelsatz und die Regel der aktuellen Sitzung.
Überprüfen von Sitzungsstatistiken
Zweck
Stellen Sie sicher, dass AppQoS-Sitzungsstatistiken an jedem Ausgangsknoten akkumuliert werden.
Aktion
Geben Sie im Betriebsmodus den show class-of-service application-traffic-control counter Befehl ein.
user@host> show class-of-service application-traffic-control counter pic: 2/1 Counter type Value Sessions processed 300 Sessions marked 200 Sessions honored 0 Sessions rate limited 100 Client-to-server flows rate limited 100 Server-to-client flows rate limited 100 pic: 2/0 Counter type Value Sessions processed 400 Sessions marked 300 Sessions honored 0 Sessions rate limited 200 Client-to-server flows rate limited 200 Server-to-client flows rate limited 200
Bedeutung
Die AppQoS-Statistiken werden nur verwaltet, wenn der Dienst application-traffic-control aktiviert ist. Die Anzahl der verarbeiteten, markierten und honorierten Sitzungen zeigt, dass Sitzungen basierend auf konfigurierten AppQoS-Funktionen geleitet werden. Die Statistiken zur Ratenbegrenzung zählen die Anzahl der richtungsgebundenen Sitzungsdatenströme, die ratenbegrenzt wurden.
Überprüfen von Ratenbegrenzer-Statistiken
Zweck
Stellen Sie sicher, dass die Bandbreite wie erwartet begrenzt ist, wenn die FTP-Anwendung gefunden wird.
Aktion
Geben Sie im Betriebsmodus den show class-of-service application-traffic-control statistics rate-limiter Befehl ein.
user@host> show class-of-service application-traffic-control statistics rate-limiter pic: 2/1 Ruleset Application Client-to-server Rate(kbps) Server-to-client Rate(kbps) app-test1 HTTP test-r2 200 test-r2 200 app-test1 HTTP test-r2 200 test-r2 200 appp–test1 FTP test-r1 100 test-r1 100
Bedeutung
Informationen zur Bandbreitenbegrenzung von Anwendungen in Echtzeit für jeden PIC werden nach Regelsatz angezeigt. Dieser Befehl gibt einen Hinweis auf die Anwendungen, die auf die Rate begrenzt sind, und das angewendete Profil.
Überprüfen von Regelstatistiken
Zweck
Stellen Sie sicher, dass die Regel mit den Regelstatistiken übereinstimmt.
Aktion
Geben Sie im Betriebsmodus den show class-of-service application-traffic-control statistics rule Befehl ein.
user@host>show class-of-service application-traffic-control statistics rule pic: 2/1 Ruleset Rule Hits app-test1 0 100 app-test1 1 200 ... pic: 2/0 Ruleset Rule Hits app-test1 0 100 app-test1 1 200
Bedeutung
Dieser Befehl liefert Informationen über die Anzahl der (Sitzungs-)Treffer für eine Regel unter jedem Regelsatz.
Quality of Service-Unterstützung von Anwendungen für einheitliche Richtlinien
Einheitliche Richtlinien sind die Sicherheitsrichtlinien, die es Ihnen ermöglichen, dynamische Anwendungen als Teil der vorhandenen 5-Tupel- oder 6-Tupel-Übereinstimmungsbedingungen (5-Tupel mit einer Benutzer-Firewall) zu verwenden, um Anwendungsänderungen im Laufe der Zeit zu erkennen.
Application Quality of Service (AppQoS) wird unterstützt, wenn das Sicherheitsgerät mit einheitlichen Richtlinien konfiguriert ist. Sie können einen standardmäßigen AppQoS-Regelsatz konfigurieren, um Konflikte mit einheitlichen Richtlinien zu verwalten, wenn mehrere Sicherheitsrichtlinien mit dem Datenverkehr übereinstimmen.
AppQoS-Regelsätze sind in der einheitlichen Richtlinie zur Implementierung einer anwendungsbezogenen Quality of Service-Steuerung enthalten. Sie können einen Regelsatz mit Regeln unter der application-traffic-control Option konfigurieren und den AppQoS-Regelsatz als Anwendungsservice an eine einheitliche Sicherheitsrichtlinie anhängen. Wenn der Datenverkehr mit der angegebenen dynamischen Anwendung übereinstimmt und die Richtlinienmaßnahme "Zulassen" lautet, wird die anwendungsbezogene Quality of Service angewendet.
Beachten Sie die folgenden AppQoS-Funktionen in einheitlichen Richtlinien:
Upgrade von einer traditionellen Sicherheitsrichtlinie auf eine einheitliche Richtlinie: Wenn Sie in einer einheitlichen Richtlinie die
dynamic-applicationOption alsnonekonfigurieren, wird der AppQoS-Regelsatz während der Sicherheitsrichtlinienübereinstimmung angewendet und AppQoS sucht nach der entsprechenden Regel für den identifizierten Datenverkehr. Dies ist das gleiche Verhalten für die AppQoS-Funktionalität in Junos OS-Versionen vor Version 18.2R1.AppQoS-Regel mit einheitlicher Richtlinie: In der Konfiguration der Anwendungsdatenverkehrssteuerung wird der AppQoS-Regelsatz mit der Übereinstimmungsbedingung
application-anykonfiguriert, und in der einheitlichen Richtlinie wird eine bestimmte dynamische Anwendung als Übereinstimmungsbedingung verwendet, dann arbeitet die AppQoS-Funktionalität gemäß der Regel in der einheitlichen Richtlinie.
- Grundlegendes zum Standardregelsatz für Anwendungs-Quality-of-Service für einheitliche Richtlinien
- Standardmäßiger Quality-of-Service-Regelsatz für Anwendungen in verschiedenen Szenarien
- Begrenzung der AppQoS mit einheitlichen Richtlinien
Grundlegendes zum Standardregelsatz für Anwendungs-Quality-of-Service für einheitliche Richtlinien
Sie können einen AppQoS-Standardregelsatz konfigurieren, um Sicherheitsrichtlinienkonflikte zu verwalten.
Die erste Phase der Richtliniensuche findet vor der Identifizierung einer dynamischen Anwendung statt. Wenn in der Liste der potenziellen Richtlinien mehrere Richtlinien vorhanden sind, die unterschiedliche AppQoS-Regelsätze enthalten, wendet das Sicherheitsgerät den standardmäßigen AppQoS-Regelsatz an, bis eine explizitere Übereinstimmung aufgetreten ist.
Sie können eine AppQoS als Standard-AppQoS-Regelsatz unter der edit security ngfw Hierarchieebene festlegen. Der standardmäßige AppQoS-Regelsatz wird aus einem der vorhandenen AppQoS-Regelsätze genutzt, die unter der [edit class-of-service application-traffic-control] Hierarchieebene konfiguriert sind.
Tabelle 2 fasst die Verwendung des standardmäßigen AppQoS-Regelsatzes unter verschiedenen Szenarien in einer einheitlichen Richtlinie zusammen.
Status der Anwendungsidentifikation |
Verwendung des AppQoS-Regelsatzes |
Aktion |
|---|---|---|
Kein Konflikt mit Sicherheitsrichtlinien. |
Der AppQoS-Regelsatz unter der Hierarchie [ |
AppQoS wird wie im AppQoS-Regelsatz angewendet. |
Für Sicherheitsrichtlinienkonflikte und widersprüchliche Richtlinien gibt es unterschiedliche AppQoS-Regelsätze. |
Der standardmäßige AppQoS-Regelsatz ist nicht konfiguriert oder wird nicht gefunden. |
Die Sitzung wird ignoriert, da das AppQoS-Standardprofil nicht konfiguriert ist. Selbst wenn die endgültige übereinstimmende Richtlinie im Richtlinienkonfliktszenario über einen AppQoS-Regelsatz verfügt, wird dieser Regelsatz daher nicht angewendet. Es wird empfohlen, einen standardmäßigen AppQoS-Regelsatz zu konfigurieren, um Sicherheitsrichtlinienkonflikte zu verwalten. |
Der Standard-AppQoS-Regelsatz ist konfiguriert. |
AppQoS wird wie im Standard-AppQoS-Regelsatz angewendet. |
|
Die endgültige Anwendung ist identifiziert |
Die entsprechende Sicherheitsrichtlinie verfügt über einen AppQoS-Regelsatz, der mit dem Standard-AppQoS-Regelsatz identisch ist. |
AppQoS wird wie im Standard-AppQoS-Regelsatz angewendet. |
Die entsprechende Sicherheitsrichtlinie verfügt nicht über einen AppQoS-Regelsatz. |
Der standardmäßige AppQoS-Regelsatz wird nicht angewendet und AppQoS wird nicht auf die Sitzung angewendet. |
|
Die übereinstimmende Sicherheitsrichtlinie verfügt über einen AppQoS-Regelsatz, der sich vom AppQoS-Standardregelsatz unterscheidet, der bereits angewendet wird. |
Der Standard-AppQoS-Regelsatz bleibt der Standard-AppQoS-Regelsatz. |
Wenn ein standardmäßiger AppQoS-Regelsatz auf den Datenverkehr angewendet wird und die endgültige Sicherheitsrichtlinie einen anderen AppQoS-Regelsatz hat, wird in solchen Fällen das Switching vom standardmäßigen AppQoS-Regelsatz zum AppQoS-Regelsatz in der endgültigen Sicherheitsrichtlinie nicht unterstützt.
Standardmäßiger Quality-of-Service-Regelsatz für Anwendungen in verschiedenen Szenarien
Die folgenden Links führen zu Beispielen, in denen die standardmäßigen AppQoS-Regelsätze in verschiedenen Szenarien erläutert werden:
Tabelle 3 zeigt verschiedene AppQoS-Regelsätze, die für einheitliche Richtlinien mit dynamischen Anwendungen als Übereinstimmungsbedingung konfiguriert sind.
Sicherheits-Richtlinie |
Quell-Zone |
Quell-IP-Adresse |
Zielzone |
Ziel-IP-Adresse |
Portnummer |
Protokoll |
Dynamische Anwendung |
Dienstleistung |
AppQoS-Regelsatz |
|---|---|---|---|---|---|---|---|---|---|
Richtlinie – P1 |
S1 |
50.1.1.1 |
D1 |
Beliebig |
Beliebig |
Beliebig |
Facebook (Englisch) |
AppQoS |
AppQoS-1 |
Richtlinie – P2 |
S1 |
50.1.1.1 |
D1 |
Beliebig |
Beliebig |
Beliebig |
AppQoS |
AppQoS-2 |
|
Richtlinie-P3 |
S1 |
50.1.1.1 |
D1 |
Beliebig |
Beliebig |
Beliebig |
YouTube (Englisch) |
AppQoS |
AppQoS-3 |
In diesem Beispiel können alle AppQoS-Regelsätze (AppQoS-1, AppQoS-2, AppQoS-3) als AppQoS-Standardregelsatz unter der [security ngfw] Hierarchieebene konfiguriert werden. Es ist nicht erforderlich, dass ein Standardregelsatz Teil einer Sicherheitsrichtlinienkonfiguration ist. Jeder AppQoS-Regelsatz unter der [edit class-of-service application-traffic-control] Hierarchieebene kann als Standard-AppQoS-Regelsatz zugewiesen werden.
- Kein Richtlinienkonflikt – alle Richtlinien haben denselben AppQoS-Regelsatz
- Kein Richtlinienkonflikt: Alle Richtlinien haben denselben AppQoS-Regelsatz und die endgültige Richtlinie hat keinen AppQoS-Regelsatz
- Richtlinienkonflikt – Für die endgültige Richtlinie ist kein AppQoS-Regelsatz konfiguriert.
- Richtlinienkonflikt: Standardmäßiger AppQoS-Regelsatz und ein anderer AppQoS-Regelsatz für die endgültige Richtlinie
Kein Richtlinienkonflikt – alle Richtlinien haben denselben AppQoS-Regelsatz
Alle übereinstimmenden Richtlinien haben denselben AppQoS-Regelsatz wie in Tabelle 4 dargestellt.
Sicherheits-Richtlinie |
Quell-Zone |
Quell-IP-Adresse |
Zielzone |
Ziel-IP-Adresse |
Portnummer |
Protokoll |
Dynamische Anwendung |
Dienstleistung |
AppQoS-Regelsatz |
|---|---|---|---|---|---|---|---|---|---|
Richtlinie – P1 |
S1 |
Beliebig |
D1 |
Beliebig |
Beliebig |
Beliebig |
Facebook (Englisch) |
AppQoS |
AppQoS-1 |
Richtlinie – P2 |
S1 |
Beliebig |
D1 |
Beliebig |
Beliebig |
Beliebig |
AppQoS |
AppQoS-1 |
In diesem Szenario haben die Richtlinien Policy-P1 und Policy-P2 denselben AppQoS-Regelsatz. das heißt, AppQoS-1. Der Regelsatz AppQoS-1 wird angewendet. Policy-P3 ist in diesem Szenario nicht konfiguriert.
Wenn Sie den Regelsatz AppQoS-2 als Standardregelsatz konfiguriert haben, wird er nicht angewendet. Dies liegt daran, dass es in den AppQoS-Regelsätzen in den widersprüchlichen Richtlinien (Policy-P1 und Policy-P2) keinen Konflikt gibt.
Kein Richtlinienkonflikt: Alle Richtlinien haben denselben AppQoS-Regelsatz und die endgültige Richtlinie hat keinen AppQoS-Regelsatz
Alle übereinstimmenden Richtlinien haben denselben AppQoS-Regelsatz wie in Tabelle 5 gezeigt, und die endgültige Richtlinie hat keinen AppQoS-Regelsatz.
Sicherheits-Richtlinie |
Quell-Zone |
Quell-IP-Adresse |
Zielzone |
Ziel-IP-Adresse |
Portnummer |
Protokoll |
Dynamische Anwendung |
Dienstleistung |
AppQoS-Regelsatz |
|---|---|---|---|---|---|---|---|---|---|
Richtlinie – P1 |
S1 |
Beliebig |
D1 |
Beliebig |
Beliebig |
Beliebig |
Facebook (Englisch) |
AppQoS |
AppQoS-1 |
Richtlinie – P2 |
S1 |
Beliebig |
D1 |
Beliebig |
Beliebig |
Beliebig |
AppQoS |
AppQoS-1 |
|
Richtlinie-P3 |
S1 |
50.1.1.1 |
D1 |
Beliebig |
Beliebig |
Beliebig |
YouTube (Englisch) |
Sonstiges |
Keine |
In diesem Szenario verfügen sowohl Policy-P1 als auch Policy-P2 über denselben AppQoS-Regelsatz, d. h. AppQoS-1. In diesem Fall wird der Regelsatz AppQoS-1 angewendet.
Wenn die endgültige Richtlinie Policy-P3 übereinstimmt, ignoriert AppQoS die Sitzung, da der AppQoS-Regelsatz nicht für Policy-P3 konfiguriert ist.
Wenn die endgültige Sicherheitsrichtlinie keinen AppQoS-Regelsatz enthält, wird AppQoS nicht auf den Datenverkehr angewendet. Alle AppQoS-Einstellungen, die in der Phase vor dem Abgleich angewendet werden, werden auf die ursprünglichen Werte zurückgesetzt.
Richtlinienkonflikt – Für die endgültige Richtlinie ist kein AppQoS-Regelsatz konfiguriert.
Der standardmäßige AppQoS-Regelsatz (in diesem Szenario AppQoS-1) wird während der potenziellen Richtlinienübereinstimmung angewendet, wie in Tabelle 6 dargestellt. Die endgültige Richtlinie Policy-P3 hat keinen AppQoS-Regelsatz.
Sicherheits-Richtlinie |
Quell-Zone |
Quell-IP-Adresse |
Zielzone |
Ziel-IP-Adresse |
Portnummer |
Protokoll |
Dynamische Anwendung |
Dienstleistung |
AppQoS-Regelsatz |
|---|---|---|---|---|---|---|---|---|---|
Richtlinie – P1 |
S1 |
50.1.1.1 |
D1 |
Beliebig |
Beliebig |
Beliebig |
Facebook (Englisch) |
AppQoS |
AppQoS-1 |
Richtlinie – P2 |
S1 |
50.1.1.1 |
D1 |
Beliebig |
Beliebig |
Beliebig |
AppQoS |
AppQoS-2 |
|
Richtlinie-P3 |
S1 |
50.1.1.1 |
D1 |
Beliebig |
Beliebig |
Beliebig |
YouTube (Englisch) |
Sonstiges |
NA |
AppQoS ignoriert die Sitzung, wenn die endgültige übereinstimmende Richtlinie Policy-P3 angewendet wird.
Wenn die endgültige Sicherheitsrichtlinie keinen AppQoS-Regelsatz enthält, wird AppQoS nicht auf den Datenverkehr angewendet. In diesem Fall werden alle AppQoS-Einstellungen, die in der Phase vor dem Abgleich angewendet werden, auf die ursprünglichen Werte zurückgesetzt.
Richtlinienkonflikt: Standardmäßiger AppQoS-Regelsatz und ein anderer AppQoS-Regelsatz für die endgültige Richtlinie
Der Regelsatz AppQoS-1 ist als Standardregelsatz konfiguriert und wird angewendet, wenn die endgültige Anwendung noch nicht identifiziert ist. Die endgültige Richtlinie Policy-P3 hat einen anderen AppQoS-Regelsatz (AppQoS-3), wie in Tabelle 7 dargestellt.
Sicherheits-Richtlinie |
Quell-Zone |
Quell-IP-Adresse |
Zielzone |
Ziel-IP-Adresse |
Portnummer |
Protokoll |
Dynamische Anwendung |
Dienstleistung |
AppQoS-Regelsatz |
|---|---|---|---|---|---|---|---|---|---|
Richtlinie – P1 |
S1 |
50.1.1.1 |
D1 |
Beliebig |
Beliebig |
Beliebig |
Facebook (Englisch) |
AppQoS |
AppQoS-1 |
Richtlinie – P2 |
S1 |
50.1.1.1 |
D1 |
Beliebig |
Beliebig |
Beliebig |
AppQoS |
AppQoS-2 |
|
Richtlinie-P3 |
S1 |
50.1.1.1 |
D1 |
Beliebig |
Beliebig |
Beliebig |
YouTube (Englisch) |
AppQoS |
AppQoS-3 |
Wenn die endgültige Anwendung identifiziert ist, wird die Richtlinie Policy-P3 abgeglichen und angewendet. In diesem Fall wird der Regelsatz AppQoS-3 nicht angewendet. Stattdessen wird der Regelsatz AppQoS-1 als Standardregelsatz angewendet und bleibt als Standardregelsatz erhalten.
Begrenzung der AppQoS mit einheitlichen Richtlinien
Wenn eine Sicherheitsrichtlinie auf den übereinstimmenden Datenverkehr angewendet wird, wird der AppQoS-Regelsatz auf den zulässigen Datenverkehr angewendet. Wenn die Sicherheitsrichtlinie und der angewendete AppQoS-Regelsatz unterschiedliche dynamische Anwendungen aufweisen, kann ein Konflikt auftreten, wie im folgenden Beispiel gezeigt:
user@host#set class-of-service application-traffic-control rule-sets AQ2 rule 1 match application junos:GOOGLEuser@host#set class-of-service application-traffic-control rule-sets AQ2 rule 1 then forwarding-class network-controluser@host#set class-of-service application-traffic-control rule-sets AQ2 rule 1 then dscp-code-point 110001user@host#set class-of-service application-traffic-control rule-sets AQ2 rule 1 then loss-priority high
user@host#set security policies from-zone trust to-zone untrust policy 1 match source-address anyuser@host#set security policies from-zone trust to-zone untrust policy 1 match destination-address anyuser@host#set security policies from-zone trust to-zone untrust policy 1 match application anyuser@host#set security policies from-zone trust to-zone untrust policy 1 match dynamic-application junos:FTPuser@host#set security policies from-zone trust to-zone untrust policy 1 then permit application-services application-traffic-control rule-set AQ2
In diesem Beispiel ist die Regel zur Steuerung des Anwendungsdatenverkehrs für junos:GOOGLE konfiguriert, und die Übereinstimmungsbedingung für die Sicherheitsrichtlinie für die dynamische Anwendung lautet junos: FTP. In solchen Fällen können Konflikte auftreten, wenn die endgültige Richtlinie angewendet wird.
Siehe auch
Beispiel: Konfiguration von Quality of Service von Anwendungen mit einheitlichen Richtlinien
Dieses Beispiel zeigt, wie Anwendungs-QoS (Application Quality of Service) innerhalb einer einheitlichen Richtlinie aktiviert wird, um Priorisierung und Ratenbegrenzung für den Datenverkehr bereitzustellen.
Anforderungen
In diesem Beispiel werden die folgenden Hardware- und Softwarekomponenten verwendet:
Firewall der SRX-Serie mit Junos OS Version 18.2R1 und höher. Dieses Konfigurationsbeispiel wurde für Junos OS Version 18.2R1 getestet.
Vor der Konfiguration dieser Funktion ist keine spezielle Konfiguration erforderlich, die über die Geräteinitialisierung hinausgeht.
Überblick
In diesem Beispiel konfigurieren Sie einen AppQoS-Regelsatz und rufen AppQoS als Anwendungsdienst in der Sicherheitsrichtlinie für die Facebook-Anwendung auf.
Sie definieren einen standardmäßigen AppQoS-Regelsatz unter der Hierarchieebene [edit security ngfw], um etwaige Sicherheitsrichtlinienkonflikte zu verwalten.
Konfiguration
Vorgehensweise
Schritt-für-Schritt-Anleitung
So konfigurieren Sie AppQoS mit einer einheitlichen Richtlinie:
Definieren Sie einen AppQoS-Regelsatz.
[edit] user@host# set class-of-service application-traffic-control rule-sets RS1 rule 1 match application junos:FACEBOOK-APP user@host# set class-of-service application-traffic-control rule-sets RS1 rule 1 then forwarding-class fc-appqos loss-priority medium-low dscp-code-point 101110 log user@host# set class-of-service application-traffic-control rule-sets RS1 rule 1 then rate-limit client-to-server Ratelimit1 user@host# set class-of-service application-traffic-control rate-limiters Ratelimit1 bandwidth-limit 1000
Konfigurieren Sie einen standardmäßigen AppQoS-Regelsatz. Wählen Sie den Regelsatz
RS1, der unter der Kontrolle des Anwendungsdatenverkehrs erstellt wird, als Standard-AppQoS-Regelsatz aus.[edit] user@host# set security ngfw default-profile application-traffic-control rule-set RS1
Ordnen Sie den Class-of-Service-Regelsatz der einheitlichen Richtlinie zu.
[edit] user@host# set security policies from-zone untrust to-zone trust policy from_internet match source-address any user@host# set security policies from-zone untrust to-zone trust policy from_internet match destination-address any user@host# set security policies from-zone untrust to-zone trust policy from_internet match application any user@host# set security policies from-zone untrust to-zone trust policy from_internet match dynamic-application junos:FACEBOOK-APP user@host# set security policies from-zone untrust to-zone trust policy from_internet then permit application-services application-traffic-control rule-set RS1
Ergebnisse
Bestätigen Sie im Konfigurationsmodus Ihre Richtlinienkonfiguration, indem Sie den show security policies Befehl eingeben. Wenn die Ausgabe nicht die beabsichtigte Konfiguration anzeigt, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.
Der Kürze halber enthält diese show Befehlsausgabe nur die Konfiguration, die für dieses Beispiel relevant ist. Alle anderen Konfigurationen auf dem System wurden durch Auslassungspunkte ersetzt (...).
...
policies {
from-zone trust to-zone untrust {
policy permit-all {
match {
source-address any;
destination-address any;
application any;
dynamic-application junos:FACEBOOK-APP;
}
then {
permit {
application-services {
application-traffic-control {
rule-set RS1;
}
}
}
}
}
}
}
...
ngfw {
default-profile {
application-traffic-control {
rule-set RS1;
}
}
}
Wenn Sie mit der Konfiguration des Geräts fertig sind, rufen Sie den Konfigurationsmodus auf commit .
Verifizierung
Bestätigen Sie, dass die Konfiguration ordnungsgemäß funktioniert.
Überprüfen der Konfiguration der Flow-Sitzung
Zweck
AppQoS-Sitzungsstatistiken anzeigen.
Aktion
Geben Sie im Betriebsmodus den show class-of-service application-traffic-control counter Befehl ein.
Beispielausgabe
Befehlsname
pic: 0/0 Counter type Value Sessions processed 2 Sessions marked 1 Sessions honored 1 Sessions rate limited 1 Client-to-server flows rate limited 0 Server-to-client flows rate limited 1 Session default ruleset hit 1 Session ignored no default ruleset 1
Bedeutung
Die Ausgabe zeigt die Anzahl der verarbeiteten, markierten und honorierten Sitzungen an. Die Statistiken zur Ratenbegrenzung zählen die Anzahl der richtungsgebundenen Sitzungsdatenströme, die ratenbegrenzt wurden.
Überprüfen von Regelstatistiken
Zweck
Zeigen Sie die AppQoS-Regelstatistik an.
Aktion
Geben Sie im Betriebsmodus den show class-of-service application-traffic-control statistics rule Befehl ein.
user@host>show class-of-service application-traffic-control statistics rule
pic: 0/0
Ruleset Rule Hits
RS1 1 1
Bedeutung
Die Ausgabe enthält Informationen über die Anzahl der Sitzungen, die für die Regel unter jedem AppQoS-Regelsatz übereinstimmen.
HTTP2: AppQoS DSCP-Unterstützung
HTTP/2 Application Quality of Service (AppQoS) Die Unterstützung von Differentiated Services Code Point (DSCP) verbessert die Anwendung von Quality of Service (QoS)-Regeln in HTTP/2-Sitzungen durch Nutzung von First-Stream-Klassifizierungen. Diese Erweiterung ermöglicht die Anwendung von QoS-Regeln auf HTTP/2-Sitzungen, wodurch sichergestellt wird, dass der Datenverkehr nach Anwendungstyp klassifiziert und priorisiert wird. Mit dieser Funktion können Sie granulare AppQoS-Richtlinien im HTTP/2-Datenverkehr durchsetzen, was bei der Verarbeitung mehrerer Streams, die unter verschiedenen Anwendungen kategorisiert sind, von entscheidender Bedeutung ist. Durch Anwenden von AppQoS-Regeln basierend auf der Klassifizierung der ersten Streamsitzung stellen Sie eine konsistente QoS-Verwaltung sicher, selbst wenn die Fallbacklogik aufgrund nicht spezifizierter Regeln aufgerufen wird. Die Funktion lässt sich in bestehende Frameworks für das HTTP/2-Datenverkehrsmanagement integrieren, unterstützt Szenarien in traditionellen und einheitlichen Richtlinienfällen und sorgt für eine effektive QoS-Durchsetzung in verschlüsselten Sitzungen ohne zusätzliche CLI-Konfiguration.
Überblick
HTTP/2-Datenverkehr erbt jetzt HTTP AppQoS-Regeln für die DSCP-Markierung, wenn eine bestimmte HTTP/2-Regel nicht vorhanden ist, wodurch ein konsistentes QoS-Verhalten garantiert wird.
HTTP ist eine übergeordnete Anwendung, bei der mehrere Apps (z. B. Facebook, Twitter) als separate Sitzungen angezeigt und unabhängig voneinander klassifiziert werden, wobei AppQoS pro Sitzung angewendet wird. Bisher wurden HTTP/2-Sitzungen nur als http2 klassifiziert, ohne dass eine Klassifizierung von Child-Stream-Anwendungen erforderlich war
Das heißt, für HTTP/2-Sitzungen kann nur die AppQoS-Regel der übergeordneten Sitzung angewendet werden. HTTP/2 verwendet jedoch mehrere Streams, die jeweils als unterschiedliche Anwendungen klassifiziert sind. Untergeordnete Sitzungsklassifizierungen wurden für den AppQoS-Regelabgleich ignoriert.
Mit dem neuen Update wird die Anwendungsklassifizierung der ersten Streamsitzung verwendet, um die AppQoS-Regel mit der übergeordneten HTTP/2-Sitzung abzugleichen und auf diese anzuwenden. Wenn die endgültige klassifizierte Anwendung des ersten Streams keine AppQoS-Regel hat, greift die Sitzung auf die übergeordnete HTTP/2-AppQoS-Regel zurück.
Beispiel:
Ziehen Sie eine HTTP/2-Sitzung in Betracht, die mehrere Streams enthält.
- Der erste Stream wird als Twitter identifiziert.
- Die AppQoS-Regel für Twitter wird angewendet.
- Jeder Stream der übergeordneten HTTP/2-Sitzung erbt die Regel.
Hier gehen die Pakete nicht mehr in eine generische http2-Warteschlange; sie gehen vollständig in die Anwendungswarteschlange von First Stream (Twitter).
Fallback-Logik
HTTP/2-Datenverkehr wird als Teil des HTTP-Datenverkehrs behandelt. Wenn eine HTTP/2-Regel fehlt, greift der Datenverkehr zur DSCP-Markierung auf die HTTP AppQoS-Regel zurück. Um diesen Fallback zu erreichen, werden die Klassifizierungspfade wie im folgenden Beispiel gezeigt angepasst:
Übergeordnete Sitzung
- Bisheriges Verhalten:
ip.tcp.ssl.http2 - Neues Verhalten:
ip.tcp.ssl.http.http2
Untergeordnete Sitzung
- Vorheriges Verhalten:
ip.tcp.ssl.http.facebook - Neues Verhalten:
ip.tcp.ssl.http.http2.facebook
Klassifizierungslogik
AppQoS für HTTP/2 verwendet eine Top-Down-Regelsuche, die mit der spezifischsten App beginnt und über HTTP2, HTTP, SSL und application-any zurückgreift. Die Klassifizierung der ersten Stream-Sitzung wird jetzt für den Abgleich von übergeordneten Sitzungsregeln verwendet, wodurch eine genaue QoS-Zuweisung und -Protokollierung gewährleistet wird.
Regelsatz- und Anwendungszuordnung- Jede Sicherheitsrichtlinie verwendet einen Regelsatz mit spezifischen AppQoS-Regeln für verschiedene Anwendungen (z. B. http, http2, facebook).
- Jede Regel weist eine Weiterleitungsklasse (Best Effort, Assured Forwarding, Expedited Forwarding, Network Control) und eine COS-Warteschlange zu.
- Die AppQoS-Regelsuche beginnt mit der spezifischsten Anwendung (verschachtelte App) und bewegt sich in der Hierarchie nach oben. Sitzungen (übergeordnete/untergeordnete) werden anhand eines hierarchischen Pfads klassifiziert (Beispiel:
ip.tcp.ssl.http.http2.facebook).Im Beispiel sieht die Suchreihenfolge wie folgt aus:
- Wenn die verschachtelte App (
facebook-chat) nicht im Regelsatz konfiguriert ist, wird diehttp2Regel angewendet. - Wenn
http2diese nicht konfiguriert ist, wird diehttpRegel angewendet. - Wenn
httpdiese nicht konfiguriert ist, wird diesslRegel angewendet. - Wenn keine AppQoS-Regel für klassifizierte Apps vorhanden ist, wird die
application-anyRegel angewendet. - Wenn
application-anynicht konfiguriert, wird die Sitzung mit der zuvor angewendeten DSCP-Regel fortgesetzt.
Diese Klassifizierung stellt sicher, dass HTTP/2-Sitzungen niemals ignoriert werden und immer eine QoS-Behandlung erhalten.
- Wenn die verschachtelte App (
Beispiel: Ein AppQoS-Profil enthält Regeln für bestimmte Anwendungen sowie eine "Any"-Catch-All-Regel. Das Profil enthält beispielsweise Regelsätze für HTTP, Facebook, Yahoo und Any, und der erste Stream wird klassifiziert als: Http.http2.twitter
Fall A – "beliebige" Regel konfiguriert
- Es gibt keine explizite Twitter-Regel.
- Da die Regel Any vorhanden ist, wählt AppQoS Any aus.
- Ergebnis: Die Any-Regel wird angewendet.
Fall B – "Beliebige" Regel nicht konfiguriert
- Es gibt keine explizite Twitter-Regel.
- Es ist keine Regel verfügbar.
- In diesem Fall greift das System auf die nächstbeste Übereinstimmung in absteigender Reihenfolge der Spezifität zurück:
- HTTP2-Regel (falls vorhanden)
- Wenn keine http2-Regel → auf http zurückgreifen
- Wenn keine HTTP-Regel die Standardwarteschlange verwenden →
- Ergebnis: Die Regel für die engste Übereinstimmung wird basierend auf der obigen Fallbackreihenfolge ausgewählt.
- Übergeordnete Sitzung: In der Regel auf einer höheren Ebene klassifiziert (Beispiel: http2).
- Untergeordnete Sitzung: Klassifiziert mit spezifischeren verschachtelten Apps (Beispiel: Facebook, Twitter).
Die Klassifizierung der ersten Streamsitzung wird jetzt für den Regelabgleich in der übergeordneten Sitzung berücksichtigt.
Weiterleitung und Protokollierung- Dem Datenverkehr jeder Sitzung wird basierend auf der übereinstimmenden Regel eine Weiterleitungsklasse und eine Warteschlange zugewiesen.
- Syslog-Einträge spiegeln die Klassifizierung und Regelübereinstimmung sowohl für das Schließen von Sitzungen als auch für das Schließen von Streams wider
Einschränkungen
- Für HTTP/2 wird nur die Anwendungsklassifizierung des ersten Streams für den AppQoS-Regelabgleich in der übergeordneten Sitzung verwendet.
- In langlebigen Sitzungen können Midstream-App-Switches (HTTP/1 oder HTTP/2) Änderungen an der CoS-Warteschlange verursachen, was zu einer Neuordnung der Pakete führt. Die TCP-Reassemblierung auf Endgeräten erledigt dies über Sequenznummern.
- HTTP/2 für AppQoS wird in Chassis-Cluster- und Multinode-Hochverfügbarkeitsszenarien nicht unterstützt.
- AppQoS-Ratenbegrenzer funktionieren für HTTPS-Datenverkehr sowohl in HTTP/1.1- als auch in HTTP/2-Datenverkehr-Setups nicht ordnungsgemäß, wenn der SSL-Weiterleitungsproxy konfiguriert ist.
HTTP2-verschlüsselter Datenverkehr
Bei verschlüsseltem Datenverkehr ist das HTTP/2-Modul deaktiviert, sodass keine untergeordneten HTTP/2-Sitzungen erstellt werden. AppQoS wird nur auf die übergeordnete Sitzung angewendet.
Plattformspezifisches AppQoS-Verhalten
Verwenden Sie AppQoS und den Feature-Explorer , um die Plattform- und Release-Unterstützung für bestimmte Funktionen zu bestätigen.
Verwenden Sie die folgende Tabelle, um das plattformspezifische Verhalten für Ihre Plattform zu überprüfen:
| Plattform |
Unterschied |
|---|---|
| SRX-Serie |
SRX5400, SRX5600 und SRX5800 verwenden die folgende Konfigurationsanweisung zum Definieren von Weiterleitungsklassennamen und Warteschlangenzuweisungen: [edit class-of-service] user@host# set forwarding-classes class forwarding-class-name queue-num queue-number |
| SRX-Serie | SRX300, SRX320, SRX340, SRX345, SRX380, SRX400, SRX440, SRX550M, SRX1500, SRX4100, SRX4200, SRX4600 und vSRX, verwenden Sie die folgende Konfigurationsanweisung zum Definieren von Weiterleitungsklassennamen und Warteschlangenzuweisungen: [edit class-of-service] user@host# set forwarding-classes queue queue-number forwarding-class-name |
| SRX-Serie | SRX300, SRX320, SRX340, SRX345, SRX400, SRX440 Verwenden Sie die Option in der loss-priority-highAppQoS-Regel, um die Standardaktion zu überschreiben.[edit] user@host# set class-of-service application-traffic-control rule-sets rset-01 rule r1 then rate-limit loss-priority-high |
| SRX-Serie | SRX5400, SRX5600 und SRX5800 unterstützen bis zu 1000 Ratenbegrenzer pro Gerät. Er erlaubt jedoch nur 16 verschiedene Profile, die jeweils durch eine eindeutige Kombination aus Bandbreitenbegrenzungs- und Burstgrößenbegrenzungsparametern definiert sind. |
Tabellarischer Änderungsverlauf
Die Unterstützung der Funktion hängt von der Plattform und der Version ab, die Sie benutzen. Verwenden Sie den Feature-Explorer , um festzustellen, ob eine Funktion auf Ihrer Plattform unterstützt wird.