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

Кстати, вариант с /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 при случайном ветвлении.

Ещё немного о железе. Рекламный пост про 400Гбит/c чип, что само по себе хорошо, если рекламируют то значит есть рынок, спрос, области применения, массовость. Интересно, что с точки зрения реализации, законы физики остаются неприступной границей, однако подбираться к ней можно бесконечно близко.
Хочешь больше скорости, расширяй рабочую полосу спектра или увеличивай количество состояний и частоту. Сильно не расширишься, да и по частотам не попрыгаешь как хочется, везде разное затухание и потери. Но можно подобрать в старых границах то что раньше не смогли, потому что точности не хватало.
Чем больше количество состояний тем меньше между ними разницы, тем больше вероятность спутать одно с другим и ошибиться, поэтому и здесь предел вполне ощутимый.

В итоге, в одном чипе (пишут что впервые) удалось уместить 3x400Гбит/c (1,2Tбит/c) в одном канале внутри датацентра, увеличив ширину спектра до 150ГГц, эволюция начиналась с 50. В рамках города уже 2x400, дальше меньше - сильнее потери, надо меньше состояний, другая модуляция. Ждём пока доберётся до персоналок, а пока ищем в DWDM решениях.

​​Ого-го!

Лаборатория Касперского анонсировала бесплатный доступ к своему Threat Intelligence Portal для всех желающих!

https://opentip.kaspersky.com/

Первая моя ассоциация была примерно такой: Ого, появился русский аналог VirusTotal! Но в блоге, посвященном анонсу, ребята из ЛК это опровергают и выделяют следующие причины: их продукт использует больше технологий обнаружения, чем это делает зарубежный аналог, весь анализ проводится собственными средствами и технологиями, без привлечения внешних систем, а результаты анализа не доступны широкому кругу подписчиков, как это сделано на VirusTotal.

Хотя платная подписка для получения той самой Threat Intelligence все же присутствует :)

Бложик: https://eugene.kaspersky.com/2019/10/24/open-tip/

Если у вас вдруг когда нибудь возникал вопрос, почему стандартное разрешение текстового терминала 80x25, то вот вам ответ - https://exple.tive.org/blarg/2019/10/23/80x25/
Читать долго, но интересно. Давным, давно... всё началось из-за денег.

Инструмент мониторинга состояния префиксов на различных точках обмена трафиком от Oracle. Проверяет подписи RPKI, записи в IRR, наличие в SPAMHAUS и BOGONS (специальные, не публичные, не назначенные префиксы). Есть общая статистика по каждой IXP, наших нет, зато других много. Префиксы можно просмотреть отдельно и там своя статистика.
Общая информация есть в блоге, там же беглый обзор возможностей.

В начале недели состоялась Internet Measurement Conference /19, много серьёзных публикаций от более чем серьёзных докладчиков. Темы очень разные и всё читать, наверное, не имеет смысла, но интересные должны найтись.

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

Ещё, про то как выбрать имена маршрутизаторов из доменного имени. Имена придумывает человек, поэтому можно догадаться (научиться) и выбрать ту часть имени которая соответствует названию маршрутизатора, а не интерфейсу или чему-то другому. Практически никогда нет сложности другому человеку понять где это название спрятано, вопрос в том как это сделать автоматически. Тут нужен формальный подход, который реализован через регулярные выражения. Рабочий инструмент можно увидеть установив пакет Scamper и воспользовавшись утилитой sc_hoiho.

Почему-то, в связи с этими рассуждениями вспомнилась давнишняя статья про Fault Management System и как автор видел идею этого в NOC Project: https://habr.com/ru/post/126051/