SUR CETTE PAGE
Exemple : Génération d’une alarme de sécurité en réponse au non-respect des règles
Vérification de l’utilisation de la mémoire sur les équipements SRX Series
Haute disponibilité (HA) Synchronisation du nom d’adresse Résolution du cache
Comportement d’utilisation de la mémoire spécifique à la plate-forme
Surveillance et dépannage des stratégies de sécurité
La surveillance fournit une présentation en temps réel de données significatives représentant l’état des activités d’accès sur un réseau. Ces informations vous permettent d’interpréter et d’affecter facilement les conditions opérationnelles. Le dépannage fournit des conseils contextuels pour résoudre les problèmes d’accès sur les réseaux. Vous pourrez alors répondre aux préoccupations des utilisateurs et fournir une résolution dans les meilleurs délais.
Comprendre les alarmes de sécurité
Des alarmes sont déclenchées lorsque des paquets sont abandonnés en raison d’une violation de stratégie. Une violation de stratégie se produit lorsqu’un paquet correspond à une politique de rejet ou de refus. Une alarme de violation de stratégie est générée lorsque le système surveille l’un des événements audités suivants :
Nombre de violations de stratégie par un identificateur de réseau source au cours d’une période spécifiée
Nombre de violations de stratégie par rapport à un identificateur de réseau de destination au cours d’une période donnée
Nombre de violations de la politique d’une application au cours d’une période spécifiée
Règle de stratégie ou groupe de violations de règles au cours d’une période spécifiée
Il existe quatre types d’alarmes correspondant à ces quatre événements. Les alarmes sont basées sur l’adresse IP source, l’adresse IP de destination, l’application et la stratégie.
Lorsqu’un paquet rencontre une stratégie de rejet ou de refus, les compteurs de violation de stratégie pour tous les types d’alarme activés augmentent. Lorsqu’un compteur atteint le seuil spécifié au cours d’une période spécifiée, une alarme est générée. Après une période spécifiée, le compteur de violation de la stratégie est réinitialisé et réutilisé pour démarrer un autre cycle de comptage.
Pour afficher les informations sur l’alarme, exécutez la show security alarms commande. Le nombre de violations et l’alarme ne persistent pas après les redémarrages du système. Après un redémarrage, le nombre de violations est remis à zéro et l’alarme est effacée de la file d’attente des alarmes.
Après avoir pris les mesures appropriées, vous pouvez effacer l’alarme. L’alarme reste dans la file d’attente jusqu’à ce que vous l’effaciez (ou jusqu’à ce que vous redémarriez l’appareil). Pour effacer l’alarme, exécutez la clear security alarms commande. Une fois que vous avez effacé l’alarme, une série ultérieure de violations de la stratégie de flux peut entraîner le déclenchement d’une nouvelle alarme.
Voir aussi
Exemple : Génération d’une alarme de sécurité en réponse au non-respect des règles
Cet exemple montre comment configurer l’appareil pour générer une alarme système lorsqu’une violation de stratégie se produit. Par défaut, aucune alarme n’est déclenchée en cas de non-respect de la stratégie.
Exigences
Aucune configuration spéciale au-delà de l’initialisation de l’appareil n’est requise avant de configurer cette fonctionnalité.
Aperçu
Dans cet exemple, vous configurez une alarme à déclencher dans les cas suivants :
La taille de l’application est de 10240 unités.
La violation de l’adresse IP source dépasse 1000 en 20 secondes.
Le nombre de violations de l’adresse IP de destination dépasse 1000 en 10 secondes.
La violation de la correspondance de stratégie dépasse 100, avec une taille de 100 unités.
Configuration
Procédure
Configuration rapide de la CLI
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, copiez et collez les commandes dans l’interface de ligne de commande au niveau de la [edit] hiérarchie , puis passez commit en mode de configuration.
set security alarms potential-violation policy application size 10240 set security alarms potential-violation policy source-ip threshold 1000 duration 20 set security alarms potential-violation policy destination-ip threshold 1000 duration 10 set security alarms potential-violation policy policy-match threshold 100 size 100
Procédure étape par étape
L’exemple suivant vous oblige à naviguer à différents niveaux dans la hiérarchie de configuration. Pour obtenir des instructions sur cette procédure, reportez-vous à la section Utilisation de l’éditeur CLI en mode configuration dans le Guide de l’utilisateur de l’interface de ligne de commande.
Pour configurer des alarmes de non-respect des politiques :
Activez les alarmes de sécurité.
[edit] user@host# edit security alarms
Spécifiez qu’une alarme doit être déclenchée en cas de violation d’une application.
[edit security alarms potential-violation policy] user@host# set application size 10240
Spécifiez qu’une alarme doit être déclenchée en cas de violation de l’adresse IP source.
[edit security alarms potential-violation policy] user@host# set source-ip threshold 1000 duration 20
Spécifiez qu’une alarme doit être déclenchée lorsqu’une violation de l’adresse IP de destination se produit.
[edit security alarms potential-violation policy] user@host# set destination-ip threshold 1000 duration 10
Spécifiez qu’une alarme doit être déclenchée lorsqu’une violation de correspondance de stratégie se produit.
[edit security alarms potential-violation policy] user@host# set policy-match threshold 100 size 100
Résultats
À partir du mode configuration, confirmez votre configuration en entrant la show security alarms commande. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de configuration de cet exemple pour la corriger.
policy {
source-ip {
threshold 1000;
duration 20;
}
destination-ip {
threshold 1000;
duration 10;
}
application {
size 10240;
}
policy-match {
threshold 100;
size 100;
}
}
Si vous avez terminé de configurer l’appareil, passez commit en mode de configuration.
Vérification
Pour confirmer que la configuration fonctionne correctement, à partir du mode opérationnel, entrez la show security alarms commande.
Stratégies de sécurité correspondantes
La show security match-policies commande vous permet de résoudre les problèmes de trafic à l’aide des critères de correspondance suivants : port source, port de destination, adresse IP source, adresse IP de destination et protocole. Par exemple, si votre trafic ne passe pas parce qu’une stratégie appropriée n’est pas configurée ou que les critères de correspondance sont incorrects, la show security match-policies commande vous permet de travailler hors connexion et d’identifier l’origine du problème. Il utilise le moteur de recherche pour identifier le problème et vous permet ainsi d’utiliser la politique de correspondance appropriée pour le trafic.
L’option result-count spécifie le nombre de stratégies à afficher. La première stratégie activée de la liste est la stratégie appliquée à tout le trafic correspondant. Les autres stratégies en dessous sont « masquées » par la première et ne sont jamais rencontrées par le trafic correspondant.
La show security match-policies commande s’applique uniquement aux stratégies de sécurité ; Les stratégies IDP ne sont pas prises en charge.
Exemple 1 : show security match-policies
user@host> show security match-policies from-zone z1 to-zone z2 source-ip 10.10.10.1 destination-ip 192.0.2.1 source-port 1 destination-port 21 protocol tcp
Policy: p1, action-type: permit, State: enabled, Index: 4
Sequence number: 1
From zone: z1, To zone: z2
Source addresses:
a2: 203.0.113.1/25
a3: 10.10.10.1/32
Destination addresses:
d2: 203.0.113.129/25
d3: 192.0.2.1/24
Application: junos-ftp
IP protocol: tcp, ALG: ftp, Inactivity timeout: 1800
Source port range: [0-0]
Destination port range: [21-21]
Exemple 2 : Utilisation de l’option result-count
Par défaut, la liste en sortie contient la stratégie qui sera appliquée au trafic avec les caractéristiques spécifiées. Pour répertorier plusieurs stratégies qui correspondent aux critères, utilisez l’option result-count . La première stratégie répertoriée est toujours la stratégie qui sera appliquée au trafic correspondant. Si la result-count valeur est comprise entre 2 et 16, la sortie inclut toutes les stratégies qui correspondent aux critères jusqu’au result-count. Toutes les stratégies répertoriées après la première sont « masquées » par la première et ne sont jamais appliquées au trafic correspondant.
Utilisez cette option pour tester le positionnement d’une nouvelle stratégie ou pour dépanner une stratégie qui n’est pas appliquée comme prévu pour un trafic particulier.
Dans l’exemple suivant, les critères de trafic correspondent à deux stratégies. La première stratégie répertoriée, p1, contient l’action appliquée au trafic. La stratégie p15 est masquée par la première stratégie et, par conséquent, son action ne sera pas appliquée au trafic correspondant.
user@host> show security match-policies from-zone zone-A to-zone zone-B source-ip 10.10.10.1 destination-ip 192.0.2.1 source-port 1004 destination-port 80 protocol tcp result-count 5
Policy: p1, action-type: permit, State: enabled, Index: 4
Sequence number: 1
From zone: zone-A, To zone: zone-B
Source addresses:
sa1: 10.10.0.0/16
Destination addresses:
da5: 192.0.2.0/24
Application: any
IP protocol: 1, ALG: 0, Inactivity timeout: 0
Source port range: [1000-1030]
Destination port range: [80-80]
Policy: p15, action-type: deny, State: enabled, Index: 18
Sequence number: 15
From zone: zone-A, To zone: zone-B
Source addresses:
sa11: 10.10.10.1/32
Destination addresses:
da15: 192.0.2.5/24
Application: any
IP protocol: 1, ALG: 0, Inactivity timeout: 0
Source port range: [1000-1030]
Destination port range: [80-80]
Voir aussi
Suivi du nombre d’accès à la stratégie
Utilisez la show security policies hit-count commande pour afficher le taux d’utilité des stratégies de sécurité en fonction du nombre d’accès qu’elles reçoivent. Vous pouvez utiliser cette fonctionnalité pour déterminer quelles stratégies sont utilisées sur l’appareil et à quelle fréquence elles sont utilisées. Selon les options de commande que vous choisissez, le nombre d’appels peut être répertorié sans ordre ou trié par ordre croissant ou décroissant, et il peut être limité au nombre d’appels qui tombent au-dessus ou en dessous d’un nombre spécifique ou dans une plage. Les données sont affichées pour toutes les zones associées aux stratégies ou aux zones nommées.
Vérification de l’utilisation de la mémoire sur les équipements SRX Series
Vous pouvez isoler les problèmes de mémoire en comparant les valeurs de mémoire avant et après la configuration des stratégies.
Certaines pratiques peuvent aider à surveiller l’utilisation actuelle de la mémoire sur l’appareil et à optimiser les paramètres pour mieux dimensionner la configuration du système, en particulier lors de la mise en œuvre des stratégies.
Pour vérifier l’utilisation de la mémoire :
Utilisez la commande pour vérifier l’utilisation globale de la
show chassis routing-enginemémoire du moteur de routage (RE). La sortie suivante de cette commande montre une utilisation de la mémoire de 39 % :user@host#
show chassis routing-engineRouting Engine status: Slot 0: Current state Master Election priority Master (default) DRAM 1024 MB Memory utilization 39 percent CPU utilization: User 0 percent Background 0 percent Kernel 2 percent Interrupt 0 percent Idle 97 percent Model RE-PPC-1200-A Start time 2011-07-09 19:19:49 PDT Uptime 37 days, 15 hours, 44 minutes, 13 seconds Last reboot reason 0x3:power cycle/failure watchdog Load averages: 1 minute 5 minute 15 minute 0.22 0.16 0.07Utilisez la
show system processes extensivecommande pour obtenir des informations sur les processus en cours d’exécution sur le moteur de routage.Utilisez l’option
find nsdde lashow system processes extensivecommande pour afficher l’utilisation directe sur le démon de sécurité réseau (NSD) avec une mémoire totale de 10 mégaoctets et une utilisation du processeur de 0 %.user@host# show system processes extensive | find nsd 1182 root 1 96 0 10976K 5676K select 2:08 0.00% nsd 1191 root 4 4 0 8724K 3764K select 1:57 0.00% slbd 1169 root 1 96 0 8096K 3520K select 1:51 0.00% jsrpd 1200 root 1 4 0 0K 16K peer_s 1:10 0.00% peer proxy 1144 root 1 96 0 9616K 3528K select 1:08 0.00% lacpd 1138 root 1 96 0 6488K 2932K select 1:02 0.00% ppmd 1130 root 1 96 0 7204K 2208K select 1:02 0.00% craftd 1163 root 1 96 0 16928K 5188K select 0:58 0.00% cosd 1196 root 1 4 0 0K 16K peer_s 0:54 0.00% peer proxy 47 root 1 -16 0 0K 16K sdflus 0:54 0.00% softdepflush 1151 root 1 96 0 15516K 9580K select 0:53 0.00% appidd 900 root 1 96 0 5984K 2876K select 0:41 0.00% eventd
Vérifiez la taille du fichier de configuration. Enregistrez votre fichier de configuration avec un nom unique avant de quitter l’interface de ligne de commande. Ensuite, entrez la
ls -1 filenamecommande à partir de l’invite de l’interpréteur de commandes dans l’interpréteur de commandes de niveau UNIX pour vérifier la taille du fichier, comme indiqué dans l’exemple de sortie suivant :user@host> start shell % ls -l config -rw-r--r-- 1 remote staff 12681 Feb 15 00:43 config
Voir aussi
Surveiller les statistiques des stratégies de sécurité
But
Surveillez et enregistrez le trafic que Junos OS autorise ou refuse en fonction des stratégies configurées précédemment.
Action
Pour surveiller le trafic, activez les options de comptage et de journalisation.
Compter—Configurable dans une politique individuelle. Si l’option count est activée, des statistiques sont collectées pour les sessions qui entrent dans l’équipement pour une stratégie donnée, ainsi que pour le nombre de paquets et d’octets qui transitent par l’équipement dans les deux sens pour une stratégie donnée. Pour les comptages (uniquement pour les paquets et les octets), vous pouvez spécifier que des alarmes soient générées chaque fois que le trafic dépasse les seuils spécifiés. Voir count (Stratégies de sécurité).
Journal—La fonctionnalité de journalisation peut être activée avec des stratégies de sécurité pendant l’étape d’initialisation de session (session-init) ou de fermeture de session (session close). Reportez-vous à la section journal (Stratégies de sécurité).
Pour afficher les journaux des connexions refusées, activez l’ouverture de session sur session-init.
Pour consigner les sessions après leur fin ou leur interruption, activez l’option Connexion à la fermeture de session.
Le journal de session est activé en temps réel dans le code de flux, ce qui a un impact sur les performances de l’utilisateur. Si la fermeture de session et l’initialisation de session sont activées, les performances sont encore dégradées par rapport à l’activation de l’initialisation de session uniquement.
Pour plus d’informations sur les informations collectées pour les journaux de session, reportez-vous à la section Informations fournies dans les entrées du journal de session pour les passerelles de services SRX Series.
Vérification des stratégies fantômes
- Vérification de toutes les stratégies fantômes
- Vérification de l’observation d’une stratégie d’une ou de plusieurs stratégies
- Vérification de l’ignorance d’une stratégie par une ou plusieurs stratégies
Vérification de toutes les stratégies fantômes
But
Vérifiez toutes les stratégies qui masquent une ou plusieurs stratégies.
Action
À partir du mode de fonctionnement, entrez les commandes suivantes :
Pour les systèmes logiques, entrez la
show security shadow-policies logical-system lsys-name from-zone from-zone-name to-zone to-zone-namecommande.Pour les stratégies globales, entrez la
show security shadow-policies logical-system lsys-name globalcommande.
root@host> show security shadow-policies from-zone zone-a to-zone zone-b
Policies Shadowed policies
P1 P3
P1 P4
P2 P5
Signification
La sortie affiche la liste de toutes les stratégies qui suivent d’autres stratégies. Dans cet exemple, la stratégie P1 surveille les stratégies P3 et P4 et la stratégie P2 suit la stratégie P5.
Vérification de l’observation d’une stratégie d’une ou de plusieurs stratégies
But
Vérifiez si une stratégie donnée masque une ou plusieurs stratégies placées après elle.
Action
À partir du mode de fonctionnement, entrez les commandes suivantes :
Pour les systèmes logiques, entrez la
show security shadow-policies logical-system lsys-name from-zone from-zone-name to-zone to-zone-name policy policy-namecommande.Pour les stratégies globales, entrez la
show security shadow-policies logical-system lsys-name global policy policy-namecommande.
root@host> show security shadow-policies from-zone zone-a to-zone zone-b policy P1
Policies Shadowed policies
P1 P3
P1 P4
Signification
La sortie affiche toutes les stratégies qui sont masquées par la stratégie donnée. Dans cet exemple, la stratégie P1 surveille les stratégies P3 et P4.
Vérification de l’ignorance d’une stratégie par une ou plusieurs stratégies
But
Vérifiez si une stratégie donnée est masquée par une ou plusieurs stratégies placées avant elle.
Action
À partir du mode de fonctionnement, entrez les commandes suivantes :
Pour les systèmes logiques, entrez la
show security shadow-policies logical-system lsys-name from-zone from-zone-name to-zone to-zone-name policy policy-name reversecommande.Pour les stratégies globales, entrez la
show security shadow-policies logical-system lsys-name global policy policy-name reversecommande.
root@host> show security shadow-policies from-zone zone-a to-zone zone-b policy P4 reverse
Policies Shadowed policies
P1 P4
Signification
La sortie affiche la stratégie donnée, masquée par une ou plusieurs stratégies. Dans cet exemple, la stratégie P4 est masquée par la stratégie P1.
Dépannage des stratégies de sécurité
- Synchronisation des stratégies entre le moteur de routage et le moteur de transfert de paquets
- Vérification de l’échec de validation d’une stratégie de sécurité
- Vérification d’une validation de stratégie de sécurité
- Recherche de stratégie de débogage
Synchronisation des stratégies entre le moteur de routage et le moteur de transfert de paquets
Problème
Description
Les stratégies de sécurité sont stockées dans le moteur de routage et le moteur de transfert de paquets. Les stratégies de sécurité sont transférées du moteur de routage au moteur de transfert de paquets lorsque vous validez les configurations. Si les stratégies de sécurité du moteur de routage ne sont pas synchronisées avec le moteur de transfert de paquets, la validation d’une configuration échoue. Des fichiers de core dump peuvent être générés si la validation est tentée à plusieurs reprises. La désynchronisation peut être due à :
Un message de stratégie envoyé par le moteur de routage au moteur de transfert de paquets est perdu en transit.
Une erreur avec le moteur de routage, telle qu’un UID de stratégie réutilisé.
Environnement
Les stratégies du moteur de routage et du moteur de transfert de paquets doivent être synchronisées pour que la configuration soit validée. Toutefois, dans certaines circonstances, les stratégies du moteur de routage et du moteur de transfert de paquets peuvent ne pas être synchronisées, ce qui entraîne l’échec de la validation.
Symptômes
Lorsque les configurations des stratégies sont modifiées et qu’elles ne sont pas synchronisées, le message d’erreur suivant s’affiche : error: Warning: policy might be out of sync between RE and PFE <SPU-name(s)> Please request security policies check/resync.
Solution
Utilisez la show security policies checksum commande pour afficher la valeur de la somme de contrôle de la stratégie de sécurité et utilisez la request security policies resync commande pour synchroniser la configuration des stratégies de sécurité dans le moteur de routage et le moteur de transfert de paquets, si les stratégies de sécurité ne sont pas synchronisées.
Voir aussi
Vérification de l’échec de validation d’une stratégie de sécurité
Problème
Description
La plupart des échecs de configuration de stratégie se produisent au cours d’un commit ou d’un runtime.
Les échecs de validation sont signalés directement sur la CLI lorsque vous exécutez la commande CLI commit-check en mode configuration. Ces erreurs sont des erreurs de configuration, et vous ne pouvez pas valider la configuration sans corriger ces erreurs.
Solution
Pour corriger ces erreurs, procédez comme suit :
Passez en revue vos données de configuration.
Ouvrez le fichier /var/log/nsd_chk_only. Ce fichier est écrasé chaque fois que vous effectuez une vérification de validation et contient des informations détaillées sur les échecs.
Vérification d’une validation de stratégie de sécurité
Problème
Description
Lors de l’exécution d’une validation de configuration de stratégie, si vous remarquez que le comportement du système est incorrect, procédez comme suit pour résoudre ce problème :
Solution
Commandes d’affichage opérationnelles : exécutez les commandes opérationnelles pour les stratégies de sécurité et vérifiez que les informations affichées dans la sortie correspondent à ce que vous attendiez. Si ce n’est pas le cas, la configuration doit être modifiée en conséquence.
Traceoptions : définissez la commande dans la configuration de
traceoptionsvotre stratégie. Les indicateurs de cette hiérarchie peuvent être sélectionnés en fonction de l’analyse utilisateur de la sortie de lashowcommande. Si vous ne parvenez pas à déterminer l’indicateur à utiliser, l’optionalld’indicateur peut être utilisée pour capturer tous les journaux de suivi.user@host#
set security policies traceoptions <flag all>
Vous pouvez également configurer un nom de fichier facultatif pour capturer les journaux.
user@host# set security policies traceoptions <filename>
Si vous avez spécifié un nom de fichier dans les options de traçage, vous pouvez rechercher le fichier journal dans le fichier journal /var/log/<filename> pour vérifier si des erreurs ont été signalées dans le fichier. (Si vous n’avez pas spécifié de nom de fichier, le nom de fichier par défaut est événement.) Les messages d’erreur indiquent le lieu de la défaillance et la raison appropriée.
Après avoir configuré les options de traçage, vous devez valider à nouveau la modification de configuration à l’origine du comportement incorrect du système.
Recherche de stratégie de débogage
Problème
Description
Lorsque vous disposez de la configuration correcte, mais qu’une partie du trafic a été incorrectement abandonnée ou autorisée, vous pouvez activer l’indicateur lookup dans les traceoptions des stratégies de sécurité. L’indicateur lookup consigne les traces associées à la recherche dans le fichier de trace.
Solution
user@host# set security policies traceoptions <flag lookup>
Haute disponibilité (HA) Synchronisation du nom d’adresse Résolution du cache
Le processus de sécurité réseau (NSD) redémarre lorsque le système redémarre, que le basculement HA se produit ou que le processus se bloque. Pendant ce temps, si un grand nombre d’adresses de nom de domaine sont configurées dans les stratégies de sécurité, les pare-feu SRX Series tentent d’envoyer des requêtes au serveur DNS pour obtenir toutes les adresses IP résolues. Une grande quantité de ressources système est consommée lorsqu’un grand nombre de requêtes et de réponses DNS sont échangées. Par conséquent, les pare-feu SRX Series ne peuvent pas obtenir de réponse du serveur DNS et l’adresse d’un nom d’hôte dans une entrée du carnet d’adresses peut ne pas se résoudre correctement. Cela peut entraîner une perte de trafic, car aucune correspondance de politique de sécurité ou de session n’est trouvée. La nouvelle amélioration des pare-feu SRX Series résout ce problème en mettant en cache les résultats de la requête DNS dans un fichier de cache DNS local et en synchronisant régulièrement le fichier de cache DNS du nœud principal HA vers le nœud de sauvegarde HA. Les fichiers de cache DNS stockent les adresses IP, le nom de domaine et les valeurs TTL. Après le basculement HA, le nœud de sauvegarde précédent devient le nœud principal. Étant donné que tous les résultats du cache DNS sont disponibles sur le nouveau nœud principal, le traitement des stratégies de sécurité se poursuit et le trafic relais est autorisé conformément aux règles de stratégie.
À partir de Junos OS version 19.3R1, la mémoire cache DNS de stratégie est synchronisée dans un fichier de cache DNS local sur le nœud actif HA et copiée sur le nœud de sauvegarde HA pour supprimer les requêtes ou les réponses DNS lors du redémarrage de NSD.
Pour que la synchronisation ait lieu, les étapes suivantes sont effectuées :
Toutes les 30 secondes, la mémoire cache DNS de la stratégie est synchronisée avec un fichier de cache DNS de stratégie local situé dans le chemin d’accès /var/db/policy_dns_cache si le contenu de la mémoire cache DNS de la stratégie a été modifié pendant cette période.
Le fichier de cache DNS local est synchronisé du nœud principal HA au nœud de sauvegarde HA immédiatement après la mise à jour du fichier de cache DNS local à l’étape 1.
La synchronisation comprend le contenu suivant :
-
Nom de domaine
-
Liste d’adresses IPv4 et sa durée de vie (TTL)
-
Liste d’adresses IPv6 et son TTL
Lorsque NSD redémarre, il lit et analyse le fichier de cache DNS local et importe toutes les entrées de cache en mémoire. La synchronisation garantit que les requêtes DNS sont supprimées lors d’un redémarrage NSD. NSD redémarre sur le nouveau nœud principal lors du basculement HA, car les adresses IP résolues pour les noms de domaine existent déjà dans la mémoire cache DNS lors de la lecture des configurations des stratégies. Par conséquent, le nouveau trafic relais est autorisé conformément à la stratégie de sécurité après le basculement HA, car toutes les adresses IP résolues pour les noms de domaine existent dans les stratégies du moteur de routage et du moteur de transfert de paquets du nouveau nœud principal.
Comportement d’utilisation de la mémoire spécifique à la plate-forme
Utilisez l’explorateur de fonctionnalités pour confirmer la prise en charge de fonctionnalités spécifiques par la plate-forme et la version.
Utilisez le tableau suivant pour examiner le comportement spécifique à votre plate-forme :
| Plateforme |
Différence |
|---|---|
| SRX Series |
|