As ACLs (Listas de Controle de Acesso) em dispositivos de rede podem ser implementadas usando hardware ou software, ou mais comumente, ACLs baseadas em hardware e ACLs baseadas em software. Embora as ACLs baseadas em software sejam autoexplicativas — são regras armazenadas e processadas na RAM (ou seja, no Plano de Controle), com todas as limitações que isso acarreta —, neste artigo exploraremos como as ACLs baseadas em hardware são implementadas e operam. Usaremos switches ExtremeSwitching da Extreme Networks como exemplo.
Como estamos interessados especificamente em ACLs baseadas em hardware, a implementação interna do Plano de Dados, ou os chipsets (ASICs) utilizados, é de fundamental importância. Os switches de todas as linhas de produtos da Extreme Networks são construídos com ASICs da Broadcom, portanto, a maior parte das informações abaixo também se aplica a outros switches disponíveis no mercado que utilizam os mesmos ASICs.
Como mostra a figura acima, o "ContentAware Engine" no chipset é diretamente responsável pela operação de ACL, com mecanismos separados para "entrada" e "saída". Arquiteturalmente, eles são idênticos, apenas o de "saída" é menos escalável e menos funcional. Fisicamente, ambos os "ContentAware Engines" consistem em memória TCAM mais a lógica associada, e cada regra de ACL de usuário ou sistema é uma simples máscara de bits armazenada nessa memória. É por isso que o chipset processa o tráfego pacote a pacote, sem qualquer degradação de desempenho.
Uma única TCAM física de entrada/saída é logicamente dividida em vários segmentos (dependendo da quantidade de memória e da plataforma), chamados de "fatias ACL". Por exemplo, o mesmo acontece com o mesmo disco rígido físico em seu laptop quando você cria várias unidades lógicas nele — C:>, D:>. Cada fatia ACL consiste em células de memória, na forma de "strings", onde as "regras" (máscaras de bits) são escritas.
A divisão da TCAM em fatias ACL possui uma lógica específica. Cada fatia ACL individual só pode conter "regras" compatíveis. Se uma "regra" for incompatível com a anterior, ela será gravada na próxima fatia ACL, independentemente de quantas linhas de "regras" livres ainda existam na fatia anterior.
De onde surge essa compatibilidade ou incompatibilidade das regras de ACL? O fato é que uma "linha" da TCAM, onde as "regras" são escritas, tem 232 bits de comprimento e é dividida em vários campos: Fixo, Campo1, Campo2 e Campo3. 232 bits, ou 29 bytes, de memória TCAM são suficientes para armazenar a máscara de bits de um endereço MAC ou IP específico, mas significativamente menos do que o cabeçalho completo de um pacote Ethernet. Em cada fatia individual da ACL, o ASIC realiza uma busca independente usando as máscaras de bits definidas em F1-F3. No geral, essa busca pode ser realizada nos primeiros 128 bytes do cabeçalho Ethernet. Como a busca pode ser realizada em 128 bytes, mas apenas 29 bytes podem ser escritos, um deslocamento em relação ao início do pacote deve ser definido para que a busca seja feita corretamente. O deslocamento para cada fatia da ACL é definido quando a primeira regra é escrita nela e, se a necessidade de um deslocamento diferente for descoberta ao escrever uma regra subsequente, essa regra será considerada incompatível com a primeira e será escrita na próxima fatia da ACL.
A tabela abaixo mostra a ordem de compatibilidade das condições especificadas em uma ACL. Cada linha individual contém máscaras de bits que são compatíveis entre si e outras que são incompatíveis com as demais linhas.
Cada pacote individual processado pelo ASIC executa uma busca paralela em cada fatia da ACL. A verificação é realizada até que a primeira correspondência seja encontrada na fatia da ACL, mas múltiplas correspondências para o mesmo pacote em diferentes fatias da ACL são permitidas. Cada "regra" individual possui uma ação correspondente a ser executada se a condição (máscara de bits) for atendida. Se uma correspondência ocorrer em múltiplas fatias da ACL, o bloco "Resolução de Conflitos de Ação" decide qual ação executar com base na prioridade da fatia da ACL. Se uma ACL especificar tanto uma "ação" (permitir/negar) quanto um "modificador de ação" (contagem/QoS/log/...), então, no caso de múltiplas correspondências, apenas a "ação" de maior prioridade será executada, enquanto todos os "modificadores de ação" serão executados. O exemplo abaixo mostra que ambos os contadores serão incrementados e a ação "negar" de maior prioridade será executada.
Informações mais detalhadas sobre o funcionamento da ACL estão disponíveis publicamente no site. Caso tenha alguma dúvida ou ainda precise de esclarecimentos, pode sempre contactar a nossa equipa administrativa. .
Fonte: habr.com
