Если какой-то ресурс в Интернете перестал быть доступным, то возможно потому что кто-то по пути до него не удалил уже не анонсируемый префикс. Статья на lab.ripe.net про это. Коротко - да такое явление существует, но причины этого неизвестны. Скорее всего проблема в маршрутизаторах и их ПО.

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

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

Про современные немного поостывшие тренды, разве что Kafka везде мелькает. Но к теперешним AI (Искусственному Интеллекту) и ML (Машинному Обучению) относится в полной мере. Разве ты Google? - статья про то что инструменты надо выбирать сообразно проблеме, для простоты можно воспользоваться методологией UNPHAT:

1. Understand - поймите в чём проблема
2. eNumerate - дайте себе возможность выбора, рассмотрите несколько инструментов
3. Paper - изучите каждый из инструментов
4. Historical - и практику его применения
5. Advantages - после этого выбирайте по объективным признакам
6. Think - а теперь принимайте решение

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

Реальность внесёт свои коррективы: временные, финансовые, интеллектуальные, административные - но это обычно сужает круг, иногда до неприличия. Выбор от это проще не становится, правильные решения приходится отстаивать, такова реальность.

Если уж анонсировали, то можно посмотреть что получилось. Презентации и видео со встречи UPTIMEDAY 2019-04-12. Формат почти часовых выступлений немного утомителен если не смотреть их в живую, получается больше воды и не всегда понятные без сопровождения презентации. Зато разных тем не так много и можно перематывать записи :) Загружу себе в телефон, буду по дороге слушать.

Настоящий, первый черновик BGP. На картинке, как я понимаю, конечный автомат состояний BGP.

В большем разрешении, отсюда. Спасибо за ссылку нашему читателю, без вас - никак! Сравнить с тем что получилось в итоге можно в RFC 1105.

RIPE NCC ведёт статистику распределения своих ресурсов: ASn и адресов с указанием страны. Это достаточно лёгкий способ приблизительной геолокации, не абсолютный, но во многих случаях достаточный. Эту информацию можно видеть непосредственно по whois в базе - атрибут country объекта inetnum. Или на ftp://ftp.ripe.net/pub/stats/, где данные собраны в одном файле, включая IPv4, IPv6, ASn, который удобно обрабатывать автоматически. Присутствуют данные для других RIR и исторические данные.

Простейший скрипт разбора, буквально в 10 строчек, описан тут blog.erben.sk. И даже уже есть готовый актуальный разбор по странам, правда только для IPv4.

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

Мониториг, в общем случае метрология та ещё наука. Измерения могут быть правдивы (что не факт), а вот их интерпретация совсем нет. Многочисленная постобработка в системах мониторинга о которой можно и не догадываться приводит к жутким искажениям. Если не использовать или не обращать внимания на все данные, особенно пиковые то ложное впечатление о функционировании подконтрольного объекта вам гарантировано.

Об этом много и подробно написано в статье про измерения задержек, за авторством Tyler Treat, по мотивам выступления Gil Tene (2015 год, но там такие понятия которые сложно пошатнуть). Приводится пример с нагрузочным тестированием, на сколько неправильное усреднение приводит к искажению реальности. Общий вывод - мониторинг не может быть в отрыве от измеряемой системы, используйте базовый уровень для выработки SLA. Не надо ориентироваться только на 95 перцентиль, 99,999 перцентиль или сколько угодно девяток перцентиль, без реальной системы он ничего не значит.

Но это всё имеет смысл если у вас есть измерения. Мониторинг очень важный аспект работы системы, не зная что происходит невозможно ни чинить ни прогнозировать. ICMP echo уже могут много показать. Для этого, например, есть SmokePing, который измерят задержки используя большое количество инструментов, в том числе и пробников. Хватит на многое.

Отличная новость !
OpenBGPD 6.5p0 released

Это первый релиз в версии portable. Функционал пока урезан по сравнению с версией для OpenBSD (не умеет апдейтить FIB).
Попробовать можно тут - https://openbgpd.org/ftp.html

Ну и к первомаю (на самом деле раньше), релизнулся OpenBSD 6.5 - https://www.openbsd.org/65.html
, так что полный не-portable OpenBGPd можно пользовать там.

Главное в юридической проработке IT-проекта не прийти к такому

1 мая 1964 впервые был использован BASIC. В своё время было сложно пройти мимо него и я не прошёл, хотя он и не стал моей любовью.
Сейчас не так, я даже с трудом смог бы что-то порекомендовать вместо. BASIC специально создавался чтобы все могли программировать и даже первая буква в его названии об этом говорит. Сегодня идея "все должны программировать" звучит очень громко, а такого языка каким был тот BASIC - нет.
По ссылке статья в Time, стоит заглянуть.

IPv6 всё ещё очень молодой протокол, очень. OpenBSD 6.5:

001: RELIABILITY FIX: May 3, 2019 All architectures
If a userland program sets the IPv6 checksum offset on a raw socket, an incoming packet could crash the kernel. ospf6d is such a program.

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

BGP глобальный для всего мира, но часто возникает желание управлять им локально - иметь полную синхронизацию причём быстро. Условия диктуют распределённые системы. В основе многих, если не всех, лежит принцип anycast адресации до ближайшего. Балансировка нагрузки, во многом, ложится на таблицы маршрутизации и очень важно чтобы в разных частях света она была одинакова и чем быстрее это будет происходить после изменений тем лучше. Это исключит перекосы трафика, сделает его путь предсказуемым.

Но BGP медленный, и вряд ли, в глобальном смысле, вообще синхронизирован на каждом из узлов участников. Насколько медленный посчитал Ben Cox и написал в своём блоге.
Принцип простой - запускаем счётчик (очень точный), анонсируем префикс и принимаем его в разных частях света. Меняем провайдера, повторяем. Худший провайдер Level3, время приёма префикса через которого от 18 до 50 секунд. У остальных сильно лучше, как правило всего пару секунд.

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

P.S. Часть статей из блога blog.benjojo.co.uk переведены на русский язык, соответствующие ссылки добавлены автором в оригиналы.

А вы знали, что для PF есть весьма функциональная веб-морда? Вот если не знали, загляните, возможно пригодится в работе:

https://github.com/sonertari/PFRE

#openbsd #pf #github

Иногда я пишу на Habr, обычно по вдохновению и если не ленюсь. Статья про то, что видно на заблокированном РКН ресурсе, немного статистики по адресам, IPv6 и про то как работают фильтры.

Ещё пару авторских абзацев, взгляд со стороны провайдера. Фильтр штука затратная если его вставлять inline для всего, затратная не только по деньгам, но и по результату, качеству получаемого трафика, надёжности. Для решения этой проблемы можно много чего применять, чтобы уменьшить трафик через фильтр:

1. Пропускать через фильтр только исходящий трафик
2. Пропускать через фильтр только трафик к запрещённым ресурсам
3. Поставить фильтр не в разрез, а сбоку - зеркалировать в него трафик
4. Или блокировать трафик только для средств проверки - Ревизоров. Конечно, применяются не только они, в любом момент из любого места сети может быть сделана проверка сотрудником контролирующей организации, но Ревизоры это делают постоянно.

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

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

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

P.S. Всех настоящих связистов с праздником. Интернетчики это седьмая вода на киселе, но они обычно за компанию отмечают.

В какое удивительное время мы живем, вот например рекламное видео нового терминала Windows https://www.youtube.com/watch?v=8gw0rXPMMPE

Вкладки, рендеринг текста, эмоджи и кастомизация вашего терминальчика в 2к19 от Microsoft.

Летом обещают залить в магазин приложений, а официальный релиз состоится ближе к концу года. Код для "поиграться" доступен уже сейчас: https://github.com/microsoft/terminal

DNS потихонечку переползает на Query Name Minimization, без особой помпы поддержка добавляется в существующие решения. Как результат всё меньше кто-то будет знать об истинных намерениях каждого. Наверное, это хорошо. Время "Интернета для технарей" прошло, поэтому заменили спокойствие - можно всё посмотреть и понять, на спокойствие обратное - меньше знаешь, крепче спишь.

Хм... ЦРУ открыло своё представительство в TOR: ciadotgov4sjwlzihbbgxnqg3xiyrg7so2r2o3lt5wz5ypk4sxyjstad.onion

​Ну теперь понятно, как защищаться от угроз сети.