gul_tech

Я gul_kiev.
Это мой журнал для постингов на технические темы - про Cisco, Juniper, unix и прочее, что может быть неинтересно многим френдам моего основного аккаунта.

JONOScripts (в числе прочего) дают возможность автоматически реагировать на произвольные события. Например, при обнаружении более 2% потерь на линке увеличить ospf metric. Механизм мощный и гибкий.

В нашем случае понадобилось два применения:
1. Нужно резервирование L2-транспорта. Причём на одном из путей BPDU не проходят, так что любые варианты STP не подходят (bpdu tunneling тоже не работает).
2. Трафик на клиента распределяется на два линка, как multipath bgp, клиенту нужно ограничить полосу по сумме этих двух путей. Поскольку ограничение скорости у MX делается на каждом ICHIP независимо, а сабинтерфейсы клиента у нас принадлежали разным физическим 10GE-интерфейсам, ограничение полосы "в лоб" не получается.

Обе задачи успешно решаются через event scripts.
В первом случае - реакция либо на OSPF, либо на ping tests. При падении основного линка указанный список виланов из этого транка убирается, а в транк на резервный линк добавляется. При поднятии основного линка конфигурация возвращается в исходное состояние. Скрипт
Во втором - реакция на изменение состояния BGP с клиентом. Если обе сессии живы, на каждом из сабинтерфейсов прописывается ограничение в половину положенной клиенту полосы. Если одна из BGP упала - на оставшейся полисер увеличивается до полной полосы. Скрипт

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

В целом, всё работает. Однако есть нюансы. ( ложка дёгтя )

Все привыкли к тому, что время от времени случаются DoS и DDoS-атаки. Что с ними делать?
Владельцы ресурсов и админы корпоративных сетей пытаются защитить себя сами. Всякие IDS, IPS, PIX, ASA, Netscreen и много других умных слов. Этот подход логичен, но имеет очевидный недостаток: если атака уложила border router или забила канал к провайдеру, находящиеся внутри средства обнаружения и предотвращения атак бесполезны, нужно содействие ISP.
Что же делать ISP, как защитить клиентов? Ведь его задача - передавать IP-трафик максимально качественно (надёжно, быстро и без потерь), фильтрация в его функции не входит. На объёмах трафика ISP фильтрация (IPS) будет стоить неразумно, клиентам попросту не нужен такой сервис за такие деньги. Да и настройка фильтров - процесс трудоёмкий и индивидуальный, у каждого клиента свои потребности и особенности.
Реакция ISP нужна только тогда, когда атака уложила либо канал, либо border router клиента. Иначе клиент имеет возможность отфильтровать самостоятельно, и перекладывать эту функцию на ISP смысла нет. Автоматическая фильтрация на стороне ISP может быть и вредна. Например, трафик вполне легитимной видеоконференции может быть ошибочно расценен как DoS (большой поток UDP) и отфильтрован, что, очевидно, не вызовет благодарности клиента.
( Read more... )

Давно не писал про рейтинг.
Поступил с ним по-сисадмински: дал инструменты для самостоятельного его просмотра, включая графики, и на постинги забил. А на самом-то деле, читать обзоры многим интересно, а куда-то идти и запрашивать рейтинг - нет. :)
Регулярно постить не буду, но кое-что, всё-таки, опубликую.
( Read more... )

Когда на винде или на маке падает какое-то приложение, выскакивает окошко с предложением отправить об этом информацию в Майкрософт или, соответственно, в Apple для изучения. Под FreeBSD, если пользователь сталкивается с ошибкой, он может сказать "send-pr" и отправить problem report.

Однако, если я сталкиваюсь с явной проблемой в Cisco/Juniper/Extreme, я должен заплатить за то, чтобы сообщить производителю о проблеме. Даже если у меня на руках отброшенная иосом кора, трапнувшийся джуносовый демон или воспроизводимая бага экстрима. Мне это совершенно непонятно. Ведь это не мне нужно - если у меня что-то не работает, я не буду ждать, пока вендор исправит ошибку и выпустит обновление, это для меня неприемлемо, я найду другой способ решения поставленной задачи, чтобы больше с этой ошибкой не сталкиваться. А после этого могу сообщить вендору об ошибке (чтобы другие пользователи не наступали на те же грабли), а могу не сообщать. Почему вендоры препятствуют тому, чтобы я им сообщал об ошибке? Ведь для этого не обязательно брать на себя гарантии исправления, не обязательно делать багрепорты общедоступными - почему бы просто не дать возможность отправить багрепорт?

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

Объясните.

Часто есть задача: ограничить скорость вилана, проходящего транзитом через свич из одного интерфейса в другой.
Каталисты легко поддерживают ingress policing на физическом интерфейсе, но если нужно ограничить не весь трафик из интерфейса, а отдельные виланы из транкового порта, всё становится сложнее. Особенно, если скорость должна быть ограничена не по сумме всех направлений вилана, а в каждую сторону независимо (а обычно оно именно так). Тем не менее, задача решается как на 3560 (3550, 3750, 3560-E и т.п.), так и на 6500.
( Read more... )

В JunOs не так давно (9.4 или 9.5 - лень смотреть) появилась dynamic-db.
Фича интересная и полезная - в первую очередь для prefix-lists. Смысл в том, что некоторые части конфигурации, относящиеся только к bgp (prefix-lists и policy-statements) можно выносить в отдельный конфиг, а из основного туда делать ссылки. Это сильно уменьшает размер основного конфига, ускоряет коммит, не засоряет rollback history автообновлениями фильтров. У нас prefix-lists - это около 90% объёма конфига, коммит вместо пары минут стал проходить за ~20 секунд.
Однако, как оказалось, пока там не всё гладко. :-(
Первое, с чем столкнулся - нет возможности посмотреть этот самый dynamic config, кроме как войти туда и сказать show, что очень неудобно для скриптов, и требует привилегий изменения конфигурации, когда нужен только просмотр. Пришлось сделать op script show-dyn-conf.slax, показывающий dynamic config (правда, проблему с привилегиями это не решает).
А примерно через месяц использования dynamic-db у него без каких-либо видимых причин сорвало крышу (MX480, 9.5R2.7). :-(
( ужас-ужас )

После апдейта IOS у клиента отвалилась BGP. Как оказалось, у EdgeCore, DLink и всяких noname-китайцев BGP падает, если им предложить поддержку ASN32. Падает с ошибкой "Capability error: unknown capability code 65". Понятно, что технически это проблема клиента и его железа (неподдерживаемые capabilities нужно игнорировать), но клиенту от этого не легче. Предполагаю, что не только мы наступаем на эти грабли.
Решение для Сisco:
neighbor <ip-address> dont-capability-negotiate
Решение для Juniper:
set disable-4byte-as (в конфиурации bgp, group или neighbor).

И там, и там это hidden command.

На языках программирования, у которых цикл делается только через рекурсию, мне приходилось писать (lisp, exim acl).
Но вот с языком, у которого невозможно изменять значения переменных, встретился впервые. 8-() Непонятно, собственно, почему они называются "переменные". Вспоминается анекдот "а дустом не пробовали?"
Ладно бы я не понимал, как оно внутри работает. Но ведь в своё время достаточно много писал на асме - там есть и переменные, и условные/безусловные переходы, и многое другое, чего вдруг не оказалось в языке "высокого уровня". Я, конечно, знаю термины "алгоритмический" и "функциональный" язык, но всё равно вывернуть свои мозги так, чтобы применять рекурсию вместо цикла было естественно, мне напряжно. А значение переменной почему-то иногда хочется изменить.
Но ничего, освоил SLAX (Stylesheet Language Alternative Syntax) и написал скрипт, который был нужен.

Неприятно удивила низкая эффективность. Я почему-то ожидал, что если скрипты работают через junos api, то у них со скоростью должно быть всё нормально, по аналогии с embedded perl и другими встраиваемыми скриптовыми языками. Нифига - запрос конфигурации выполняется примерно полминуты (как и "show configuration"). Коммит и того больше. Вот не понимаю я, что нужно делать, чтобы текстовый файл размером два мегабайта на современном процессоре парсить целую минуту? Мне и секунду-то на эту задачу трудно представить. И заплатки с dynamic-db - я бы понял, если бы там был двухгиговый файл, а не двухмеговый.

Другие хохмочки, конечно, тоже доставляют. Например, арифметические выражения есть, а деления нет (или я не нашёл, как). Ну тут ладно, вместо деления на два можно умножить на 0.5. Но почему же printf("%d", 6000000000*0.5) возвращает "3e+09", который, естественно, парсером конфига не воспринимается?

Конечно, идеология change/commit в JunOS гораздо удобнее, чем в Cisco IOS. Но почему же нельзя закоммитить только изменения, а не весь конфиг? Или залочить только один из уровней иерархии конфига, а не его весь? Это ведь не rocket science. А как без этого скрипт может надёжно менять конфиг (скажем, апдейтить префикс-листы или что-то по событиям)? Ведь вдруг в это время кто-то что-то конфигурирует? А в результате получается система, которая "как правило, работает корректно", "глючит нечасто" и т.п. :-( Про "configure private" знаю - это хороший способ откатить чьи-то изменения и не заметить этого.

То, что у других всё ещё хуже, утешает, но не сильно. :)

P.S. А вообще, junoscripts - мощная штука, я пропёрся.

Сделал рисовалку графиков на основе рейтинга провайдеров. Вот пример её работы:
( картинки )

Поплачусь.
Пачиму, если на Juniper имя каунтера длиннее 23-х символов, то этот каунтер не доступен по snmp (jnxFWCounter)? Откуда идея такого странного ограничения?
Вот, например, colocall-in-rate-limit есть, а colocall-out-rate-limit - уже нет. :(
При этом из cli этот каунтер можно смотреть без проблем.
MX480, 9.5R2.7
То, что полисер считает только дропнутые пакеты, но не дропнутые байты - неудобно, но с этим уже смирился (приходится умножать кол-во дропнутых пакетов на средний размер пакета). Хотя вот даже с6500 нормально считает и пакеты, и байты.

Есть такая старая проблема:
клиент анонсирует /23 апстриму и эту же сетку, как два /24, в IX (например, в UA-IX). В результате получается, что трафик из мира приходит апстриму по /23, а потом идёт клиенту уже по /24 (more specific) через IX. В итоге клиент получает внешний трафик через IX, без ограничений скорости, учёта и пр.
( Как с этим бороться )

Раньше я думал, что все, кто настраивает BGP или MTA, в общих чертах знают, как это делать. Сейчас вижу, что роут-лики - это не единичные случайные ошибки, а пугающе массовое явление. Поэтому думаю, что описание банальных и очевидных для многих вещей будет не лишним.
( ликбез по BGP )

Администратор домена UA Дмитрий Кохманюк aka dk379:

via fox_mulder_cp via optijazz via ain.ua

Напишите регулярное выражение (обычное, работающее для egrep), которое определяет числа, записанные в двоичной системе, кратные трём (и только их). Или докажите, что это невозможно.
Мне понадобилось несколько заходов для решения, но всё-таки решил. :)

Приношу извинения за долгое молчание - как-то много работы было.

Сделал рейтинг провайдеров по запросу: http://asrank.happy.kiev.ua
Вот Рейтинг провайдеров RU&UA за 20-26 августа.
Из существенных дополнений (помимо того, что теперь можно самостоятельно смотреть рейтинг с нужными параметрами) - можно запрашивать список роут-ликов, содержащих указанную AS в пути. Может быть полезно. Если надо - можно выдавать не только путь, но и убежавшие по нему префиксы.
О найденных неточностях (не те апстримы, правильный путь определён как роут-лик и т.п.) сообщайте, буду разбираться и дотачивать алгоритм.

Конечно, планов по доработке ещё много. Информация за историю находится в процессе обработки - постепенно будет появляться информация о более старых данных. Cвежие добавляются автоматически.

Рейтинг за прошедшую неделю. Полный мировой top1000 тут.

Что нового. Во-первых, это данные усреднённые за пять дней, 1-5 августа, а не взятые по одному снимку, как это делалось раньше. Как видно из общей таблички, от случайных флуктуаций (вызванных определённого вида роутликами) это не защитило. Буду дальше думать, как от них защититься, некоторые мысли есть.

Во-вторых, добавилось данных. Возможно, таблица оказалась перегруженной, тогда часть данных вынесу в ajax-овые тултипы. Добавилось: после кол-ва сетей и кол-ва префиксов через дробь сколько из них собственных, принадлежащих своей же автономке. После degree (общего количества обнаруженных линков с другими автономками) через дробь количество апстримов и дальше через дробь количество пирингов. Числа не точные, возможны ошибки, это нормально. При наведении на количество апстримов в виде подсказки всплывает их перечень (причём количество апстримов в подсказке может даже не совпадать с числом за счёт того, что число - это усреднение за период). Последняя колонка - количество апдейтов (изменений роутинга), через дробь количество withdraw (удаление пути), через дробь - удельное количество withdraw на один префикс в день. Этот последний показатель довольно интересен, он говорит по сути об устойчивости в клиентском конусе, хотя и понятно, что один флапающий клиент может его накрутить довольно сильно.

( Табличка )

Очередной рейтинг провайдеров RU&UA.
Прикрутил стрелочки про изменения с прошлого раза. Видно, что изменений за неделю практически нет. И видно, что есть флуктуации, т.е. что нужно таки усреднять за неделю, а не брать одну таблицу. Ну это нетрудно, к следующему разу сделаю.
Вот полный рейтинг (top1000). Там по сравнению с прошлым разом прикрутил группирование автономок, принадлежащих одному провайдеру. Список автономок показывается в tooltip при наведении на as number (во всех ли браузерах работает?).
По софту - сделал обработку файлов с апдейтами. Полные снимки делаются каждые два часа, апдейтов за это время меньше, так что обработка по апдейтам получается быстрее.
( Табличка )

Рейтинг провайдеров по состоянию на сегодня.
Полный список top1000 выложил вот тут.

К сожалению, на прошлой неделе было немного времени на реализацию дополнительных шашечек. Сделал, разве что, отслеживание включения одних префиксов другими. То есть, например, если аннонсируется 2.2.2.0/23 и 2.2.3.0/24, то теперь оно считается как два префикса /24 (раньше считалось как три). Кроме того, немного улучшил алгоритм поиска tier1 и сделал поддержку первой версии mrtd rib table (старые таблицы на routeviews хранятся в этом формате). Надеюсь, что на следующей неделе дам какую-то статистику за прошедшие периоды.
( табличка )

В далёком 2000-м году я решил разобраться в связях между украинскими провайдерами. Тогда и самих провайдеров, и связей между ними было не так много, поэтому я просто сел и, глядя на таблицу маршрутизации, начал на бумажке рисовать схемы. "Тупиковые" автономки не рисовал. Потом эта бумажка попала к bormal и так ему почему-то понравилась, что он её отсканировал.
( Что получилось )
Сейчас почти такое же рисуется автоматически на robtex.com.
( Пример )