Если не видели, ISC собирает у себя на сайте ссылки на утилиты для работы с DNS, в том числе и online. Есть для диагностики, тестов, управления. Плюсом ссылки на тематические инструкции и статьи.

Я уже много лет, очень много лет как выпал из мира администрирования Windows. У меня осталось к этому миру много вопросов, больше чем к миру программирования, вопросы до которых я не добрался. Наверное, вот ответ на один из них: "Как настроить сбор логов и читать их?" - в виде шпаргалок с ссылками куда идти и смотреть дальше. Я подозреваю что не открыл вселенную, но шпаргалки, думаю, будут полезны и для тех кто в курсе.

Интересную идею подсказали: вместо того, чтобы чёрти как генерить для своей любимой лабы жалкое подобие фулвью с непойми какими AS_PATH, надо просто взять и поднять машину скачивающую её каждый день(что просто) и слегка подпиливать дамп, чтобы не было слишком грустно без TCAM (что уже интересней). А потом запихать в свою любимую лабу и быть счастливым.
https://networkingbodges.blogspot.com/2019/04/a-real-full-internet-table-in-lab.html

Ansible очень простой и практичный инструмент для автоматизации. Если знаешь как решается задача, то сформировать её в виде playbook не составит большого труда. Хитростей никаких нет, есть задача - решаешь. По сути, нужен справочник по тому что умеют модули, если их самим не писать. Любая статья и даже книги в итоге скатывается к тому как использовать конкретные модули, или точнее как решать задачи используя Ansible. Например, как что-то сделать на Cisco IOS-XR, в котором Ansible, как и положено отличному инструменту почти незаметен, фокус на задаче.

Поэтому на первом месте в автоматизации всегда вопрос что же мы автоматизируем, а потом всё остальное. Наверное, какие-то задачи перерастают во что-то большее и ценное само по себе. Я не думаю что нельзя было бы написать для Ansible playbook который бы генерировал полноценную конфигурацию для BGP роутера, со всеми фильтрами и ограничениями построенными по различным IRR и данными из PeeringDB. Для BIRD и OpenBGPD уже есть отдельное решение - ARouteServer, те же YAML и Jinja2, а остальное можно и Ansible оставить.

Меня правильно поправляют, что ARouteServer только для BIRD и OpenBGPD, но не всё сразу.

Пример поиска причин проблемы в вопросе: "Почему traceroute не добирается до конца", от Daniel Dib. Как и в любой проблеме сошлось много факторов - traceroute может быть не самым простым и файрволы часто слишком умные, Об этом стоит помнить и уметь собирать всё в кучу.

​Спасибо что делитесь со мной крутыми вещами! Вдогонку к предыдущему посту ссылка от нашего подписчика - traceroute на стероидах, dublin-traceroute. Много как технических фишек, например, определение ECMP и NAT. Так и визуальных - генерация диаграм, вывод в JSON. Посмотреть точно есть на что. Ставить можно из репозиториев, правда не из main. Или GitHub, если есть желание собирать самим.

Давайте ещё один "другой" traceroute сегодня и ещё раз большая благодарность нашему подписчику. fbtracert от Facebook - это pathping (или mtr, кому что ближе) на стероидах, который массированно загружает весь путь от источника до приёмника и смотрит где и что потерялось. Под Windows у меня не взлетело, потому что TCP на raw socket нельзя, оказывается. Не самая понятная и дружелюбная вещь, но использовать при случае сгодится.
Как это видят в Facebook можно посмотреть на Youtube или вот тут почитать.

Пройденный путь иногда ценнее полученного результата, а если про это ещё и красиво рассказать. Как сдать CCIE начав в 2012 - просто история, хорошая и добрая история. Не про технологии, а про человека.

​Как далеко до Интернета в текущих реалиях означает как далеко до ближайшей точки присутствия CDN, статья на labs.ripe.net как раз про это. Из России до GoogleCloud ближе всего.

Я не поленился и попинговал ресурсы которые приводятся в статье. Получилось вот такое RTT:

Googlecloud 37мс
Fastly 38мс
Cloudfront 44мс
Akamai 49мс
Cachefly 55мс
Cloudflare 61мс
Azure 65мс

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

МТС с 1 сентября закрывает CSD. Заканчивается целая эпоха. Хотя многие даже и не подозревали, что CSD до сих пор работает. Если вообще в курсе, что это такое.

CSD - это модемный дозвон для подключения к интернету. Помните в 90-е мы через модемы, подключенные к компьютеру, звонили на телефонный номер и подключались к интернету. Скорость тогда была разной, зависела как от модема, так и от качества телефонной линии. И при всем желании больше 56 килобит получить было невозможно. 30 в лучшем случае.

Так вот, автор этих строк настолько стар, что прекрасно помнит, как он настраивал CSD на SonyEricsson T630. И какой был восторг от того, что с мобильного телефона можно было подключиться к интернету. GPRS тогда еще не было, если что.

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

Что ж. Помянем CSD. GSM стоит приготовиться и, как говорят в таких случаях, привести дела в порядок.

В OpenNET сегодня решили отпраздновать 50-летие UNIX, почему бы и нет? Хороший повод перечитать первую публичную статью по теме от создателей, вышедшую в 1974 году - The UNIX Time-Sharing System.

Отличная коллекция статей по применению протокола NTP
https://blog.webernetz.net/ntp/

Миллион самых запрашиваемых доменов по версии Cisco Umbrella - CSV файлы, можно выбирать за конкретный день. Список строится на основе анализа DNS из тех данных которые получает Cisco от пользователей своего продукта. Можно увидеть, например, домены третьего и четвёртого уровня в отличие от Alexa.

У Ruckus что-то случилось с их облачным сервисом (написали что уже починили), при этом у некоторых пользователей слетели лицензии и как следствие развёрнутые ими Wi-Fi сети перестали работать. Наверное, не самое удачное решение привязывать свои внутренние сервисы к внешнему облаку, как бы это не было удобно и дёшево.
Даже если отвлечься от облаков, бум корпоративных мессенджеров который случился не так давно рушит все внутренние коммуникации если что-то вдруг ломается, пусть не сам мессенджер, но Интернет. В том числе и поэтому почта остаётся на коне, хотя и тут многие переползли со своих серверов на Google, Yandex, Mail и подобные. Удобно? Да удобно и красиво и трат меньше, но свой Jabber у нас ещё живёт, на всякий случай.

Как обстоят дела с TCP MSS в 2019 - история вопроса про TCP MSS с ссылками на RFC и статистика за несколько июльских недель. Поводом к исследованию послужили вот эти уязвимости, эксплуатирующие низкие значения MSS. Низкие значения были обнаружены, но скорее как следствия ошибок. В целом же, по мнению автора, с некоторой долей осторожности сейчас можно исходить из значений 1500 для IP MTU и соответствующих MSS: 1460 для IPv4 и 1440 для IPv6 или в совсем не далёком будущем.

Замеры iperf, speedtest, использования CPU и времени загрузки нескольких виртуальных маршрутизаторов: VyOS, Debian с FRR, Mikrotik CHR, pfSense и OPNSense - в окружении KVM (Proxmox) и ESXi. Наверное, можно что-то покрутить, автор этого не делает и всё тестируется в минимальной конфигурации. Побеждает Linux.

Awesome по сетевой автоматизации https://automate.network/, в основном перечисляются инструменты, библиотеки и API, а ещё DevOps. Тема достаточно популярная сейчас, но на мой взгляд не хватает философских, структурных книг или даже учебников, может быть переосмысления чего-то старого. Есть много деталей, кубиков, а вот что строить не всегда понятно.
В раздел книг попали хорошие вещи, но опять же, это всё больше для программистов, сложно балансировать на этой границе. Что-то есть на русском, например, Ansible: Up and Running (очень конкретно, как настраивать) или "Проект Феникс" (роман про современную разработку), как мне коллега подсказывает и советует почитать.
Сети спускаются на уровень ниже, но всё ещё остаются сетями с которыми необходимо что-то делать, иначе, не понятно для чего нужна автоматизация ;)

Устройство включается, получает IP адрес через DHCP и загружает свою конфигурацию по TFTP. Называется Cisco PnP и реализуется в рамках DNA средствами DNAC. Дежавю... ещё несколько примеров PnP, посложнее.

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