Ещё раз напоминание от Ивана Пепельняка, что RFC никому не указ, на этот раз с таймерами OSPF. Интересный момент в этой истории, о чём собственно говорится в RFC1925, что netlab будет поправлять такое поведение, что добавляет ещё один слой сложности, который теперь влияет на поведение, пусть и внутри лабы, и про который надо помнить, потому что изначальное поведение тоже может измениться. И так далает, наверняка, не только netlab, и вот этот слоёный слипшийся пирог мы едим каждый день.

GoBGP дорос до версии 4, не пропускайте.

В любом расследовании главное не выйти на самого себя. Анализ пакетов TCP SYN с полезной нагрузкой, в котором обнаружено что 75% анализируемого трафика приходится на трафик исследователей. Из оставшегося, досталось Zyxel и непонятным TLS запросам, а 5% никак не классифицировали.

Как в Cloudflare определяют CGNAT, с помощью RIPE Atlas трасировок, PTR, списков VPN и машинного обучения по поведению клиентов. Пишут что со скоростями за NAT дела обстоят хуже чем без него. В Африке NAT больше всего и большее количество абонентов упаковывается в один адрес.

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

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

Спасибо самым лучшим подписчикам за ссылку. SSH это SSH, а TLS это TLS, ассиметричная криптография и там и там, но реализация этого разная. А в доверии TLS сертификатам, может быть скоро, нас ждут большие изменения. Кстати, вы же проверяете fingerprint SSH перед тем как добавляете хост в доверенные?

MTR для Linux и Mac на Go, с отображением параллельных маршрутов.

Итак, я уже давно пропагандирую использовать netlab для своих лаб
И давно пропагандирую отказываться уже от legacy EVPN\VXLAN изучать EVPN VXLAN
И если вы всё ждали знак свыше, что бы сделать или то или сё или всё вместе - то вот вам целых два (2!) знака.
Отвертеться не получится больше. Кто не юзает netlab - тот козявка теперь.
Ныть о том что "му-хрю нету русских статей про netlab и evpn\vxlan" больше нет никакого права.
Встречайте

Книга от Дмитрия @aeangel - https://aeangel.gitbook.io/netlab_for_otus
Книга от Александра @Sloukot https://mr-grin93.gitbook.io/netlab-homeworks

В работе Димы для меня было новым использование инструмента EdgeShark (https://netlab.tools/extool/edgeshark/) - живая капча по клику мышки!
А Саша открыл для меня возможность запуска лаб прям в codespace (https://github.com/features/codespaces) - ну то есть теперь ваще ничего не надо у себя держать, хватит просто аккаунта на гитхабе

Крайне рекомендую ОБЕ работы. Потом ещё раз пару раз.
И если после этого будете на собесы приходить без знания EVPN\VXLAN то я даже не знаю ваще чё вам ещё надо-то в жизни

Страх интернетчика номер один - увидеть свою AS в публичных отчётах утечек/hijack BGP. У автора в итоге ничего страшного, но пиринг есть пиринг, даже если он чисто технический, внутренний и для исследовательских, альтруистических целей.
Мне несколько раз, и даже не на заре своей карьеры, приходилось упускать частные сети наружу, без последствий. Пару раз спасали фильтры апликов вплоть до отстрела BGP сесси, но что-то увидел уже в публичном LG. Остаётся пожелать всем быть внимательным, чтобы такого с вами не случалось.

Инструмент с помощью которого можно визуализировать большие сети, в частности Интернет (связи между AS) , как показано в примерах. Написано на Python, выглядит просто и красиво, может быть слишком геометрично, есть возможность поиграться параметрами.

Помогло бы расширение канала? Возможно, но не обязательно. Как ещё один слой QoS, несомненно, добавляет много сложности, порой очень много, когда пересекаются интересы разных участников и разных сетей. Помните про это и будьте готовы, я однажды вольно пересказал, нарисовав те графики которые хотел, маленький кусочек учебника Cisco по QoS от Odom и Cavanaugh, остающийся актуальным до сих пор, с него можно начать.

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

Ну всё, больше никаких отмазок. IPv6 Forum призывает всех сделать последний рывок и переходить на IPv6 only. В документе перечисление тех кто уже молодец и что к чему с NAT64, DNS64 и 464XLAT.