Les ACL (Listes de Contrôle d'Accès) sur les dispositifs réseau peuvent être mises en œuvre de manière matérielle ou logicielle, ou plus familièrement dites basées sur le matériel et sur le logiciel. Et si les ACL basées sur le logiciel sont assez claires — ce sont des règles qui sont stockées et traitées dans la mémoire vive (c'est-à-dire sur le Plan de Contrôle), avec toutes les limitations qui en découlent, nous allons analyser comment les ACL basées sur le matériel sont mises en œuvre et fonctionnent dans notre article. Comme exemple, nous utiliserons les commutateurs de la série ExtremeSwitching de la société Extreme Networks.
Puisque nous nous intéressons spécifiquement aux ACL basées sur le matériel, la mise en œuvre interne du Plan de Données, ou des chipsets utilisés (ASIC), est primordiale pour nous. Les commutateurs de toutes les gammes de la société Extreme Networks reposent sur des ASIC de Broadcom, et donc la plupart des informations suivantes seront également valables pour d'autres commutateurs présents sur le marché et réalisés sur des ASIC similaires.
Comme on peut le voir sur l'illustration ci-dessus, les travaux des ACL dans le chipset sont gérés par le "ContentAware Engine", séparément pour "ingress" et "egress". Architecturément, ils sont identiques, seulement l'"egress" est moins évolutif, et moins fonctionnel. Physiquement, les deux "ContentAware Engine" consistent en de la mémoire TCAM plus la logique associée, et chaque règle d'utilisateur ou système ACL est un simple masque de bits (bit-mask) enregistré dans cette mémoire. C'est pourquoi le traitement du trafic par le chipset s'effectue paquet par paquet et sans dégradation des performances.
Physiquement, le même TCAM d'Ingress/Egress est logiquement divisé en plusieurs segments (en fonction de la quantité de mémoire et de la plateforme), appelés "tranches ACL". Par exemple, c'est comme ce qui se passe avec un même disque dur physique sur votre ordinateur portable, lorsque vous créez plusieurs disques logiques dessus – C:>, D:>. Chaque tranche ACL se compose à son tour de cellules de mémoire sous forme de "lignes" où les "règles" (bit-masques) sont enregistrées.
La division de la TCAM en tranches ACL repose sur une certaine logique. Dans chaque tranche ACL distincte, seules des "règles" compatibles peuvent être enregistrées. Si une des "règles" n'est pas compatible avec la précédente, elle sera enregistrée dans la tranche ACL suivante, peu importe combien de lignes libres pour les "règles" restent dans la précédente.
D'où provient donc cette compatibilité ou incompatibilité des règles ACL ? En fait, une « ligne » TCAM, où sont enregistrées les « règles », fait 232 bits de long et se divise en plusieurs champs : Fixed, Field1, Field2, Field3. 232 bits ou 29 octets de mémoire TCAM suffisent largement pour enregistrer un bit-mask d'une adresse MAC ou IP, mais c'est beaucoup moins que l'en-tête complet d'un paquet Ethernet. Dans chaque tranche ACL distincte, l'ASIC effectue une recherche indépendante selon les bit-masks définis dans F1-F3. En général, cette recherche peut être effectuée sur les 128 premiers octets de l'en-tête Ethernet. C'est précisément parce que la recherche peut s'effectuer sur 128 octets, tandis que seulement 29 octets peuvent être enregistrés, qu'un décalage (offset) doit être défini par rapport au début du paquet pour un lookup correct. Le décalage pour chaque tranche ACL est défini lors de l'enregistrement de la première règle, et si, lors de l'enregistrement de la règle suivante, il est nécessaire d'utiliser un autre décalage, cette règle est considérée comme incompatible avec la première et est enregistrée dans la tranche ACL suivante.
Le tableau ci-dessous présente l'ordre de compatibilité des conditions spécifiées dans la ACL. Chaque ligne individuelle contient des bit-masks compatibles entre eux, et incompatibles avec d'autres lignes.
Chaque paquet distinct traité par l'ASIC lance 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 pour un même paquet dans différentes tranches ACL sont autorisées. Chaque « règle » distincte a une action correspondante à exécuter en cas de correspondance de condition (bit-mask). Si une correspondance se produit dans plusieurs tranches ACL, dans le bloc « Résolution de conflit d’action », une décision est prise sur quelle action exécuter en fonction de la priorité de la tranche ACL. Si une ACL spécifie à la fois une « action » (permettre/refuser) et un « modificateur d’action » (compter/QoS/journaliser/…), alors dans le cas de plusieurs correspondances, seule l'« action » la plus prioritaire sera exécutée, toutes les actions-modificateurs seront quand même réalisées. L'exemple ci-dessous montre que les deux compteurs seront augmentés et que l'« action » la plus prioritaire sera « refuser ».
avec des informations plus détaillées sur le fonctionnement de l'ACL accessibles sur le site . Toute question éventuelle ou restante peut toujours être posée aux employés de notre bureau – .
Source : habr.com
