Les limites de connexion s’appliquent à l’ensemble de la grappe. Chaque nœud dispose d’une estimation des valeurs de compteur à l’échelle de la grappe en fonction des messages de diffusion. Pour des raisons d’efficacité, la limite de connexion configurée dans la grappe pourrait ne pas être appliquée exactement au nombre limite. Chaque nœud peut surévaluer ou sous-évaluer la valeur du compteur à l’échelle de la grappe à tout moment. Cependant, les informations seront mises à jour au fil du temps dans une grappe à charge équilibrée.

• Si le canal de données et les flux du canal de contrôle FTP appartiennent à différents membres de la grappe, le propriétaire du canal de données enverra périodiquement des mises à jour du délai d’inactivité au propriétaire du canal de contrôle et mettra à jour la valeur du délai d’inactivité. Cependant, si le propriétaire du flux de contrôle est rechargé et que le flux de contrôle est réhébergé, la relation de flux parent/enfant ne sera plus maintenue; le délai d’inactivité du flux de contrôle ne sera pas mis à jour.

La NAT peut affecter le débit global de la grappe. Les paquets NAT entrants et sortants peuvent être envoyés à différents défense contre les menacesdans la grappe, car l’algorithme d’équilibrage de charge repose sur les adresses IP et les ports, et la NAT fait en sorte que les paquets entrants et sortants aient des adresses IP ou des ports différents. Lorsqu’un paquet arrive à défense contre les menaces qui n’est pas le propriétaire NAT, il est transféré sur la liaison de commande de grappe vers le propriétaire, ce qui entraîne un trafic important sur la liaison de commande de grappe. Notez que le nœud de réception ne crée pas de flux de transfert vers le propriétaire, car le propriétaire de la NAT peut ne pas créer de connexion pour le paquet en fonction des résultats des vérifications de sécurité et des politiques.

Si vous souhaitez toujours utiliser la NAT en grappe, tenez compte des directives suivantes :

• No Proxy ARP (Pas de serveur mandataire ARP) : Pour les interfaces individuelles, une réponse de serveur mandataire ARP n’est jamais envoyée pour les adresses mappées. Cela empêche le routeur adjacent de maintenir une relation d’homologue avec un ASA qui ne fait plus partie de la grappe. Le routeur en amont a besoin d’une route statique ou d’un PBR avec suivi d’objets pour les adresses mappées qui pointe vers l’adresse IP de la grappe principale.

• No interface PAT on an Individual interface (Pas de PAT d'interface sur une interface individuelle) Le PAT d'interface n'est pas pris en charge pour les interfaces individuelles.

• PAT avec attribution de bloc de ports : Consultez les consignes suivantes pour cette fonctionnalité :

  • La limite maximale par hôte n’est pas une limite à l’échelle de la grappe et s’applique à chaque nœud individuellement. Ainsi, dans une grappe à 3 nœuds avec la limite maximale par hôte configurée à 1, si le trafic d’un hôte est équilibré en charge sur les 3 nœuds, 3 blocs avec 1 dans chaque nœud peuvent lui être alloués.

  • Les blocs de ports créés sur le nœud de sauvegarde à partir des pools de sauvegarde ne sont pas pris en compte lors de l’application de la limite maximale par hôte.

  • Les modifications des règles PAT à la volée, où l'ensemble PAT est modifié avec une toute nouvelle plage d’adresses IP, entraînera des échecs de création de sauvegarde xlate pour les demandes de sauvegarde xlate qui étaient encore en transit lorsque le nouveau ensemble est entré en vigueur. Ce comportement n’est pas spécifique à la fonctionnalité d’attribution de bloc de ports et il s’agit d’un problème transitoire d'ensemble PAT que l’on observe uniquement dans les déploiements en grappe où l'ensemble est distribué et le trafic est équilibré en charge sur les nœuds de la grappe.

  • Lorsque vous utilisez une grappe, vous ne pouvez pas simplement modifier la taille de l’allocation de bloc. La nouvelle taille n’est en vigueur qu’après le rechargement de chaque périphérique de la grappe. Pour éviter d’avoir à téléverser chaque périphérique, nous vous recommandons de supprimer toutes les règles d’attribution de blocage et d’effacer tous les xlates associés à ces règles. Vous pouvez ensuite modifier la taille du bloc et recréer les règles d’attribution des blocs.

• Distribution des adresses de l'ensemble NAT pour la PAT dynamique : lorsque vous configurez un ensemble PAT, le cluster divise chaque adresse IP de l'ensemble en blocs de ports. Par défaut, chaque bloc comporte 512 ports, mais si vous configurez des règles d’attribution de bloc de ports, votre paramètre de blocage est utilisé à la place. Ces blocs sont répartis uniformément entre les nœuds de la grappe, de sorte que chaque nœud ait un ou plusieurs blocs pour chaque adresse IP dans l'ensemble PAT. Ainsi, vous pourriez avoir aussi peu qu’une adresse IP dans un ensemble PAT pour une grappe, si cela est suffisant pour le nombre de connexions PAT que vous attendez. Les blocs de ports couvrent la plage de ports 1 024 à 65535, sauf si vous configurez l’option pour inclure les ports réservés, 1 à 1023, dans la règle NAT de l'ensemble PAT.

• Reusing a PAT pool in multiple Rules (réutiliser un pool PAT dans plusieurs règles) : Pour utiliser le même pool PAT dans plusieurs règles, vous devez faire attention à la sélection d'interface dans les règles. Vous devez soit utiliser des interfaces spécifiques dans toutes les règles, soit utiliser « any » dans toutes les règles. Vous ne pouvez pas combiner des interfaces spécifiques et « any » dans les règles, sans quoi le système pourrait ne pas être en mesure de faire correspondre le trafic de retour vers le bon nœud dans la grappe. L’option la plus fiable est l’utilisation d'ensembles de PAT uniques par règle.

• Pas de tourniquet (Round robin) : le tourniquet pour un ensemble PAT n’est pas pris en charge avec la mise en grappe.

• Pas de PAT étendue : la PAT étendue n'est pas prise en charge avec la mise en grappe.

• Tableaux xlates dynamiques de NAT gérés par le nœud de contrôle : Le nœud de contrôle conserve et reproduit le tableau xlate sur les nœuds de données. Lorsqu’un nœud de données reçoit une connexion qui nécessite une NAT dynamique et que le xlate n’est pas dans le tableau, il le demande au nœud de contrôle. Le nœud de données est propriétaire de la connexion.

• Disques xlates périmés : le temps d’inactivité xlate sur le propriétaire de la connexion n’est pas mis à jour. Ainsi, le temps d’inactivité peut dépasser le délai d’inactivité. Une valeur de minuteur d’inactivité supérieure au délai d’expiration configuré avec un contrôle de référence de 0 est une indication d’un xlate périmé.

• Pas de PAT statique pour les inspections suivantes :

  • FTP

  • RSH

  • SQLNET

  • TFTP

  • XDMCP

  • SIP

• Si vous avez un nombre extrêmement important de règles NAT, plus de dix mille, vous devez activer le modèle de validation transactionnelle à l’aide de la commande asp rule-engine transactional-commit nat dans l’interface de ligne de commande du périphérique. Sinon, le nœud pourrait ne pas être en mesure de rejoindre la grappe.

Un flux de contrôle peut être créé sur n’importe quel nœud (en raison de l’équilibrage de la charge); ses flux de données enfants doivent résider sur le même nœud.

Un agent SNMP interroge chaque défense contre les menaces en fonction de l’adresse IP locale de son interface Diagnostic. Vous ne pouvez pas interroger les données consolidées de la grappe.

Vous devez toujours utiliser l’adresse locale, et non l’adresse IP de la grappe principale pour l’interrogation SNMP. Si l’agent SNMP interroge l’adresse IP de la grappe principale, si un nouveau nœud de contrôle est choisi, l’interrogation du nouveau nœud de contrôle échouera.

Lorsque vous utilisez SNMPv3 avec la mise en grappe et que vous ajoutez un nouveau nœud de grappe après la formation initiale de la grappe, les utilisateurs SNMPv3 ne seront pas répliqués sur le nouveau nœud. Vous devez supprimer les utilisateurs, les rajouter, puis redéployer votre configuration pour forcer les utilisateurs à se reproduire sur le nouveau nœud.

• Chaque nœud de la grappe génère ses propres messages syslog. Vous pouvez configurer la journalisation de sorte que chaque nœud utilise le même ID d’appareil ou un ID d’appareil différent dans le champ d’en-tête du message syslog. Par exemple, la configuration du nom d’hôte est répliquée et partagée par tous les nœuds de la grappe. Si vous configurez la journalisation pour utiliser le nom d’hôte comme ID d’appareil, les messages syslog générés par tous les nœuds semblent provenir d’un seul nœud. Si vous configurez la journalisation pour utiliser le nom de nœud local attribué dans la configuration de démarrage de la grappe comme ID d’appareil, les messages du journal système semblent provenir de nœuds différents.

Seul le nœud de contrôle reçoit les informations des balises de groupe de sécurité (SGT). Le nœud de contrôle remplit ensuite la balise SGT pour les nœuds de données, et les nœuds de données peuvent prendre une décision de correspondance pour la balise SGT en fonction de la politique de sécurité.

Chaque nœud envoie périodiquement un paquet de diffusion heartbeat sur la liaison de commande de grappe. Si le nœud de contrôle ne reçoit aucun paquet heartbeat ou autre paquet d’un nœud de données au cours du délai d’expiration configurable, le nœud de contrôle supprime le nœud de données de la grappe. Si les nœuds de données ne reçoivent pas de paquets du nœud de contrôle, un nouveau nœud de contrôle est élu parmi les nœuds restants.

Si les nœuds ne peuvent pas se joindre sur le lien de commande de grappe en raison d’une défaillance du réseau et non parce qu’un nœud est réellement défaillant, la grappe peut entrer dans un scénario de « scission du cœur » où les nœuds de données isolés éliront leurs propres nœuds de contrôle. Par exemple, si un routeur tombe en panne entre deux emplacements de grappe, le nœud de contrôle d’origine à l’emplacement 1 supprimera les nœuds de données de l’emplacement 2 de la grappe. Pendant ce temps, les nœuds de l’emplacement 2 éliront leur propre nœud de contrôle et formeront leur propre grappe. Notez que le trafic symétrique peut échouer dans ce scénario. Une fois la liaison de commande de grappe restauré, le nœud de contrôle qui a la priorité la plus élevée conservera le rôle de nœud de contrôle.

Lorsqu’un nœud de la grappe tombe en panne, les connexions hébergées par ce nœud sont transférées en toute transparence vers d’autres nœuds; Les renseignements d’état sur les flux de trafic sont partagés sur la liaison de commande de grappe du nœud de contrôle.

Si le nœud de contrôle échoue, un autre membre de la grappe ayant la priorité la plus élevée (numéro le plus bas) devient le nœud de contrôle.

défense contre les menaces tente automatiquement de rejoindre la grappe, en fonction de l’événement d’échec.

Remarque

Lorsque défense contre les menaces devient inactif et ne parvient pas à rejoindre automatiquement la grappe, toutes les interfaces de données sont fermées; Seule l’interface de gestion/dépistage de gestion peut envoyer et recevoir du trafic.

Chaque connexion a un propriétaire et au moins un propriétaire secondaire dans la grappe. Le propriétaire de secours ne prend pas en charge la connexion en cas d’échec; au lieu de cela, il stocke les informations d’état TCP/UDP, de sorte que la connexion puisse être transférée de manière transparente à un nouveau propriétaire en cas de défaillance. Le propriétaire de la sauvegarde est généralement aussi le directeur.

Certains trafics nécessitent des informations d’état au-dessus de la couche TCP ou UDP. Consultez le tableau suivant pour connaître la prise en charge ou l’absence de prise en charge de ce type de trafic.

Consultez les rôles suivants, définis pour chaque connexion :

• Propriétaire : généralement, le nœud qui reçoit initialement la connexion. Le propriétaire gère l’état TCP et traite les paquets. Une connexion n’a qu’un seul propriétaire. Si le propriétaire d’origine échoue, lorsque les nouveaux nœuds reçoivent des paquets de la connexion, le directeur choisit un nouveau propriétaire dans ces nœuds.

• Propriétaire du sauvegarde : Nœud qui stocke les informations d’état TCP/UDP reçues du propriétaire, de sorte que la connexion puisse être transférée en toute transparence à un nouveau propriétaire en cas de défaillance. Le propriétaire de secours ne prend pas en charge la connexion en cas d’échec. Si le propriétaire devient indisponible, le premier nœud à recevoir les paquets de la connexion (selon l’équilibrage de la charge) contacte le propriétaire de secours pour obtenir les informations d’état pertinentes, afin qu’il puisse devenir le nouveau propriétaire.

  Tant que le directeur (voir ci-dessous) n’est pas le même nœud que le propriétaire, le directeur est également le propriétaire secondaire. Si le propriétaire se choisit lui-même directeur, un propriétaire de secours distinct est choisi.

  Pour la mise en grappe sur le périphérique Firepower 9300, qui peut inclure jusqu’à 3 nœuds de grappe dans un châssis, si le propriétaire de secours se trouve sur le même châssis que le propriétaire, un propriétaire de secours supplémentaire sera choisi dans un autre châssis pour protéger les flux d’une défaillance du châssis .

• Directeur : nœud qui gère les demandes de recherche de propriétaire provenant des transitaires. Lorsque le propriétaire reçoit une nouvelle connexion, il choisit un directeur en fonction d’un hachage de l’adresse IP source/de destination et des ports (voir ci-dessous pour les détails du hachage ICMP) et envoie un message au directeur pour enregistrer la nouvelle connexion. Si les paquets arrivent à un nœud autre que le propriétaire, le nœud interroge le directeur sur quel nœud est le propriétaire afin qu’il puisse transférer les paquets. Une connexion n’a qu’un seul directeur. En cas de défaillance d’un directeur, le propriétaire en choisit un nouveau.

  Tant que le directeur ne se trouve pas sur le même nœud que le propriétaire, le directeur est également le propriétaire suppléant (voir ci-dessus). Si le propriétaire se choisit lui-même directeur, un propriétaire de secours distinct est choisi.

  Détails du hachage ICMP/ICMPv6 :

  • Pour les paquets Echo, le port source correspond à l’identifiant ICMP et le port de destination est 0.

  • Pour les paquets de réponse, le port source est 0 et le port de destination est l’identifiant ICMP.

  • Pour les autres paquets, les ports source et de destination sont à 0.

• Forwarder  (transitaire) : nœud qui transfère les paquets au propriétaire. Si un transitaire reçoit un paquet pour une connexion qu’il ne possède pas, il interroge le directeur à propos du propriétaire, puis établit un flux vers le propriétaire pour tout autre paquet qu’il reçoit pour cette connexion. Le directeur peut également être un transitaire. Notez que si un transitaire reçoit le paquet SYN-ACK, il peut en dériver le propriétaire directement d’un témoin SYN dans le paquet, donc il n’a pas besoin d’interroger le directeur. (Si vous désactivez la répartition aléatoire de la séquence TCP, le témoin SYN n’est pas utilisé; une requête au directeur est requise.) Pour les flux de courte durée tels que DNS et ICMP, au lieu d’interroger, le redirecteur envoie immédiatement le paquet au directeur, qui l’envoie ensuite au propriétaire. Une connexion peut avoir plusieurs redirecteurs; le débit le plus efficace est obtenu par une bonne méthode d’équilibrage de la charge où il n’y a pas de redirecteurs et où tous les paquets d’une connexion sont reçus par le propriétaire.

  Remarque

  Nous vous déconseillons de désactiver la répartition aléatoire de la séquence TCP lors de l’utilisation de la mise en grappe. Il y a un faible risque que certaines sessions TCP ne soient pas établies, car le paquet SYN/ACK sera abandonné.

• Propriétaire de fragment : Pour les paquets fragmentés, les nœuds de la grappe qui reçoivent un fragment déterminent le propriétaire du fragment à l’aide d’un hachage de l’adresse IP source du fragment, de l’adresse IP de destination et de l’ID de paquet. Tous les fragments sont ensuite transférés au propriétaire du fragment sur la liaison de commande de grappe. Les fragments peuvent être équilibrés en charge vers différents nœuds de grappe, car seul le premier fragment comprend le quintuple utilisé dans le hachage d’équilibrage de charge du commutateur. Les autres fragments ne contiennent pas les ports source et de destination et peuvent être répartis en charge vers d’autres nœuds de la grappe. Le propriétaire du fragment rassemble temporairement le paquet afin de pouvoir déterminer le directeur en fonction d’un hachage de l’adresse IP source/de destination et des ports. S’il s’agit d’une nouvelle connexion, le propriétaire du fragment s’enregistrera en tant que propriétaire de la connexion. S'il s’agit d’une connexion existante, le propriétaire du fragment transfère tous les fragments au propriétaire de la connexion fourni par la liaison de commande de grappe. Le propriétaire de la connexion rassemblera ensuite tous les fragments.

L'exemple suivant montre l'établissement d'une nouvelle connexion.

1. Le paquet SYN provient du client et est livré à un défense contre les menaces (selon la méthode d’équilibrage de la charge), qui devient le propriétaire. Le propriétaire crée un flux, code les renseignements sur le propriétaire dans un témoin SYN et transfère le paquet au serveur.

2. Le paquet SYN-ACK provient du serveur et est livré à un défense contre les menaces différent (selon la méthode d’équilibrage de la charge). Ce défense contre les menaces est le transitaire.

3. Comme le transitaire n’est pas propriétaire de la connexion, il décode les informations sur le propriétaire à partir du témoin SYN, crée un flux de transfert vers le propriétaire et transmet le SYN-ACK au propriétaire.

4. Le propriétaire envoie une mise à jour de l’état au directeur et transmet le SYN-ACK au client.

5. Le directeur reçoit la mise à jour d’état du propriétaire, crée un flux à destination du propriétaire et enregistre les informations d’état TCP ainsi que le propriétaire. Le directeur agit en tant que propriétaire secondaire pour la connexion.

6. Tous les paquets suivants livrés au transitaire seront transférés au propriétaire.

7. Si des paquets sont livrés à d’autres nœuds, il interrogera le directeur à propos du propriétaire et établira un flux.

8. Tout changement d’état du flux entraîne une mise à jour d’état du propriétaire au directeur.

L'exemple suivant montre l'établissement d'une nouvelle connexion.

1. 

   Le premier paquet UDP provient du client et est remis à un défense contre les menaces (selon la méthode d’équilibrage de la charge).

2. Le nœud qui a reçu le premier paquet interroge le nœud directeur qui est choisi en fonction d’un hachage de l’adresse IP et des ports source/de destination.

3. Le directeur ne trouve aucun flux existant, crée un flux de directeur et renvoie le paquet au nœud précédent. Autrement dit, le directeur a choisi un propriétaire pour ce flux.

4. Le propriétaire crée le flux, envoie une mise à jour d’état au directeur et transfère le paquet au serveur.

5. Le deuxième paquet UDP provient du serveur et est livré au redirecteur.

6. Le transitaire interroge le directeur pour fournir les renseignements sur la propriété. Pour les flux de courte durée tels que le DNS, au lieu d’interroger, le redirecteur envoie immédiatement le paquet au directeur, qui l’envoie ensuite au propriétaire.

7. Le directeur répond au transitaire avec les renseignements de propriété.

8. Le transitaire crée un flux de transfert pour enregistrer les informations sur le propriétaire et transfère le paquet au propriétaire.

9. Le propriétaire transfère le paquet au client.