Dépannage de la configuration de Policer
Nombre incomplet d’abandons de paquets
Problème
Description
Dans certaines circonstances, Junos OS peut afficher un nombre trompeur de paquets abandonnés par un mécanisme de contrôle d’entrée.
Si des paquets sont abandonnés en raison du contrôle d’admission entrant, les statistiques du mécanisme de contrôle peuvent ne pas afficher le nombre d’abandons de paquets attendus en calculant la différence entre le nombre de paquets entrants et sortants. Cela peut se produire si vous appliquez un mécanisme de contrôle d’entrée à plusieurs interfaces et que le taux d’entrée agrégé de ces interfaces dépasse le débit de ligne d’une interface de sortie commune. Dans ce cas, les paquets peuvent être supprimés de la mémoire tampon d’entrée. Ces abandons ne sont pas inclus dans le nombre de paquets abandonnés par le contrôleur, ce qui fait que les statistiques du contrôleur sous-estiment le nombre total d’abandons.
Solution
Il s’agit d’un comportement attendu.
Réinitialisation du compteur lors de l’édition du filtre
Problème
Description
Si vous modifiez un terme de filtre de pare-feu, la valeur de tout compteur associé à n’importe quel terme dans le même filtre est définie sur 0, y compris le compteur implicite de tout mécanisme de contrôle référencé par le filtre. Prenons les exemples suivants :
Supposons que votre filtre a
term1
,term2
etterm3
, et que chaque terme a un compteur qui a déjà compté les paquets correspondants. Si vous modifiez l’un des termes de quelque manière que ce soit, les compteurs de tous les termes sont réinitialisés à 0.Supposons que votre filtre a
term1
etterm2
. Supposons également que a unpolicer
modificateur d’action et queterm2
le compteur implicite du mécanisme de contrôle a déjà compté 1000 paquets correspondants. Si vous modifiezterm1
outerm2
de quelque manière que ce soit, le compteur du mécanisme de contrôle référencé parterm2
est remis à 0.
Solution
Il s’agit d’un comportement attendu.
Statistiques non valides pour Policer
Problème
Description
Si vous appliquez un mécanisme de contrôle bicolore à taux unique dans plus de 128 termes dans un filtre de pare-feu, la sortie de la show firewall
commande affiche des données incorrectes pour le mécanisme de contrôle.
Solution
Il s’agit d’un comportement attendu.
Les mécanismes de contrôle de sortie sur les appareils QFX3500 peuvent autoriser un débit supérieur à celui configuré
Problème
Description
Si vous configurez un mécanisme de contrôle pour limiter le débit et que vous l’appliquez à la sortie vers plusieurs interfaces d’un commutateur ou d’un nœud QFX3500, le débit contrôlé agrégé mesuré peut être deux fois supérieur au débit configuré, selon les interfaces auxquelles vous appliquez le mécanisme de contrôle. Le doublement du taux de contrôle se produit si vous appliquez un mécanisme de contrôle à plusieurs interfaces et que les deux conditions suivantes sont remplies :
Il existe au moins une interface contrôlée dans la plage xe-0/0/0 à xe-0/0/23 ou la plage xe-0/1/1 à xe-0/1/7.
Il existe au moins une interface contrôlée dans la plage xe-0/0/24 à xe-0/0/47 ou la plage xe-0/1/8 à xe-0/1/15.
Par exemple, si vous configurez un mécanisme de contrôle pour limiter le débit du trafic à 1 Gbit/s et que vous l’appliquez (à l’aide d’un filtre de pare-feu) à xe-0/0/0 et xe-0/0/24 dans le sens de sortie, le débit de chaque interface est limité à 1 Gbit/s, pour un débit total autorisé de 2 Gbit/s. Le même comportement se produit si vous appliquez le mécanisme de contrôle à xe-0/1/1 et xe-0/0/24 : le débit de chaque interface est limité à 1 Gbit/s.
Si vous appliquez le même mécanisme de contrôle à la sortie à plusieurs interfaces de ces groupes, le débit de chaque groupe est limité à 1 Gbit/s. Par exemple, si vous appliquez le mécanisme de contrôle à xe-0/0/0 à xe-0/0/4 (cinq interfaces) et à xe-0/0/24 à xe-0/0/33 (dix interfaces), le débit de chaque groupe est limité à 1 Gbit/s, pour un débit total autorisé de 2 Gbit/s.
Voici un autre exemple : Si vous appliquez le mécanisme de contrôle à xe-0/0/0 à xe-0/0/4 et xe-0/1/1 à xe-0/1/5 (soit un total de dix interfaces), le débit de ce groupe est limité à 1 Gbit/s au total. Si vous appliquez également le mécanisme de contrôle à xe-0/0/24, cette interface est limitée à 1 Gbit/s, tandis que les dix autres sont toujours limitées à 1 Gbit/s au total.
Les interfaces xe-0/1/1 à xe-0/1/15 sont physiquement situées sur les ports de liaison montante QSFP+, selon le schéma suivant :
xe-0/1/1 à xe-0/1/3 sont sur Q0.
xe-0/1/4 à xe-0/1/7 sont sur Q1.
xe-0/1/8 à xe-0/1/11 sont en Q2.
xe-0/1/2 à xe-0/1/15 sont au T3.
Le doublement de la fréquence contrôlée ne se produit que si le mécanisme de contrôle est appliqué dans le sens de sortie. Si vous configurez un mécanisme de contrôle comme décrit ci-dessus, mais que vous l’appliquez dans le sens d’entrée, le débit total autorisé pour toutes les interfaces est de 1 Gbit/s.
Solution
Il s’agit d’un comportement attendu.
Les mécanismes de contrôle de sortie spécifiques aux filtres sur QFX3500 appareils peuvent autoriser un débit plus élevé que ce qui est configuré
Problème
Description
Vous pouvez configurer les mécanismes de contrôle pour qu’ils soient spécifiques aux filtres. Cela signifie que Junos OS ne crée qu’une seule instance de contrôleur, quel que soit le nombre de fois que le mécanisme de contrôle est référencé. Dans ce cas, la limitation de débit est appliquée de manière agrégée. Par conséquent, si vous configurez un mécanisme de contrôle pour qu’il ignore le trafic qui dépasse 1 Gbit/s et que vous le référencez en trois termes différents, la bande passante totale autorisée par le filtre est de 1 Gbit/s. Toutefois, le comportement d’un mécanisme de contrôle spécifique au filtre est affecté par la façon dont les termes de filtre de pare-feu qui font référence au mécanisme de contrôle sont stockés dans la mémoire ternaire de contenu adressable (TCAM). Si vous créez un mécanisme de contrôle spécifique à un filtre et que vous le référencez dans plusieurs termes de filtre de pare-feu, le mécanisme de contrôle autorise plus de trafic que prévu si les termes sont stockés dans des tranches TCAM différentes. Par exemple, si vous configurez un mécanisme de contrôle pour qu’il ignore le trafic qui dépasse 1 Gbit/s et que vous lui faites référence en trois termes différents stockés dans trois tranches de mémoire distinctes, la bande passante totale autorisée par le filtre est de 3 Gbits/s et non de 1 Gbit/s.
Solution
Pour éviter ce comportement inattendu, utilisez les informations sur les tranches TCAM présentées dans Planification du nombre de filtres de pare-feu à créer pour organiser votre fichier de configuration de manière à ce que tous les termes de filtre de pare-feu qui font référence à un mécanisme de contrôle spécifique à un filtre donné soient stockés dans la même tranche TCAM.
Les mécanismes de contrôle peuvent limiter les filtres de sortie
Problème
Description
Sur certains commutateurs, le nombre de mécanismes de contrôle de sortie que vous configurez peut affecter le nombre total de filtres de pare-feu de sortie autorisés. Chaque agent de contrôle dispose de deux marqueurs implicites qui occupent deux entrées dans un TCAM à 1024 entrées. Ceux-ci sont utilisés pour les compteurs, y compris les compteurs qui sont configurés en tant que modificateurs d’action dans les termes de filtre de pare-feu. (Les mécanismes de contrôle utilisent deux entrées, car l’une est utilisée pour les paquets verts et l’autre pour les paquets non verts, quel que soit le type de mécanisme de contrôle.) Si le TCAM est saturé, vous ne pouvez plus valider les filtres de pare-feu de sortie qui ont des conditions avec des compteurs. Par exemple, si vous configurez et validez 512 mécanismes de contrôle de sortie (bicolores, tricolores ou une combinaison des deux types de mécanismes de contrôle), toutes les entrées de mémoire des compteurs sont utilisées. Si, plus loin dans votre fichier de configuration, vous insérez des filtres de pare-feu de sortie supplémentaires avec des termes qui incluent également des compteurs, aucun des termes de ces filtres n’est validé, car il n’y a pas d’espace mémoire disponible pour les compteurs.
Voici d’autres exemples :
Supposons que vous configuriez des filtres de sortie qui incluent un total de 512 mécanismes de contrôle et aucun compteur. Plus loin dans votre fichier de configuration, vous incluez un autre filtre de sortie avec 10 termes, dont 1 a un modificateur de contre-action. Aucun des termes de ce filtre n’est validé, car il n’y a pas assez d’espace TCAM pour le compteur.
Supposons que vous configuriez des filtres de sortie qui incluent un total de 500 mécanismes de contrôle, de sorte que 1000 entrées TCAM sont occupées. Plus loin dans votre fichier de configuration, vous incluez les deux filtres de sortie suivants :
Filtre A avec 20 termes et 20 compteurs. Tous les termes de ce filtre sont validés, car il y a suffisamment d’espace TCAM pour tous les compteurs.
Le filtre B vient après le filtre A et possède cinq termes et cinq compteurs. Aucun des termes de ce filtre n’est validé car il n’y a pas assez d’espace mémoire pour tous les compteurs. (Cinq entrées TCAM sont requises, mais seulement quatre sont disponibles.)
Solution
Vous pouvez éviter ce problème en veillant à ce que les termes de filtre de pare-feu de sortie avec contre-actions soient placés plus tôt dans votre fichier de configuration que les termes qui incluent des mécanismes de contrôle. Dans ce cas, Junos OS valide les mécanismes de contrôle même s’il n’y a pas assez d’espace TCAM pour les compteurs implicites. Par exemple, supposons ce qui suit :
Vous disposez de 1024 termes de filtre de pare-feu de sortie avec des contre-actions.
Plus loin dans votre fichier de configuration, vous avez un filtre de sortie avec 10 termes. Aucun des termes n’a de compteur, mais l’un d’entre eux a un modificateur d’action de contrôleur.
Vous pouvez valider le filtre avec 10 termes même s’il n’y a pas assez d’espace TCAM pour les compteurs implicites du contrôleur. Le policier s’engage sans les compteurs.