Comment faire pour résoudre les problèmes de valeurs de traitement CTD en hausse ou en cours d’exécution élevées dans > performances POW du plan de données de débogage

> debug dataplane pow performance
func                                  max-μs   avg-μs        count     total-μs  ac-max-μs  ac-avg-μs         ac-count      ac-total-μs
sml_vm                                     0      276491782.0  0            0         65        1.1           312208           369019
ctd_token                                  0      36.0           27197221  0        180       20.8            18000           374440
detector_run_p1                            0      0.0            0            0         66        4.9             8509            42053
detector_run_p2                            0      0.0            0            0         27        1.5             8786            13669
regex_lookup                               0      0.0            0            0       1093        7.0            11494            81464

• Pan-OS
• CTD (Détection de contenu et de menaces)

• Un certain nouveau flux de trafic a été introduit qui est important ou lourd sur le moteur d'inspection du pare-feu tel que: unknown-udp, unknown-tcp, ms-ds-smb, mssql-db, etc.
• Une quantité ou un débit anormalement élevé d’un type de trafic plus lourd traverse le pare-feu, tel que: unknown-udp, unknown-tcp, ms-ds-smb, mssql-db, etc.
• La totalité ou une grande partie du trafic passe par une règle d'autorisation de politique de sécurité avec un ou plusieurs profils de sécurité « stricts » attachés (en particulier lorsque la quantité de trafic approche les performances et la capacité maximales de ce modèle - dans ce cas, sml_vm, ctd_token, detector_run_p1 et detector_run_p2 sont élevés).
• La totalité ou la plupart du trafic passe par une seule règle de profil de sécurité large sur laquelle de nombreux profils de sécurité lourds ou stricts sont configurés, en particulier si de grandes quantités de trafic non classifié (unknown-udp, unknown-tcp) ou un trafic à débit de données élevé (ms-ds-smb, mssql-db, etc.) passent par le pare-feu
• Une signature/un objet de filtrage d’URL personnalisé, d’application personnalisée ou de menace personnalisée inefficace a été configuré, qui utilise trop de caractères génériques, n’utilise rien d’autre qu’un seul caractère générique, est trop large, etc. (Cette mauvaise configuration entraînera souvent une augmentation spécifique de la fonction regex_lookup ). Pour résoudre ce problème, supprimez tous les caractères génériques ou modèles inefficaces ayant un impact sur les performances dans les objets de filtrage d’URL, les applications personnalisées ou les signatures personnalisées - voir Caractères génériques imbriqués(*) dans URL peuvent affecter gravement les performances pour plus de détails

1. Prenez une base de référence de ces valeurs avant que le problème ne se produise (ou vérifiez les valeurs historiques).Si les valeurs actuelles pour sml_vm, ctd_token, detector_run_p1 et detector_run_p2 sont beaucoup plus élevées que les valeurs précédentes, elles peuvent être à l’origine du problème de CPU ou de trafic élevé. Si les valeurs actuelles sont à peu près les mêmes que les anciennes valeurs lorsque le problème ne se produisait pas, elles peuvent ne pas être le coupable ou la cause première du problème. Si la ou les valeurs sont anormalement supérieures aux valeurs de référence avant que le problème ne commence, passez à l’étape 2 ci-dessous.
2. Identifier quel nouveau flux de trafic (par IP source, Port source, IP de destination, Port de destination, Application) a été introduit qui a commencé à entraîner l’augmentation de ces valeurs
   1. Accédez à l’onglet Activité réseau > ACC > afficher les graphiques Activité IP source, Activité IP de destination et Utilisation des applications
   2. Examinez et évaluez tous les flux de trafic dans les graphiques ci-dessus qui se distinguent comme des valeurs aberrantes occupant une grande quantité de: octets, sessions, taux de paquets, etc. (en particulier les nouveaux flux de trafic qui ne sont apparus que depuis que le problème a commencé à se produire). Recherchez un flux de trafic ou une application spécifique qui apparaît dans les graphiques uniquement lorsque le problème se produit et qui n’apparaît pas lorsque le problème ne se produit pas
   3. Exécutez la commande CLI : > afficher les statistiques d’application en cours d’exécution pour vérifier si des applications ont une valeur anormalement élevée pour une colonne (en particulier pour les applications à débit de données plus lourdes telles que : navigation Web, unknown-udp, unknown-tcp, dns, ms-ds-smb, ms-ds-smbv2, ms-ds-smbv3 et mssql-db, ou toute application personnalisée)
   4. Si des flux de trafic ou des applications se distinguent comme des contrevenants possibles dans les étapes ci-dessus, c’est-à-dire lorsque leurs valeurs sont plus élevées qu’à des heures normales, de travail et sans problème lorsqu’il n’y a pas de problème de trafic / CPU élevé), arrêtez temporairement ce flux de trafic à travers le pare-feu et voyez si les valeurs liées au CTD dans > performances POW du plan de données de débogage (sml_vm, ctd_token, detector_run_p1 ou detector_run_p2) redescendent à des niveaux normaux et si le problème de circulation a maintenant disparu
3. Réduisez les inspections effectuées sur ce flux de trafic spécifique en :
   1. Créer une application personnalisée pour ce trafic (afin qu’il ne soit pas classé comme inconnu-udp ou unknown-tcp)
   2. Envoyez ce trafic à la place via une règle de stratégie de sécurité qui n’a aucun profil de sécurité attaché (ou utilisez un profil moins strict avec moins de signatures activées)
   3. Activer DSRI sur la règle de stratégie de sécurité que prend ce trafic
   4. Créer un remplacement d’application pour ce trafic (à utiliser uniquement si le trafic est approuvé par votre organisation)