Мы тут сели и придумали вот какую штуку, вам точно понравится.
Вы много раз просили нас перевести RFC. А мы не понимали, зачем. Строгий технический английский, каким написан документы, хорошо переводится переводчиками. А если вам скучно читать RFC на сайте IETF, то и перевод будет так же скучен. В конце концов, RFC на русском тоже уже есть.
Но мы придумали. Еженедельник RFC.
Раз в неделю до конца года мы разберём в видеоформате 40 самых главных RFC в истории.
Каждую субботу будем публиковать новый разбор.

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

Спасибо оператору Павлу Остапенко и супер-классному Юре, который сделал монтаж.

https://www.youtube.com/watch?v=RWvNLRRfRdk

Хорошее исследование про фрагментацию Интернета с точки зрения Евросоюза, есть русский перевод от Координационного центра. Хорошее, в первую очередь, определением термина "фрагментация" и это не только про фильтрацию, это и замыкание в экосистемах и технологическое разделение, например на IPv6 и IPv4. Присутствует критика Евросоюза, в том числе, когда на словах одно, а на деле другое. Есть про ТикТок, США против Китая и Китай вместе с Россией, нормы международного права и стандартизацию.

Сравнение pfSense с OPNsense - общий обзор и базовый функционал. Нет сравнения производительности и каких-то погружений в детали, что в таких вещах как NAT, например, очень важно. Я никогда не пытался использовать ничего из этого, в моей копилке только аппаратные решения, вот для таких как я эта статья, кто первый раз выбирает.

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

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

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

Cloudflare запустил анализатор веб сайтов, пока в бете, прямая ссылка - https://radar.cloudflare.com/scan. По URL вытаскивает сертификаты, адреса, DNS, куки, хостеров, фреймворки, перекрёстные ссылки. Наверное будет полезно, сами они говорят про безопасность. Как минимум в одном месте собраны результаты тестов с разных сторон.

Возможное наше счастливое будущее, в котором решена проблема с обратной трассировкой и больше не надо будет искать того кто пришлёт тебе свой вариант пути, сейчас же это самый надёжный способ. Черновик в полной мере описывает все варианты что уже были придуманы в попытках победить. Однако, сдаётся мне SOCи тут же попытаются зарубить новый подход, обычная трассировка и та не всегда проходит. А ещё можно послушать 40 минутный подкаст с одним из авторов, но прочитать черновик будет достаточно для понимания.

Очередной раз столкнулся с проблемой что SFP не взлетели в коммутаторе. Очень дорогие SFP в очень дорогом коммутаторе, одного и того же вендора. Я не могу сказать что я стал сталкиваться с этим чаще, но и реже не стал. Иметь в наборе 20 SFP вместо одной за ту же цену, есть же разница, при том что и то и то может не определиться в устройстве, да ещё иметь чуть отличные длины волн, чтобы наверняка только парную использовать той же модели.

Когда мало работаешь с оптикой и интегратор тебе считает всё комплектом, да и ТП хочет чтобы SFP были одобренные можно и пропустить мимо. Но вроде и ТП уже нет в том виде в каком была, а интеграторы всё продолжают считать одну с именем по цене 20 безымянных. Найдите свою SFP, пары попыток будет достаточно, и она не обязательно должна быть дорогой.

Если смотрели Mr.Robot то знаете что источники бесперебойного питания очень взрывоопасные штуки и это не фантазия. С тех пор стало хуже и никакие хакеры для этого не нужны.

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

Кому принадлежит почта, а так как про DNS мы уже знаем, то правильный ответ можно попытаться угадать заранее. Yandex и Mail.ru на этот пир тоже приглашены, если считать среди первого миллиона доменов.

RETN на UKNOF51 рассказывает как пережил прошедший год на Украине - обрывы, отсутствие электропитания, непрогнозируемое перераспределение трафика в том числе и из-за блокировки российских AS, проблемы с доставкой оборудования и запасных частей к нему. Со всем справились.

Что только не придумают лишь бы коннектор не переобжимать.

Обстоятельно про размер буферов в маршрутизаторах с точки зрения производителя. Хочется поменьше и к этому вынуждают вполне реальные технические ограничения и достижения алгоритмов контроля потоков, хотя в мире TCP/IP они не являются гарантией. Но оправданные запросы на большие буферы есть и пока с этим как-то справляются даже на терабитных скоростях.

Как проектировать IPv6 сеть, которая совсем не IPv4. Много примеров для провайдеров, датацентров и корпоративных сетей, VPN, а ещё про NAT и безопасность, и то что меньше /32 брать не надо.

Когда уже нельзя остановиться в придумывании всё более и более безопасного способа загрузки web странички. Помните же про фрагментирование Интернет по технологическому аспекту? Хорошим решением было бы вообще не подключаться к сети, но и тут никто гарантий дать не сможет. Всё из-за Эдварда, нашего, Сноудена.

Во всех новостях сегодня, а нигде прямой ссылки нету- https://portal.noc.gov.ru/ru/monitoring/. Говорят что анализируют, в том числе, маршрутную информацию которую отдают владельцы AS по закону. Downdetector.com строится на постоянном наблюдении тысяч непосредственных пользователей сервисов, и тут уже вопрос что надёжнее при определении сбоя, непосредственный пользовательский опыт или технический мониторинг. Есть ещё downradar.ru, там тоже что-то детектируется, но при таком способе очень важно сколько глаз следят за ресурсами.

Внимательные читатели, конечно, заметили и написали мне чтобы я не пропустил, за что им большое спасибо, что там ещё один сервис рекламируется и он более полезный в повседневной работе - это Looking Glass https://portal.noc.gov.ru/ru/lg/ с очень большим набором узлов разных провайдеров. Мой домашний префикс нашёлся больше в чем 1000 мест, в каждом видно AS_PATH и community. Можно искать по ASn и IPv6, строится график связности. Если префикс не нашёлся, попробуйте задать его другой длины.

Ещё одна статья про атаку по количеству анонсируемых префиксов с целью исчерпания ресурсов маршрутизаторов. Здесь больше практического подхода, авторы попробовали построить распределённую инфраструктуру необходимую для атаки и у них, в целом, всё получилось. Собственно, тот же Китай, может себе позволить анонсировать несколько тысяч автономных систем за раз, по одному префиксу, а если там будет 1000 префиксов, а 10000? Но обычно то к чему готовишься не случается, я бы всё же смотрел больше на IPv4, там добавить надо всего лишь чуть.