As ACL (lista de control de acceso) nos dispositivos de rede pódense implementar tanto en hardware como en software, ou máis comúnmente, en ACL baseadas en hardware e software. E se todo debe quedar claro coas ACL baseadas en software: estas son regras que se almacenan e procesan na RAM (é dicir, no plano de control), con todas as restricións conseguintes, entón entenderemos como se implementan as ACL baseadas en hardware e funcionan o noso funcionamento. artigo. Como exemplo, utilizaremos interruptores da serie ExtremeSwitching de Extreme Networks.
Dado que nos interesan as ACL baseadas en hardware, a implementación interna do Data Plane, ou os chipsets reais (ASIC) utilizados, é de suma importancia para nós. Todas as liñas de conmutadores de Extreme Networks están construídas sobre ASIC de Broadcom e, polo tanto, a maior parte da información que aparece a continuación tamén será certa para outros conmutadores do mercado que se implementen nos mesmos ASIC.
Como se pode ver na figura anterior, o "ContentAware Engine" é directamente responsable do funcionamento das ACL no chipset, por separado para a "entrada" e a "saída". Arquitectónicamente, son iguais, só a "saída" é menos escalable e menos funcional. Fisicamente, ambos os "Motores ContentAware" son memoria TCAM máis a lóxica de acompañamento, e cada regra ACL de usuario ou sistema é unha simple máscara de bits escrita nesta memoria. É por iso que o chipset procesa o tráfico paquete a paquete e sen degradación do rendemento.
Fisicamente, o mesmo Ingress/Egress TCAM, á súa vez, divídese loxicamente en varios segmentos (dependendo da propia cantidade de memoria e da plataforma), os chamados "slices ACL". Por exemplo, o mesmo ocorre co mesmo disco duro no teu portátil cando creas varias unidades lóxicas nel - C:>, D:>. Cada ACL-slice, á súa vez, consta de celas de memoria en forma de "cadeas" onde se escriben "regras" (regras/máscara de bits).
A división de TCAM en ACL-slices ten unha certa lóxica detrás. En cada un dos segmentos ACL individuais, só se poden escribir "regras" compatibles entre si. Se algunha das "regras" non é compatible coa anterior, escribirase na seguinte porción ACL, independentemente de cantas liñas libres de "regras" queden na anterior.
De onde vén entón esta compatibilidade ou incompatibilidade das regras ACL? O feito é que unha "liña" TCAM, onde se escribe "regras", ten unha lonxitude de 232 bits e está dividida en varios campos: Fixo, Campo1, Campo2, Campo3. A memoria TCAM de 232 bits ou 29 bytes é suficiente para gravar a máscara de bits dun enderezo MAC ou IP específico, pero moito menos que a cabeceira completa do paquete Ethernet. En cada segmento ACL individual, o ASIC realiza unha busca independente segundo a máscara de bits definida en F1-F3. En xeral, esta busca pódese realizar usando os primeiros 128 bytes da cabeceira Ethernet. En realidade, precisamente porque a busca pode realizarse en 128 bytes, pero só se poden escribir 29 bytes, para unha busca correcta hai que establecer un desfase en relación ao inicio do paquete. A compensación para cada segmento ACL establécese cando se escribe a primeira regra nel e se, ao escribir unha regra posterior, se descobre a necesidade doutra compensación, esta regra considérase incompatible coa primeira e escríbese no seguinte ACL-slice.
A táboa seguinte mostra a orde de compatibilidade das condicións especificadas na ACL. Cada liña individual contén máscaras de bits xeradas que son compatibles entre si e incompatibles con outras liñas.
Cada paquete individual procesado polo ASIC realiza unha busca paralela en cada ACL-slice. A comprobación realízase ata a primeira coincidencia no segmento ACL, pero permítense varias coincidencias para o mesmo paquete en diferentes segmentos ACL. Cada "regra" individual ten unha acción correspondente que debe realizarse se a condición (máscara de bits) coincide. Se se produce unha coincidencia en varios segmentos ACL á vez, entón no bloque "Resolución de conflitos de accións", en función da prioridade do segmento ACL, tómase a decisión que acción realizar. Se a ACL contén "acción" (permitir/denegar) e "modificador de acción" (conto/QoS/log/...), entón en caso de coincidencias múltiples só se executará a "acción" de maior prioridade, mentres que "acción" -modifier” completarase. O exemplo seguinte mostra que ambos os contadores incrementaranse e executarase o "denegar" de maior prioridade.
Fonte: www.habr.com