Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 22
Слово «лист» — это проф.жаргон в данной предметной области, или от незнания общеупотребительного русского слова «список»?
Даже если жаргон, то термин очень неудачный, т.к. вносит двусмысленность:
— конечный узел дерева (leaf)
— список (list)
— страница (sheet)
Тем более, ACL уже имеет традиционный перевод «список контроля доступа»
Даже если жаргон, то термин очень неудачный, т.к. вносит двусмысленность:
— конечный узел дерева (leaf)
— список (list)
— страница (sheet)
Тем более, ACL уже имеет традиционный перевод «список контроля доступа»
Согласен, исправил
Спасибо за поправку)
Спасибо за поправку)
Вот блин) за заголовок вообще забыл, поспешишь — людей насмешишь)
Еще раз спасибо)
Еще раз спасибо)
А я вот противник перевода терминологии и сторонник ее транслитерации в случае необходимости. Лучше уж «Префикс-листы как метод управления процессом обмена маршрутными обновлениями» (да, запятая тоже была там явно лишняя). «Списком префиксов» может быть и указанный ниже хак с ACLями, а вот «префикс-листом» он быть не может.
Меня как-то поставило в тупик упоминание кем-то «протокола связующего дерева». Я секунд 5 думал, что он знает что-то, чего не знаю я, потом дошло :) Осталось еще перевести OSPF как «открытый кратчайший путь первым» (от «Open SPF», изначального происхождения названия), и приплыли…
Меня как-то поставило в тупик упоминание кем-то «протокола связующего дерева». Я секунд 5 думал, что он знает что-то, чего не знаю я, потом дошло :) Осталось еще перевести OSPF как «открытый кратчайший путь первым» (от «Open SPF», изначального происхождения названия), и приплыли…
По поводу перевода вопрос философский, мне нравится, да и кажется более правильным, называть все адекватными русскоязычными терминами… ровно до тех пор пока не натыкаюсь на что, что не обладает полным и всеобъемлющим русским аналогом.
и тут сталкиваются два предпочтения — использовать русскоязычную терминологию, и описывать все однотипным образом)
И запятая мне в заголовке нравится, стоит себе на своем месте как по мне.
Для невозможности разночтения, возможно, следует добавлять соответствующий английский термин, скажем так: «Списки префиксов (prefix-list) ...»
и тут сталкиваются два предпочтения — использовать русскоязычную терминологию, и описывать все однотипным образом)
И запятая мне в заголовке нравится, стоит себе на своем месте как по мне.
Для невозможности разночтения, возможно, следует добавлять соответствующий английский термин, скажем так: «Списки префиксов (prefix-list) ...»
По поводу перевода вопрос философский
«John Smith» => «Иван Кузнецов». Вроде не очень философский вопрос — при совке так изредка делали, но сейчас уже нет.
По мне, переводить конкретный термин «prefix-list», обозначающий совершенно конкретную сущность внутри конкретного списка операционок, не менее нелепо. Но как хотите.
И запятая мне в заголовке нравится, стоит себе на своем месте как по мне.
И вот я впервые за много лет вынужден открыть справочник и посмотреть правила, которых я вообще не знаю :)
www.gramota.ru/class/coach/punct/45_183
Не обособляются обороты с союзом КАК в пяти случаях:
…
Если союз КАК стоит между подлежащим и сказуемым (без этого союза там требовалось бы поставить тире), например: Озеро как зеркало;
Невозможность определения совпадения маски маршрута
На что поспорим? Я говорю, что возможно (за совсем старые линейки IOS, в районе 10-11, не поручусь, но это можно было делать еще до появления понятия префикс-листов).
Значительное увеличение производительности по сравнению с ACL и просмотре больших списков записей. Маршрутизатор преобразует список префиксов в древовидную структуру, в которой каждая ветка дерева представляет собой определенное условие, что позволяет Cisco IOS определить необходимое действие, разрешение или запрет, значительно быстрее
Я знаю, что на уровне TCAM ACLи максимально оптимизируются весьма совершенными алгоритмами, и над созданием этих алгоритмов чесали затылки очень умные люди. И хотя тут TCAM не при делах — я уверен, что и в control plane операциях тоже используются оптимизации. Было бы глупо их не использовать.
Да и в конце концов, какой длины должны быть ACLи, чтобы хоть немного заметно влиять на скорость выполнения операций?
Поддержка инкрементных изменений. Стандартные нумерованные ACL, не поддерживают редактирование, в них одна команда no удаляет весь ACL.
R00(config)#access-list 2 permit 1.1.1.1
R00(config)#access-list 2 permit 1.1.1.2
R00(config)#do sh access-list 2
Standard IP access list 2
10 permit 1.1.1.1
20 permit 1.1.1.2
R00(config)#ip access-list standard 2
R00(config-std-nacl)#no 10
R00(config-std-nacl)#do sh access-list 2
Standard IP access list 2
20 permit 1.1.1.2Вы, простите, учебный центр и занимаетесь обучением людей, я правильно понимаю? :)
Хотя я нисколько не спорю с тем, что из «здесь можно использовать префикс-листы» следует «здесь необходимо использовать префикс-листы».
Так, по очереди важности)
Каюсь, но не знаю, но как с помощью ACL решить следующую задачу — есть два маршрута: 10.0.0.0/8 и 10.0.0.0/16, мне надо один из них отфильтровать так что бы он не был передан (соседу или другому протоколу через перерапределение) средствами ACL?
По поводу редактирования — без использования интерфейса редактирования именованных ACL — таки никак)
По производительности — думаю у провайдеров и ближе к магистрали списки могут быть приличные)
Но все это не так важно и фактически было для «полноты картины» взято из официальных материалов.
А вот первый вопрос весьма интересный. Есть подозрение что даже если и можно, то явно циска не планировала такой вариант использования ACL.
Каюсь, но не знаю, но как с помощью ACL решить следующую задачу — есть два маршрута: 10.0.0.0/8 и 10.0.0.0/16, мне надо один из них отфильтровать так что бы он не был передан (соседу или другому протоколу через перерапределение) средствами ACL?
По поводу редактирования — без использования интерфейса редактирования именованных ACL — таки никак)
По производительности — думаю у провайдеров и ближе к магистрали списки могут быть приличные)
Но все это не так важно и фактически было для «полноты картины» взято из официальных материалов.
А вот первый вопрос весьма интересный. Есть подозрение что даже если и можно, то явно циска не планировала такой вариант использования ACL.
Ага. Вопрос отпал.
Расширенные ACL работают не «как обычно» в связке с distribute-list.
Расширенные ACL работают не «как обычно» в связке с distribute-list.
без использования интерфейса редактирования именованных ACL — таки никак
Это был стандартный нумерованный ACL? Да. Можно ли редактировать его по одному ACE за раз? Определенно. Какие вопросы? :)
думаю у провайдеров и ближе к магистрали списки могут быть приличные)
Но я как-то все равно плохо представляю себе, где в control plane может быть сколь угодно заметный ущерб от длинных ACL (вариант с сотнями тысяч записей опустим, такая ситуация означает серьезные проблемы с архитектурой решения). Замеров на эту тему тоже не видел. А с data plane еще проще: если ACL влез в TCAM, то поиск в нем займет фиксированное количество времени, длина списка не имеет никакого значения, за то и любят TCAM. Ну это если мы рассматриваем платформы, у которых есть TCAM, а именно такие железки будут стоять «у провайдеров и ближе к магистрали».
Есть подозрение что даже если и можно, то явно циска не планировала такой вариант использования ACL.
Это делалось как раз в ответ на мат кастомеров по поводу «не могу отделить 10.0.0.0/8 от 10.0.0.0/16». Сделали такой хак. Дальше, через N лет, реализовали альтернативную структуру данных «префикс-лист», более удобную с точки зрения работы с префиксами.
Можно сказать что теперь я знаю как делать можно, но не нужно
Ну вот допустим вылезет мерзкий баг, связанный с обработкой префикс-листов. Вот один из возможных воркараундов в ожидании фикса.
Но все это не так важно и фактически было для «полноты картины» взято из официальных материалов.
Я нахожу немало вранья в «certification guide'ах», верить им надо с крайней осторожностью. И к документации на сайте надо относиться очень аккуратно. Мой любимый вопрос: скажите, в более-менее современных версиях IOS есть выигрыш в скорости обработки и потреблении памяти от использования peer-group'ов по сравнению с применением к пирам одинаковых роут-мапов?
Таким или таким книгам верить можно (их авторы действительно знают матчасть), но с поправкой на устаревание указанной там информации, т.е. опять можно наткнуться на не соответствующие современной реальности данные.
По поводу выигрыша, циско пишет что есть) во всяком случае с «BGP Dynamic Update Peer-Groups feature», который есть начиная с 12.0(24)S
Хотя реально не замерял. И почему-то мне кажется что если это ваш любимый вопрос, то очевидный на первый взгляд ответ не является верным, как минимум до конца)
Хотя реально не замерял. И почему-то мне кажется что если это ваш любимый вопрос, то очевидный на первый взгляд ответ не является верным, как минимум до конца)
циско пишет что есть) во всяком случае с «BGP Dynamic Update Peer-Groups feature», который есть начиная с 12.0(24)S
Вот вы умудрились дать неправильный ответ, указав совершенно верные ключевые слова, без которых правильный ответ не найти — я такое вижу впервые :)
(ну или я плохо сформулировал вопрос — я имел в виду статическую конфигурацию пир-группы, с применением политик именно к ней).
Нет, сейчас от статически сконфигурированных пир-групп нет ни малейшего профита помимо уменьшения длины конфига. Никакие ресурсы при обработке апдейтов не экономятся.
Однако, если вы откроете разные доки, вы везде найдете, что польза от конфигурирования пир-групп есть. Несмотря на то, что уже довольно давно процесс BGP умеет объединять пиров со схожими политиками в dynamic update-groups, добиваясь того же результата без всяких дополнительных требований к конфигурации.
Ну и заодно еще одна злобная придирка. Мне кажется, в вашей статье термины «маршрут» и «префикс» являются излишне взаимозаменяемыми, что несколько неправильно… Например: «В этом случае соседнему маршрутизатору будут передана только один маршрут: 172.16.0.0/16». Это не маршрут, а префикс :) Вот если сказать «В этом случае соседнему маршрутизатору будут передана только один маршрут: на 172.16.0.0/16», "… на сеть 172.16.0.0/16" или "… на префикс 172.16.0.0/16", то будет более корректно. «Сеть» и «префикс», кстати, тоже не всегда можно заменять друг на друга…
JDima, насколько просядет производительность если на входной интерфейс аплинка навесить ACL из 6 строк в котором 5 сетей /23 и в конце deny any? трафика примерно 5гб
либо это всё делается hardware и никак не повлияет? железо уровня cat65, gsr12k
либо это всё делается hardware и никак не повлияет? железо уровня cat65, gsr12k
Ну как я уже говорил, на хардварных платформах (cat6500, GSR) ACL не дает штрафов к производительности. Можете хоть тысячу записей делать на ACL. Главное, чтобы ресурсов TCAM на хранение масок/записей хватило.
Только есть нюансы по поводу, во-первых, ключевого слова «log» (его не надо использовать никогда), а во-вторых, определенных комбинаций TCP флагов. Обычно «established» (аналог ACK/PSH/RST) аппаратный, а вот другие комбинации могут быть и программными, даже в пределах cat6500 есть различия в зависимости от задействованного PFC.
Но с обычными L3 ACLями всё должно быть хорошо.
Только есть нюансы по поводу, во-первых, ключевого слова «log» (его не надо использовать никогда), а во-вторых, определенных комбинаций TCP флагов. Обычно «established» (аналог ACK/PSH/RST) аппаратный, а вот другие комбинации могут быть и программными, даже в пределах cat6500 есть различия в зависимости от задействованного PFC.
Но с обычными L3 ACLями всё должно быть хорошо.
ясно. спасибо
просто как представлю что нужно перелопатить 5гб трафика ACL'ем как-то страшно становится :)
просто как представлю что нужно перелопатить 5гб трафика ACL'ем как-то страшно становится :)
Для не совсем нового sup720 и его PFC3 заявлено 400Mpps… 5гб/с даже мелкими пакетами для него ничто. Конечно, с правильной линейной картой (и я сейчас даже не про DFC) и без глупостей в конфигурации и определенных багов.
Вот для GSR 5гб/с уже весьма прилично будет… А вообще, читайте www.cisco.com/c/en/us/support/docs/routers/12000-series-routers/40742-acl-12000.html, есть там свои нюансы.
Вот для GSR 5гб/с уже весьма прилично будет… А вообще, читайте www.cisco.com/c/en/us/support/docs/routers/12000-series-routers/40742-acl-12000.html, есть там свои нюансы.
промазал с ответом
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Управления процессом обмена маршрутными обновлениями с помощью списков префиксов (prefix-list)