RETN на UKNOF51 рассказывает как пережил прошедший год на Украине - обрывы, отсутствие электропитания, непрогнозируемое перераспределение трафика в том числе и из-за блокировки российских AS, проблемы с доставкой оборудования и запасных частей к нему. Со всем справились.

Что только не придумают лишь бы коннектор не переобжимать.

Обстоятельно про размер буферов в маршрутизаторах с точки зрения производителя. Хочется поменьше и к этому вынуждают вполне реальные технические ограничения и достижения алгоритмов контроля потоков, хотя в мире TCP/IP они не являются гарантией. Но оправданные запросы на большие буферы есть и пока с этим как-то справляются даже на терабитных скоростях.

Как проектировать IPv6 сеть, которая совсем не IPv4. Много примеров для провайдеров, датацентров и корпоративных сетей, VPN, а ещё про NAT и безопасность, и то что меньше /32 брать не надо.

Когда уже нельзя остановиться в придумывании всё более и более безопасного способа загрузки web странички. Помните же про фрагментирование Интернет по технологическому аспекту? Хорошим решением было бы вообще не подключаться к сети, но и тут никто гарантий дать не сможет. Всё из-за Эдварда, нашего, Сноудена.

Во всех новостях сегодня, а нигде прямой ссылки нету- https://portal.noc.gov.ru/ru/monitoring/. Говорят что анализируют, в том числе, маршрутную информацию которую отдают владельцы AS по закону. Downdetector.com строится на постоянном наблюдении тысяч непосредственных пользователей сервисов, и тут уже вопрос что надёжнее при определении сбоя, непосредственный пользовательский опыт или технический мониторинг. Есть ещё downradar.ru, там тоже что-то детектируется, но при таком способе очень важно сколько глаз следят за ресурсами.

Внимательные читатели, конечно, заметили и написали мне чтобы я не пропустил, за что им большое спасибо, что там ещё один сервис рекламируется и он более полезный в повседневной работе - это Looking Glass https://portal.noc.gov.ru/ru/lg/ с очень большим набором узлов разных провайдеров. Мой домашний префикс нашёлся больше в чем 1000 мест, в каждом видно AS_PATH и community. Можно искать по ASn и IPv6, строится график связности. Если префикс не нашёлся, попробуйте задать его другой длины.

Ещё одна статья про атаку по количеству анонсируемых префиксов с целью исчерпания ресурсов маршрутизаторов. Здесь больше практического подхода, авторы попробовали построить распределённую инфраструктуру необходимую для атаки и у них, в целом, всё получилось. Собственно, тот же Китай, может себе позволить анонсировать несколько тысяч автономных систем за раз, по одному префиксу, а если там будет 1000 префиксов, а 10000? Но обычно то к чему готовишься не случается, я бы всё же смотрел больше на IPv4, там добавить надо всего лишь чуть.

Если очень хочется то можно и OSPF в датацентр на underlay затащить, но всегда думайте про масштабирование своей сети. Хотя это и выглядит сильно проще по настройкам в статье, подводных камней с OSPF может быть побольше.

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

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

Сейчас я всегда ставлю .1, точнее первый доступный хост, маски /24 остались в домашней сети, одновременно с этим резервируя место в начале и в конце адресов на восемь. Например, в случае FHRP, адреса на физических интерфейсах я нумерую с конца, виртуальный остаётся в начале, а если сеть маленькая, то всё попадает вперёд.
Я не вижу причин которые должны были бы вас остановить делать как удобно именно вам, но .254 я действительно давно не встречал.

Если кто, как и я, не увидел слона https://t.iss.one/yourcybergrandpa/284.

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

BPF как официальный стандарт, возможно, ждёт нас в будущем. Но и без этого можно применять.

Собираем кластер из двух Firepower 9300 на 6 нод ASA. В принципе, в ASA самой по себе удачно механизм кластеризации реализован, могу ещё и Palo Alto за это похвалить - всё что я ожидаю резервирование, обновление, работает без перерыва функционала. А вот с Juniper никак у меня не сложится обновить ноды по очереди не потеряв трафик.

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

Я не знаю почему меня так смущает термин МСЭ, который всё чаще и чаще появляется везде, коверкать язык и писать брэндмауэр или файрвол (не уверен что правильно написал), сложно, но выглядит это как-то органичнее и это при том что я стараюсь. Да, жаргон и жаргонизмы не только являются быстрым способом объяснить какое-то понятие для посвящённых, но и идентификатором свой-чужой. Порой одинаковое явление имеет разную терминологию в разных социальных средах, условно админов и программистов или сетевиков, хороший пример NAT терминология, тогда друг друга никак не понять.
От этого лучше избавится при трансляции чего-то на широкую публику, поэтому какие-то жаргонизмы очень странно порой выглядят в пресс-релизах пусть и профильных компаний, не говоря уже о гос.структурах. А к МСЭ, видимо, придётся привыкнуть, но вот “многоадресная рассылка” так и не зашла.

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