SNMPv3 стандартно отдаёт уникальный идентификатор (как правило основанный на MAC), uptime и количество перезагрузок любым неавторизованным пользователям. Это не повод не включать SNMPv3 у себя в сети, что в общем-то совсем не сложно, но позаботиться об ограничении доступа, помимо аутентификации, конечно стоит. Сайт snmpv3.io с данными мониторинга доступных хостов с SNMPv3 и там же ссылка на публикацию про это.

​​Смотрел, смотрел я на этот график количества префиксов IPv6 в BGP и всё-таки пересилил свою лень чтобы посмотреть что за автономка скрывается за этой гребёнкой. Для чего пошёл на routeviews.org за дампами. "Внезапно" оказалось что толковой машины с Linux у меня под рукой нет, одни микро VPS да embedded с не самыми последними дистрибутивами. Поэтому bgpscanner у меня не собрался, я сломался когда компилятор стал ругаться на неподдерживаемые возможности языка, хотя и продвинулся достаточно далеко. Пришлось ставить bgpdump стандартным способом, благо он есть в репозиториях и ничего собирать не надо, а также умерить свои аппетиты выборкой из 10 воскресных измерений. Плюс немного sed, sort, uniq и join для устраивающего меня результата.

Оказалось и это действительно меня удивило до такой степени, что я подумал и где-то до сих пор сомневаюсь (ох как же я сомневаюсь) что всё сделал правильно - количество автономных систем которые меняют количество анонсируемых IPv6 префиксов, по крайней мере за это время, очень невелико, если быть точным то 172 из ~27500. А количество AS которые делают это в объёмах больших 10 префиксов за раз и того меньше: AS4515, AS4927, AS6730, AS7470, AS7545, AS8100, AS8376, AS20473, AS32167, AS52965, AS58810, AS135373, AS397199, AS397206, AS397232, AS397237. Из всех только две меняют количество анонсируемых префиксов каждый двухчасовой интервал - AS20473 в больших объёмах и AS397220 лишь на пару префиксов за раз. С другой стороны так действительно должно быть, не знаю почему я ожидал иного, гораздо большие изменения, скорее всего видны, в AS_PATH и community, нежели в анонсируемых домашних префиксах. И на этом фоне каждая из этих AS выглядит аномальной.

В итоге получился вот такой график для наиболее изменяемых. Общая разница между замерами выглядят вот так:

0-2:-121
2-4:+65
4-6:+260
6-8:-724
8-10:-10
10-12:+47
12-14:+256
14-16:-297
16-18:+759

Явной периодики не видно, хотя если смотреть на график можно что-то к этому притянуть, но интервал слишком короток. Также, между некоторыми из этих автономок, возможно, есть более тесная связь, но на этом мой запал иссяк и заглядывать и сравнивать префиксы я уже не стал.

История языков программирования, несерьёзная, но правдивая.

IPv4 адреса DoD никому не дают покоя особенно когда они меняют своё место "мистическим" образом. Просто их много и кому-то они достанутся, если ещё будут нужны.

Немного пространные рассуждения по поводу что BGP это не просто протокол, а то о чём, в том числе, должен знать и бизнес, а не только технические службы. Потому что он то что делает бизнес в прямую, а не опосредовано. С чем я не очень согласен.
И я бы не заострял на этой статье внимание, но она была написана до того как Facebook ненароком рассказал что такое BGP не только бизнесу, а вообще всем и теперь она читается немного по-другому.

Вот так даааа. Насколько удивительно, что мы ещё ни разу не вспомнили про kipchatov.ru, мне почему-то кажется что не все знали. Читайте всё, начало kipchatov.ru/blog/-paged=82.htm. Про телекомы изнутри в то время - обязательно встретите знакомые темы и подачи: технологии, блокировки!, новости, крышки люков, BGP и бизнес пиринговых войн, вот было же время. Не скучно и полезно, в том числе и для осознания сегодняшней ситуации.

Тут коллега пошарил статью, что BGP это в том числе и про бизнес.

Я позволю себе процитировать Алексея Александровича Кипчатова:

"BGP, являясь технологической основой маршрутизации, в реальном провайдинге является скелетом для формирования финансовых потоков провайдинга."

И всем, кто связан с провайдингом и BGP, рекомендую к прочтению эту статью: https://kipchatov.ru/blog/-p=202.htm

Old but gold, как говорится.

https://t.iss.one/patchcord/2071

Ну и вот эта статья тоже хороша.

https://kipchatov.ru/blog/-p=212.htm

P.S. Вас еще нет на https://peeringdb.com ?

Ещё одна вещь которую подарило нам падение Facebook. Суть https://bridging-gap-protocol.com/

Если вы в Интернет - за вами следят. Не обязательно, даже, чем-то пользоваться - за вами следит ваш провайдер, как минимум американский. Полный отчёт FTC в PDF.

Немного трюков при работе с консолью JunOS. Первые два это пример, и то за что собственно мне нравится эта консоль, того богатства управления конфигурацией, на лету, без постоянного повторения одного и того же копипастом.

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

Если очень хочется DMVPN, то можно обойтись и без Cisco или даже без DMVPN, но построить похожее по смыслу.

Не забывайте выключать IPv6 RA там где это нужно, и главное, делайте это правильно - напоминание от APNIC. Пример команды для Cisco, поэтому есть повод заглянуть в документацию для своего роутера.

IS-IS теперь и видимо надолго пришёл в локальные сети вместе с Cisco SD-Access как рекомендуемый протокол для базовой сети. Предполагается что его там не будет много - включил и забыл, а остальное сделает DNAC, но незнание основ не освобождает от ответственности.

Поэтому дружно смотрим в сторону SP треков, где IS-IS много, но мало официальных Cisco изданий. А ещё читаем недавно обновлённые статьи Chris'а Parker'а про дивный мир родного OSI стека, хоть и для Juniper и как он уживается с повсеместным IP.

Ещё немного особенностей Juniper теперь с OSPF. Отвечаем на вопрос что делает ABR ABRом, практически. Присутствует сравнение с Cisco, правда не подкреплённое испытаниями. Любителям стандартов и их реализаций будет интересно, потому что про Cisco и IBM есть целый отдельный RFC3509, как раз про то о чём говорится в статье.

BBR против CUBIC, а если точнее то BBR плюс CUBIC через теорию игр, конкретно Равновесие Нэша, того самого из "Игр Разума".

Исследуются ситуации при различных комбинациях потоков через ограниченную полосу, когда выбор алгоритма BBR или CUBIC для конкретного потока не решает ничего. Это получается, в том числе, из-за нелинейной функции средней пропускной способности каждого потока при использовании только алгоритма BBR - меньшее количество потоков имеют большую среднюю пропускную способность. Итого, пока есть разнообразие, то в каждом конкретном месте и в каждый конкретный момент оптимальное решение может отличаться, или как показывает эта работа, быть безразличным чтобы мы не выбрали. Хороший "ленивый" вариант которым многие пользуются.

lldpd vs. openlldp - побеждает lldpd от ISC сейчас уже версии 1.0.12. В статье сравнение по нескольким параметрам: живости, функционалу - в конце табличка.

Несмотря ни на что документация на первом месте и протоколы обнаружения помогут её создать автоматически при первом включении устройства, в том числе и LLDP. Если, конечно, вы управляете своей сетью автоматически, если нет, то лучше с портами определиться и жёстко привязать их заранее. В каждодневной эксплуатации LLDP, CDP и компания - это про сервисы и совместимость устройств, например, IP телефонов и коммутаторов с voice vlan. Собственно статья как раз от разработчиков встраиваемых систем.

За последнее время серверы, всё-таки, пришлось поискать, правда с CDP и виртуальные, хорошо VMware поддерживает.

Общий архитектурный взгляд на различные применяемые механизмы отказоустойчивости на уровне устройства: BFD, Graceful Restart, Non-Stop Forwarding, Non-Stop Routing, Stateful SwitchOver - в ответ на серию статей с поднятыми проблемами, которую тоже стоит почитать, ссылки в конце поста. Чем меньше сложности, в том числе скрытой, там надёжнее - всегда.

Выступление Torbjörn Eklöv про проблемы внедрения IPv6 в отдельно взятой Швеции, с конференции Netnod Tech Meeting 2021. 30 минут видео, 10 из которых дискуссия в зале.

По уровню внедрения Швеция и Россия, судя по статистике Google, на одном уровне окoло 10%. Причины, как в основном следует из последовавшей дискуссии, такие же как и вероятно везде:
- нет запроса от конечного пользователя, который не видит преимущества нового протокола
- нет экономической и бизнес целесообразности, как минимум её не видит руководство компаний
- недостаточность ресурсов для перехода на IPv6, так как пока есть более срочные и важные задачи, как у больших так и у маленьких операторов.

В самом выступлении много списывается на характерную двухуровневую организацию доступа к Интернет в стране и невозможность договориться между участниками этого взаимодействия, а также отсутствие включенного IPv6 по умолчанию на конечном оборудовании пользователя.

А пока работаем через CGNAT, вопрос только как ещё долго.

Никогда не поздно включить uRPF на Juniper или Cisco, тем более что не так давно по этому поводу обновились Best Current Practice 84 / RFC8704, что, скорее, говорит о печальном состоянии в плане спуфинга, что заставляет применять что-то новое и напоминать об этом.