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

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

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

В свете нашумевшего исчерпания IP-адресов составил список - кто является обладателем блоков /8, и используют ли они их. Оказалось, что неиспользуемых довольно много. Хотя и непонятно, можно ли их законно отобрать и дать кому-то другому (RIR-ам).
Под использованием я понимаю наличие BGP-анонсов. То есть, если блок проанонсирован как /8, считаю, что используется полностью, даже если на самом деле там всего одна /24 используется.
С другой стороны, если блок совсем не анонсируется, он считается неиспользуемым, даже если внутри корпорации он активно используется в качестве серых адресов. Потому что нефиг - для этого специально есть 10.0.0.0/8 и др.
В список не включены блоки, отданные RIR-ам, тут только имеющие частных владельцев.
( табличка )

Хочу ipv7 (или какой там следующий свободен).
В смысле, не хочу ipv6.
Хочу, чтобы всё было как в IPv4, но только адреса 64-битные. Обычный u_int64_t. Одно слово (один регистр) на 64-битных архитектурах.
Лёгкий переход, минимальные правки в софте, количества хватит навсегда, эффективнная обработка... Примерно как с asn16 перешли на asn32 без лишнего шума и потрясений.
Не ощущаю я счастья от ipv6. И ощущаю гемор ещё долгие годы, от параллельного существования ipv4 и ipv6, от невозможности интернетовским ресурсам полноценно существовать только на ipv6 без ipv4 при невозможности безболезненно получить блок ipv4, от неготовности всяких железок к ipv6 (фаерволы, wifi ap, телефоны и т.д.)...

Давненько ничего сюда не постил, сорри. Материалов достаточно, просто руки не доходят.
Постараюсь не уходить так надолго.

Пока свежо в памяти, расскажу, что у нас приключилось совсем недавно (а точнее - позавчера).

Ничто не предвещало беды, когда port-channel из нескольких 10GE интерфейсов (между cat6500 и extreme x650) упал с сообщением

Jan 17 16:07:01.581 marmot: %PM-SP-4-ERR_DISABLE: channel-misconfig error detected on Po2, putting Po2 in err-disable state

при том, что последнее изменение конфигурации этого шеститонника было за три дня до этого. Потом (через полминуты) он поднимался по autorecover и через пару минут падал опять с тем же сообщением. Пересоздание этого port-channel ситуацию не изменило. В дебаге тоже ничего путного.

На поиск причин и методов устранения ушло около часа.
Как оказалось, один из клиентов начал слать странные bpdu, а поскольку он был включен в x650, на его порту bpdu не фильтровались, а проходили дальше на 6500. А 6500 при этом укладывал port-channel со столь странной диагностикой.

Открыл для себя команду "no spanning-tree etherchannel guard misconfig". Точнее, это sha90w мне её открыл (и заодно себе). Всем рекомендую.

Выводы:
1. STP - зло. Если его использование необходимо, BPDU должны ходить только в пределах собственной сети, и фильтроваться на всех клиентских портах в обе стороны (не лениться делать это через mac acl, где более простых способов нет). Хотя даже в этом случае нельзя быть полностью спокойным.
2. Реализация L2 в Cisco IOS мягко говоря странная.

Приведу ещё один пример, на этот раз гипотетической ситуации, демонстрирующей эти два вывода.
Допустим, мы купили L2-транспорт у стороннего оператора, q-in-q. И этот оператор (по нашей просьбе или по своей инициативе) прописал для нас туннелирование bpdu, "l2protocol-tunnel stp" на каталистах. Мы аккуратно прописали bpdufilter на клиентских портах и используем stp на этом линке.

И тут один из наших клиентов прислал нам туннелированный bpdu-пакет (а фактически, произвольный пакет на мультикастовый мак 01:00:0c:cd:cd:d0). Этот пакет прошёл наш bpdufilter, потому что это не bpdu, и ушёл в этот транспорт. Тамошний каталист, туннелирующий bpdu, обнаруживает уже туннелированный пакет. Вместо того, чтобы его дропнуть, он что-то не очень внятное сообщает в лог и закрывает порт по err-disable, хоть там 8*10GE и 1000 виланов. И не сообщает, в каком вилане ему пришёл вызвавший такую его реакцию пакет. И этот errdisable не отключается.

Фактически имеем примерно то же самое, что в реальном позавчерашнем случае: незащищённость от активности с клиентских портов, крайне скудная диагностика свича и сложность диагностировать проблему вручную, укладывание всего порта (в т.ч. port-channel) из-за одного неожиданного пакета по err-disable вместо того, чтобы просто дропнуть этот пакет, на cisco ios (другие вендоры за этим не замечены).

Как-нибудь при случае расскажу ещё о всяких интересных граблях на mstp (из-за чего мы сейчас используем только pv-stp).

Публиковать скрипт на 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 (для ускорения, я их не использую).

Изменение позиций в топе как России, так и Украины.
ReTN и ITSystems уступили лидерство. Сейчас среди российских провайдеров по размеру клиентского конуса (в пересчёте на IP-адреса) лидирует РосТелеком, среди украинских - ETT. Таблица ниже под катом.

Немного доделал движок, сейчас можно выбирать, сколько первых строк показывать, и (отдельно) минимальный ранг показываемых провайдеров в мировом рейтинге. Например, можно показать российских провайдеров с рангом не ниже 1000, но не более 100 штук. А то раньше многих сбивало с толку: вроде, задал показать 1000 украинских провайдеров, а многих нет - на самом деле, показывались украинские провайдеры с мировым рангом не ниже 1000, а таких не так уж много. Отсутствие ограничения означает показывать всех.

Нашлись таблицы BGP начиная с ноября 1997. Правда, только от Origon-IX, одного источника маловато для получения надёжных результатов, но, тем не менее, что-то получилось, вполне правдоподобное. Вот графики развития основных украинских провайдеров того времени, за 5 лет с 1997 по 2002 годы:


Тут можно напомнить, что в 2000 в результате рейдерства LuckyNet сменил владельца и ген.директора (с Сергея Гульчука на Артура Габовича).
( Рейтинг провайдеров RU и UA )

Прислали:

P.S. Этот пост не проплачен. ;-)

Появилось новое явление (или я раньше про него не знал): без спроса автора сайта, расположенного на бесплатном хостинге вроде narod.ru, делается его зеркало на нормальном хостере и красивом домене.
Пример: http://dolotov.narod.ru - оригинал, возникшее зеркало: http://speleologist.ru, а вот мнение владельца этого сайта.
Как-то это для меня непонятно и неожиданно. Даже добавленных баннеров не заметил (может, спрятаны - искал не сильно).
Интересно, насколько это законно или наказуемо? Вроде как, авторство себе не приписывается, а копия - ну так она и в кеше поисковиков есть, и на web.archive.org. Но с другой стороны - что-то в этом есть неправильное, как будто контент спёрли.