Детайли за ACL комутаторите

ACL (Access Control List) на мрежови устройства могат да бъдат реализирани както на хардуерно, така и на софтуерно ниво, или по-разбираемо казано, на базата на hardware и software. И ако за 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 е проста битова маска, записана в тази памет. Именно затова обработката на трафика от чипсета се извършва пакетно и без деградация на производителността.

Физически същата Ingress/Egress TCAM, от своя страна, логически се дели на няколко сегмента (зависи от количеството на самата памет и платформата), наречени “ACL slices”. Например, същото става и с физически един и същ HDD на вашия лаптоп, когато създавате няколко логически диска – C:>, D:>. Всеки ACL-slice от своя страна се състои от клетки памет, в форма на “редове”, където се записват “правилата” (rules/битови маски).

Разделянето на TCAM на ACL-slices има определена логика. Във всеки от отделните ACL-slice могат да бъдат записани само съвместими помежду си “правила”. Ако някое от “правилата” не е съвместимо с предходното, то ще бъде записано в следващия по ред ACL-slice, независимо от това колко свободни реда остават за “правила” в предишния.

Откъде произтича съвместимостта или несъвместимостта на ACL правилата? Факт е, че една "строка" TCAM, където се записват "правила", има дължина 232 бита и се разделя на няколко полета – Fixed, Field1, Field2, Field3. 232 бита или 29 байта TCAM памет са напълно достатъчни, за да запишат битова маска на определен MAC или IP адрес, но са значително по-малко от целия заглавен файл на Ethernet пакета. Във всеки отделен ACL-срез ASIC извършва независимо търсене по установените в F1-F3 битови маски. В общи линии това търсене може да се извършва по първите 128 байта на Ethernet заглавието. Всъщност, именно поради факта, че търсенето може да се извършва по 128 байта, а записаното може да бъде само 29 байта, за правилно търсене трябва да бъде зададена преместване (offset) относно началото на пакета. Offset за всеки от ACL-срезовете се задава по време на записването на неговото първо правило, и ако при записването на следващото правило се открие необходимост от друг offset, тогава такова правило се счита за несъвместимо с първото и се записва в следващия ACL-срез.

В таблицата по-долу е показан редът на съвместимост на условията, записвани в ACL. Всяка отделна редица съдържа съвместими помежду си и несъвместими с други редове формирани битови маски.

Всеки пакет, обработван от ASIC, стартира паралелно търсене в всеки ACL-срез. Проверка се извършва до първото съвпадение в ACL-среза, но е допустимо множество съвпадения за един и същи пакет в различни ACL-срезове. Всеки отделен "правило" има съответно действие, което трябва да бъде извършено в случай на съвпадение на условията (битова маска). Ако съвпадение стане веднага в няколко ACL-среза, то в блока "Action Conflict Resolution" на основание приоритета на ACL-среза се взема решение кое действие да бъде извършено. Ако в ACL е записано и "действие" (разреши/откажи), и "модификатор на действието" (броене/QoS/лог/... ), то при множество съвпадения ще бъде извършено само по-приоритетното "действие", "модификаторът на действието" обаче ще бъдат изпълнени всички. В примера по-долу е показано, че и двете счетоводства ще бъдат увеличени и ще бъде изпълнено по-приоритетното "отказ".

"Ръководство за решения на ACL" с по-подробна информация за работата на ACL в свободен достъп на сайта extremenetworks.com. Винаги можете да зададете възникнали или оставени въпроси на служителите на нашия офис – cis@extremenetworks.com.

Източник: habr.com