История поиска проблемы, когда не знаешь что искать и движешься шаг за шагом, от косвенных данных к конкретным.

Это обычная практика, потому что все известные проблемы уже покрыты триггерами там где нужно и по сути проблемами не являются. А вот неизвестные приходится искать, потому что данных недостаточно для понимания всего сразу. Потом они переходят в разряд известных и даже тривиальных, вот только система мониторинга должна быть всё производительней и производительней.

При этом не стоит пренебрегать любыми доступными инструментами - если это проще сделать в Excel (как в статье) сделайте анализ данных в Excel - главное не инструмент, а результат.

Эпоху IPX я застал, но конечно на излёте. Всё что я видел это бородатых админов в свитерах, и это не фигура речи, и сервер с Novell Netware в корпусе big tower гордо стоящим на столе в их кабинете.
Но сети работали и Cisco были и много чего ещё. Настройки можно посмотреть в блоге EtherealMind, пример конфигурации и выдержка из документации на переломе эпох.

Zabbix форкнули, уж не знаю как проект потянет всё таки масштабно всё очень, а Zabbix это марка. В любом случае если будет что-то значимое, то и в Zabbix сможем увидеть изменения - конкуренция вещь полезная.

Looking Glass из консоли с помощью curl - можно получать AS_PATH, ORIGIN, AS-NAME и собственно префикc по указанному конкретному IP:

>curl http://bgpstuff.net/origin?ip=2a02:6b8::2:242
The origin AS for 2a02:6b8::2:242 is AS13238

>curl http://bgpstuff.net/asname?as=13238
The AS name for AS13238 is YANDEX

Формат, возможно ещё поменяется, но всегда можно посмотреть подсказку.

Для запросов прямо из Телеграма есть другой способ - @LookinGlassBot

Интересное наблюдение сравнения скорости IPv6 против IPv4 по данным APNIC. IPv6 в случае 10 самых больших мобильных операторов в мире - быстрее. Стоит отметить что в среднем для всех он медленнее, дождитесь загрузки графика на labs.apnic.net он работает.

Про самых больших проводных операторов в США можно сказать то же - IPv6 быстрее. Вопрос, почему? Автор приводит алгоритм Happy Eyeballs RFC8305, который фактически даёт преимущество IPv6, т.е. гонка и замеры получаются нечестные.

Алгоритм используется во всех браузерах, чтобы обеспечить работу сайта при любом раскладе, даже если IPv6 вдруг сломается хотя AAAA запись есть. Но IPv4 подвинут в сторону, намеренно, что приводит к ситуации, во-первых некорректного набора данных для анализа на APNIC. Во-вторых IPv6 надо включить на вашем ресурсе, потому что для абонентов с включенным IPv6 ваш чисто IPv4 сайт будет работать медленнее чем с включенным IPv6, которому сделаны преференции.

Общественные Mesh сети это не только про свободу и независимость, но и про вполне земные задачи доступа там где его сложно получить по другому. Вот в Тайланде например, горы и джунгли, разнесённые локации. Статья в общем не про это, а про то как задействовать неиспользуемый радиодиапазон 802.11af и соеденить эти локации вместе. Не используемый не значит не лицензируемый, чтобы его задействовать с государством пришлось договариваться.

Про Mesh в целом как подход есть awesome на Github, что-то можно оттуда почерпнуть. За ссылку большая благодарность нашему подписчику.

BGP может и не такой сложный как о нём принято считать, но точно не простой в своём применении. Поэтому когда помимо собственно протокола возникают проблемы в его реализации, тем более в железном исполнении, становится совсем грустно. Juniper как раз о такой проблеме рапортует.  Не сказать что это совсем редкость, вот у Quagga или FRRouting.
В железном варианте плохо то что сообщение об ошибке в логе будет, скорее всего, затрагивать следствие проблемы, а не причину. С учётом сложности воспроизводства аварии получается нескончаемая головная боль инженера - пиры падают, а причину понять невозможно :(

Сколько проходит времени между нажатием на клавишу и до момента как буква появится на экране? А если сравнить с раритетными компьютерами?
Как раз это и сделал автор этой статьи и сравнение далеко не в пользу гигагерцовых процессоров и высокочастотных современных дисплеев. Про причины, с технической стороны вопроса тоже есть. Для всего есть своя цена.

DOOM в Qiwi, надо набрать IDDQD в строке поиска. Официальное заявление Qiwi.

Европейская система позиционирования Галилео находится в состоянии аварии, видимо до сих пор, начиная со вчера. Статус большинства спутников NOT-USABLE:

satellite is not operational and it is not contributing to the service provision (NAGU issued after Service Declaration).

Проверить мне на на чем, но пользователи подтверждают. Желаем скорейшего восстановления, очень мы сильно от всяких таких штучек зависим, может даже чересчур.

AS_PATH prepend самый простой из механизмов повлиять на входящий трафик в Интернете, может не самый-самый простой, но самый часто используемый. В Oracle посчитали, что 60000 маршрутов из full-view используют препенды безоговорочно, для всего, даже несколько вероятных теорий предложили почему так получилось.

На самом деле препенды не самый эффективный механизм, уж точно не надо их вставлять 10 раз подряд, так не работает. В статье приводятся примеры этому, а ещё примеры возникновения утечек чему излишнее количество препендов только помогает. У многих магистральных операторов есть комьюнити, разной степени удобства конечно, но с их помощью можно непосредственно влиять на трафик выставляя local preference и те же препенды непосредственно у апстрима, так эффективнее.

Не очень люблю обилие цвета в терминале, в vim, например, специально выключаю раскраску синтаксиса. Но если хочется можно сделать красиво, при условии использования PuTTY - включить xterm-256color, шрифты немного поправить и конечно уравнять в правах IPv6.

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

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

Не знаю что сказать про наши реалии, мне кажется такую схему будет очень сложно объяснить контролирующим организациям. Но идея и правда замечательная.

Я до сих пор страдаю от того что COM порт исчез из стандартного набора портов на ПК и ноутбуках, вроде и USB2COM есть, да и на самих железках можно к USB напрямую подключаться, но что-то не то.

Конечно есть терминальные серверы на разное количество портов с доступом по сети и со всякими плюшками, вроде встроенного модема для телефонной линии - MOXA наше всё. Такое уже не только для первичной настройки годится, но и для организации внеполосного управления в боевом режиме.

Нечто похожее предлагают ребята из проекта WLAN Pi - доступ к COM порту через Wi-Fi. По факту это WLAN Pi, плюс переходник USB2COM, плюс софт который позволяет получить доступ через сеть. Подключаешься к точке, получаешь IP а дальше уже telnet для доступа к консоли. Наверное, где-то это будет применимо, там где с проводами или электропитанием сложно или неудобно возиться, как минимум выглядит интересно.

Вдогонку. Мне в личку вот такую советуют консоль беспроводную, говорят лучше не найти https://www.get-console.com/shop/en/27-airconsole

В копилку публичных ресурсов DoH от Powerdns - doh.powerdns.org. Больше графиков, не только этого сервиса, можно тут посмотреть.

А ещё SIDN Labs запустили свой NTP - time.nl, про него тоже можно смотреть статистику и в блоге почитать (язык голландский, но Google спасает).

Ваш пароль не имеет значения, по мнению инженера из Microsoft, а вот двухфакторная аутентификация решает. На самом деле, если внимательно следить за руками, то пароль таки имеет значение, как раз по причине того что он должен быть сложным и длинным, то что отвергается в самом начале статьи, но из неё же и вытекает.
Да, существует масса способов украсть его у вас и этих способов гораздо больше чем случаев когда сложность пароля действительно важна, но пренебрегать сложным паролем и полагаться полностью на двухфакторную аутентификацию... так себе способ. Чем меньше слабых звеньев в цепочке тем цепочка прочнее.

В блоге APNIC обзор исследования про предотвращение DDoS атак при помощи blackhole. Три тезиса:
1. У многих защита срабатывает автоматически в течение нескольких минут после начала атаки.
2. Опять же, многие не сразу возвращают сети из blackholing после завершения атаки. От нескольких часов до суток, кто-то и больше.
3. Даже невысокая интенсивность 100 пакетов в секунду и меньше, может послужить поводом для отправки сетей в blackhole, хотя в общем эта мера применяется к более мощным атакам.

Всё же DDoS это головная боль хостеров и держателей ресурсов, интернет провайдерам для домашних пользователей попроще. Иногда прилетает, конечно, трафик в сторону какого-нибудь абонента так, что все магистрали в полку укладываются, но обычно это не долго, а увести такого абонента в blackhole гораздо проще. Автомата у нас нет, но нескольких минут хватает, если уж видим что совсем всё плохо. Плюс хорошо работают мерой превентивной защиты, спрятать IP абонента от Интернета. Можно PAT, можно ACL прикрыться, подавляющему большинству открытые наружу порты не нужны, а для тех кому нужны можно оставить переключатель в личном кабинете.

Иван Пепельняк напоминает, что если в OSPF использовать только одну area то она не обязана быть ноль. Даже больше, можно использовать две разные не нулевые area на одном устройстве между которыми формально не передаются маршруты, но так как устройство одно, то в таблице маршрутизации будут нужные маршруты до доступа к адресам из любой area. Можно вообще два разных OSPF процесса поднять, главное чтобы трафик смог дойти до конкретно этого маршрутизатора который уже решит куда его дальше отправить, потому что знает обо всём что у него есть. Такое часто встречается в различных промежуточных моментах, когда две сети объединяются, например.

Чем глубже знания и больше практического опыта их применения тем меньше в голове различных запретов, даже если они формально где-то описаны. В своё время этот барьер сломал для меня преподаватель по микроэлектронике когда спросил: "А что будет если на входы RS-триггера подать сигналы одновременно?" - в учебниках и справочниках это запрещённое состояние, так нельзя делать. А правда, что будет? А ничего страшного, в идеальном случае будет идеальный случайный выбор одного из состояний, на практике чаще будет выбираться какое-то одно, никакого бабаха. Нет запретов, но почти всегда есть последствия, а чтобы их осознавать как раз и нужны знания.

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

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

Но единые сети я всё же видел и даже если выкинуть автоматизацию они очень легко эксплуатируются. Можно всё свести к замене неисправного оборудования, не думая - не работает меняй, и почти в 100% случаев это поможет. Админы в этом случае всё же нужны, чтобы в рамках заложенного проекта расширять и масштабировать, как правило это всегда требуется с ростом компании.

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