Gli ACL (Access Control List) sui dispositivi di rete possono essere implementati sia nell'hardware che nel software o, più comunemente parlando, ACL basati su hardware e software. E se tutto dovrebbe essere chiaro con gli ACL basati su software - si tratta di regole che vengono archiviate ed elaborate nella RAM (cioè sul piano di controllo), con tutte le restrizioni che ne conseguono, allora capiremo come vengono implementati e come funzionano gli ACL basati su hardware articolo. Utilizzeremo ad esempio gli switch della serie ExtremeSwitching di Extreme Networks.
Poiché siamo interessati agli ACL basati su hardware, l'implementazione interna del Data Plane o i chipset effettivi (ASIC) utilizzati è per noi di fondamentale importanza. Tutte le linee di switch Extreme Networks sono costruite su ASIC Broadcom e pertanto la maggior parte delle informazioni riportate di seguito saranno vere anche per altri switch sul mercato implementati sugli stessi ASIC.
Come si può vedere dalla figura sopra, il “ContentAware Engine” è direttamente responsabile del funzionamento degli ACL nel chipset, separatamente per “ingress” ed “egress”. Dal punto di vista architettonico sono uguali, solo l’“uscita” è meno scalabile e meno funzionale. Fisicamente, entrambi i "motori ContentAware" sono memoria TCAM più la logica di accompagnamento, e ciascuna regola ACL dell'utente o del sistema è una semplice maschera di bit scritta in questa memoria. Ecco perché il chipset elabora il traffico pacchetto per pacchetto e senza degrado delle prestazioni.
Fisicamente, lo stesso Ingress/Egress TCAM, a sua volta, è suddiviso logicamente in più segmenti (a seconda della quantità di memoria stessa e della piattaforma), le cosiddette “ACL slice”. Ad esempio, la stessa cosa accade fisicamente con lo stesso HDD sul tuo laptop quando crei più unità logiche su di esso: C:>, D:>. Ciascuna fetta ACL, a sua volta, è costituita da celle di memoria sotto forma di "stringhe" in cui vengono scritte "regole" (regole/maschere di bit).
La divisione del TCAM in sezioni ACL ha una certa logica dietro. In ciascuna delle singole sezioni ACL possono essere scritte solo “regole” compatibili tra loro. Se una qualsiasi delle "regole" non è compatibile con quella precedente, verrà scritta nella sezione ACL successiva, indipendentemente da quante righe libere per le "regole" sono rimaste nella sezione precedente.
Da dove viene allora questa compatibilità o incompatibilità delle regole ACL? Il fatto è che una "linea" TCAM, dove sono scritte le "regole", ha una lunghezza di 232 bit ed è divisa in diversi campi: Fisso, Campo1, Campo2, Campo3. La memoria TCAM da 232 bit o 29 byte è sufficiente per registrare la maschera di bit di uno specifico indirizzo MAC o IP, ma molto meno dell'intestazione completa del pacchetto Ethernet. In ogni singola sezione ACL, l'ASIC esegue una ricerca indipendente in base alla maschera di bit impostata in F1-F3. In generale, questa ricerca può essere eseguita utilizzando i primi 128 byte dell'intestazione Ethernet. In realtà, proprio perché la ricerca può essere effettuata su 128 byte, ma se ne possono scrivere solo 29, per una corretta ricerca è necessario impostare un offset relativo all'inizio del pacchetto. L'offset per ciascuna sezione ACL viene impostato quando viene scritta la prima regola e se, durante la scrittura di una regola successiva, viene rilevata la necessità di un altro offset, tale regola viene considerata incompatibile con la prima e viene scritta nella sezione sezione ACL successiva.
La tabella seguente mostra l'ordine di compatibilità delle condizioni specificate nell'ACL. Ogni singola riga contiene maschere di bit generate che sono compatibili tra loro e incompatibili con altre righe.
Ogni singolo pacchetto elaborato dall'ASIC esegue una ricerca parallela in ciascuna sezione ACL. Il controllo viene eseguito fino alla prima corrispondenza nella sezione ACL, ma sono consentite più corrispondenze per lo stesso pacchetto in sezioni ACL diverse. Ad ogni singola “regola” è associata un'azione che deve essere eseguita se la condizione (maschera di bit) viene soddisfatta. Se si verifica una corrispondenza in più sezioni ACL contemporaneamente, nel blocco "Risoluzione dei conflitti di azione", in base alla priorità della sezione ACL, viene presa la decisione su quale azione eseguire. Se l'ACL contiene sia "azione" (permetti/nega) che "modificatore di azione" (conteggio/QoS/log/...), in caso di corrispondenze multiple verrà eseguita solo l'"azione" con priorità più alta, mentre "azione -modifier" sarà tutto completato. L'esempio seguente mostra che entrambi i contatori verranno incrementati e verrà eseguito il "negamento" con priorità più alta.
con informazioni più dettagliate sul funzionamento di ACL di pubblico dominio sul sito web . Qualsiasi domanda che sorga o rimanga può sempre essere posta al nostro personale d'ufficio - .
Fonte: habr.com