Патчкорд

Чтобы понять как что-то работает стоит сделать своё - Traceroute на Python. Я бы сказал что надо быть подготовленным читая этот текст, как минимум в Python потому что реализация даётся как есть, хотя и с предварительным описанием алгоритма. Но наверное кому-то так будет нагляднее.

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

Чуть день IPv6 не пропустили, дата не круглая поэтому просто включаем, без шампанского. Прогнозы про 5% вроде ещё в силе - по Гуглу не дотянули до 45%, но близко, всем не очень до этого было.

Вчера в моей статье на Habr про обратную маску, один из читателей нашёл ошибку в ACL которая там была с момента написания статьи, больше 10 лет назад и после 100К просмотров. Я повторно и внимательно вычитал и нашёл ещё одну ошибку уже в другом ACL. Это к вопросу о сложности и нужности, о чём как раз зашла речь в комментариях. Тут иногда в простых префиксах ошибиться можно так что несколько часов на поиск уходит, с обратной маской всё гораздо запутаннее. Чем проще, пусть даже и многословнее, тем в конечном итоге надёжнее, да порой надо экономить на ресурсах железа, но это порой.

А вот и 30Tbps, из которых 20Tbps в Сан-Паулу. Причем закопано емкости у них по Сан-Паулу раза в 2 больше (на момент марта 2021 было что-то около 32Tbps). Vai Brasil!

RRDtool всё ещё рисует самые красивые картинки, в данном случае это MRTG. Бразильцы молодцы.

Дополнение к предыдущему посту про борьбу с DDoS от нашего подписчика, за что от меня отдельное и большое спасибо, про работы в области защиты от DDoS: Так есть проекты подобие http://paaddos.nl/ Также ведут публичные DDoS fingerprints от одного из известного CDN поставщика - Clearing House https://github.com/ddos-clearing-house/documentation/wiki с описанием подробностей в блоге https://www.concordia-h2020.eu/blog-post/setting-up-a-national-ddos-clearing-house/ также недавно, в январе 2023 года вышла еще одна работа Defending Root DNS Servers Against DDoS Using Layered Defenses https://www.isi.edu/~johnh/PAPERS/Rizvi23a.pdf на конференции Comsnets 2023 https://ant.isi.edu/blog/?p=1948 То что мне приходилось наблюдать 10-20Гбит/c спасала собственная широкая полоса, а в текущий момент широкая полоса нашего провайдера. Наверное, без этого компонента противопоставить что-то в ответ проблематично.

Когда у вас большая anycast сеть с серверами в разных частях света и на вас обрушивается DDoS, то можно попытаться перераспределить трафик между сайтами так чтобы уменьшить его влияние на сервис, заранее к этому приготовившись. Статья на APNIC так себе, а вот публикация на Usenix очень подробная с перечислением методов управления трафиком и последствиями этого управления. А ещё я вспомнил про доклад ИВИ на Пиринговом форуме 2018, где anycast и распределённый пиринг сам по себе хорошо помогает в случае DDoS, размазывая нагрузку на всю сеть.

Если вдруг нужен моноширный шрифт - Spleen 2.0, в разных размерах, для разных операционок. Я не любитель, просто увидел DOS в описании :)

Текущее состояние борьбы с bufferbloat со стороны IETF: стандарты, черновики, протоколы. Ещё одна сторона борьбы с дизайном пакетной передачи и hop-by-hop принципом, когда хочется чтобы источник и приёмник и многочисленные посредники договорились о скорости передачи, а не реагировали на проблемы постфактум, переполняя буферы и сбрасывая скорость до 0. Причём договориться надо ещё и между уровнями сетевого стека, далеко не прозрачными. И пока лучшее из придуманных решений сбрасывать пакеты по какому либо из алгоритмов, не дожидаясь пока буферы переполнятся, отдавая контроль скорости передачи вышестоящим протоколам, в надежде что они умеют это разруливать.

Свободное пространство BGP IPv4 full-view 2001-2023, год/cек, 640x480 gif

Я решил не бросать на полпути и сделать красиво. Визуализация свободного пространства в full-view ipv4 с помощью ipv4-heatmap начиная с 2001 года до 2023. Исходные данные RRC0 первый файл года, за исключением 2021, потому что там какая-то аномалия в исходных данных - резкий всплеск занятого пространства, поэтому для этого года используется первый файл февраля. На картинке цветом - свободные области, соответственно, чёрное пространство - занятые. Каждый пиксель /24. Цвет показывает непрерывность области, чем больше подряд незанятого места тем краснее. С течением времени мы можем наблюдать как красные области разбиваются на более мелкие и зеленеют, иногда происходит и наоборот. Левый верхний угол первая - первая четверть всего адресного пространства, под ним вторая четверть, справа внизу - третья четверть, над ним последняя. Хорошо видно что разные области заполняются неравномерно, да и вообще есть интересные места куда посмотреть. Я не стал добавлять подписи кому что принадлежит, выделил только зарезервированные на данный момент области, но стоит учитывать что на 2001 год картина с резервами отличалась. Исходные картинки большого размера, гифка поменьше, чтобы было удобнее смотреть, и то мой компьютер не сильно тянет, в отличие от телефона который поновее.

Свободное пространство BGP IPv4 full-view 2001-2023, год/cек

Ээх... Даже уже РБК знает что всё сломалось.

Вот вам хороший повод накатить с утра. Праздник же! https://servernews.ru/1087102

Случайно в поиске вылезла моя статья на Habr от 2016 года про свободные блоки в BGP, которые не видны в анонсах. Залез посмотреть на код который я писал, понял что я ничего не понимаю, но он запустился и я его прогнал по актуальным данным. Данные не совпали с моими представлениями :) и с теми данными которые были приведены в статье тоже не совпали. В итоге я нашёл там ошибку, прямо такую которая привела к двукратному увеличению в общей оценке по параметру количества префиксов выраженных в блоках по /8 и /24. Саму статью я править не стал, за всё время никто ошибку не увидел, да и на смысл статьи она не влияет сильно, тем более сейчас. В коде тоже есть глюк, и я не понял где он, зато понял как его обойти, исключив одно из вычислений в принципе, так как оно было нужно для другой статьи на Nag, но там ошибка меньше, порядка 2% в сторону увеличения. Итак, текущее состояние с дырами в full-view в сравнении с подкорректированными данными за 2011 и 2016. На текущий момент если сложить всё вместе - чуть больше 38 блоков по /8 не видно в анонсах. Это обычные адреса, все зарезервированные я уже исключил. В 2016 году таких было 54,5, а в 2011 чуть больше 79 блоков по /8. Наверное, они где-то используются, как минимум на IX, да и в целом никто не заставляет их использовать в публичном пространстве, но тенденция к уменьшению хорошо видна. Самый большой невидимый целый 48.0.0.0/8.