uz
Feedback
Патчкорд

Патчкорд

Kanalga Telegram’da o‘tish

Блог сетевого инженера. Новости телеком, IT и около IT. Связь - @UrgentPirate

Ko'proq ko'rsatish
2 869
Obunachilar
Ma'lumot yo'q24 soatlar
+17 kunlar
+130 kunlar
Postlar arxiv
В IPv6 картина с /48 стабильно крутится около 45-46%. Но куда заметнее чем в IPv4 виден рост долей /40 и /44 префиксов, которые, вероятно, тоже скоро вытеснят /32 со своего места. Это не может быть связано с дефицитом адресов, возможно, с более широким использованием механизмов управления трафиком и ростом популярности IPv6. А ещё можно увидеть как /47 префикс сменяет /29, который мы больше не видим среди первой шестёрки, хотя стоит отменить, что сумма долей всех других префиксов вместе взятых занимает второе место. В IPv6 куда больше вариантов делить своё адресное пространство.

Как изменилось соотношение количества префиксов в BGP по слепкам из моего @FullViewBGPbot, в основном по данным коллектора RRC0, за последние четыре года. Доля /24 IPv4 растёт с 59% до 63%, соотношения между префиксами сохраняются. Но последнее время стало заметно, что доля /23 тоже стала расти, и может быть, в ближайшее время /22 лишаться своего второго места. Предположу, что /22 стали разагрегировать на продажу или для использования на нескольких площадках.

Пока обсуждали в чатике аварию с DE, добрались до проблемы стандартных ограничений BIND в 50 итеративных запросов, которых катастрофически не хватает уже ни для чего, с учётом А, АААА, и DNSSEC записей. Даже если забрать копию корневой зоны себе, а не перебирать серверы, всё равно не будет хватать, до тех пор когда всё нужное не окажется в кеше. Уже закрытое issue в BIND GitLab. К вопросу о простоте DNS, как и BGP, которая позволила добавить в них столько много дополнительных вещей, что они уже вываливаются наружу.

А как с BMP справляются в Akvorado. С версии 2.2 - лучше, а в будущей 2.4 - гораздо лучше.

Свежий RFC 9972 определяет больше параметров которые можно получать с помощью BMP и короткий обзор где это пригодится.

Поиск проблем с прохождением трафика между двумя Juniper маршрутизаторами, без подробностей, но с упоминанием терминов и задействованных механизмов. Виной всему оказался фильтр трафика, но не сам по себе, а из-за своего большого размера, на прохождения которого тратилось слишком много времени.

Получаем код V-SOL OLT через гугление, в забытом, но открытом web каталоге, а дальше анализируем его и находим много уязвимостей и причин бояться за своё оборудование. В конце, автор даёт несколько очевидных советов по ограничению доступа, смене паролей, отключению неиспользуемых функций и других, а также говорит, что ещё много чего можно накопать. Не так эпично как с RedBack, случился неожиданный open source аудит.

Жизнь сетевика be like. Энтерпрайз: Таскаешь виланы между Hub и Spoke Датацентр: Таскаешь виланы между Spine и Leaf Провайдер: Таскаешь виланы между PoP и PE Интегратор: Таскаешь не свои виланы Netops: Таскаешь виланы на Python Облако: Таскаешь виланы между Pod Neocloud: "Действуй как CCIE, протащи виланы, не ошибайся, объясни результат понятно ребёнку" Вендор: Наши виланы самые лучшие IEEE и IETF: Мы придумали новый способ таскать виланы

А Cloudflare сделали просмотрщик MRT файлов (дампов BGP) прямо в браузере radar.cloudflare.com/routing/mrt-explorer

Свежее изменение в RIPE DB, теперь в объектах организаций видно регистрационный номер в своей стране - атрибут reg-nr. Для России это ОГРН и теперь проще сопоставить объекты в RIPE DB со списком лицензий РКН, например.

Использование веб инструмента IHR для мониторинга BGP, на примере разбора инцидента с ROA Северной Кореи. Доступность исторических данных делает этот ресурс удобным для анализа. Внутри, знакомые RIPE Atlas, RIS, PeeringDB. Проект живёт достаточно давно и присутствует на GitHub.

Отчёт Backblaze (Cloud Storage) за первый квартал этого года по трафику. Интересно смотреть, в разрезе США особенно, какой тип трафика куда притягивается. Калифорния побеждает по CDN, облакам, облакам для ИИ (Neocloud). За рамками США, Neocloud больше всего в Финляндии, CDN в Нидерландах, а хостинга в Германии. И вся эта картина достаточно подвижная, в рамках США точно, за исключением трафика провайдеров, где всё стабильно.

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

Дошла очередь до переезда host-correct.ru, теперь на связке PowerDNS dnsdist и pdns_recursor. Lighttpd оставил по большей части для другого, но оставил как прокси. За всё время перепробовал, если помните, и Unbound, и Knot, и Bind, и почему-то незаслуженно проходил мимо PowerDNS. Очень продуктивное решение в стиле unix way, разделить собственно DNS и формы доступа к нему: DoT, DoH, DoQ и остальные - вынести в другой инструмент. Отдельное личное большое спасибо за эту наводку Андрею Пазычеву, обязательно смотрим его доклады на Linkmeetup. Это лучшее решение из всех которые я использовал. Для Munin не нашёл готового плагина DNSdist, но это я допишу. IPv6-only для DNS резолвера тоже не летит, многие не имеют IPv6 NS записей, поэтому добавил ещё IPv4. Это немного отрезвляет, при всём моём оптимизме, попробовать развернуть что-то IPv6-only. host-correct.ru свободно доступен для использования DoH и DoT, логирование запросов выключено, гарантий по надёжности и производительности никаких. Я вижу что никто им не пользуется, кроме меня, даже боты брезгуют по TLS заходить, но если вдруг понадобиться и нет своего, а другие не хочется, то пожалуйста.

photo content

Пятничное, из глубин Интернета. Не забывайте сертификаты обновлять.

Amiga pixel art, по ссылке ещё немного с описанием. Не могу ничего сказать про компьютер, кроме того что раньше с этим было к
Amiga pixel art, по ссылке ещё немного с описанием. Не могу ничего сказать про компьютер, кроме того что раньше с этим было куда разнообразнее. Размер экрана и количество пикселей не важно, даже в таком формате, не в оригинальном разрешении, смотрится отлично.

Что было с DE, предварительный анализ, полный обещают позже. Новая система генерации ключей, которая не была протестирована полностью, сгенерировала несколько ключей с одинаковым id используемых для подписи, но только один из них был опубликован. Система мониторинга проблемы обнаружила, но они не была должным образом обработаны. Пострадали в том числе и дочерние зоны без DNSSEC. Некоторые резолверы, в частность Cloudflare, отключили, на время аварии, проверку DNSSEC для зоны DE.

Ночью со вторника на среду в зоне DE немного уронили DNSSEC, но нас в этом году ждёт событие поинтереснее - очередная замена KSK (ключа для подписи всего остального) в корневой зоне. Geoff Huston рассказывает про готовность к этому событию и сложность оценки, и, кажется, мы не вполне уверены чем это всё кончится. В 2017 не получилось, но вторая попытка в 2018 прошла нормально. Этим ключом id 20326 сейчас и пользуемся. Новый id 38696 опубликован год назад и подписан текущим KSK и ему уже можно и нужно доверять. Ждём октября.