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 на вашия лаптоп, когато създавате на него няколко логически диска – C:>, D:>. Всеки ACL-slice от своя страна се състои от клетки памет, във вид на 'строки', където се записват 'rules' (правила/битови маски).
Разбивката на TCAM на ACL-slices има своя логика. Във всеки от отделните ACL-slice могат да бъдат записани само съвместими помежду си 'rules'. Ако някое от 'rules' не е съвместимо с предходното, то ще бъде записано в следващия по ред ACL-slice, независимо от това колко свободни редове под 'rules' са останали в предходния.
Откъде произлиза тази съвместимост или несъвместимост на ACL правилата? Факт е, че единствената "строка" TCAM, в която се записват "правила", има дължина 232 бита и се дели на няколко полета - Fixed, Field1, Field2, Field3. 232 бита или 29 байта TCAM памет са напълно достатъчни, за да запишат битова маска на определен MAC или IP адрес, но значително по-малко от пълния заглавен пакет на Ethernet. Във всеки отделен ACL-срез ASIC извършва независим търсене по установените в F1-F3 битови маски. Общо търсенето може да се извършва по първите 128 байта на заглавния пакет Ethernet. Всъщност, именно поради факта, че търсенето може да се извършва по 128 байта, а записаното може да бъде само 29 байта, за правилно търсене трябва да бъде зададено изместване (offset) спрямо началото на пакета. Изместването за всеки от ACL-срезовете се задава по време на записването на първото правило и ако при записването на последващото правило се открие необходимост от друго изместване, то такова правило се счита за несъвместимо с първото и се записва в следващия ACL-срез.
В таблицата по-долу е показан редът на съвместимост на условията, записвани в ACL. Всяка отделна строка съдържа съвместими помежду си и несъвместими с други строки образувани битови маски.
Всеки отделен пакет, обработван от ASIC, стартира паралелно търсене във всеки ACL-срез. Проверка се извършва до първото съвпадение в ACL-среза, но е допустимо многократно съвпадение за един и същи пакет в различни ACL-срезове. Всеки отделен "правило" има съответстващо действие, което трябва да се изпълни в случай на съвпадение на условията (битова маска). Ако съвпадението настъпи веднага в няколко ACL-среза, тогава в блока "Action Conflict Resolution" на базата на приоритета на ACL-среза се взема решение кое от действията да се изпълни. Ако в ACL е записано и "действие" (permit/deny), и "действие-модификатор" (count/QoS/log/…), то при многократни съвпадения ще се изпълни само по-приоритетното "действие", "действие-модификатор" обаче ще бъдат изпълнени всички. В примера по-долу е показано, че ще бъдат увеличени и двата брояча и ще бъде изпълнено по-приоритетното "deny".
с по-подробна информация за работата на ACL, достъпна на сайта . Винаги можете да зададете въпроси на служителите на нашия офис – .
Източник: habr.com
