Le ACL (Access Control List) sui dispositivi di rete possono essere implementati sia a livello hardware che software, o più comunemente parlando, come ACL basate su hardware e software. Se per quanto riguarda le ACL basate su software è tutto chiaro — si tratta di regole archiviate e elaborate nella memoria RAM (cioè sul Control Plane), con tutte le limitazioni del caso, in questo articolo analizzeremo come sono implementate e funzionano le ACL basate su hardware. Useremo come esempio gli switch della serie ExtremeSwitching dell'azienda Extreme Networks.
Poiché ci interessa specificamente le ACL basate su hardware, la cosa più importante per noi è la reale implementazione del Data Plane, cioè i chip utilizzati (ASIC). Gli switch di tutte le linee dell'azienda Extreme Networks sono costruiti su ASIC di Broadcom, per cui gran parte delle informazioni che seguono sarà valida anche per altri switch presenti sul mercato e realizzati con gli stessi ASIC.
Come si può vedere dall'immagine sopra, la responsabilità della gestione delle ACL nel chip è affidata ai “ContentAware Engine”, separatamente per “ingress” ed “egress”. Architettonicamente sono identici, solo che “egress” è meno scalabile e meno funzionale. Fisicamente, entrambi i “ContentAware Engine” sono una memoria TCAM più la logica associata, e ogni regola ACL, sia essa per l'utente che di sistema, è una semplice maschera di bit (bit-mask) registrata in questa memoria. Questo è il motivo per cui il chip gestisce il traffico pacchetto per pacchetto senza degradare le prestazioni.
Fisicamente, la stessa TCAM Ingress/Egress è logicamente suddivisa in più segmenti (a seconda della quantità di memoria stessa e della piattaforma), noti come “ACL slices”. Ad esempio, lo stesso avviene con un unico disco rigido fisico nel tuo laptop quando crei più dischi logici – C:>, D:>. Ogni slice ACL consiste a sua volta in celle di memoria, sotto forma di “righe” dove vengono registrate le “rules” (regole/maschere di bit).
La suddivisione della TCAM in ACL-slices è guidata da una logica specifica. In ciascun singolo slice ACL possono essere registrate solo “rules” compatibili fra loro. Se una delle “rules” non è compatibile con la precedente, sarà registrata nel successivo slice ACL, indipendentemente da quante righe libere sotto le “rules” siano rimaste nella precedente.
Da dove deriva quindi questa compatibilità o incompatibilità delle ACL rules? Il fatto è che una 'riga' di TCAM, in cui vengono registrate le 'rules', ha una lunghezza di 232 bit ed è suddivisa in diversi campi: Fixed, Field1, Field2, Field3. 232 bit o 29 byte di memoria TCAM sono più che sufficienti per registrare una bit-mask di un determinato indirizzo MAC o IP, ma sono decisamente inferiori rispetto all'intero header di un pacchetto Ethernet. In ogni singolo ACL-slice, l'ASIC esegue un lookup indipendente basato sulle bit-mask impostate in F1-F3. Complessivamente, questo lookup può avvenire sui primi 128 byte dell'header Ethernet. In realtà, proprio perché la ricerca può avvenire su 128 byte e ciò che può essere registrato è solo 29 byte, per un corretto lookup deve essere impostato un offset rispetto all'inizio del pacchetto. L'offset per ogni ACL-slice viene impostato al momento della registrazione della prima regola, e se durante la registrazione di una regola successiva si rileva la necessità di un altro offset, tale regola è considerata incompatibile con la prima e viene registrata nel successivo ACL-slice.
Nella tabella sottostante è illustrato l'ordine di compatibilità delle condizioni scritte nell'ACL. Ogni singola riga contiene bit-mask compatibili tra loro e non compatibili con altre righe.
Ogni singolo pacchetto elaborato dall'ASIC avvia un lookup parallelo in ogni ACL-slice. Il controllo avviene fino al primo corrispondenza nell'ACL-slice, ma è consentita anche una corrispondenza multipla per lo stesso pacchetto in diversi ACL-slice. Ogni singola 'rule' ha un'azione corrispondente che deve essere eseguita in caso di corrispondenza delle condizioni (bit-mask). Se la corrispondenza avviene in più ACL-slice, nella sezione 'Action Conflict Resolution' viene presa una decisione su quale azione eseguire sulla base della priorità dell'ACL-slice. Se nell'ACL sono definite sia un'azione (permit/deny) che un 'action-modifier' (count/QoS/log/…), in caso di corrispondenze multiple verrà eseguita solo l'azione di maggiore priorità, mentre tutti gli 'action-modifier' verranno eseguiti. Nell'esempio qui sotto si mostra che entrambi i conteggi verranno incrementati e verrà eseguita l'azione di maggiore priorità 'deny'.
con informazioni più dettagliate sul funzionamento delle ACL, disponibili pubblicamente sul sito . Qualsiasi domanda sorga o resti può sempre essere indirizzata ai membri del nostro ufficio – .
Fonte: habr.com
