Это конечно бы стоило послушать, но за неимением лучшего - презентация про современный дизайн BGP сети интернет провайдеров в PDF.

RIPE NCC сообщает что перетащили BGPlay под свой новый интерфейс, к которому я всё ещё привыкаю и никак не привыкну. Попробовать сразу не удалось, потому что мой текущий браузер показывает новый интерфейс на 1 секунду, потом стирает, пустой экран секунд 5, потому опять показывает на секунду и дальше по кругу. Попробую значит попозже, с надеждой что хотя бы чуть-чуть это дело стало побыстрее.

А вот теперь 10 лет с момента официального запуска IPv6. Мои гадания по Гуглу с 5% прироста в год всё ещё в силе, сейчас 40%. Всех следящих за ситуацией с каким никаким, а праздником.

Погода over DNS, время over DNS, мой IP over DNS, IP калькулятор over DNS - это dns.toys. А профессиональные инструменты для отладки DNS - есть у PowerDNS.

Ещё про DNS, дополнение к предыдущей статье про НСДИ с данными собранными за год с графиками, новыми префиксами и ASn. Всё в принципе работает, из публичного поля тема как-то исчезла, то ли все подключились, то ли всем стало всё равно.

Почти час поздней ночью пролежал Cloudflare, и как замечают умные люди, причина всё та же — BGP и человеческий фактор. Ошибка в конфигурации (чтобы не читать всё, Ctrl+F reject-the-rest) привела к полному отказу работоспособности маршрутизаторов 19 датацентров Cloudflare. Авторы поста в блоге говорят, что "ошибку было сложно заметить", но если честно — она очень типовая, и непонятно, как автоматические системы, которыми компания много раз хвасталась, этой ошибки не заметили.

Мораль: падают все, страдают от ошибок все, движение вперед — постоянный баланс между скоростью работы и количеством ошибок. Даже у таких монстров как Cloudflare.
https://blog.cloudflare.com/cloudflare-outage-on-june-21-2022/

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

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

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

Ещё один инструмент для анализа записей об интернет ресурсах irrexplorer.nlnog.net и примеры его использования.

Свежий срез на тему: "Сколько инструкций процессора используется в программах" - на этот раз в sqlite3, в разных вариантах компиляции. Сравнивать можно с этим.

Как корпоративной сети всё-таки включить IPv6, большой обзор практических вопросов с которыми придётся столкнуться по различным аспектам внедрения.

Типичная ситуация и иллюстрация к картинке выше, в которой со слов интегратора они молодцы, а провайдер и клиент ничего не могут. Расскажу как подобная история выглядит со стороны провайдера, хотя сейчас я работаю со стороны "большого" клиента.

Не всегда, но очень часто когда подключается какой-то "большой" клиент с офисом в Москве, то сотрудники в его филиалах не обладают никакой компетенцией и возможностью принимать хоть какие-то решения. Даже если в местном штате есть IT в каком-то виде, то любое действие через согласование в Москве, доступов никаких и никуда, максимум что могут шнурок переткнуть. И когда ты проходишь этот уровень и выходишь на специалиста из головного офиса, то часто первая реакция - у нас так работает в 100500 местах мы ничего менять не будем, ваши схемы нам не интересны, нужен белый IP на интерфейсе, оптика мультимод, RIP и ещё куча других условий на выбор, чтобы было как везде, мы ваш клиент делайте как хотите.

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

Если договориться не получается, такое тоже случается, то применяется "нестандартная схема", в которой появляются костыли в виде промежуточных устройств, или конвертеров, или настроек сверху того что обычно делают. Любая "нестандартная схема" - минус к устойчивости, плюс к срокам восстановления при аварии, плюс к большему количеству косяков со стороны провайдера. В таких случаях "большой" клиент, скорее всего уйдёт, потому что его супер вылизанная внутренняя схема не обеспечивает стабильность столкнувшись с реальностью. Уйдёт к другому провайдеру где на какой-то итерации они совпадут.

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

Исчерпывающее, по мнению авторов, руководство по работе с современным DNS. Начинается всё, впрочем, с самого начала что такое DNS вообще, а заканчивается обзором систем имён за рамками того что мы называем DNS. А между этим все основные архитектурные концепты - мониторинг, доступность, конфиденциальность, целостность, противодействие злоупотреблениям. Так как статья академическая то сразу готовимся к табличкам, графикам, сравнениям, сотням ссылок на другие работы и терминам, а воплощать в конкретные конфигурации всё придётся самим.

Исторический экскурс про разницу между клавишами Enter и Return. Про MAC не знаю, на PC клавиатура, как физическое устройство генерирует SCAN коды клавиш. Это идентифицирует каждую клавишу самостоятельно и позволяет обрабатывать любые их сочетания хоть два Enter, три и четыре клавиши одновременно в том числе. У этих кодов нет никаких осмысленных действий пока их не обработает драйвер и даже дальше, превращаясь в ASCII или другой код, дело за программой как его интерпретировать. Понятно, что в какой-то момент произошла логическая трансформация от "Возврата каретки" к "Подтверждению ввода", вероятно из-за желания не плодить новых клавиш, хотя этот период в развитии клавиатур тоже присутствует, но в статье этот момент показан очень слабо, впрочем, рекомендую сходить по ссылкам, там гораздо интереснее.

История развития протоколов автоконфигурации сетевого стека начиная с ARP. В блоге APNIC уже обобщение и дополнение оригинального письма John Gilmore живого свидетеля процесса.

Управление трафиком в BGP в 7 частях (2, 3, 4, 5, 6, 7). Рассуждения от Russ White - как передать трафик через определённую точку, как принять трафик через определённую точку, и как не дать другой AS передавать ваш трафик.

Ещё в копилку Reno vs. Cubic vs. BBR на этот раз для Старлинка в Австралии, в сравнении с геостационарным доступом и оптикой - BBR победил везде.