gul_tech | Entries tagged with juniper

Лень всё же победила. :)
Вместо того, чтобы в очередной раз руками вычищать из конфига куски, которые перестали использоваться (policy-statements, firewall filters и т.п.) написал для этого перловый скрипт.
Ему параметром или на stdin даётся конфиг, он его анализирует, и на выходе выдаёт команды удаления неиспользуемых policy-statements, prefix-lists, community, as-path, firewall filters, firewall policers. Эти команды удаления можно потом копипастнуть в конфиг. Если используется dynamic-db, динамический конфиг можно дать вторым параметром - тогда скажет, что можно удалить и оттуда.

Сначала подумал, не сделать ли его как junoscript (на commit или как op script), но решил, что это и писать сложнее, и использовать менее удобно.
Написан за час (может, два) на коленке, написан неправильно (парсинг конфига, если по уму, нужно делать совсем не так), сделан исключительно под мои конфиги, так что корректную работу с другими конфигами не обещаю. Но может и сработать. :) У меня отработал и на MX, и на EX. Ловит inactive-части конфига, использование firewall filters как input/output на интерфейсе или вложенные, либо как fail-filter в urpf, полисеры - используемые из фильтров или непосредственно на интерфейсе (input/output/arp), policy-statements - в конфигурации протоколов или вложенные.
Если кому предложит удалить что-то лишнее или наоборот - не предложит удалить то, что надо бы - пишите, поправлю. Это только самая-самая первая версия.

Надо будет и для cisco ios такое тоже сделать.

Или это я велосипед изобретаю, и оно такое давно есть стандартное?

Публиковать скрипт на 50 строчек, конечно, смешно, но учитывая, что это скрипт на SLAX, надеюсь, что не засмеёте. Потому что пользователей JunOS по моим представлением гораздо больше, чем тех, кто пишет скрипты. Ну и написание/отладка существенно сложнее, чем perl или bash (по крайней мере, для меня).

В общем, скрипт - выводит "show bgp sum" в несколько другом формате и с дополнительной информацией. Формат - по одной строке на каждый пир (после поднятия IPv6 обычный "show bgp sum" стал рисовать пиров в две строки, из-за чего не получалось использовать "| match ..."); кроме того, для каждого пира пишет его группу и description. Длина выводимых строк около 100, соответственно, желательно, чтобы у терминала тоже строки были длиннее 80 символов. Может, кому пригодится. Скрипт.

Скрипт надо положить в /var/db/scripts/op/ и в конфиге прописать "set system scripts op file show-bgp-sum.slax", после чего будет работать команда "op show-bgp-sum".

UPD:
ver 0.2 - Process groups inheritance, support route-instances (заменил первую версию на эту)
ver 0.2.1 - Show advertised prefix count - Cougar 20100513
ver 0.2.2 - Added local interface name
ver 0.3 - Get additional info by "show bgp group", not from config (based on 0.2.1)
ver 0.3.1 - Add local interface information

Если информация о локальных интерфейсах не нужна, версии 0.3.1 и 0.2.2 использовать смысла нет, лучше вместо них брать 0.3 или 0.2.1.
Версии 0.3 и 0.3.1 не требуют прав чтения конфигурации пользователем. Соответственно, корректно отрабатывают случаи использования commit-scripts. Но при этом не показывают информацию про route-instance (только bgp group).
Версии 0.2.1 и 0.2.2 работают чуть медленнее, чем 0.2, т.к. делают дополнительный запрос (get-bgp-neighbor).
Версия 0.3.1 работает несколько медленнее, чем 0.3 по той же причине.
Что быстрее - 0.2.x или 0.3.x - в разных случаях по-разному.

Выбирайте наиболее подходящий для вас вариант. :) Лично я у себя использую 0.2.2 с выброшенной оттуда работой с bgp instances (для ускорения, я их не использую).

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, понять, как и с какими параметрами их запускать, проблематично, сорри.

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

В 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). :-(
( ужас-ужас )

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

На языках программирования, у которых цикл делается только через рекурсию, мне приходилось писать (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 нормально считает и пакеты, и байты.