Я никогда не работал с ISDN или dial-up и DSL со стороны провайдера, т.е. начиная с 2006 года. Как пользователь я даже dial-up толком не прочувствовал, потому что домашний телефон у меня появился сильно позже чем сотовый, на котором я вполне сносно получал Интернет через Edge. При этом все Cisco материалы до середины 2010-х вполне себе содержали и про ISDN и про Frame Relay, особенно про Frame Relay. Но почитать байки, уже байки если не сказки, как это было в 90-х, мне всегда интересно.

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

Верхнеуровневая разбивка IPv6 блока на подсети https://github.com/buraglio/ipv6planner больше интересно как практика программирования Go, но и прямое применение можно найти. Вывод в HTML у меня чего-то не завёлся, но это всегда можно самому поправить.

Мониторинг и дампы трафика на Микротик. Вообще, сейчас такое почти везде есть, от уровня L3-коммутаторов и выше. Называться может по разному порой пересекаясь терминами с другими вендорами, имеющими другое значение. Например, monitor в Cisco и Eltex с Huawei - про разное. Ещё бывает полезно логировать срабатывание правил в ACL, что тоже есть не везде, бывает разной детализации и иногда прячется в debug режиме.

Сильно рекламная статья, но с достаточно интересной статистикой из недр IPinfo, о том какое количество адресов и как часто меняют свою геолокацию, достаточно часто. Таблички можно посмотреть, остальное прочитать по диагонали.

Сначала придумали фрагментацию и сборку и чтобы это делал сетевой стек, а не приложение. А потом всё у всех стало работать по разному, особенно в случаях разделения на перекрывающие друг друга фрагменты (статья в pdf). Упоминаемый инструмент PYROLYSE сейчас недоступен, чтобы самим повторить, но статья написана достаточно объёмно и подробно, чтобы применять эти знания.

Классика.

Starlink запустился в Индии, через местных операторов согласно местным законам.

CDP это протокол которому вы доверяете, поэтому, там где вы не доверяете, на границе вашей сети, например, CDP и другие доверенные протоколы надо отключать. А ещё вспомнить про безопасность на L2 и контролировать загрузку портов и CPU политиками, если они есть. Про STP говорить не буду, оно и без постороннего воздействия может привести к катастрофе, если не настроить. Упоминаемый инструмент Yersinia.

Что происходит если добавить новую корневую ноду к DNS в котором RIPE NCC держит, в частности, обратную зону для своего адресного пространства, но не только. Помимо того что подавляющую часть запросов съест Google, оставшиеся таки придутся на территорию внутри которой новая нода была установлена. Но далеко не все - решает не расстояние, а BGP связность, там своя география.

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

Теория управления потоками (flow control), без привязки к каким-то конкретным стандартам или реализациям, хотя что-то и упоминается. Определения, формулы, аппаратные подходы, сравнения, выводы.

К вопросу куда деваются отброшенные пакеты и о размерах буферов передачи. А что если не тратить память, а зациклить передачу между служебными портами, до того момента когда основной порт будет свободен.
Впрочем, без буферов вполне можно обойтись совсем, может быть, даже будет лучше чем с ними, в любом виде, как минимум, к этому вынуждает железо. С другой стороны, у нас уже есть файловые системы в DNS и в ICMP, чем буфер непосредственно в канале передачи хуже? Осталось только реализовать.

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

Теперь и Juniper поддерживает RFC 9234:

BGP route leak prevention by using BGP roles and OTC attributes based on RFC 9234 (cRPD, MX204, MX240, MX301, MX304, MX480, MX960, MX10004, MX10008, MX2008, MX2010, and MX2020)—You can prevent route leaks in BGP routing by using BGP roles and OTC attributes as defined in RFC 9234. The feature ensures that routes from providers or peers are only propagated to customers, reducing misconfigurations and errors. The BGP speaker automatically sets the OTC based on its configured role, and then advertises a prefix based on the OTC presence in the BGP update message, making the configuration straightforward and minimizing manual intervention. With this feature, you can maintain intended routing policies and prevent network delays and denial-of-service (DoS) attacks.

Пользуйтесь, это работает.