CEF (часть 2)

Продолжаем обсуждать внутреннюю архитектуру устройств Cisco. Ну и на самом деле многих других роутеров и свечей. У них внутри устройства будет так или иначе у всех более-менее похоже, потому что на центральном процессоре обработать IP или Ethernet коммутацию не представляется возможным на сколько-нибудь серьезной скорости. А если вы хотите выпрыгнуть там за пределы скорости, например, в 1 гигабит, то фактически вы обязаны использовать аппаратное ускорение, и как следствие вы будете в обязательном порядке использовать какие-то ухищрения. Как сделать так, чтобы у нас не просто была какая-то табличка, в которой мы периодически смотрели, а чтобы эта табличка была оптимизирована и правильно устроена внутри. И вот так получается, что здесь, хотя много разных производителей делают сетевое железо, внутри у них получается все одно и то же, потому что эту задачу наиболее эффективно решать вполне определенным образом. И для того, чтобы эффективно решать задачи маршрутизации и коммутации Ethernet,

маршрутизация IP, я имею в виду и коммутации Ethernet, удобно использовать память, которая имеет архитектуру TECAM. Это память, которая может хранить, ну или, скажем, делать вид, что хранить значение 0, 1 и что-нибудь еще. То есть она поэтому называется троичная память. И, соответственно, в этой памяти можете задать вопрос. Я тебе даю на вход некий образец. Скажи мне, пожалуйста, совпадает ли он с каким-нибудь значением в твоей табличке или не совпадает? Если совпадает, то дай мне результат. И вот то, что вот это самое троичное значение, которое хранится в TECAM, оно выступает ключом. По этому ключу можно искать какое-то содержимое. И вот эти вот памяти TECAM, ее на устройствах, как правило, не очень много, потому что она сложная, дорогая. И если есть возможность не делать ее много на железке, то, конечно же, имеет смысл этого не делать. То есть зачем на устройстве, на котором эта память эффективно не будет эксплуатироваться, делать много такой памяти?

Незачем. Вот так или иначе, на всех маршрутизаторах, на всех коммутаторах эта самая память будет. То есть будет ли эта штука называться Cisco Express Forwarding или какой-нибудь другой. Внутри у любой железки, так или иначе, организовано все это дело будет примерно вот таким образом. На самом деле она называется, конечно, троичная. Это потому, что она себя ведет как троичная память. Внутри она, тем не менее, все логические элементы будет использовать обычные двоичные. То есть вы можете, ну, фактически, да, хранить, если вам нужно там вот IP-адреса хранить, вы можете отдельно хранить эталонный IP-шник и маску, и дальше просто операция двоичного умножения вам будет давать эффект этой самой троичной памяти. Так что если говорить про, скажем, законы физики, да, их никто не отменял, там все равно в ячейках памяти используются те самые нолики-единички, просто организована эта память так, чтобы создавалось впечатление, что она хранит троичные значения. Поэтому вы, в принципе, можете использовать для этой памяти обычную оперативку.

Вам никто это не мешает сделать, и на младших, например, тех же самых цисках там нет никакой прямо специальной, прямо отдельной памяти, которая выделяется под ткам. Это просто кусок оперативки, которой вы говорите, давайте под оперативку, в смысле, под, допустим, нужды цефа выделим вот этот вот кусок оперативной памяти, у нас ее там типа много, и вы можете на роутер взять и добавить лишнюю планку памяти, и у вас под хранение маршрутов, там под хранение всего, чего только можно, будет выделяться больше места. Ну, естественно, это софтовая, как бы, эмуляция ткама, и если вы возьмете контроллер, который прям по-честному будет реализовывать задачу хранения вот этих самых трех троичных элементов, то делать это все будет намного быстрее. Если говорить про аппаратные роутеры, аппаратные свечи, которые оперируют очень большими объемами трафика, то там именно прям специальная отдельная память, она тоже двоичная на самом деле внутри, но контроллер, который реализует задачу, вот представление, как будто эта память троичная,

вот в нем, собственно, вся магия и хранится. Если говорить про свечи ЦИСКа, то, соответственно, я уже говорил, что традиционные, скажем, учебники говорят, что есть память CAM, а есть память T-CAM, и память CAM используется для таблиц коммутации, а память T-CAM для таблиц маршрутизации, для киосов, вот. На самом деле это все фигня. На современных ЦИСКах используется только память T-CAM, то есть если у вас есть свеч, вот, например, на картинке показан 3750-й свеч, у него этой памяти T-CAM ограниченное количество, и вы можете распределять, в каком объеме вы эту память отдаете под какие задачи. Вы можете сказать, что у вас этот свеч чистый L2, соответственно, вам нужно побольше MAC-адресов в нем хранить, то есть побольше прикидываться, что это только чистая CAM память, и вам, в принципе, там киосовских аксесс-листов, обычных аксесс-листов security, маршрутов, ну, то есть тех механизмов, которые используют T-CAM память, особо много не нужно. В этом случае вы можете сказать, давайте вот мы перераспределим ее в пользу таблицы коммутации,

в пользу таблицы MAC-адресов Unicast-овых. Если вы говорите, что у вас 3750-й свеч будет больше решать задачи маршрутизации, вы на него хотите пригнать много маршрутов, а вот таблицы MAC-адресов, у него не будет много MAC-ов, поэтому большую таблицу держать незачем, памяти много под MAC-и выделять незачем, то вы можете, опять же, перераспределить эту память в сторону увеличения таблицы маршрутизации за счет уменьшения таблицы коммутации. Вы не можете назначать, сколько именно памяти пойдет на каждый конкретный механизм. Вам в младших линейках, в частности в 3650-х, в 3750-х, в 3560-х, в 3750-х свечах доступна такая штука, которая называется SDM-темплейтс. Это шаблоны SDM Switch Database Manager. Не путайте, пожалуйста, это с Security Device Manager, которая гуевая такая Java-приблуда для управления цисками, старая, предшественник Cisco Configuration Professional,

и дальний родственник ASDM, который для ASA используется, Cisco ASA. Вот это SDM-шаблоны, фактически возможны варианты распределения этой самой специальной памяти по разным механизмам. Вы можете сказать, что вас интересует либо один вариант шаблона, где больше памяти под одни механизмы, меньше под другие, либо другой вариант шаблона, где больше под другие, меньше под первые. Но, соответственно, вы не можете сказать, что не хочется под таблицу MAC-адресов выдать 12 345 байт. Вы можете только выбрать один из нескольких вариантов этого самого шаблона. И вот здесь в табличке показаны как раз три варианта шаблона Default, Routing и VLAN. В случае, если вы выбираете шаблон Default, это вариант, скажем, разметки памяти TKAM, форматирования памяти TKAM, таким образом, чтобы там подо все, в принципе, чуть-чуть было отведено памяти. Там 6000 MAC-адресов можно в ней хранить в таблице, 1000 мультикастовых маршрутов и IGMP-шных групп,

которые вы можете подслушивать, 8000 маршрутов юникастовых, причем не любых, а вполне определенных. Если вы храните маршруты до хостов, которые прямо с вами в одной таблице находятся, вы помните, да, в цехе это считается отдельная строчка, когда вы говорите, что у вас есть сетка, коннекты там 122, 168, 0, 0, 24, и у вас есть сосед в этой сети, это считается как отдельная строчка в цехе, отдельная строчка, отдельный маршрут. Поэтому вот Directly Connected Hosts, это как бы считается отдельный маршрут, и вы этих хостов можете хранить 6000 штук, соседей, которые с вами в одной сети находятся. И Indirect Roots, это как раз обычные маршруты в таблице маршрутизации, которые помечаются отдельной строчкой. Вот, так что на самом деле он пишет 8К, но на самом деле маршрутов в таблице маршрутизации больше 2000 при дефолтном шаблоне вы поместить не сможете. Policy Based Rooting не предполагает, что у вас вообще будет выделяться место под него в цехе.

Соответственно, если вы используете шаблон дефолт, то PBR у вас либо не будет работать вообще, либо будет работать целиком на процессоре. И производительность его при этом, конечно, будет крайне низкой. Quality of Service, Access Listы, то есть если вы будете включать Quality of Service, там можно будет сделать 512 записей, что достаточно для очень простенького реализации Quality of Service. Ну, обычно в предприятии много этих механизмов и не требуется. То есть вам редко приходится на свечах, типа вот 35, 60, 37, 50 линеек, делать много разных классификаторов, говорить, что вот этот трафик относится к одному классу, к другому, этот к третьему, этот к 50, этот к сотому. Вот, в принципе, 512 записей хватает в большинстве случаев подо все. Ну и некоторое количество Access Listов вы можете наплодить, то есть в частности, 1 тысяча строчек Access List. Каждая строчка – это вот ACE, Access Control Entry, это строка Access List. Если мы делаем Access List, он может состоять из нескольких строк.

Вот каждая строчка – это ACE. И в базе VLAN-ов вы можете разместить до 1 тысячи VLAN-ов. Вот. Если вы при этом говорите, что вот, да, замечательно, у нас 6 тысяч маков можно хранить в дефолтном шаблоне, но столько у меня в сети нету. У меня сеть на 24, там, слышишь, 24, на 256 хостов. Все они в одном VLAN-е, все они в таблице MAC-ADRSO будут иметь только одну запись. Ну, то есть у меня в реальности в сети там 250, ну, 300 маков. Мне 6 тысяч их хранить не обязательно. В этом случае вы можете переключить ваш шаблон SDM в шаблон Routing и получить меньше MAC-адресов в таблице. То есть максимум там получится 3 тысячи MAC-ов. Но зато у вас увеличится количество маршрутов на достаточно большое количество. То есть 3 тысячи Directly Connected Hosts и 8 тысяч Indirect Roots – это вот 8 тысяч маршрутов в таблице маршрутизации – вы сможете получить. Плюс там Policy Based Routing включается,

то есть под PBR немножко памяти начинает отводиться. Если вы включаете шаблон Routing, это предполагает, что у вас L2-сеть небольшая, что количество хостов у вас в одной сети будет маленькое, в VLAN-ов много не будет, но, соответственно, у вас включаются механизмы, которые полезны при маршрутизации. Это большая таблица маршрутизации, в кавычках большая. Она в 4 раза больше, чем при шаблон Default. Она не очень большая в абсолютном выражении. 8 тысяч маршрутов – это так, куром на смех, например, по сравнению с интернетом. Вы не можете на свечи 3750 пригнать FullView из интернета. Но, тем не менее, в сети предприятия это вполне нормальное количество маршрутов. Ну и, да, под PBR у вас включается отведение памяти ТК. ПБР у вас начинает работать с аппаратным ускорением. Если вы скажете, что у вас, напротив, сеть большая, и вы в 6 тысяч, например, маков не укладываетесь, потому что у вас везде L2, вы везде транками соединяетесь между свечами,

у вас везде там Spanning 3 бегает, в этом случае вам не нужно на свечах много маршрутов, в таблице маршрутизации. Вам нужно как раз много маков, вам нужно много VLAN-ов в базе, вам не нужны маршруты, вам не нужно большое количество хостов в таблице ARP, в таблице adjacency CF. Вот в этой ситуации, если вы используете шаблон VLAN, у вас фактически вся память начинает отъедаться под таблицу марк-адресов за счет всего, что связано с маршрутизацией. То есть память у вас в любом случае ограниченное количество, это самое ТКам, но вы можете ее раздать по разным механизмам, разными способами. Сказать, что вас интересует либо побольше памяти отдать под одно, поменьше под другое, либо наоборот. В любом случае, если вы используете на 3750 или 3560 линейке шаблоны, вот эти вот самые default, которые, как ни странно, используются по умолчанию, либо раутинг, либо VLAN,

вы не получаете ничего, ни единого байта этой самой ТКам под IPv6. То есть если вы хотите включить IPv6 на 3750 линейке, вы должны будете использовать другие шаблоны. И, соответственно, там сейчас на следующем слайде, если мне память не изменяет, будет как раз список этих шаблонов. Переключаются они в глобальном конфиге команды SDM, prefer, и дальше вы указываете, какой шаблон вас интересует. Есть шаблоны access routing default VLAN, и распределение у них примерно вот такое вот по различным механизмам. То есть в случае с access вы получаете всего по чуть-чуть и маршрутов средние, и маков средние. В случае с default вы получаете поменьше маршрутов, побольше маков. В случае с раутингом поменьше маков, побольше маршрутов. В случае с VLAN вы получаете чисто L2 switch, который не может ничего толком делать с маршрутизацией. А там вся маршрутизация выполняется на процессоре.

Этого достаточно для того, чтобы, например, решить задачу подключения к удаленному устройству по телонету, но пользовательский трафик, конечно, так маршрутизировать нельзя. Если вы хотите включить IPv6, у вас будут шаблоны, которые начинаются со слов dual IPv4 and IPv6. И там тоже три варианта. Default, раутинг и VLAN. Естественно, что IPv6, что адреса, что маршруты, что записи в access control entry, они намного больше по размеру. То есть там, где IPv4, IPv6 занимает 4 байта, IPv6, IPv6 занимает 16 байта. Поэтому если у вас есть условно там 1 мегабайт оперативки на все, и вы начинаете говорить, давайте мы повключаем IPv4 маршруты и IPv6, то тогда у вас количество возможных записей в этой памяти, которые могут хранить в себе IPv6 адреса, оно будет, конечно, сильно меньше. Если вы указываете dual IPv4 and IPv6 default, то есть такой шаблон, который ни нашим, ни вашим, он позволяет хранить 2000 MAC адресов,

1000 маршрутов IPv4 и 1000 маршрутов IPv6. То есть это маршруты, которые вполне могут встретиться в сети предприятия. Ну, в принципе, да, такой неплохой вариант, если вы заранее не знаете, сколько у вас маршрутов будет. Если вы хотите побольше маршрутов, то вот сильно много этих маршрутов вы в любом случае не получите, потому что если у вас есть и IPv4, и IPv6, а чаще всего так и бывает, вот вы больше чем 1000, там, полторы тысячи маршрутов в принципе не сможете хранить в этой памяти, потому что просто места тупо не хватает. И вот самый жирный в части выделения под маршруты IPv6 шаблон, это Dual IPv4 и IPv6 routing, он по тысячу с четвертью маршрутов IPv4, тысяча с четвертью маршрутов IPv6, причем, если мне память не изменяет, там хреново тучи connected маршрутов из них считается, вот этих самых connected хостов,

и полторы тысячи записей в таблице MAC адресов. Ну то есть, если вы вдруг думаете, что свечи, на которых можно включить маршрутизацию, это неплохие маршрутизаторы, да, они неплохие маршрутизаторы, но имейте в виду, что много записей в CEF им запихнуть не получится. Если вы захотите, вы можете использовать шаблон Dual IPv4 и IPv6 в VLAN, тогда будет 8000 записей в таблице MAC адресов, и можно будет IPv6 адреса повесить на саму железку. То есть маршрутизировать-то она не сможет, ну вот у нее будут, по крайней мере, свои, эти самые, свои IPv6 адреса, можно будет сделать некоторое количество IPv6 аксесс-листов, закрыться ими вот, а так, каких-то снаружи, ну вот, да. В любом случае вы получаете доступ к памяти за счет того, что вы где-то память отъедаете под нужды других механизмов. Хотите включить IPv6, вы ограбите все, что только можно,

и можете максимум там 1250 маршрутов получить в таблице Takama. Вот, это пример в 3560 V2 свече, древний-древний свеч, но на экзамене, возможно, у вас все спросит вот эту вот команду sdm-prefer, и про шаблоны будут тоже спрашивать. Вам она потребуется только в случае, если вы захотите в реальности, да, включить маршрутизацию на IPv6 на свечах, и вам она понадобится, если у вас вот старые свечи, на новых свечах, скорее всего, она уже будет не сильно нужна. Равно она не будет нужна, если у вас много свечей прям дорогих. Вы можете посмотреть, как у вас сейчас распределяются записи в Takama, то есть по каким механизмам, сколько памяти будет роздано. И вот здесь показывается show sdm-prefer, команда, которая показывает текущие свойства выбранного шаблона. Вот в нашем случае, да, show sdm-prefer показывает,

что сейчас выбран шаблон на свече desktop IPv4 на IPv6, и, соответственно, вот если у вас маршрутизация IPv4 и IPv6 используется, то вот такое вот количество записей каждого типа вы можете создать в Takama. Видно, да, что здесь есть indirect routes, вот эти вот 1250 маршрутов. Вот больше, чем вот это число, вы в таблицу маршрутизации запихнуть не сможете. А если попытаетесь запихнуть еще хотя бы один маршрут, 1251, то у вас все это дело вместо CEF будет вкладываться в обычную оперативку. И в обычной оперативке он либо утечет по количеству оперативки и будет kernel panic, либо, если даже он не утечет, то у вас просто весь трафик, который будет, будет CEF обрабатываться, не CEF, а будет процессором обрабатываться, процессор упадет в 100% нагрузку, и, ну, да, железка перестанет толком работать. Поэтому, пожалуйста, не пытайтесь превзойти вот эти вот значения. Даже если вдруг это получится сделать

в каком-то гипотетическом сценарии, скорее всего, железка будет работать очень сильно некорректно, если на ней, ну, вот, какие-то механизмы будут задействовать большее количество записей, чем железка может предоставить. Вот. Дальше. Ага-ха-ха-ха. Вы можете посмотреть, как TECAM распределяется по факту. То есть одно дело, сколько максимум можно сделать записей, другое дело, сколько вот по факту эксплуатируется. Есть команда showplatform.tacamutilization. Она покажет, вот как по факту сейчас, прямо в настоящий момент, какое количество записей используется для хранения актуальной информации. И вот здесь showplatform.tacamutilization показывает, что у нас есть, собственно говоря, да, железка, на которой можно создать некоторое количество маршрутов IPv4, можно некоторое количество IPv6 маршрутов создать. И показывается,

что вот у нас есть, например, где у нас тут, IPv6, Unicast Indirectly Connected Roots, 2000 записей, это максимальное количество маршрутов, которые можно запихать в таблицу маршрутизации IPv6. И вот по факту, да, мы 2096 различных вариантов можем напихать в этот самый CEF, но по факту напихали только 262. Это включая служебные записи, которые там могут появляться. Поэтому, когда пишут там 1250 максимум, вот это вот 2096, это с учетом служебных маршрутов, которые не показываются в 1250. в устах 50. И вот здесь показано, что 262 из них мы уже сожрали. Вы, да, вы можете, если вы понимаете, что у вас на устройстве не хватает, допустим, памяти под хранение IPv4 маршрутов или под IPv6 маршрута не хватает, вы можете взять и переключить шаблон. Но, опять же, надо понимать, что вы это делаете

за счет какого-то другого механизма. Если у вас видно, что во всех этих самых строчках достаточно большие цифры будут приведены, что здесь там, допустим, Unicast-овый MAC-адреса, максимальное значение 4000, а вы видите там, ну, например, 3000 или 2000. Вот вы понимаете, да, что эту память уже грабить дальше бессмысленно, что Unicast-овая таблица у вас записана по максимуму. Или там то же самое с аксесс-листами. Вот. Далее. У вас в большинстве случаев, как уже говорилось, используется специальный контроллер, который берет обычную двоичную память и делает из нее в кавычках троичную. Делает он это за счет того, что хранятся пары IP-шник и маска. И вот здесь показывается маскс и валюс. Вот валюс это индивидуальное значение, какое там у нас может быть

IP-шник, например, в таблице марштизации, а маска это вот как раз варианты расположения тех битиков, которые не нолика, не единичка, которые битики я не знаю. И эти значения хранятся отдельно. И можно повторно в некоторых случаях будет эксплуатировать возможные маски, то есть если у вас используется там сетка 112.168.1.0 по 24 маски, 112.168.2.0 по 24 маске, то по факту вполне возможно, что эти две строчки будут разделять значения маски. У них вот эта вот маска слэш 24 возможно будет храниться одна внутри таблицы масок. И, соответственно, ограничение на количество масок сверху тоже есть. Оно занимает отдельную строчку в специализированной отдельной табличке с масками. И вот здесь максимальные цифры, которые есть, там 262 slash 2096. Вот 2096 это сколько значений по факту может влезть в количество

маршрутов, а 262 это количество масок, которые мы можем впихать туда. и вот в нашем случае мы видим, что возможных вариантов IPv6 масок, да, у нас не так много может быть, но 262 скорее всего с запасом нам хватит. Потому что если у нас slash 128 сетка будет, вот можно сделать slash 1, slash 2, slash 3, slash 4, slash 5 и так далее до slash 128. Поэтому 262 возможных варианта, ну да, нормальное количество. В IPv4 все интереснее, потому что в IPv4 мы можем делать access-листы с кривыми wildcard масками, и там можно будет встретить какие-то вот для IPv4 unicast маршруты, вот здесь 5, 4, 4 возможных вариантов маски. Это тяжелое наследие старых времен, когда RFC 950 предполагал, что вы можете хранить сети с кривыми масками, где единички, нолики чертовались между собой. Ну и для access-листов

это сегодня тоже можно будет встретить в некоторых случаях. Поэтому вот, да, здесь не пугайтесь, если вы видите, что масок у вас сильно больше, чем возможные варианты разумных значений этих самых масок. Да, Cisco умеет работать с масками сильно кривыми. Так, да, Techamps физически состоит из кусков двоичной памяти, они будут называться VMR, Value Mask Result, то есть у вас будет отдельно храниться самый эталонный эталонный IPшник, эталонный MAC, который будет являться ключом, маска, это будет указание на маску эталона, и result это то, что вы будете хранить с ключом в виде IPшника или MAC, или чего-то там еще. То есть, вы как знаете, бывает в протоколах связи TLV, Type Lens Value, здесь вот VMR, Value Mask Result. Вы указываете, соответственно, если у нас IPшник совпадает

с неким эталоном по какой-то маске, то вернуть из памяти значение результата. Result это какой-то результат, который может быть непредсказуемого размера, но зависит он от конкретного типа того, что вы храните, а вот Value и Mask, они всегда одинакового размера, то есть, независимо от того, что вы будете хранить, можно хранить IPшники, IPv4, IPv6, Mac, у вас всегда вот эти вот самые VMR, они будут одинакового размера. Value будет 134 бита и Mask тоже будет 134 бита. Соответственно, если вы используете хранение, допустим, MAC адресов, у вас, в принципе, вот эта вот одна ячейка VMR будет использоваться для как это сказать, для запроса либо одного IPшника или одного MAC-адреса, или вы можете сразу два IPшника и два MAC-адреса

запихивать в один результат, вы говорите, ко мне пришел пакет с вот таким IPшником источника, с вот таким IPшником результата, есть ли у меня куда его девать. и соответственно, учитывая, что там в IPv4 пакете у нас IPшники IPv4 будут 32 бита каждый, то соответственно 64 бита будут выделяться под IPшники, плюс еще 1 байт 8 бит будет выделяться под полепротокол, плюс еще там всякие разные другие штуки есть, которые можно сравнивать, там номера портов. Вот в итоге вы можете просто брать и первые 134 бита заполнять той информацией, которая вас интересует, это IPшники, поле протокола, номера портов и сразу в одной пачке VMR выдавать результат, что с пакетами с таким содержимым нужно будет делать. То есть вот 134 бита это как раз размер VMR, который предназначался для работы с IPv4 пакетами. Естественно, что для IPv6 эти штуки уже не очень хорошо подходят,

потому что в IPv6 у нас размер пардон, в IPv6 у нас размер одного адреса 128 бит. Поэтому если вы храните, например, аксесс-листы IPv6, то у вас на одну строчку в аксесс-листе будет отводиться несколько физических вот этих ячеек VMR. Потому что IPшник надо будет источника, IPшник получателя, поле протокола, то есть как минимум три этих самых VMR будут отводиться под одну запись в аксесс-контрол-энтри. Так, перескочила. Для сравнения по номерам портов у вас будут использоваться еще ячейки другого типа, которые называются Logical Operations Unit. Это штука, которая будет полезна для сравнения больше-меньше. То есть, например, вы в ЦИСКе можете сказать, что нас интересует аксесс-контрол-лист, который говорит, что если трафик идет из-под

номера порта в диапазоне от 1024 до 2048, то делаем то. Пермит там ледяная. Вот, соответственно, вот эти вот эталонные сравнения, они будут храниться в отдельной ячейке, в отдельной табличке, табличка Low, и, соответственно, там они будут чаще всего использоваться повторно. Если вы будете делать аксесс-лист, который содержит много-много-много разных отсылок к номерам портов, вот эти вот самые EQ, NE, GT, LT, Range, то вы не должны будете делать много разных записей с очень сильно разными номерами портов. Потому что, если вы говорите, что давайте мы сравним там, не сравним, а давайте мы сделаем строчку Permit IP-шник такой-то там с номером порта таким-то, то вот это вот с номером порта таким-то хранится в отдельной ячейке. Если вы потом сделаете еще одну запись с номером порта тем же самым, он эту ячейку переиспользует, он не будет ее, не будет новую создавать ячейку с тем же содержимым. Однако, если вы делаете

много записей с разными оперантами с портами, то, соответственно, у вас все вот эти вот ячейки low будут очень быстро расходоваться. И вполне возможно, что они у вас закончатся. И у вас как бы место в access control entry, вот эти самые ACE, security ACE, которые в таком выделяются, может еще быть, а вот место в табличке low может уже закончиться. Поэтому вы можете теперь, зная примерно, как устроены вот этого самая токам, предположить, что если вы делаете access control листы, повторно нужно как можно больше использовать одних и тех же, одни и те же операнты при работе с портами. Потому что, если вы будете делать много и разных сравнений, то, соответственно, у вас эта штука может просто не скомпилироваться и в память CEF'а не уложиться.