Безопасность кода за последние 15 лет не улучшилось для сетевых устройств начального/домашнего уровня.

https://securityledger.com/2019/08/huge-survey-of-firmware-finds-no-security-gains-in-15-years/amp/?__twitter_impression=true

Не так давно реализованный сервис ris-live.ripe.net для получения потока обновлений BGP открыл много возможностей и упростил многие задачи глобального мониторинга маршрутизации в Интернете. Форматированный машинный вывод, API, множество точек присутствия, поддержка Python и JS. Если раньше требовалось придумывать способы получения нужной информации со своих BGP спикеров, или с других открытых источников, или использовать сторонние сервисы, то теперь надо всего лишь организовать обёртку поверх RIS Live.

Например, в NTT написали утилиту для отслеживания состояний префиксов - видимость и hijack. Забираем с GitHub, уже есть бинарники, но если хочется самим то всё написано на Node.js.

В ISC, кстати, тоже на Node.js сделали RADIUS Server и поддержку клиентов. Забираем на их Gitlab.

P.S. Кажется, Node.js для серверных админов, а Python для сетевых, главное не перепутать :)

Qrator про свою систему управления конфигурациями, мало деталей, но есть названия инструментов и высокоуровневое описание подходов. Получилась broadcast/multicast рассылка конфигураций и дополнений к ним на anycast сети по протоколу Apache Thrift с полезной нагрузкой форматированной Msgpack.

Если не видели, 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.