junos dynamic-db

В 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. Вот. Он писан для себя, а не как продукт, пригодный для использования другими, поэтому с диагностикой не всё хорошо, с документацией ещё хуже, но можно попытаться запустить (предварительно заглянув внутрь - как минимум, там всякие умолчания прописаны в начале).

Cisco: ограничение скорости транзитного вилана

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

Нипанимаю

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

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

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

Объясните.

Рейтинг провайдеров

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