Больше разрядность процессора - больше места под указатели памяти и данные, больше места - больше обрабатывать, больше обрабатывать - меньше скорость. Всё так и не так одновременно, при сравнении 32-битных и 64-битных архитектур. Поменялись не только размеры, но и подходы в том числе, что нивелировало фактор размера, но всё равно имеет свою цену.

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

С безопасностью почты, настоящей, той что SMTP, всё очень плохо. DANE из-за DNSSEC не летит. MTA-STS тоже не летит, но тут скорее из-за того что смешали вместе веб и почту, хотя с ним вроде бы проще должно быть по замыслу. В итоге, все всё знают, что не стоит посылать важных писем почтой, вроде сбросов паролей или доступов в личный кабинет, но продолжают так делать.

Чат, привет!

Я выпустил новую версию NextBox UI Plugin для отрисовки сетевых топологий в NetBox, и это самый большой релиз за 4 года его существования:

– Новый движок визуализации, написанный мной же с нуля (в итоге назвал его topoSphere).
– Основательно переработанные фильтры.
– Поддержка темного режима.
– Экспорт в PNG/JPEG/JSON.

Обновиться, как и прежде, можно через PIP или из исходников на GitHub. Буду рад обратной связи и багрепортам.

Зафиксируем ситуацию. Из проголосовавших, PON продают большинство, 10G-PON много. Наверное, PON, и 10G-PON, и 50G-PON в перспективе, хороший такой фактор увеличения скоростей доступа к Интернет. С Ethernet для скоростей больше 1G всё равно придётся переходить на оптику, для чего надо будет постараться, в PON это от рождения. Одинаковую скорость восходящего и нисходящего канала в PON тоже придумали. Мой скептицизм по поводу более закрытого и узкоспециализированого решения никуда не делся, но в этом витке технологий ITU побеждает, предлагая классический стандарт связи.

Geoff Huston озвучивает то о чём многие не только догадывались, но и вполне себе знали - IPv6 не несёт ничего нового с собой в современный мир, поэтому ждать скорого поголовного внедрения не приходится. Как всегда много истории про то что было, как принимались решения, что предполагалось. IPv6 старый протокол, его придумали чтобы решить в основном проблему нехватки IPv4 и поэтому не сделали там ничего особенного по сравнению с IPv4. Вот это "ничего особенного" и не позволило выиграть за явным преимуществом сразу. А потом весь Интернет изменился, сети больше не на центральном месте в экономике потребления контента, сети просто сети, рулят приложения и DNS, поэтому сквозная проходимость не нужна, и уникальные адреса не нужны, хватает и переупаковки того что уже есть.
В начале статьи приводится срок окончания перехода на IPv6 - 2045 год, при условии сохранения линейного роста, а заканчивается статья на том, что переход может и не закончится, но никому до этого не будет никакого дела.

Я конечно, не Geoff Huston, но таки смахнул слезу и перечитал свою статью от 2015 года - "IPv6 не нужен?", где заголовок статьи не вопрос нужности или не нужности самого IPv6, а вопрос продавца-провайдера на рынке, который ходит и предлагает IPv6, а его никто из абонентов не берёт, потому что не видит разницы. Гадания когда всё закончится у нас тоже регулярно проводятся, последнее показывает что линейный рост кончился.

В любом случае, это не значит что сейчас надо бросить и не заниматься IPv6, конечно нет. 45% это ого-го! уже 45%, почти половина и их будет ещё больше, не в этом так в следующем году перевалим за половину. Поэтому без поддержки этого уже не нового протокола может внезапно стать хуже, и хотя бы к этому, чтобы не стало хуже, не говоря про то чтобы стало лучше, надо быть готовым.

А как же NAT? А к нему настолько все привыкли, что по умолчанию сразу проектируют как его обходить, вот пример для QUIC p2p. Причём QUIC сразу не закладывался на привязку к каким-либо IP адресам, у него свои идентификаторы, которые всегда обеспечивают связность из конца в конец, даже при смене IP на лету, а бонусом multipath передачу.

Кровавый энтерпрайз be like. Где-то в недрах Yandex. Конфколл:
- Так, нам надо провести конференцию для сетевиков. Мы такое уже делали, поэтому все всё должны знать. Нужные таски я уже завёл. Маша, на тебе форма регистрации.
....
Маша: "Фронтедеров знаю, бэкендеров знаю, девопсов тоже знаю. Сетевики хммм, если из инфраструктуры, то, точно не HR. Наверное, программисты такие. А у нас и стандартная форма есть, добавлю ещё согласие на предложения работы, программистов мы всегда ищем."
Фронтедеры: Размещают форму регистрации без прямой ссылки, чтобы ей никто не мог поделиться.

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

ИИ в сетях. Помимо очевидного анализа данных в повседневных задачах - AIOps, в том числе и в домашних условиях, который можно делать уже прямо сейчас, ещё можно продавать "лопаты для золотоискателей" - строить ЦОДы для задач ИИ. Немного ссылок, экономики и скепсиса. Как всегда результаты узнаем через несколько лет, насколько это было хайпом или не хайпом.

Kentik про очередной BGP route leak, на этот раз через Узбектелеком. Что и куда утекло, через Россию, и как это отразилось на Интернет. Что делать тоже понятно, надо только делать.

Амазон про криптографические алгоритмы на эллиптических кривых, что это такое, зачем там простые числа и как они их хорошо реализовали. Результат смотрим на Github.

После 3-х лет теперь стандарт RFC9687. Чиним проблему зависших сессий BGP, когда TCP нам не друг.

Автоматизация чего-то вещь сугубо индивидуальная и для этого не существует коробочного решения, особенно если говорить об автоматизации всего, а не какого-то отдельного элемента. И это только о чисто технических вопросах, а ведь ещё есть и человеческий фактор.
В сертификатах, не только по автоматизации, особенно вендорских, есть другая проблема, о чём написано в самом первом абзаце, но дальше мысль раскрывается другая. Очень сложно соблюсти баланс общего и частного и не скатиться, с одной стороны к перечислению методов конкретного API, а с другой стороны к описанию принципов работы интерпретаторов, например. Очень хорошо понимаю вендоров когда в их экзаменах только их технологии и подходы, но это всё разваливается если нет какого-то общего знаменателя для всех. Названия пунктов меню конкретного продукта, очень быстро устаревают и помнить их нужно только до момента сдачи экзамена. Важнее система, в хороших продуктах она есть, в очень хороших эта система становится общей для отрасли. Без системы это сертификат одного продукта, что в общем тоже полезно и имеет место быть.
Наше высшее образование частенько ругают за отсутствие практики, но согласитесь, что двоичная арифметика, алгебра логики, теория множеств, теория графов, пережила уже не одного вендора, а конкретные применения всего этого понять проще и быстрее зная основы.
Список сертификатов по сетевой автоматизации есть в статье. Я в самом начале посматривал на сдачу DevNet, но конкретные ссылки методов в конкретном продукте меня тогда сильно смутили. А вот Ansible, YAML, Pyhon, REST и все остальные инструменты и технологии которые понимаются сейчас под автоматизацией и стали отраслевым стандартом, вполне себе можно изучать в деталях.

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

Помните про serverless? Говорят что оно возвращается. На мой взгляд далекого от этого человека всё выглядит дико странно. Серверы никуда не делись, поставщики просто переподняли их у себя, на примере AWS Fargate, поменяв сложность обслуживания серверов на сложность взаимодействия с облачным провайдером, скорее всего не одним, и построение собственного слоя абстракции.

Fastly радуется тому что не попал в новости и поэтому делает новость сам про RPKI и проверку маршрутов. Проблема утечки и перехватов маршрутов в Интернет, как и технология RPKI давно уже не новая и широко используется, настолько, что государства обратили на неё внимание, как минимум в США и России (ищем на 71 странице pdf).
Сейчас подписано больше половины всех маршрутизируемых префиксов, пора внедрять проверку для широкого круга, а это делается немного сложнее чем просто подписать, но делать тоже надо. В будущем, наверное, доживём когда неподписанные прификсы приравняют к сбойным и тогда можно будет считать вопрос в этом аспекте решённым.

Ох, сравнение в одной статье QinQ, MPLS и SDH c DWDM. Всё это, конечно, для передачи Ethernet как сервиса, но чтобы так в лоб сравнивать. Интересно, что автор называет QinQ проще чем MPLS, но в то же время противоречит сам себе и говорит, что обычно опыта работы с L2 не хватает поэтому большинство выбирает MPLS.
Масштабно QinQ мне встречался 15 лет назад и это была только провайдерская сеть, где для сегментации обычной нумерации виланов не хватило и пришлось добавлять второй тег. Но позже, несколько раз приходилось использовать двойное тегирование в том смысле в котором написано в статье, чтобы перенести клиентские виланы сквозь собственную сеть, не нарушив инкапсуляцию. В таком микро виде, с минимум подготовительной работы, QinQ действительно проще. Но L2 сети остаются L2 сетями со своими заморочками, а при том количестве материалов описывающих MPLS в различных видах, он не кажется сильно сложнее или дороже в эксплуатации.

Чуть больше подробностей о том как Fortnite распространяет свои обновления, что это становится заметно всем. И они так делают не первый раз, и не только они.

Обзор методов работы с файлами из приложений. Всё, конечно, не просто.