masterzp Feb 10 2014 at 13:19

Управления процессом обмена маршрутными обновлениями с помощью списков префиксов (prefix-list)

11 min

44K

Cisco*Network technologies*

Tutorial

From sandbox

Comments 22

nickolaym Feb 10 2014 at 14:08

Слово «лист» — это проф.жаргон в данной предметной области, или от незнания общеупотребительного русского слова «список»?

Даже если жаргон, то термин очень неудачный, т.к. вносит двусмысленность:
— конечный узел дерева (leaf)
— список (list)
— страница (sheet)

Тем более, ACL уже имеет традиционный перевод «список контроля доступа»

masterzp Feb 10 2014 at 14:24

Согласен, исправил
Спасибо за поправку)

nickolaym Feb 10 2014 at 16:21

ТщательнЕе надо, товарищ! Поиск по слову «лист» даёт несколько вхождений, включая заголовок статьи :)

masterzp Feb 10 2014 at 16:30

Вот блин) за заголовок вообще забыл, поспешишь — людей насмешишь)
Еще раз спасибо)

JDima Feb 10 2014 at 21:46

А я вот противник перевода терминологии и сторонник ее транслитерации в случае необходимости. Лучше уж «Префикс-листы как метод управления процессом обмена маршрутными обновлениями» (да, запятая тоже была там явно лишняя). «Списком префиксов» может быть и указанный ниже хак с ACLями, а вот «префикс-листом» он быть не может.

Меня как-то поставило в тупик упоминание кем-то «протокола связующего дерева». Я секунд 5 думал, что он знает что-то, чего не знаю я, потом дошло :) Осталось еще перевести OSPF как «открытый кратчайший путь первым» (от «Open SPF», изначального происхождения названия), и приплыли…

masterzp Feb 10 2014 at 22:31

По поводу перевода вопрос философский, мне нравится, да и кажется более правильным, называть все адекватными русскоязычными терминами… ровно до тех пор пока не натыкаюсь на что, что не обладает полным и всеобъемлющим русским аналогом.
и тут сталкиваются два предпочтения — использовать русскоязычную терминологию, и описывать все однотипным образом)
И запятая мне в заголовке нравится, стоит себе на своем месте как по мне.
Для невозможности разночтения, возможно, следует добавлять соответствующий английский термин, скажем так: «Списки префиксов (prefix-list) ...»

JDima Feb 10 2014 at 22:40

По поводу перевода вопрос философский

«John Smith» => «Иван Кузнецов». Вроде не очень философский вопрос — при совке так изредка делали, но сейчас уже нет.

По мне, переводить конкретный термин «prefix-list», обозначающий совершенно конкретную сущность внутри конкретного списка операционок, не менее нелепо. Но как хотите.

JDima Feb 10 2014 at 22:48

И запятая мне в заголовке нравится, стоит себе на своем месте как по мне.

И вот я впервые за много лет вынужден открыть справочник и посмотреть правила, которых я вообще не знаю :)
www.gramota.ru/class/coach/punct/45_183

Не обособляются обороты с союзом КАК в пяти случаях:
…
Если союз КАК стоит между подлежащим и сказуемым (без этого союза там требовалось бы поставить тире), например: Озеро как зеркало;

masterzp Feb 11 2014 at 01:00

Перефразировал)
Еще раз больше спасибо за комментарии.

JDima Feb 10 2014 at 19:48

Невозможность определения совпадения маски маршрута

На что поспорим? Я говорю, что возможно (за совсем старые линейки 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

Вы, простите, учебный центр и занимаетесь обучением людей, я правильно понимаю? :)

Хотя я нисколько не спорю с тем, что из «здесь можно использовать префикс-листы» следует «здесь необходимо использовать префикс-листы».

masterzp Feb 10 2014 at 20:08

Так, по очереди важности)
Каюсь, но не знаю, но как с помощью ACL решить следующую задачу — есть два маршрута: 10.0.0.0/8 и 10.0.0.0/16, мне надо один из них отфильтровать так что бы он не был передан (соседу или другому протоколу через перерапределение) средствами ACL?

По поводу редактирования — без использования интерфейса редактирования именованных ACL — таки никак)
По производительности — думаю у провайдеров и ближе к магистрали списки могут быть приличные)
Но все это не так важно и фактически было для «полноты картины» взято из официальных материалов.

А вот первый вопрос весьма интересный. Есть подозрение что даже если и можно, то явно циска не планировала такой вариант использования ACL.

masterzp Feb 10 2014 at 20:21

Ага. Вопрос отпал.
Расширенные ACL работают не «как обычно» в связке с distribute-list.

masterzp Feb 10 2014 at 20:31

Но с диапазонами масок таки проблема, да и при работе с BGP одна логика, а при работе с IGP другая.
Но в любом случае спасибо. Было интересно разобраться)
Можно сказать что теперь я знаю как делать можно, но не нужно)))

JDima Feb 10 2014 at 21:33

без использования интерфейса редактирования именованных 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'ов по сравнению с применением к пирам одинаковых роут-мапов?

Таким или таким книгам верить можно (их авторы действительно знают матчасть), но с поправкой на устаревание указанной там информации, т.е. опять можно наткнуться на не соответствующие современной реальности данные.

masterzp Feb 10 2014 at 21:57

По поводу выигрыша, циско пишет что есть) во всяком случае с «BGP Dynamic Update Peer-Groups feature», который есть начиная с 12.0(24)S
Хотя реально не замерял. И почему-то мне кажется что если это ваш любимый вопрос, то очевидный на первый взгляд ответ не является верным, как минимум до конца)

JDima Feb 10 2014 at 22:15

циско пишет что есть) во всяком случае с «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", то будет более корректно. «Сеть» и «префикс», кстати, тоже не всегда можно заменять друг на друга…

masterzp Feb 10 2014 at 22:35

То я излишне сократил ответ)
С уточнением по поводу маршрута и префикса — согласен, поправлю.

rdntw Feb 11 2014 at 17:36

JDima, насколько просядет производительность если на входной интерфейс аплинка навесить ACL из 6 строк в котором 5 сетей /23 и в конце deny any? трафика примерно 5гб
либо это всё делается hardware и никак не повлияет? железо уровня cat65, gsr12k

JDima Feb 11 2014 at 17:48

Ну как я уже говорил, на хардварных платформах (cat6500, GSR) ACL не дает штрафов к производительности. Можете хоть тысячу записей делать на ACL. Главное, чтобы ресурсов TCAM на хранение масок/записей хватило.

Только есть нюансы по поводу, во-первых, ключевого слова «log» (его не надо использовать никогда), а во-вторых, определенных комбинаций TCP флагов. Обычно «established» (аналог ACK/PSH/RST) аппаратный, а вот другие комбинации могут быть и программными, даже в пределах cat6500 есть различия в зависимости от задействованного PFC.

Но с обычными L3 ACLями всё должно быть хорошо.

rdntw Feb 11 2014 at 17:51

ясно. спасибо
просто как представлю что нужно перелопатить 5гб трафика ACL'ем как-то страшно становится :)

JDima Feb 11 2014 at 19:29

Для не совсем нового sup720 и его PFC3 заявлено 400Mpps… 5гб/с даже мелкими пакетами для него ничто. Конечно, с правильной линейной картой (и я сейчас даже не про DFC) и без глупостей в конфигурации и определенных багов.

Вот для GSR 5гб/с уже весьма прилично будет… А вообще, читайте www.cisco.com/c/en/us/support/docs/routers/12000-series-routers/40742-acl-12000.html, есть там свои нюансы.

JDima Feb 10 2014 at 21:33

промазал с ответом

Show the best of all time