Про CRC ошибки, их природу и диагностику, и как всё не просто в случае cut-through коммутаторов.

Уважаемые участники КРОС-2022!

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

Начало было положено вот этим выступлением Виктора Бритько на КРОС-2022.

Описание проекта - здесь. Там кратко описано, кто может принимать участие (все), о чем можно писать (много о чём) и куда это все можно направлять (в редакцию nag.ru).

Когда DNS перешёл на HTTPS то для него открылись новые возможности, например, получение ответов на ещё не заданные вопросы через server push. Этими ответами в первую очередь могут быть данные для подтверждения подлинности ответов через DNSSEC. Для этого, конечно, надо поработать ещё и с самим DNSSEC, но это хорошая причина, чтобы окончательно загнать DNS на прикладной уровень, где сами приложения будут решать что с этим делать.

Широкими мазками по всему IPv6, в PDF на несколько десятков страниц. Не забыты моменты безопасности, развёртывания приложений, механизмы перехода (да, они всё ещё актуальны).

Что можно было послушать, посмотреть на прошедшем RIPE84 по мнению Enno Ray и всё ещё можно это сделать пройдя по ссылками из статьи.

TCPLS - как QUIC только лучше, только вот за плечами QUIC стоит Google и уже 8% трафика.

Это конечно бы стоило послушать, но за неимением лучшего - презентация про современный дизайн 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 и ещё куча других условий на выбор, чтобы было как везде, мы ваш клиент делайте как хотите.

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

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

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