Электропитание, охлаждение, поставщики сторонних решений, собственные системы и сети - сбои от которых мы страдали в 2023 по версии Uptime Institute. Их катастрофичность уменьшилась, но сами сбои, конечно, никуда не делись. Сети хотя и далеко не на первом месте, но они на первом месте среди причин сбоев IT сервисов, это наверное есть в полном отчёте, но мы довольствуемся только 10 страничным буклетом. А ещё человеческий фактор, всё что человек делает он же потом и ломает.

Иван Пепельняк разносит, как всегда, сетевые концепции и в этот раз досталось TRILL и SPB в сравнении с EVPN и VXLAN. Про TRILL я первый и последний раз услышал на YaC2013, но в тот раз меня больше зацепил круглый стол по DDoS, после которого очень сильно были переосмыслены применяемые мной в работе подходы.

Пример анализа задержек в сети с использованием eBPF от исследовательской лаборатории Red Hat и разработанной для этого утилитой epping. На LibreQoS тоже можно посмотреть. Тема QoE, лезшая из всех щелей лет пять назад как-то забылась сегодня, наверное всё стало хорошо с качеством, но может это только кажется.

Если ЕС попросит у Роскомнадзора научить как правильно блокировать, научат или нет? По крайней мере, некоторые грабли могли бы стороной обойти, если уж ввязались. А пока ситуация с блокировками в ЕС не очень - достаточно сменить DNS с провайдерского на публичный и всё скорее всего заработает, это помимо того что зеркала почти никто не трогает.

Я переехал на свой собственный почтовый сервер для личной почты и очень доволен этим решением. Инсталляция из Postfix, Dovecot, Opendkim, к которой я добавил DANE, для чего пришлось поднять DNSSec на своих мощностях и отключил нешифрованный трафик на вход. Для спама, которого не сказать что много, простые фильтры прямо в Postfix по адресам и никакого веб интерфейса.
Моё решение уже для сильно увлечённых, но всегда можно сделать ещё сложнее, а может проще, кому что ближе. Вместо Postfix - OpenSMTPD, вместо Linux - FreeBSD с jail (BastilleBSD), рядом Rspamd с Redis. Настройки pf тоже присутствуют и даже разговоры о шифровании ZFS. Во второй части про вебморду. За скобками остался самый главный вопрос, о поддержке всей этой инфраструктуры, которая в любом случае будет что-то просить и в этом плане сторонняя почта на своём домене в разы проще.

Напоминание что TCP/IP сети это про надёжные сети, в которых даже один процент потерь это много, а 10% - катастрофа. Пока посчитали для CUBIC, в следующий раз обещают сравнить с BBR и Reno.

mapcidr для манипуляции с IP адресами, чтобы не писать самим, если уже не написали, на Go.

Реалии современного веба, детально, с фактами, примерами, отсылками, советами. Объёмный текст, если коротко - всё плохо, однако есть исключения. И дело не в скорости вашего Интернет-соединения, дело в скорости вашего процессора и подходах к разработке софта, хотя разработчики ПО всё сваливают на разработчиков железа. Старые сайты работают быстрее, современные оптимизации не работают, применяемые для измерений метрики успешно подтасовываются, чтобы выглядеть хорошо. По поводу оформления собственного сайта, автор тоже прошлёся в заключтельном слове.

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

Карта точек обмена трафиком в Латинской Америке https://lac-ix.org/ixps/, на всякий случай. Там где есть, включена информация о количестве участников, поддержке RPKI, MANRS.

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

Если ещё не видели то посмотрите на Topolograph - для визуализации и анализа OSPF и IS-IS. Локально тоже можно развернуть, включая и real-time мониторинг.

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

Мы живём в мире без цели и без архитектуры, зато с процессом и по плану, и он как-то работает. Отчасти, это удивительно, но, кажется, так не может продолжаться вечно.

Вы же помните Kenneth Finnegan который хотел разобраться как работает Интернет купил себе ASn и больше его было не остановить. Теперь у него сеть из зеркал для репозиториев. На остальные проекты и истории, для тех кто всё же забыл, есть ссылки внутри статьи.

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

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

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

О том как важно делиться проблемами на примере Новозеландской DNS зоны .nz и их DNSSEC. Оригинальный отчёт о том инциденте доступен всем в pdf на 95 страниц. Надеюсь про историю с нашим DNSSEC можно будет почитать хотя бы на страниц 10, а пока даже свежие ежемесячные отчёты ЦМУ ССОП пропали.

В США есть свой РКН - это FCC и они тоже не против что-то порегулировать, в данном случае безопасность BGP. Cообщество против такого, говорит мы сами разберёмся, а то вы нам тут всё поломаете что мы уже построили.