Vi рулит в ситуациях когда не остаётся вариантов, а это не такая уж и редкость. Недавнее приключение - пропадает электропитание, Juniper ребутится и возвращается в аварийном Amnesiac режиме. Повод залогиниться и разобраться, но файлы побились, включая базу паролей, и тебя никуда и никак не пускает, хотя должно было бы. Ладно, есть режимы восстановления в которые можно зайти при перезагрузке, что отдельная проблема, потому что перезагружать особо не кому, а уложиться, чтобы перейти, надо в 3 секунды. Сброс на заводские настройки с кнопки, тоже, кстати, отказал.

Когда наконец попадаем в консоль FreeBSD, то понимаем что стандартный описанный способ восстановления хотя бы пароля не сработает, потому что без системной базы паролей никакая Juniper консоль не запустится, а у нас в /etc/passwd бинарная каша, а /etc/master.passwd ссылается на пустоту, и в распоряжении только тот набор системных утилит, что есть в образе FreeBSD включая vi и pwd_mkdb. Их хватает чтобы сформировать новую базу паролей /usr/sbin/pwd_mkdb -p /etc/master.passwd, скопировав содержимого оригинального файл с другого устройства, но в принципе можно найти в установочном файле, хотя закопано там очень далеко, архив на архиве и в конце образ QEMU диска. Я думаю хватило бы и одного root или стандартного BSD списка пользователей. После чего попадаем в консоль Juniper, которая уже запускается, откуда сбрасываем конфиг и ставим систему заново, но тут повезло, что того что осталось не побитого для этого хватило.

Удивительно, что за неделю до этого PaloAlto выкинул такой же фортель, сломав /etc/passwd при обновлении записав туда два раза root. К счастью, это не повлияло на возможность попадать в режим обслуживания, который, загрузился сам, ловить момент с нажатием кнопок и вводить пароли было не надо. Даже по сети доступ оставался, который у PA для управления всегда внеполосный, там правда пароль нужен, но не системный, по серийнику.

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

Пару недель назад количество действительных подписанных RPKI префиксов IPv4 в глобальном BGP перевалило за 50%, для IPv6 это событие случилось уже очень давно. Можно приступать к проверке и фильтрации, коллеги Routinator себе поставили и довольны, главное не переборщить.
А вот общее количество префиксов, за которым можно следить там же в @bgp_table_bot или @FullViewBGPbot, растёт неохотно. Может уже миллион, а может чуть меньше, смотря откуда смотреть, будет с нами очень долго, может быть очень-очень долго.

Current RPKI status IPv4 #RPKI [a]
@[email protected]

DHCPv6 как конкретное техническое решение проблем с количеством ND записей в кешах устройств, генерируемых SLAAC, с долгоживущими TCP сессиями и одна из возможных причин медленного внедрения IPv6 на предприятиях, из-за принципиального отсутствия DHCPv6 в некоторых системах.

Подробный разбор того как запустить Juniper vSRX на Linux Debian в KVM, с посылом использовать ПК в качестве полноценного маршрутизатора/файрвола, хотя и маленького. Есть даже про Wireguard, как его поднять на хосте и притащить внутрь виртуалки, но общий смысл уже должен быть понятен после прочтения статьи сначала.

Немного драмы с интерфейсом управления PaloAlto в версиях прошивок 11.1, когда внеполосное управление не совсем внеполосное, но только для IPv6: менеджмент интерфейс не может ссылаться на шлюз по умолчанию на том же устройстве. Это работало раньше, но сейчас не работает, но если так настраивать, то в случае краха устройства, доступ по IP вы к нему не получите, что ставит под вопрос вообще смысл внеполосного управления, и, отчасти, делает новое поведение защитой от дурака, хотя мотивация там совсем другая.

Очень полезный опрос для моделирования ситуации: "Кто мониторит системы мониторинга?" - и как выйти из этой рекурсии.

RIPE NCC собирается остановить обслуживание собственного DNS ns.ripe.net для работы с обратными зонами. Если вы не в первый раз слышите про этот сервис, добро пожаловать в рассылку с обсуждением, чтобы поддержать или противостоять этому.

Очень оптимистичное мнение по поводу IPv6 only для дома - IPv4 не нужен и всё уже работает сейчас, но почему-то никто не торопится, как минимум, ждём Microsoft.

Я думаю что те провайдеры кто работает с GGC должны знать, что можно настроить обмен с частными IPv4 адресами, это и правда здорово экономит мощности позволяя миновать те места где работает NAT. Проверить это можно так curl -k -L https://redirector.c.youtube.com/debug_info если вы сидите с серым адресом в сети провайдера. А узнать имя ноды GGC откуда вы получаете трафик, вот так curl -k -L https://redirector.c.youtube.com/report_mapping. Опция -k обязательна, потому что сертификат там сломан при включенном HSTS. Я не знаю как там дела с GGC в России и сколько нам ещё осталось, в прошлом и позапрошлом годах пугали что уже недолго, но пока, судя по тому что я получаю в ответ на свои запросы, всё продолжает работать.

Ещё одна оптимистичная презентация с ITNOG8 про IPv6, на этот раз со стороны провайдера - как переехать на IPv6 only segment routing сеть с IPv4. У автора есть большая лаба по этой теме для разных систем, подробности на предпоследнем слайде.

Вам всё ещё надо разбираться в TCP и алгоритме Нейгла сорокалетней давности, чтобы знать когда включать TCP_NODELAY, чтобы решить все свои проблемы, а когда выключать, чтобы решить оставшиеся.

Главная проблема в планировании - это желание сделать красиво, один раз и навсегда. В этом случае, и миллиарды доступных IPv6 адресов становятся проблемой, точнее, те миллиарды неиспользованных, но выделенных.

2038 всё ближе. Предыстория как время Unix вообще появилось, тоже хорошая.

Помните EIGRP? Напоминалка, если подзабыли. Поймал себя на мысли, что уже очень, очень, очень давно не то что не сталкивался, а даже не видел какие-то упоминания этого протокола, но в памяти ещё что-то осталось и термины из статьи не кажутся тарабарщиной.

Такое конечно мы уже делали: пропустить очередной этап, чтобы сразу в следующий перейти - в космический 5G. Интересно что у Бюро 1440 пока нет лицензии на подвижную спутниковую связь, да и вообще, на этот вид деятельности, лицензий сильно не много.