Les ACL (Access Control List) sur les périphériques réseau peuvent être implémentées à la fois sous forme matérielle et logicielle, ou plus communément, sous forme d'ACL matérielles et logicielles. Et si tout devait être clair avec les ACL logicielles - ce sont des règles qui sont stockées et traitées dans la RAM (c'est-à-dire sur le plan de contrôle), avec toutes les restrictions qui en découlent, alors nous comprendrons comment les ACL matérielles sont implémentées et fonctionnent notre article. A titre d'exemple, nous utiliserons les commutateurs de la série ExtremeSwitching d'Extreme Networks.
Puisque nous nous intéressons aux ACL basées sur le matériel, l'implémentation interne du plan de données, ou les chipsets (ASIC) utilisés, est d'une importance capitale pour nous. Toutes les lignes de commutateurs Extreme Networks sont construites sur des ASIC Broadcom et, par conséquent, la plupart des informations ci-dessous s'appliqueront également aux autres commutateurs du marché implémentés sur les mêmes ASIC.
Comme le montre la figure ci-dessus, le « ContentAware Engine » est directement responsable du fonctionnement des ACL dans le chipset, séparément pour « l'entrée » et la « sortie ». Sur le plan architectural, ce sont les mêmes, seule la « sortie » est moins évolutive et moins fonctionnelle. Physiquement, les deux « moteurs ContentAware » sont de la mémoire TCAM accompagnée de la logique, et chaque règle ACL utilisateur ou système est un simple masque de bits écrit dans cette mémoire. C'est pourquoi le chipset traite le trafic paquet par paquet et sans dégradation des performances.
Physiquement, le même TCAM Ingress/Egress, à son tour, est logiquement divisé en plusieurs segments (en fonction de la quantité de mémoire elle-même et de la plate-forme), appelés « tranches ACL ». Par exemple, la même chose se produit avec physiquement le même disque dur sur votre ordinateur portable lorsque vous y créez plusieurs lecteurs logiques - C:>, D:>. Chaque tranche ACL, à son tour, est constituée de cellules mémoire sous la forme de « chaînes » où des « règles » (règles/masques de bits) sont écrites.
La division du TCAM en tranches ACL repose sur une certaine logique. Dans chacune des tranches ACL individuelles, seules des « règles » compatibles les unes avec les autres peuvent être écrites. Si l'une des « règles » n'est pas compatible avec la précédente, elle sera alors écrite dans la tranche ACL suivante, quel que soit le nombre de lignes libres pour les « règles » restantes dans la précédente.
D’où vient alors cette compatibilité ou incompatibilité des règles ACL ? Le fait est qu'une "ligne" TCAM, où les "règles" sont écrites, a une longueur de 232 bits et est divisée en plusieurs champs - Fixe, Field1, Field2, Field3. Une mémoire TCAM de 232 bits ou 29 octets est suffisante pour enregistrer le masque de bits d'une adresse MAC ou IP spécifique, mais bien moins que l'en-tête complet du paquet Ethernet. Dans chaque tranche ACL individuelle, l'ASIC effectue une recherche indépendante selon le masque de bits défini dans F1-F3. En général, cette recherche peut être effectuée en utilisant les 128 premiers octets de l'en-tête Ethernet. En fait, précisément parce que la recherche peut être effectuée sur 128 octets, mais que seuls 29 octets peuvent être écrits, pour une recherche correcte, un décalage doit être défini par rapport au début du paquet. Le décalage pour chaque tranche ACL est défini lorsque la première règle y est écrite, et si, lors de l'écriture d'une règle ultérieure, la nécessité d'un autre décalage est découverte, alors une telle règle est considérée comme incompatible avec la première et est écrite dans le prochaine tranche ACL.
Le tableau ci-dessous montre l'ordre de compatibilité des conditions spécifiées dans l'ACL. Chaque ligne individuelle contient des masques de bits générés qui sont compatibles entre eux et incompatibles avec les autres lignes.
Chaque paquet individuel traité par l'ASIC exécute une recherche parallèle dans chaque tranche ACL. La vérification est effectuée jusqu'à la première correspondance dans la tranche ACL, mais plusieurs correspondances sont autorisées pour le même paquet dans différentes tranches ACL. Chaque « règle » individuelle a une action correspondante qui doit être effectuée si la condition (masque de bits) est remplie. Si une correspondance se produit dans plusieurs tranches ACL à la fois, alors dans le bloc « Résolution des conflits d'action », en fonction de la priorité de la tranche ACL, une décision est prise quelle action effectuer. Si l'ACL contient à la fois « action » (permit/deny) et « action-modifier » (count/QoS/log/…), alors en cas de correspondances multiples, seule « l'action » de priorité plus élevée sera exécutée, tandis que « l'action » -modifier » sera entièrement terminé. L'exemple ci-dessous montre que les deux compteurs seront incrémentés et que le « refus » de priorité plus élevée sera exécuté.
avec des informations plus détaillées sur le fonctionnement de l'ACL dans le domaine public sur le site Web . Toutes les questions qui se posent ou restent peuvent toujours être posées à notre personnel de bureau - .
Source: habr.com