Ещё одно следствие того что у RIPE NCC скоро кончатся IPv4 адреса - большое количество новых LIR, их можно открывать сколько хочешь, потому что это единственный способ получить новые адреса не покупая их на рынке. Через некоторое время адреса можно передать в нужный LIR и лишние закрыть, сэкономив на членских взносах, что скорее всего и произойдет в ближайшие пару лет, количество LIR заметно уменьшится.

cat очень простая утилита, поэтому не всегда безопасная. Если привести простой пример:

$ echo -n -e "Invisible line\rVisible line \n" > hidden.txt
$ cat hidden.txt
Visible line

Я периодически применяю специальные символы для формирования вывода на консоль, но вот cat меня почему-то удивил, хотя и логично было ожидать от него именно такого поведения. Может быть, потому что я не думал в таком ключе. Escape-последовательности тоже работают, что делает cat ещё острее.

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

Про DNS TTL, немного статистики кто какие использует и несколько рекомендаций к применению. Если установить TTL побольше это позволит ближайшим к потребителю DNS кешам взять обработку запросов на себя, тем самым уменьшить время отклика и снизить нагрузку на авторитативные серверы. Если поменьше, добавит гибкости и скорости реакции в управлении доменами, это важно если использовать DNS как механизма обнаружения сервисов или для борьбы с DDoS и балансировки. Согласия какие TTL использовать, как следует из статьи, нет. И даже среди TLD встречаются значения меньшие 5 минут.

Оболочка для man pages с поиском и гиперссылками. Придётся собирать самим.
А чтобы не запутаться где хранить полученную программу - шпаргалка с описанием дерева каталогов Linux.

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

Кстати, вариант с /29 в сторону апстрима очень удобен на практике и позволяет сделать несколько вещей. Помимо того чтобы поднять вторую BGP сессию на отдельном спикере, можно поставить устройство для мониторинга непосредственно в сети на границе двух операторов, хорошая поддержка при выяснении вопроса на чьей стороне проблема. Ещё можно поиграться с next-hop балансируя трафик на разные устройства в этом маленьком импровизированном IX. Наверное, для этого нужны хорошие отношения со своими провайдерами, у нас так получилось.

Замечательная статья про Traffic Engineering внутри AWS, в которой выясняется что путь внутри облака между регионами может меняться по нескольку раз за минуту со скачками RTT в десятки миллисекунд. Для этого использовались ресурсы в разных частях сети, устанавливались TCP сессии на разных портах и измерялись задержки. Величина этой задержки во многом зависит от использованных портов, при этом около 20% соединений будут менять эту задержку (путь) раз в 10 секунд. Что конечно сказывается на обработке трафика на конечных узлах, в частности происходит постоянная перестановка пакетов из-за того что между разными путями скорость доставки сильно разная. Что в свою очередь может служить сигналом TCP о заторах и уменьшению скорости передачи уже самим протоколом.

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

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

​Насколько хорошо вы знаете curl? Ben Cox написал игру "You can't curl under pressure". Нужно немного промотать вниз, сначала идёт описание идеи.
Всё очень просто - вопрос и ваш ответ в виде командной строки с curl, в то время как вверху тикает таймер. Хороший способ понять глубину своего незнания. Технические подробности реализации тоже присутствуют, код доступен на GitHub.

Когда-то ребёнком читал в "Науке и Жизнь" про цифровое телевидение, если конечно я точно помню что это было именно про телевидение, а не просто про цифровые сигналы. Журнал был из середины или начала 80-х. Теперь другого телевидения у нас нет, только цифровое. По этому поводу передаю большой привет сотрудникам Волгоградского филиала РТРС, теперь не расслабляться и не уронить качество цифры до качества аналога :)

"Кричали женщины: ура! И в воздух чепчики бросали”.
Этого дня мы в редакции ждали долго. В России наконец-то завершился переход на цифровое вещание. В 21 регионе страны прошла четвертая волна отключения "аналога". Пилотный переход на "цифру" прошел в Твери в декабре прошлого года. Недавно Счетная палата рассказала во сколько обошлось подключение цифрового ТВ.
https://www.cableman.ru/content/v-rossii-zavershilsya-perekhod-na-tsifrovoe-veshchanie

Google рекламирует SRE, опять. Как всё хорошо и замечательно получилось у них в итоге и как они к этому пришли. Конечно, для этого уже есть свой awesome.

Russ White про то что технологии остаются технологиями и не надо боятся использовать что-то в локальной сети предприятия, думая что это не для этой сети, если этим используется какой нибудь большой провайдер услуг вроде Facebook.

С точки зрения интернет провайдера действует то же правило, особенно у нас, где очень многие взяли за основу своей сети в рамках города архитектуру локальной Ethernet сети предприятия чуть увеличив масштаб и у них получилось. Широко используя при этом DHCP security, 802.1x, port security, STP. А уж про способ подключения к Интернет через VPN и говорить нечего, сейчас их меньше но такие сети есть и работают. Даже у тех кто сидит на PPPoE в основе своей большая кампусная локальная сеть.

Я не говорю про всех, есть MPLS и его всё больше, потому что стало доступнее на оборудовании соответствующего ценового сегмента. Есть xDSL, вот про DOCSIS не знаю есть ли он где-то в России, но сейчас очень активно растёт PON, во многом являясь перепевкой DOCSIS для оптической сети. Это всё "чисто" телеком технологии, но их конечно никто не запрещает использовать. Всё дело в умении и выгоде. Поэтому заглядывайте иногда в соседнюю песочницу, там может оказаться что-то интересное.

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

Просто про IPv6 Neighbor Discovery, типы ICMP, адреса, кто кому что посылает, RS, RA с описание флагов, NS и NA, ещё DAD. Есть примеры дампов. Не сильно глубоко, но достаточно для понимания что к чему. Те самые основы без которых ничего не работает и забыть, или не знать которые может выйти очень дорого потом.

Вторая версия черновика про устойчивый BGP от NIST, стоит обратить внимание на комментарии к предыдущей части, так можно последить за мыслью автора и смыслом который он вкладывает в документ.
С практической точки зрения можно посмотреть ещё на список ресурсов приводимый Job Shijders в рассылке Nanog, там ссылки на презентации и примеры рабочих конфигураций.

Базовые команды для Linux сети - посмотреть адреса и интерфейсы, добавить маршруты, сделать подинтерфейс на виланах. Примеры для ip и nmcli (NetworkManager).

Обратите внимание на флаг -brief|-br. Удобный, компактный вывод, чтобы увидеть самое важное по одной строчке на интерфейс.

IX-API An Application Programming Interface for Interconnection Services.

IXP-ребята решили скооперироваться и разработать REST API для взаимодействия с кастомерами : провижининг L2 сервисов, регистрация MAC адреса клиентского роутера, конфигурация сессии с RS. В roadmap : статистика, мониторинг и даже управление физическими коннектами (наверно отсылка к path robot от DECIX).
Приглашают участвовать в разработке не только непосредственно IXP, но и клиентов.

Сайт: https://ix-api.net/
Видео презентации: https://ripe79.ripe.net/archives/video/295
Слайды: https://ripe79.ripe.net/wp-content/uploads/presentations/136-RIPE79_TK_IX-API_Introduction_Final.pdf

Akamai хвалится что может прокачать 100Тбит/c своей сетью. Это не какая-то одна локация или несколько, а множество серверов размазанных по всему миру (почему-то помню что про это давно было на Habr, но найти не смог). И вступить в эту сеть можно достаточно просто, получив профит в виде экономии внешней полосы в сторону магистрального провайдера и лучшего отклика для многих и многих ресурсов.

Досмотрел запись NextHop 2019. Обязательно к просмотру про безопасность в BGP от Александра Азимова, история вопроса и что делать - принимать стандарт и использовать ASPA. Наверное, самый качественный и понятный доклад, может быть ошибаюсь потому что более менее на слуху.

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

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

Практически не было вопросов из зала, кроме последнего доклада Васильева Михаила из Facebook, которые тут были более чем в тему. Посмотреть целиком определённо стоит, запись по таймеру почти 9 часов, но там есть долгие перерывы.

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