То что надо для таких песен https://www.youtube.com/watch?v=aPtr43KHBGk

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

Я думаю, что многим кто работал с L2 сетями достаточно долго приходилось применять физическую закольцовку патчем, чтобы сменить тэг у вилана: access или trunk native vlan с двух сторон и не забыть обезопасить себя от STP. Даже если и не физическое кольцо, то два коммутатора через такой патч только ради смены номера вилана. Да, некоторые коммутаторы умеют это делать логически на транковом порту менять один тэг на другой, но всё равно физический стык или кольцо сделать придётся. Способ так себе, но все про него знают.

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

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

Будущее за 50G PON если говорить про будущее PON. Технология PON ближе всего к классическому телекому, это и есть самый что ни на есть телеком, тот который был до Ethernet. Точнее до прямого применения Ethernet сетей в домашних провайдерах, которые собственно и сделали бум провайдеров и проникновения Интернет в крупных городах России.
Теперь многие смотрят на PON и применяют его с его плюсами, как минимум отсутствием активки в каждом втором подъезде в виде коммутатора. Но главный минус, то что нас возвращает на шаг назад, на мой взгляд, это привязка вас как абонента к провайдеру, а провайдера к конкретному вендору, есть нюансы, но часто это именно так. Уйти от одного к другому со своим ONT не получится, да и ONT больше не ваш, в магазине такое не купишь. В равной мере это касается и провайдеров, подружить одного вендора ONT с другим вендором OLT будет сложно. Ещё один разделяющий момент, это узкоспециализированная технология сильно отличающаяся в подходах и синтаксису в настройках у разных вендоров, как итог отсутствие универсальных обучающих материалов, прочитать такое в CCNA/CCNP/CCIE не удастся, а то что ищется сразу гуглом будет очень поверхностным.
PON решает в малоэтажной застройке, но в многоквартирных домах тоже этого много и скорее всего будет больше, спасибо, отчасти обслуживающим компаниям со своими требованиями по размещению активки провайдеров. Будущее у этой технологии точно есть, как минимум оно обозначено.

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

Великий китайский файрволл подменяет ответы DNS и не только, это есть по ссылке внутри статьи, система так же работает и у нас только на уровне провайдера, что делает возможным определять какая доля запросов выходит за границу Китая, не находясь внутри построенный телеком-системы, но находясь внутри Китая. Исследование которое пытается разобраться в эффективности работы DNS root серверов, в частности F,- I-, J-, K-, L-root anycast ноды которых присутствуют в Китае. Делается обобщение насчёт того что запросы пришедшие без изменений соответствуют запросам внутри страны, а запросы с подменой выходят во вне. На самом деле мы видим что даже для серверов которые не представлены внутри страны, какая-то доля ответов всё равно приходит без изменений, т.е. тут накладываются и другие факторы и к такому обобщению стоит относиться аккуратно.

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

В России: 1 - E-root, 6 - F-root, 1 - I-root, 2 - J-root, 3 - K-root, 5 - L-root - в основном столицах, в том числе сибирских и дальневосточных.

Про то как вообще строить и обслуживать большие системы, в частности DNS, есть RFC9199 - anycast и связность работают и работают хорошо.

Так понятно, на мой вкус конечно, как Chris Parker мало кто пишет и совсем не важно что на примерах Juniper. В этой статье про Route Distinguishers (RD), одно из ключевых понятий при построении MPLS L3VPN, от азов до практических примеров использования разных типов.

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

После маршрутизации на доступе и маршрутизации на хосте, можно переходить к MPLS на хосте. В видео много внимания уделено автоматизации как получать и раскидывать маршруты и настройки по хостам, а то что касается dataplane, вокруг чего всё строится это модули ядра Linux - fou, mpls_iptunnel, mpls_gso и что вы с ними сделаете ограничено только фантазией. В целом, дотащить полноценную, умную сеть, будь это просто маршрутизация на каком-нибудь протоколе или MPLS, до конечного приложения позволяет контролировать весь путь прохождения трафика не отвлекаясь на смены парадигм и протоколов. Здесь мы передаём привет фабрикам и всевозможным оверлеям, которые решают ту же задачу.

Крутой инструмент американского регулятора - интерактивная карта провайдеров, с поиском, с названиями. Для доступа пробуйте VPN или что-то такое из России не получится попасть.

У нашего РКН есть данные в многочисленных реестрах, но они не визуализированы, хотя при желании вытащить какую-то информацию оттуда можно. В виде карт есть "Карты покрытия GSM по регионам", скачиваем RAR внутри по областям и по операторам файлы KML (Google Earth) от 2012 года. Выглядит неплохо, но давно не актуально.

Про TCP теперь новый RFC9293 - всё что накопилось, включая первый RFC793, в одном месте.

Как включенная проверка DNSSEC влияет на производительность? По версии ISC и Bind 9.18.4 - никак не влияет, кроме того что памяти съедает на 10% больше.

Новый выпуск Internet Protocol Journal - про BGP шардинг, войну между уровнями OSI и история SIP который отметил в этом году своё двадцатилетие.

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

Семантическая маршрутизация, когда решение по отправке на сети принимается из знаний об отправляемом содержимом. Блог APNIC делает общий обзор того что творилось на сессии IETF’s Routing Area Working Group 21 июня. Для тех кто прочитал статью Geoff Huston и уже запасся попкорном, можете сразу нырять в дискуссию по ссылкам в статье.

Работа в которой исследуется iCloud Private Relay - это такой Tor от Apple, в статье есть про базовую архитектуру. В частности, находятся и перечисляются адреса и AS входных и выходных узлов, их геолокация, и, конечно, поднимаются вопросы приватности, ради которой Apple всё и затевает. Ещё один вопрос - это необходимость провайдерам пересмотреть свою связность, так как с учётом желания Apple включить этот механизм по умолчанию, важным становится не то как много у вас связности, а то как далеко вы от входного узла iCloud Private Relay, что делает роль провайдера в скорости загрузки страничек ещё меньше.

Очень давно не слушал подкасты, вот прямо года два или три, но тут увидел знакомые буквы ПЖ19 и не удержался чтобы не послушать. Михаил часто говорит слово кооператив, но не раскрывает что за этим стоит, а тема сама по себе в разрезе денег очень интересная и не совсем, да что уж говорить, совсем необычная для организации интернет провайдеров у нас, но про это в подкасте нет. Я прямо советую почитать и поискать про опыт работы и организацию ПЖ19.

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

Давайте реальные цифры которые не звучали напрямую, но которые легко посчитать, на примере ПЖ19. Я везде сильно округляю. С сайта 56606 абонентов, пусть с ARPU пресловутые 500 рублей это чуть меньше 30 000 000 рублей. Если я правильно запомнил у Комфортел ~1500 абонентов на 25000 ARPU - чуть меньше 40 000 000 рублей в месяц. Фонд оплаты труда 30%, гости сошлись на том что это хороший и большой процент - итого около 10 000 000 на ЗП. Грубо, человек 100 в штате есть, скорее даже больше. Итого 100000р на человека в среднем по больнице, со всеми налогами. Наверное, директор получает больше, может быть монтажники ещё больше, потому что всё на них держится, девопсы ещё чтобы не сбежали, сколько сетевику остаётся?
Остальной бюджет тоже можно прикинуть, осталось 20 000 000 в месяц: интернет (1% как прозвучало), телевидение, аренда каналов, аренда столбов/канализации, реклама, электричество для всего, ТСЖ, налоги, фонды, аренда помещений, оборудование, кабели, расходные материалы, кап. вложения на развитие, дивиденды владельцам. Если бюджет сошёлся, то можно начинать строить своего провайдера.

P.S. Linkmeup большой респект, за то время пока не слушал, правда оооочень давно, сильно подтянули качество звука и в целом уровень обсуждения.

240.0.0.0/4 в большом Интернете - исследование RIPE Labs, судя по которому у Amazon совсем плохо всё с адресами и они себе этот блок задействовали по полной и не только они одни.

Если не завели себе HTTPS запись для своего домена в DNS, видимо пора это уже сделать.

Не стоит тестировать на проде, но если очень хочется, то вы знаете ответ. Cтатья в целом про сеть как причину, хотя конкретно совсем про другое, но написана легко чтобы уделить время, есть пример боевого применения tc qdisc add dev eth0 root netem delay.