ACL (Access Control List) sui dispositivi di rete possono essere implementati sia a livello hardware che software, ovvero basati su hardware e software. Se per gli ACL basati su software è tutto abbastanza chiaro—si tratta di regole memorizzate e elaborate nella memoria volatile (cioè nel Control Plane), con tutte le limitazioni consequenziali, nella nostra articolo esamineremo come sono implementati e funzionano gli ACL basati su hardware. Useremo come esempio gli switch della serie ExtremeSwitching di Extreme Networks.
Poiché siamo interessati agli ACL basati su hardware, per noi è fondamentale comprendere l'implementazione interna del Data Plane, ovvero dei chip utilizzati (ASIC). Gli switch di tutte le linee di Extreme Networks sono costruiti su ASIC di Broadcom, e perciò la maggior parte delle informazioni sottostanti sarà valida anche per altri switch presenti sul mercato e implementati su ASIC similari.
Come si può vedere nell'immagine sopra, il “ContentAware Engine” è responsabile del funzionamento diretto degli ACL all'interno del chip, sia per “ingress” che per “egress”. Architettonicamente sono identici, ma “egress” è meno scalabile e funzionale. Fisicamente, entrambi i “ContentAware Engine” consistono in memoria TCAM più logica associata, mentre ogni regola ACL, sia essa utente o di sistema, è una semplice maschera di bit (bit-mask) memorizzata in questa memoria. Per questo motivo, il chip elabora i pacchetti in modo per pacchetto senza degradare le prestazioni.
Fisicamente, la stessa TCAM Ingress/Egress è suddivisa logicamente in più segmenti (a seconda della quantità di memoria e della piattaforma), noti come “ACL slices”. Ad esempio, si verifica lo stesso fenomeno con un singolo HDD fisico nel tuo laptop quando crei più dischi logici – C:>, D:>. Ogni ACL-slice è composto da celle di memoria, disposte in “righe” in cui vengono memorizzate le “rules” (regole/maschere di bit).
La suddivisione della TCAM in ACL-slices è guidata da una logica precisa. In ciascun ACL-slice possono essere scritte solo “rules” compatibili tra loro. Se una delle “rules” non è compatibile con quella precedente, verrà registrata nel successivo ACL-slice, indipendentemente dal numero di righe libere rimaste nel precedente.
Da dove deriva quindi questa compatibilità o incompatibilità delle regole ACL? Il fatto è che una “riga” di TCAM, in cui viene scritta una “rule”, ha una lunghezza di 232 bit ed è suddivisa in diversi campi – Fixed, Field1, Field2, Field3. 232 bit o 29 byte di memoria TCAM sono sufficienti per scrivere una maschera di bit di un determinato indirizzo MAC o IP, ma significativamente meno rispetto all'intestazione completa di un pacchetto Ethernet. In ciascun ACL-slice, l'ASIC effettua una ricerca indipendente in base alla maschera di bit stabilita in F1-F3. In generale, questa ricerca può essere effettuata sui primi 128 byte dell'intestazione Ethernet. Proprio per il fatto che la ricerca può essere effettuata su 128 byte, mentre possono essere scritti solo 29 byte, è necessario definire un offset corretto rispetto all'inizio del pacchetto. L'offset per ciascun ACL-slice viene impostato al momento della scrittura della prima regola, e se durante la scrittura della successiva regola si riscontra la necessità di un offset differente, quella regola è considerata incompatibile con la prima e verrà registrata nel prossimo ACL-slice.
Nella tabella sottostante è riportato l'ordine di compatibilità delle condizioni scritte negli ACL. Ogni riga separata contiene maschere di bit compatibili tra loro e non compatibili con le altre righe.
Ogni pacchetto elaborato dall'ASIC avvia una ricerca parallela in ciascun ACL-slice. Il controllo viene effettuato fino al primo match in un ACL-slice, ma è consentito che ci siano più match per lo stesso pacchetto in diversi ACL-slice. Ogni “rule” ha un'azione corrispondente da eseguire in caso di corrispondenza della condizione (bit-mask). Se si verifica una corrispondenza in più ACL-slice, nel blocco “Action Conflict Resolution” viene presa una decisione su quale azione eseguire sulla base della priorità dell'ACL-slice. Se in un ACL sono scritti sia un “action” (permit/deny) che un “action-modifier” (count/QoS/log/...), nel caso di più corrispondenze verrà eseguita solo l'azione più prioritaria, mentre tutti gli “action-modifier” saranno eseguiti. Nell'esempio seguente è mostrato che entrambi i contatori saranno incrementati e verrà eseguita l'azione più prioritaria “deny”.
con ulteriori dettagli sulle funzionalità degli ACL disponibili sul sito . Qualsiasi domanda o dubbio può sempre essere rivolto al personale del nostro ufficio – .
Fonte: habr.com
