QoS des applications
AppQoS vous permet d’identifier et de contrôler l’accès à des applications spécifiques et fournit la granularité de la base de règles du pare-feu dynamique pour correspondre et appliquer la qualité de service (QoS) au niveau de la couche application. Pour plus d’informations, consultez les rubriques suivantes :
Comprendre la qualité de service des applications (AppQoS)
La fonctionnalité de qualité de service des applications (AppQoS) étend la capacité de la classe de service (CoS) de Junos OS pour inclure le marquage des valeurs DSCP en fonction des types d’applications de couche 7, le respect du trafic basé sur les applications par le biais de paramètres de priorité des pertes et le contrôle des taux de transfert sur les PIC de sortie en fonction des types d’applications de couche 7.
Il existe quatre façons de marquer les valeurs DSCP sur l’équipement de sécurité :
Réécritures DSCP basées sur les actions d’attaque IDP
Réécritures DSCP basées sur les applications de couche 7
Réécritures DSCP basées sur ALG
Réécritures DSCP basées sur des filtres de pare-feu
Le remarquage IDP est effectué au port entrant en fonction des règles IDP. Le remarquage de l’application est effectué au niveau du port de sortie en fonction des règles d’application. Le remarquage basé sur l’interface se produit également au niveau du port de sortie en fonction des règles de filtre du pare-feu. (Consultez le Guide de l’utilisateur de la classe de service (Équipements de Sécurité) pour une description détaillée des fonctionnalités CoS de Junos OS.)
Les décisions de remarquage de ces trois rédacteurs peuvent être différentes. Si un paquet déclenche les trois, la méthode qui prévaut est basée sur la profondeur du contenu du paquet à laquelle la correspondance est effectuée. Le remarquage IDP a la priorité sur le remarquage de l’application qui a préséance sur le remarquage basé sur l’interface.
Si un paquet déclenche à la fois AppQoS et des réécritures DSCP basées sur ALG, AppQoS a la priorité sur les réécritures DSCP basées sur ALG.
La réécriture DSCP AppQoS transmet la qualité de service d’un paquet à la fois par le biais de la classe de transfert et d’une priorité de perte. Les paramètres de limitation de débit d’AppQoS contrôlent la vitesse et le volume de transmission des files d’attente associées.
- Avantage de la QoS des applications
- Classes de transfert et affectations de files d’attente uniques
- Paramètres de point de code DSCP et de priorité des pertes conscients des applications
- Profils et limiteurs de débit
- Attribution d’un limiteur de débit
- Action du limiteur de débit
- Configuration de la politique de sécurité AppQoS
Avantage de la QoS des applications
AppQoS permet de hiérarchiser et de mesurer le trafic applicatif afin d’améliorer le service au trafic applicatif stratégique ou hautement prioritaire.
Classes de transfert et affectations de files d’attente uniques
La classe de transfert fournit trois fonctions :
Regroupe les paquets ayant des caractéristiques similaires
Attribue des files d’attente de sortie
Résout les conflits avec les réécritures basées sur des filtres de pare-feu Junos OS existants
Les noms uniques des classes de transfert protègent le remarquage AppQoS contre l’écrasement par des règles de réécriture basées sur l’interface. Un réenregistreur basé sur un filtre de pare-feu remarque la valeur DSCP d’un paquet si la classe de transfert du paquet correspond à une classe définie spécifiquement pour ce réscripteur. Si la classe de transfert du paquet ne correspond à aucune des classes du réécrivain basé sur le filtre de pare-feu, la valeur DSCP n’est pas remarquée. Pour éviter que les valeurs AppQoS ne soient écrasées, utilisez donc des noms de classe de transfert inconnus du réenregistreur basé sur les filtres du pare-feu.
Chaque classe de transfert est affectée à une file d’attente de sortie qui fournit le degré approprié de traitement amélioré ou standard. De nombreuses classes de transfert peuvent être affectées à une seule file d’attente. Par conséquent, toutes les files d’attente définies pour l’appareil peuvent être utilisées par les réscripteurs basés sur des filtres d’IDP, d’AppQoS et d’IDP. C’est le nom de la classe de transfert, et non la file d’attente, qui distingue la priorité de transmission. (Pour plus d’informations sur la configuration des files d’attente et des planificateurs, reportez-vous au Guide de l’utilisateur sur la classe de service (Sécurité Appareils.)
Paramètres de point de code DSCP et de priorité des pertes conscients des applications
Pour AppQoS, le trafic est regroupé en fonction de règles qui associent une classe de transfert définie aux applications sélectionnées. Les critères de correspondance de la règle incluent une ou plusieurs applications. Lorsque le trafic d’une application correspondante rencontre la règle, l’action de la règle définit la classe de transfert et remarque la valeur DSCP et la priorité de perte aux valeurs appropriées pour l’application.
Une valeur DSCP (Differentiated Services) est spécifiée dans la règle soit par une valeur bitmap 6 bits, soit par un alias défini par l’utilisateur ou par défaut. Le Tableau 1 fournit une liste des noms d’alias DSCP par défaut de Junos OS et des valeurs bitmap.
Pseudonyme |
Valeur binaire |
|---|---|
ef |
101110 |
AF11 |
001010 |
AF12 |
001100 |
AF13 |
001110 |
AF21 |
010010 |
AF22 |
010100 |
AF23 |
010110 |
AF31 |
011010 |
AF32 |
011100 |
AF33 |
011110 |
AF41 |
100010 |
AF42 |
100100 |
AF43 |
100110 |
be |
000000 |
CS1 |
001000 |
CS2 |
010000 |
CS3 |
011000 |
CS4 |
100000 |
CS5 |
101000 |
NC1/CS6 |
110000 |
NC2/CS7 |
111000 |
Voir Valeurs et alias CoS par défaut pour plus de détails.
Le planificateur de la file d’attente utilise la priorité de perte pour contrôler la perte de paquets pendant les périodes de congestion en associant des profils de perte à des valeurs de priorité de perte particulières. (Pour plus d’informations sur la configuration des files d’attente et des planificateurs, reportez-vous au Guide de l’utilisateur sur la classe de service (Sécurité Appareils .)
La règle applique une priorité de perte aux groupes de trafic. Une priorité de perte élevée signifie une forte probabilité que le paquet soit perdu pendant une période de congestion. Quatre niveaux de priorité des sinistres sont disponibles :
highmedium-highmedium-lowlow
L’ensemble de règles est défini dans la commande de class-of-service application-traffic-control configuration :
[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
Profils et limiteurs de débit
En cas de congestion, AppQoS met en œuvre une limitation de débit sur tous les PIC de sortie de l’appareil. Si les paquets dépassent les limites attribuées, ils sont abandonnés. Les limiteurs de débit maintiennent un niveau constant de sensibilité au débit et à la perte de paquets pour différentes classes de trafic. Tous les PIC sortants utilisent le même système de limitation de débit.
La bande passante totale d’un PIC est d’environ 10 Gbit/s. Le matériel de limitation de débit du PIC peut allouer jusqu’à 2 Gbit/s. Par conséquent, la limite supérieure de la bande passante pour limiter le débit est de 231 bps.
Un profil de limiteur de débit définit les limitations. Il s’agit d’une combinaison unique de bandwidth-limit spécifications et burst-size-limit de spécifications. Définit bandwidth-limit le nombre maximal de kilobits par seconde pouvant traverser le port. Le burst-size-limit définit le nombre maximal d’octets qui peuvent traverser le port en une seule rafale. Le burst-size-limit réduit la privation du trafic de priorité inférieure en assurant une taille finie pour chaque rafale.
AppQoS permet jusqu’à 16 profils et jusqu’à 1000 limiteurs de débit par appareil. Plusieurs limiteurs de débit peuvent utiliser le même profil. Dans l’exemple suivant, cinq limiteurs de débit sont définis à l’aide de deux profils :
Nom du limiteur de débit |
Profil |
|
|---|---|---|
limite de bande passante |
limite de taille de rafale |
|
limiteur-1 |
200 |
26000 |
limiteur-2 |
200 |
26000 |
limiteur-3 |
200 |
26000 |
limiteur-4 |
400 |
52000 |
limiteur-5 |
400 |
52000 |
Les limiteurs de débit sont définis avec la class-of-service application-traffic-control commande configuration.
[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
Attribution d’un limiteur de débit
Les limiteurs de débit sont appliqués dans les règles basées sur l’application du trafic. Deux limiteurs de débit sont appliqués pour chaque session : client-to-server et server-to-client. Cette utilisation permet de provisionner séparément le trafic dans chaque direction.
Le traitement de la bande passante du trafic par les limiteurs de débit se fait au niveau des paquets, quelle que soit la direction du trafic. Par exemple : Prenons un cas où vous n’avez qu’un seul limiteur de débit de 10G configuré, si le trafic entrant et sortant provient de la même carte de ligne, alors le débit (trafic maximal des directions d’entrée et de sortie combinées) ne peut atteindre que 10G et non 20G. Toutefois, si l’équipement prend en charge l’IOC (cartes E/S) (IOC)) et que le trafic entrant passe par un IOC et le trafic sortant par un autre IOC, alors avec un seul limiteur de débit de 10G configuré, vous pouvez vous attendre à un débit de 20G.
Différentes règles AppQoS au sein d’un même ensemble de règles peuvent partager un limiteur de débit. Dans ce cas, les applications de ces règles partagent la même bande passante. Il n’y a pas de limite au nombre de règles dans un ensemble de règles qui peuvent affecter le même limiteur de débit.
Les exemples suivants montrent comment les limiteurs de débit définis dans la section précédente pourraient être affectés. Par exemple, un ensemble de règles peut réutiliser un limiteur de débit dans plusieurs règles et dans un sens de flux ou les deux :
ensemble_de_règles-1
règle-1A
limiteur client-serveur-1
limiteur serveur-client-1
règle-1B
limiteur client-serveur-1
limiteur serveur-client-1
Si les mêmes profils sont nécessaires dans plusieurs ensembles de règles, un nombre suffisant de limiteurs de débit doivent être définis spécifiant les mêmes bandwidth-limit et burst-size-limit. Les deux ensembles de règles de l’exemple suivant implémentent les mêmes profils en affectant des limiteurs de débit différents, mais comparables.
ensemble de règles-2
règle-2A
limiteur client-serveur-2
limiteur serveur-client-2
règle-2B
limiteur client-serveur-2
limiteur serveur-client-4
ensemble de règles-3
règle-3A
limiteur client-serveur-3
limiteur serveur-client-3
règle-3B
limiteur client-serveur-3
limiteur serveur-client-5
Un limiteur de débit est appliqué à l’aide de la edit class-of-service application-traffic-control rule-sets commande de la même manière qu’une classe de transfert, une valeur DSCP et une priorité de perte.
[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
Si AppQoS et la limitation du débit basée sur les filtres du pare-feu sont toutes deux implémentées sur le PIC de sortie, les deux sont prises en compte. La limitation du débit d’AppQoS est prise en compte en premier. La limitation du débit basée sur les filtres du pare-feu se produit ensuite.
Si des paquets sont perdus d’un PIC, l’appareil n’envoie pas de notifications au client ou au serveur. Les applications de niveau supérieur sur les périphériques client et serveur sont responsables de la retransmission et de la gestion des erreurs.
Action du limiteur de débit
Selon le type d’équipement de sécurité, les règles AppQoS peuvent être configurées avec différentes actions de limitation de débit :
Rejeter
Lorsque cette option est sélectionnée, les paquets hors profil sont simplement abandonnés.
Il s’agit du type d’action par défaut et n’a pas besoin d’être configuré.
Cette option est prise en charge sur tous les appareils de sécurité
Perte-priorité-élevée
Lorsque cette option est sélectionnée , elle élève la priorité des pertes au maximum. En d’autres termes, il s’agit d’une chute retardée ; En d’autres termes, la décision de rejet est prise au niveau de la file d’attente de sortie de sortie. S’il n’y a pas de congestion, il permet au trafic même avec une perte maximale de priorité. Mais en cas de congestion, il abandonne d’abord ces paquets prioritaires de perte maximale.
Cette option doit être configurée dans la règle AppQoS (pour remplacer l’action par défaut) à l’aide de la commande suivante :
[edit] user@host# set class-of-service application-traffic-control rule-sets rset-01 rule r1 then rate-limit loss-priority-high
-
Cette option est prise en charge sur certains appareils. Voir le tableau Comportement AppQoS spécifique à la plate-forme .
Configuration de la politique de sécurité AppQoS
L’ensemble de règles AppQoS peut être implémenté dans une stratégie existante ou une stratégie d’application spécifique.
[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
Voir aussi
Exemple : configuration de la qualité de service des applications
Cet exemple montre comment activer la hiérarchisation AppQoS et la limitation de débit dans une stratégie.
Exigences
Aucune configuration spéciale au-delà de l’initialisation de l’équipement n’est requise avant de configurer cette fonctionnalité.
Vue d’ensemble
Dans cet exemple, AppQoS est implémenté de sorte que les applications FTP sont limitées à un niveau inférieur au débit spécifié, tandis que les autres applications sont transmises à un niveau de priorité de vitesse et de perte plus conventionnel.
La configuration
Procédure
Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez tous les détails nécessaires pour qu’ils correspondent à votre configuration réseau, puis copiez-collez les commandes dans la CLI au niveau de la hiérarchie [modifier].
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
Procédure étape par étape
Pour configurer une AppQoS sur votre équipement de sécurité :
-
Définissez une ou plusieurs classes de transfert dédiées au marquage AppQoS. Dans cet exemple, une seule classe de transfert, my-app-fc, est définie et affectée à la file d’attente 4.
[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
Les appareils Juniper Networks prennent en charge huit files d’attente (de 0 à 7). Les files d’attente par défaut 0 à 3 sont affectées aux classes de transfert par défaut. Les files d’attente 4 à 7 n’ont pas d’affectation par défaut aux FC et ne sont pas mappées. Pour utiliser les files d’attente 4 à 7, vous devez créer des noms de FC personnalisés et les mapper aux files d’attente. Pour plus de détails, consultez Vue d’ensemble des classes de transfert.
Définir des limiteurs de débit. Dans cet exemple, deux limiteurs de débit sont définis.
[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
-
Définissez les règles AppQos et les critères de correspondance des applications.
[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
Dans cet exemple, lorsqu’une correspondance est établie, le paquet est marqué avec la classe de transfert my-app-fc, la valeur DSCP de af22 et une priorité de perte faible. Nous avons attribué le même limiteur de débit dans les deux sens.
Vous pouvez affecter un limiteur de débit à une ou aux deux directions de trafic dans une seule règle. Vous pouvez également affecter un même limiteur de débit à d’autres règles d’un ensemble de règles. Cependant, vous ne pouvez pas affecter un même limiteur de débit à un ensemble de règles différent.
-
Définissez une autre règle pour gérer les paquets d’application qui ne correspondent pas à la règle précédente. Dans cet exemple, une deuxième et dernière règle s’applique à toutes les autres demandes.
[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
-
Ajoutez le paramètre AppQoS à la stratégie de sécurité.
[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
Résultats
En mode configuration, confirmez la configuration de votre stratégie en entrant la show security policies commande and show class-of-service . Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.
Par souci de concision, cette show sortie de commande inclut uniquement la configuration pertinente pour cet exemple. Toute autre configuration du système a été remplacée par des ellipses (...).
...
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;
}
}
}
}
Si vous avez terminé de configurer l’appareil, entrez en commit mode configuration.
Vérification
Vérifiez que la configuration fonctionne correctement.
- Vérification de la configuration de la session de flux
- Vérification des statistiques de session
- Vérification des statistiques des limiteurs de débit
- Vérification des statistiques des règles
Vérification de la configuration de la session de flux
Objet
Vérifiez qu’AppQoS est activé.
Mesures à prendre
À partir du mode opérationnel, entrez la show security flow session application-traffic-control extensive commande.
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
Signification
L’entrée pour le contrôle du trafic applicatif identifie l’ensemble de règles et la règle de la session en cours.
Vérification des statistiques de session
Objet
Vérifiez que les statistiques de session AppQoS sont accumulées à chaque nœud de sortie.
Mesures à prendre
À partir du mode opérationnel, entrez la show class-of-service application-traffic-control counter commande.
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
Signification
Les statistiques AppQoS ne sont conservées que si le service application-trafic-control est activé. Le nombre de sessions traitées, marquées et honorées indique que les sessions sont dirigées en fonction des fonctionnalités AppQoS configurées. Les statistiques de limitation de débit comptent le nombre de flux de session directionnels dont le débit a été limité.
Vérification des statistiques des limiteurs de débit
Objet
Vérifiez que la bande passante est limitée comme prévu lorsque l’application FTP est rencontrée.
Mesures à prendre
À partir du mode opérationnel, entrez la show class-of-service application-traffic-control statistics rate-limiter commande.
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
Signification
Les informations en temps réel sur les limites de bande passante des applications pour chaque PIC sont affichées par ensemble de règles. Cette commande indique les applications dont le débit est limité et le profil appliqué.
Vérification des statistiques des règles
Objet
Vérifiez que la règle correspond aux statistiques de la règle.
Mesures à prendre
À partir du mode opérationnel, entrez la show class-of-service application-traffic-control statistics rule commande.
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
Signification
Cette commande fournit des informations sur le nombre d’accès (de session) à une règle sous chaque ensemble de règles.
Prise en charge de la qualité de service des applications pour des politiques unifiées
Les stratégies unifiées sont les stratégies de sécurité qui vous permettent d’utiliser des applications dynamiques dans le cadre des conditions de correspondance existantes à 5 ou 6 uplets (5 uplets avec un pare-feu utilisateur) pour détecter les changements d’application au fil du temps.
La qualité de service des applications (AppQoS) est prise en charge lorsque l’équipement de sécurité est configuré avec des politiques unifiées. Vous pouvez configurer un ensemble de règles AppQoS par défaut pour gérer les conflits de politiques unifiées si plusieurs stratégies de sécurité correspondent au trafic.
Les ensembles de règles AppQoS sont inclus dans la stratégie unifiée pour mettre en œuvre un contrôle de la qualité de service en fonction des applications. Vous pouvez configurer un ensemble de règles avec des règles sous l’option application-traffic-control et attacher l’ensemble de règles AppQoS à une stratégie de sécurité unifiée en tant que service d’application. Si le trafic correspond à l’application dynamique spécifiée et que l’action de stratégie est autorisée, la qualité de service sensible aux applications est appliquée.
Notez les fonctionnalités AppQoS suivantes dans les stratégies unifiées :
Mise à niveau d’une stratégie de sécurité traditionnelle vers une stratégie unifiée : dans une stratégie unifiée, lorsque vous configurez l’option
dynamic-applicationcomme ,nonel’ensemble de règles AppQoS est appliqué lors de la correspondance de stratégie de sécurité et AppQoS recherche la règle correspondante pour le trafic identifié. Il s’agit du même comportement pour la fonctionnalité AppQoS dans les versions de Junos OS antérieures à la version 18.2R1.Règle AppQoS avec une stratégie unifiée : dans la configuration du contrôle du trafic applicatif, l’ensemble de règles AppQoS est configuré avec la condition
application-anyde correspondance et dans la stratégie unifiée, une application dynamique spécifique est utilisée comme condition de correspondance, puis, la fonctionnalité AppQoS fonctionne conformément à la règle de la stratégie unifiée.
- Comprendre l’ensemble de règles de qualité de service des applications par défaut pour les stratégies unifiées
- Ensemble de règles de qualité de service des applications par défaut dans différents scénarios
- Limitation de l’AppQoS avec des politiques unifiées
Comprendre l’ensemble de règles de qualité de service des applications par défaut pour les stratégies unifiées
Vous pouvez configurer un ensemble de règles par défaut AppQoS pour gérer les conflits de stratégie de sécurité.
La phase initiale de recherche de stratégie a lieu avant l’identification d’une application dynamique. S’il existe plusieurs stratégies présentes dans la liste de stratégies potentielles qui contiennent différents ensembles de règles AppQoS, le périphérique de sécurité applique l’ensemble de règles AppQoS par défaut jusqu’à ce qu’une correspondance plus explicite se produise.
Vous pouvez définir une AppQoS comme règle AppQoS par défaut définie sous le niveau hiérarchique edit security ngfw . L’ensemble de règles AppQoS par défaut est tiré parti de l’un des ensembles de règles AppQoS existants, qui sont configurés au niveau de la [edit class-of-service application-traffic-control] hiérarchie.
Le tableau 2 résume l’utilisation de l’ensemble de règles AppQoS par défaut dans différents scénarios dans une stratégie unifiée.
État d’identification de l’application |
Utilisation de l’ensemble de règles AppQoS |
Mesures à prendre |
|---|---|---|
Pas de conflit avec les politiques de sécurité. |
La règle AppQoS définie sous la hiérarchie [ |
AppQoS est appliqué comme dans l’ensemble de règles AppQoS. |
Les conflits de stratégies de sécurité et les stratégies conflictuelles ont des ensembles de règles AppQoS distincts. |
L’ensemble de règles AppQoS par défaut est inconfiguré ou introuvable. |
La session est ignorée car le profil AppQoS par défaut n’est pas configuré. Par conséquent, même si la stratégie finale correspondante dans le scénario de conflit de stratégie a un ensemble de règles AppQoS, cet ensemble de règles n’est pas appliqué. Nous vous recommandons de configurer un ensemble de règles AppQoS par défaut pour gérer les conflits de stratégie de sécurité. |
L’ensemble de règles AppQoS par défaut est configuré. |
AppQoS est appliqué comme dans l’ensemble de règles AppQoS par défaut. |
|
La demande finale est identifiée |
La stratégie de sécurité correspondante dispose d’un ensemble de règles AppQoS, qui est identique à l’ensemble de règles AppQoS par défaut. |
AppQoS est appliqué comme dans l’ensemble de règles AppQoS par défaut. |
La stratégie de sécurité correspondante n’a pas d’ensemble de règles AppQoS. |
L’ensemble de règles AppQoS par défaut n’est pas appliqué et AppQoS n’est pas appliqué à la session. |
|
La stratégie de sécurité correspondante a un ensemble de règles AppQoS différent de l’ensemble de règles AppQoS par défaut, qui est déjà appliqué. |
L’ensemble de règles AppQoS par défaut reste l’ensemble de règles AppQoS par défaut. |
Lorsqu’un ensemble de règles AppQoS par défaut est appliqué au trafic et que la stratégie de sécurité finale a un ensemble de règles AppQoS différent, dans ce cas, le passage de l’ensemble de règles AppQoS par défaut à l’ensemble de règles AppQoS défini dans la stratégie de sécurité finale n’est pas pris en charge.
Ensemble de règles de qualité de service des applications par défaut dans différents scénarios
Les liens suivants mènent à des exemples qui décrivent les ensembles de règles AppQoS par défaut dans différents scénarios :
Le Tableau 3 présente différents ensembles de règles AppQoS configurés pour des stratégies unifiées avec des applications dynamiques comme condition de correspondance.
Politique de sécurité |
Source Zone |
Adresse IP source |
Destination Zone |
Adresse IP de destination |
Numéro de port |
Protocole |
Application dynamique |
Service après-vente |
Ensemble de règles AppQoS |
|---|---|---|---|---|---|---|---|---|---|
Stratégie-P1 |
S1 |
50.1.1.1 |
J1 |
N’importe lequel |
N’importe lequel |
N’importe lequel |
Facebook (en anglais) |
AppQoS |
AppQoS-1 |
Stratégie-P2 |
S1 |
50.1.1.1 |
J1 |
N’importe lequel |
N’importe lequel |
N’importe lequel |
Google (en anglais) |
AppQoS |
AppQoS-2 |
Stratégie-P3 |
S1 |
50.1.1.1 |
J1 |
N’importe lequel |
N’importe lequel |
N’importe lequel |
YouTube (en anglais) |
AppQoS |
AppQoS-3 |
Dans cet exemple, tous les ensembles de règles AppQoS (AppQoS-1, AppQoS-2, AppQoS-3) peuvent être configurés en tant qu’ensemble de règles AppQoS par défaut au niveau de la [security ngfw] hiérarchie. Il n’est pas nécessaire qu’un ensemble de règles par défaut fasse partie d’une configuration de stratégie de sécurité. Tout ensemble de règles AppQoS au niveau de la [edit class-of-service application-traffic-control] hiérarchie peut être affecté comme ensemble de règles AppQoS par défaut.
- Aucun conflit de stratégie : toutes les stratégies ont le même ensemble de règles AppQoS
- Pas de conflit de stratégie : toutes les stratégies ont le même ensemble de règles AppQoS et la stratégie finale n’a pas de jeu de règles AppQoS
- Conflit de stratégie : aucun ensemble de règles AppQoS n’est configuré pour la stratégie finale
- Conflit de stratégie : ensemble de règles AppQoS par défaut et ensemble de règles AppQoS différent pour la stratégie finale
Aucun conflit de stratégie : toutes les stratégies ont le même ensemble de règles AppQoS
Toutes les stratégies de correspondance ont le même ensemble de règles AppQoS que celui indiqué dans le tableau 4.
Politique de sécurité |
Source Zone |
Adresse IP source |
Destination Zone |
Adresse IP de destination |
Numéro de port |
Protocole |
Application dynamique |
Service après-vente |
Ensemble de règles AppQoS |
|---|---|---|---|---|---|---|---|---|---|
Stratégie-P1 |
S1 |
N’importe lequel |
J1 |
N’importe lequel |
N’importe lequel |
N’importe lequel |
Facebook (en anglais) |
AppQoS |
AppQoS-1 |
Stratégie-P2 |
S1 |
N’importe lequel |
J1 |
N’importe lequel |
N’importe lequel |
N’importe lequel |
Google (en anglais) |
AppQoS |
AppQoS-1 |
Dans ce scénario, les stratégies Policy-P1 et Policy-P2 ont le même ensemble de règles AppQoS ; c’est-à-dire AppQoS-1. L’ensemble de règles AppQoS-1 est appliqué. Policy-P3 n’est pas configuré dans ce scénario.
Si vous avez configuré l’ensemble de règles AppQoS-2 comme ensemble de règles par défaut, il n’est pas appliqué. En effet, il n’y a pas de conflit dans les ensembles de règles AppQoS dans les stratégies en conflit (Policy-P1 et Policy-P2).
Pas de conflit de stratégie : toutes les stratégies ont le même ensemble de règles AppQoS et la stratégie finale n’a pas de jeu de règles AppQoS
Toutes les stratégies correspondantes ont le même ensemble de règles AppQoS que celui indiqué dans le tableau 5 et la stratégie finale n’a pas de jeu de règles AppQoS.
Politique de sécurité |
Source Zone |
Adresse IP source |
Destination Zone |
Adresse IP de destination |
Numéro de port |
Protocole |
Application dynamique |
Service après-vente |
Ensemble de règles AppQoS |
|---|---|---|---|---|---|---|---|---|---|
Stratégie-P1 |
S1 |
N’importe lequel |
J1 |
N’importe lequel |
N’importe lequel |
N’importe lequel |
Facebook (en anglais) |
AppQoS |
AppQoS-1 |
Stratégie-P2 |
S1 |
N’importe lequel |
J1 |
N’importe lequel |
N’importe lequel |
N’importe lequel |
Google (en anglais) |
AppQoS |
AppQoS-1 |
Stratégie-P3 |
S1 |
50.1.1.1 |
J1 |
N’importe lequel |
N’importe lequel |
N’importe lequel |
YouTube (en anglais) |
Autre |
Aucun |
Dans ce scénario, Policy-P1 et Policy-P2 ont le même ensemble de règles AppQoS, c’est-à-dire AppQoS-1. Dans ce cas, l’ensemble de règles AppQoS-1 est appliqué.
Lorsque la stratégie finale Policy-P3 est mise en correspondance, AppQoS ignore la session, car l’ensemble de règles AppQoS n’est pas configuré pour Policy-P3.
Si aucune règle AppQoS n’est définie dans la stratégie de sécurité finale, AppQoS n’est pas appliqué au trafic. Tous les paramètres AppQoS appliqués lors de la phase de pré-match sont rétablis aux valeurs d’origine.
Conflit de stratégie : aucun ensemble de règles AppQoS n’est configuré pour la stratégie finale
L’ensemble de règles AppQoS par défaut (dans ce scénario AppQoS-1) est appliqué lors de la correspondance de stratégie potentielle, comme indiqué dans le tableau 6. La stratégie finale Policy-P3 n’a pas de règle AppQoS définie.
Politique de sécurité |
Source Zone |
Adresse IP source |
Destination Zone |
Adresse IP de destination |
Numéro de port |
Protocole |
Application dynamique |
Service après-vente |
Ensemble de règles AppQoS |
|---|---|---|---|---|---|---|---|---|---|
Stratégie-P1 |
S1 |
50.1.1.1 |
J1 |
N’importe lequel |
N’importe lequel |
N’importe lequel |
Facebook (en anglais) |
AppQoS |
AppQoS-1 |
Stratégie-P2 |
S1 |
50.1.1.1 |
J1 |
N’importe lequel |
N’importe lequel |
N’importe lequel |
Google (en anglais) |
AppQoS |
AppQoS-2 |
Stratégie-P3 |
S1 |
50.1.1.1 |
J1 |
N’importe lequel |
N’importe lequel |
N’importe lequel |
YouTube (en anglais) |
Autre |
S.O. |
AppQoS ignore la session si la stratégie de correspondance finale Policy-P3 est appliquée.
Si aucune règle AppQoS n’est définie dans la stratégie de sécurité finale, AppQoS n’est pas appliqué au trafic. Dans ce cas, tous les paramètres AppQoS appliqués lors de la phase de pré-match sont rétablis aux valeurs d’origine.
Conflit de stratégie : ensemble de règles AppQoS par défaut et ensemble de règles AppQoS différent pour la stratégie finale
L’ensemble de règles AppQoS-1 est configuré comme un ensemble de règles par défaut et est appliqué lorsque l’application finale n’est pas encore identifiée. La stratégie de stratégie finale-P3 a un ensemble de règles AppQoS différent (AppQoS-3), comme indiqué dans le tableau 7.
Politique de sécurité |
Source Zone |
Adresse IP source |
Destination Zone |
Adresse IP de destination |
Numéro de port |
Protocole |
Application dynamique |
Service après-vente |
Ensemble de règles AppQoS |
|---|---|---|---|---|---|---|---|---|---|
Stratégie-P1 |
S1 |
50.1.1.1 |
J1 |
N’importe lequel |
N’importe lequel |
N’importe lequel |
Facebook (en anglais) |
AppQoS |
AppQoS-1 |
Stratégie-P2 |
S1 |
50.1.1.1 |
J1 |
N’importe lequel |
N’importe lequel |
N’importe lequel |
Google (en anglais) |
AppQoS |
AppQoS-2 |
Stratégie-P3 |
S1 |
50.1.1.1 |
J1 |
N’importe lequel |
N’importe lequel |
N’importe lequel |
YouTube (en anglais) |
AppQoS |
AppQoS-3 |
Lorsque l’application finale est identifiée, la stratégie-P3 de la stratégie est mise en correspondance et appliquée. Dans ce cas, l’ensemble de règles AppQoS-3 n’est pas appliqué. Au lieu de cela, l’ensemble de règles AppQoS-1 est appliqué comme ensemble de règles par défaut et reste comme ensemble de règles par défaut.
Limitation de l’AppQoS avec des politiques unifiées
Lorsqu’une stratégie de sécurité est appliquée au trafic correspondant, l’ensemble de règles AppQoS est appliqué au trafic autorisé. Si la stratégie de sécurité et l’ensemble de règles AppQoS appliquées ont des applications dynamiques différentes, un conflit peut se produire, comme illustré dans l’exemple suivant :
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
Dans cet exemple, la règle de contrôle du trafic de l’application est configurée pour junos :GOOGLE et la condition de correspondance de la stratégie de sécurité pour l’application dynamique est junos : FTP. Dans de tels cas, des conflits peuvent survenir lors de l’application de la politique finale.
Voir aussi
Exemple : configuration de la qualité de service des applications avec une politique unifiée
Cet exemple montre comment activer la qualité de service des applications (AppQoS) au sein d’une stratégie unifiée afin de hiérarchiser et de limiter le débit du trafic.
Exigences
Cet exemple utilise les composants matériels et logiciels suivants :
Pare-feu SRX Series exécutant Junos OS version 18.2R1 et ultérieure. Cet exemple de configuration est testé pour Junos OS version 18.2R1.
Aucune configuration spéciale au-delà de l’initialisation de l’équipement n’est requise avant de configurer cette fonctionnalité.
Vue d’ensemble
Dans cet exemple, vous configurez un ensemble de règles AppQoS et appelez AppQoS en tant que service d’application dans la stratégie de sécurité de l’application Facebook.
Vous définissez un ensemble de règles AppQoS par défaut sous le niveau hiérarchique [edit security ngfw] pour gérer les conflits de stratégie de sécurité, le cas échéant.
La configuration
Procédure
Procédure étape par étape
Pour configurer AppQoS avec une stratégie unifiée :
Définir un ensemble de règles AppQoS.
[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
Configurez un ensemble de règles AppQoS par défaut. Sélectionnez l’ensemble
RS1de règles créé sous le contrôle du trafic de l’application comme ensemble de règles AppQoS par défaut.[edit] user@host# set security ngfw default-profile application-traffic-control rule-set RS1
Associez l’ensemble de règles de classe de service à la stratégie unifiée.
[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
Résultats
En mode configuration, confirmez la configuration de votre stratégie en entrant la show security policies commande. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.
Par souci de concision, cette show sortie de commande inclut uniquement la configuration pertinente pour cet exemple. Toute autre configuration du système a été remplacée par des ellipses (...).
...
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;
}
}
}
Si vous avez terminé de configurer l’appareil, entrez en commit mode configuration.
Vérification
Vérifiez que la configuration fonctionne correctement.
Vérification de la configuration de la session de flux
Objet
Affichez les statistiques de session AppQoS.
Mesures à prendre
À partir du mode opérationnel, entrez la show class-of-service application-traffic-control counter commande.
Exemple de sortie
nom_commande
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
Signification
La sortie affiche le nombre de sessions traitées, marquées et honorées. Les statistiques de limitation de débit comptent le nombre de flux de session directionnels dont le débit a été limité.
Vérification des statistiques des règles
Objet
Affichez les statistiques de la règle AppQoS.
Mesures à prendre
À partir du mode opérationnel, entrez la show class-of-service application-traffic-control statistics rule commande.
user@host>show class-of-service application-traffic-control statistics rule
pic: 0/0
Ruleset Rule Hits
RS1 1 1
Signification
La sortie fournit des informations sur le nombre de sessions mises en correspondance pour la règle sous chaque ensemble de règles AppQoS.
HTTP2 : prise en charge DSCP d’AppQoS
La prise en charge de la qualité de service des applications (AppQoS) de HTTP/2 Differentiated Services Code Point (DSCP) améliore l’application des règles de qualité de service (QoS) sur les sessions HTTP/2 en tirant parti des classifications de premier flux. Cette amélioration permet d’appliquer des règles de QoS aux sessions HTTP/2, ce qui garantit que le trafic est classé et hiérarchisé en fonction du type d’application. Cette fonctionnalité vous permet d’appliquer des politiques AppQoS granulaires dans le trafic HTTP/2, ce qui est essentiel lors de la gestion de plusieurs flux classés sous différentes applications. En appliquant des règles AppQoS basées sur la classification de la première session de flux, vous garantissez une gestion cohérente de la QoS, même lorsque la logique de secours est appelée en raison de règles non spécifiées. Cette fonctionnalité s’intègre aux frameworks de gestion du trafic HTTP/2 existants, permet de traiter des scénarios à travers des scénarios de politiques traditionnelles et unifiées, et de maintenir une application efficace de la QoS dans les sessions chiffrées sans aucune configuration CLI supplémentaire.
Vue d’ensemble
Le trafic HTTP/2 hérite désormais des règles HTTP AppQoS pour le marquage DSCP en l’absence d’une règle HTTP/2 spécifique, ce qui garantit un comportement de QoS cohérent.
HTTP est une application parapluie dans laquelle plusieurs applications (par exemple, facebook, twitter) apparaissent sous forme de sessions distinctes et sont classées indépendamment, avec AppQoS appliqué par session. Auparavant, les sessions HTTP/2 étaient classées uniquement en http2, sans aucune classification d’application de flux enfant
Autrement dit, pour les sessions HTTP/2, seule la règle AppQoS de la session parent peut être appliquée. Cependant, HTTP/2 utilise plusieurs flux, chacun classé comme des applications différentes. Les classifications de session enfants ont été ignorées pour la correspondance des règles AppQoS.
Avec la nouvelle mise à jour, la classification des applications de la première session de flux est utilisée pour faire correspondre et appliquer la règle AppQoS à la session parente HTTP/2. Si l'application classée finale du premier flux n'a pas de règle AppQoS, la session revient à la règle AppQoS HTTP/2 parente.
Exemple :
Prenons l’exemple d’une session HTTP/2 qui inclut plusieurs flux.
- Le premier flux est identifié comme twitter.
- La règle AppQoS pour Twitter est appliquée.
- Chaque flux de la session parent HTTP/2 hérite de la règle.
Ici, les paquets ne vont plus dans une file d’attente http2 générique ; ils vont entièrement dans la file d'attente des applications de First Stream (Twitter).
Logique de repli
Le trafic HTTP/2 est traité comme faisant partie du trafic HTTP. Si une règle HTTP/2 est manquante, le trafic revient à la règle HTTP AppQoS pour le marquage DSCP. Pour réaliser ce repli, les chemins de classification sont ajustés comme indiqué dans l’exemple suivant :
Session parent
- Comportement précédent :
ip.tcp.ssl.http2 - Nouveau comportement :
ip.tcp.ssl.http.http2
Session enfant
- Comportement précédent :
ip.tcp.ssl.http.facebook - Nouveau comportement :
ip.tcp.ssl.http.http2.facebook
Logique de classification
AppQoS for HTTP/2 utilise une recherche de règles descendante, en commençant par l’application la plus spécifique et en revenant à HTTP2, HTTP, SSL et application-any. La classification de la première session de flux est désormais utilisée pour la correspondance des règles de session parente, ce qui garantit une attribution et une journalisation précises de la QoS.
Jeu de règles et mappage des applications- Chaque stratégie de sécurité utilise un ensemble de règles avec des règles AppQoS spécifiques pour différentes applications (par exemple, http, http2, facebook).
- Chaque règle attribue une classe de transfert (Best Effort, Assured Forwarding, Expedited Forwarding, Network Control) et une file d’attente COS.
- La recherche de règles AppQoS part de l’application la plus spécifique (application imbriquée) et remonte dans la hiérarchie. Les sessions (parent/enfant) sont classées à l’aide d’un chemin hiérarchique (exemple :
ip.tcp.ssl.http.http2.facebook).Dans l’exemple, la séquence de recherche est la suivante :
- Si l’application imbriquée (
facebook-chat) n’est pas configurée dans l’ensemble de règles, lahttp2règle est appliquée. - Si
http2n’est pas configuré, lahttprègle est appliquée. - Si
httpn’est pas configuré, lasslrègle est appliquée. - Si aucune règle AppQoS n’existe pour les applications classées, la
application-anyrègle est appliquée. - Si
application-anyelle n’est pas configurée, la session se poursuit avec la règle DSCP précédemment appliquée.
Cette classification garantit que les sessions HTTP/2 ne sont jamais ignorées et reçoivent toujours un traitement de QoS.
- Si l’application imbriquée (
Exemple : Un profil AppQoS contient des règles pour des applications spécifiques plus une règle fourre-tout « Any ». Par exemple, le profil comprend des ensembles de règles pour HTTP, Facebook, Yahoo et Any, et le premier flux est classé comme suit : http.http2.twitter
Cas A — Règle « n’importe quelle » configurée
- Il n’existe aucune règle explicite sur Twitter.
- Étant donné que la règle Any est présente, AppQoS sélectionne Any.
- Résultat : La règle Any est appliquée.
Cas B — Règle « any » non configurée
- Il n’existe aucune règle explicite sur Twitter.
- Aucune règle n’est disponible.
- Dans ce cas, le système revient à la meilleure correspondance suivante par ordre décroissant de spécificité :
- Règle http2 (si présente)
- Si aucune règle http2 n'→ revenir à http
- Si aucune règle HTTP n'→ utiliser la file d’attente par défaut
- Résultat : La règle de correspondance la plus proche est sélectionnée en fonction de l’ordre de repli ci-dessus.
- Session parente : Généralement classée à un niveau supérieur (exemple : http2).
- Session enfant : classée avec des applications imbriquées plus spécifiques (exemple : facebook, twitter).
La classification de la première session de flux est désormais prise en compte pour la correspondance des règles dans la session parente.
Transfert et journalisation- Une classe de transfert et une file d’attente sont attribuées au trafic de chaque session en fonction de la règle correspondante.
- Les entrées syslog reflètent la correspondance de la classification et de la règle pour la fermeture de session et de flux
Limites
- Pour HTTP/2, seule la classification des applications du premier flux est utilisée pour la correspondance des règles AppQoS dans la session parente.
- Lors de sessions de longue durée, les commutateurs d’application en cours de route (HTTP/1 ou HTTP/2) peuvent modifier la file d’attente CoS et réordonnancer les paquets. Le réassemblage TCP sur les terminaux gère ce problème à l’aide de numéros de séquence.
- HTTP/2 pour AppQoS n’est pas pris en charge dans les scénarios de haute disponibilité en cluster de châssis et à plusieurs nœuds.
- Les limiteurs de débit AppQoS ne fonctionnent pas correctement pour le trafic HTTPS dans les configurations de trafic HTTP/1.1 et HTTP/2 lorsque le proxy de transfert SSL est configuré.
Trafic chiffré HTTP2
Dans le cas d’un trafic chiffré, le module HTTP/2 est désactivé, de sorte qu’aucune session enfant HTTP/2 n’est créée. AppQoS est appliqué à la session parente uniquement.
Comportement AppQoS spécifique à la plate-forme
Utilisez AppQoS et l’explorateur de fonctionnalités pour confirmer la prise en charge de la plate-forme et de la version pour des fonctionnalités spécifiques.
Utilisez le tableau suivant pour examiner le comportement spécifique à votre plate-forme :
| Plate-forme |
Différence |
|---|---|
| SRX Series |
SRX5400, SRX5600 et SRX5800, utilisez l’instruction de configuration suivante pour définir les noms de classe de transfert et les affectations de files d’attente : [edit class-of-service] user@host# set forwarding-classes class forwarding-class-name queue-num queue-number |
| SRX Series | SRX300, SRX320, SRX340, SRX345, SRX380, SRX400, SRX440, SRX550M, SRX1500, SRX4100, SRX4200, SRX4600 et vSRX, utilisez l’instruction de configuration suivante pour définir les noms de classe de transfert et les affectations de files d’attente : [edit class-of-service] user@host# set forwarding-classes queue queue-number forwarding-class-name |
| SRX Series | SRX300, SRX320, SRX340, SRX345, SRX400, SRX440 Utilisez l’option loss-priority-highde la règle AppQoS pour remplacer l’action par défaut.[edit] user@host# set class-of-service application-traffic-control rule-sets rset-01 rule r1 then rate-limit loss-priority-high |
| SRX Series | Les modèles SRX5400, SRX5600 et SRX5800 prennent en charge jusqu’à 1 000 limiteurs de débit par appareil. Cependant, il n’autorise que 16 profils distincts, chacun défini par une combinaison unique de limite de bande passante et de paramètre de limite de taille de rafale. |
Tableau de l’historique des modifications
La prise en charge des fonctionnalités est déterminée par la plateforme et la version que vous utilisez. Utilisez l’explorateur de fonctionnalités pour déterminer si une fonctionnalité est prise en charge sur votre plateforme.