Много и обстоятельно про Safe Mode в микротиках, который вернёт конфигурацию в исходную, если доступ к устройству потерян, и другие подходы к безопасному конфигурированию, с примерами. Единственная мысль которая у меня мелькнула относительно этого, а почему не сделать этот режим включенным по умолчанию? В Eltex ESR, например, commit всегда требует подтверждения. Можно, наверное, придумать ситуации от которых и такой вариант не спасёт, но внеполосный доступ и резервные копии, упоминаемые в статье в том числе, никто не отменял.

SPF, DKIM и DMARC, почему не помогают и что можно с этим сделать - добавить MTA-STS, выкрутить все опции в strict и не забыть про DNSSEC и CAA.

IPv6 много, мы сами этого хотели, а используется их мало. Многое из неиспользуемого попадает в петли маршрутизации. От этих петель пользы никакой, но вред принести можно и достаточно ощутимый. Поэтому если сеть не используется, заверните её в Null0, потом достанете.

Строим отказоустойчивую схему на двух Juniper SRX с их фишками. В комплекте - два провайдера, NAT, IPSec site-to-site, клиентский VPN, BGP, зоны безопасности, VRF.

Для любителей притащить работу к себе домой - что попадает в NetFlow на домашнем роутере, помним про гиковость автора и его расположение в Индии. В качестве коллектора используется Akvorado.

Если задаться целью, то конечно можно дожать IPv6 и до 80% трафика и даже до 100% трафика. Но исходные 67%, у автора, прямо очень не плохо, в предыдущем посте тоже доля IPv6 преобладающая. Оставшиеся приложения, в данном случае это был BitTorrent, можно подтолкнуть, для совсем оставшихся есть CLAT.

Промелькнул в ленте туннельный брокер route64.org (лучше сразу идти в панель управления, там же и регистрация, manager.route64.org), поймал себя на мысли, что сильно проще сделать самому на виртуалке в облаке, или где угодно. VPN все делать научились, надо к нему только IPv6 добавить, даже если у кого-то ещё нет IPv6, то мест где он есть полно. Не знаю как работает конкретно этот, регистрацию точно принимает, выглядит развесисто, но, кажется, всё это доживает последние дни, особенно если посмотреть на графики с двух предыдущих постов.

Возможно в физическом смысле время бесконечно, но это не точно. В инженерном смысле оно точно конечно, напоминание про это от Geoff Huston. Если не брать в расчёт GPS, где время уже несколько раз кончалось, то до ближайших дат больше 10 лет.

Новое руководство NIST про DNS в pdf. В блоге APNIC небольшой обзор. DNSSEC и DNS over что-то - присутствуют, свои DNS лучше и не забываем про мониторинг.

Как CDN выбирают откуда отдавать трафик, публикация целиком в pdf. Авторы посмотрели на популярные в мире CDN, отдельно по странам тоже, про Россию есть. Глобально, больше выбирают через DNS, а не через anycast BGP, есть пересекающиеся варианты. Отдельно проверили использование в этом выборе DNS ECS и посетовали на непрозрачность механизмов принятия решений в выборе точки раздачи трафика, и излишнюю централизацию.

В вебе достаточно данных чтобы получить относительно точное время, не используя NTP или другой специальный протокол. Как это можно сделать с помощью Cloudflare, который добавляет некоторые заголовки с отметками времени, и функций браузера. Есть готовый виджет.

Segment Routing на Arista и IS-IS, первые три статьи про основы, следующие про сервисы. Пока написано пять штук. Для Juniper и Cisco тоже есть.

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

Посмотрите в подвале, в самом тёмном углу, возможно они всё ещё там.

Расскажите свою историю.

@NAT_RTX

Перебор с мемами на этих выходных, но не могу удержаться.

На злобу дня!

#геополитика

Бонусом ко всей этой истории с IPv8 мы теперь можем вспомнить и прочитать как и зачем делали IPv6 и что с ним не так, или не с ним.
Нельзя отрицать что с тех пор, когда стало понятно что нужен новый протокол что в итоге привело к IPv6, многое поменялось, всё стало сильно сложнее. Из-за этого всё новое, ставящее себе целью не сломать текущее, скорее всего, даже не сможет начать внедрение. Вспомним про QUIC, который строится не как новый номерной протокол транспортного уровня, рядом с TCP и UDP, а как следующий уровень над UDP.
Внедрение затянулось, это тоже сложно отрицать, но для IPv6 уже проглядывается финиш. IPv4, скорее всего никуда не уйдёт, даже в среднесрочной перспективе, но уже не будет основным, сейчас это сложно сказать определённо для всех возможных случаев.

Интернет достаточно запутанное место, особенно там где встречается много операторов на точках обмена трафиком. Поэтому неудивительно, что через фильтры просачиваются не те маршруты которые должны. Других Интернета и фильтров у нас нет, особенно помня про качество исходного материала в IRR и AS-SET.

Что конкретно поменялось в curl при работе с DNS: ECH, HEv3 и производительность - в четырёх небольших частях, два, три, и четыре.

Не все утечки маршрутов в BGP настоящие утечки, многое можно списать на переходные процессы. В каждом случае надо разбираться, даже такие неутечки, могут помочь построить свою маршрутизацию лучше, чтобы потом они не превратились во что-то большее. ASPA, RFC9234, MANRS, инженерные подходы и здравый смысл в этом помогут.