ACL (Access Control List) на сетевых устройствах могут быть реализованы как аппаратно, так и программно, или привычней говоря hardware и software-based ACL. И если с software-based ACL должно быть всё понятно, — это правила которые хранятся и обрабатываются в оперативной памяти (т.е. на Control Plane), со всеми вытекающими отсюда ограничениями, то как реализованы и работают hardware-based ACL мы разберемся в нашей статье. В качестве примера будем использовать коммутаторы серии ExtremeSwitching компании Extreme Networks.
Так как нас интересует именно hardware-based ACL, то для нас имеет первостепенное значение именно внутренняя реализация Data Plane, или собственно используемых чипсетов (ASIC). Коммутаторы всех линеек компании Extreme Networks построены на ASIC от Broadcom, и поэтому большинство нижеприведённой информации будет также справедливо и для других коммутаторов, представленных на рынке, и реализованных на таких же ASIC.
Как видно из рисунка выше непосредственно за работу ACL в чипсете отвечают “ContentAware Engine”, отдельно на “ingress” и “egress”. Архитектурно они одинаковы, только “egress” менее масштабируемый, и менее функциональный. Физически же оба “ContentAware Engine” это TCAM память плюс сопутствующая логика, а каждое пользовательское или системное правило ACL это простая бит маска (bit-mask) записанная в эту память. Именно поэтому обработка чипсетом трафика осуществляется попакетно и без деградации производительности.
Физически одна и та же Ingress/Egress TCAM в свою очередь делится логически на несколько сегментов (зависит от количества самой памяти и платформы), так называемые “ACL slices”. К примеру, тоже самое происходит с физически одним и тем же HDD на вашем ноутбуке, когда вы создаете на нём несколько логических дисков – С:\>, D:\>. Каждый ACL-slice в свою очередь состоит из ячеек памяти, в виде “строк” куда и записываються “rules” (правила/бит-маски).
Разбивка TCAM на ACL-slices имеет под собой определенную логику. В каждом из отдельных ACL-slice могут быть записаны только совместимые между собой “rules”. Если какой-то из “rules” не совместим с предыдущим, то он будет записан в следующий по порядку ACL-slice, в независимости от того сколько свободных строк под “rules” осталось в предыдущем.
Откуда же тогда возникает эта совместимость или несовместимость ACL rules? Дело в том, что одна “строка” TCAM, куда записывается “rules”, имеет длину 232 bit и делится на несколько полей – Fixed, Field1, Field2, Field3. 232 bit или 29 byte TCAM памяти вполне достаточно чтобы записать bit-mask определенного MAC или IP адреса, но сильно меньше, чем полный заголовок Ethernet пакета. В каждом отдельном ACL-slice ASIC производит независимый lookup по установленным в F1-F3 bit-mask. В целом же этот lookup может производиться по первым 128 bytes Ethernet заголовка. Собственно, именно из-за того, что поиск может производиться по 128 bytes, а записано может быть только 29 bytes, для правильного lookup должно быть выставлено смещение (offset) относительно начала пакета. Offset для каждого из ACL-slice выставляется во время записи в него первого правила, и если при записи последующего правила обнаруживается необходимость в другом offset, то такое правило считается несовместимым с первым и записывается в следующий ACL-slice.
В табличке ниже приведён порядок совместимости условий прописываемых в ACL. Каждая отдельная строка содержит совместимые между собой, и не совместимые с другими строками формируемые bit-mask.
Каждый отдельный пакет обрабатываемый ASIC запускает параллельный lookup в каждом ACL-slice. Проверка производится до первого совпадения в ACL-slice, но при этом допускается множественное совпадение для одного и того же пакета в разных ACL-slice. У каждого отдельного “rule” есть соответствующее действие, которое нужно выполнить в случае совпадения условия (bit-mask). Если совпадение произошло сразу в нескольких ACL-slices, то в блоке “Action Conflict Resolution” на основании приоритета ACL-slice принимается решение какое из действий выполнить. Если в ACL прописано и “action” (permit/deny), и “action-modifier” (count/QoS/log/…), то при множественных совпадениях будет выполнено только более приоритетное “action”, “action-modifier” же будут выполнены все. На примере ниже показано, что будут увеличены оба счетчика и выполнено более приоритетное “deny”.
“ACL Solutions Guide” с более детальной информацией о работе ACL в открытом доступе на сайте extremenetworks.com. Любые возникшие или оставшиеся вопросы всегда можно задать сотрудникам нашего офиса – cis@extremenetworks.com.
Так как нас интересует именно hardware-based ACL, то для нас имеет первостепенное значение именно внутренняя реализация Data Plane, или собственно используемых чипсетов (ASIC). Коммутаторы всех линеек компании Extreme Networks построены на ASIC от Broadcom, и поэтому большинство нижеприведённой информации будет также справедливо и для других коммутаторов, представленных на рынке, и реализованных на таких же ASIC.
Как видно из рисунка выше непосредственно за работу ACL в чипсете отвечают “ContentAware Engine”, отдельно на “ingress” и “egress”. Архитектурно они одинаковы, только “egress” менее масштабируемый, и менее функциональный. Физически же оба “ContentAware Engine” это TCAM память плюс сопутствующая логика, а каждое пользовательское или системное правило ACL это простая бит маска (bit-mask) записанная в эту память. Именно поэтому обработка чипсетом трафика осуществляется попакетно и без деградации производительности.
Физически одна и та же Ingress/Egress TCAM в свою очередь делится логически на несколько сегментов (зависит от количества самой памяти и платформы), так называемые “ACL slices”. К примеру, тоже самое происходит с физически одним и тем же HDD на вашем ноутбуке, когда вы создаете на нём несколько логических дисков – С:\>, D:\>. Каждый ACL-slice в свою очередь состоит из ячеек памяти, в виде “строк” куда и записываються “rules” (правила/бит-маски).
Разбивка TCAM на ACL-slices имеет под собой определенную логику. В каждом из отдельных ACL-slice могут быть записаны только совместимые между собой “rules”. Если какой-то из “rules” не совместим с предыдущим, то он будет записан в следующий по порядку ACL-slice, в независимости от того сколько свободных строк под “rules” осталось в предыдущем.
Откуда же тогда возникает эта совместимость или несовместимость ACL rules? Дело в том, что одна “строка” TCAM, куда записывается “rules”, имеет длину 232 bit и делится на несколько полей – Fixed, Field1, Field2, Field3. 232 bit или 29 byte TCAM памяти вполне достаточно чтобы записать bit-mask определенного MAC или IP адреса, но сильно меньше, чем полный заголовок Ethernet пакета. В каждом отдельном ACL-slice ASIC производит независимый lookup по установленным в F1-F3 bit-mask. В целом же этот lookup может производиться по первым 128 bytes Ethernet заголовка. Собственно, именно из-за того, что поиск может производиться по 128 bytes, а записано может быть только 29 bytes, для правильного lookup должно быть выставлено смещение (offset) относительно начала пакета. Offset для каждого из ACL-slice выставляется во время записи в него первого правила, и если при записи последующего правила обнаруживается необходимость в другом offset, то такое правило считается несовместимым с первым и записывается в следующий ACL-slice.
В табличке ниже приведён порядок совместимости условий прописываемых в ACL. Каждая отдельная строка содержит совместимые между собой, и не совместимые с другими строками формируемые bit-mask.
Каждый отдельный пакет обрабатываемый ASIC запускает параллельный lookup в каждом ACL-slice. Проверка производится до первого совпадения в ACL-slice, но при этом допускается множественное совпадение для одного и того же пакета в разных ACL-slice. У каждого отдельного “rule” есть соответствующее действие, которое нужно выполнить в случае совпадения условия (bit-mask). Если совпадение произошло сразу в нескольких ACL-slices, то в блоке “Action Conflict Resolution” на основании приоритета ACL-slice принимается решение какое из действий выполнить. Если в ACL прописано и “action” (permit/deny), и “action-modifier” (count/QoS/log/…), то при множественных совпадениях будет выполнено только более приоритетное “action”, “action-modifier” же будут выполнены все. На примере ниже показано, что будут увеличены оба счетчика и выполнено более приоритетное “deny”.
“ACL Solutions Guide” с более детальной информацией о работе ACL в открытом доступе на сайте extremenetworks.com. Любые возникшие или оставшиеся вопросы всегда можно задать сотрудникам нашего офиса – cis@extremenetworks.com.