Досмотрел запись NextHop 2019. Обязательно к просмотру про безопасность в BGP от Александра Азимова, история вопроса и что делать - принимать стандарт и использовать ASPA. Наверное, самый качественный и понятный доклад, может быть ошибаюсь потому что более менее на слуху.

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

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

Практически не было вопросов из зала, кроме последнего доклада Васильева Михаила из Facebook, которые тут были более чем в тему. Посмотреть целиком определённо стоит, запись по таймеру почти 9 часов, но там есть долгие перерывы.

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

Ещё немного о железе. Рекламный пост про 400Гбит/c чип, что само по себе хорошо, если рекламируют то значит есть рынок, спрос, области применения, массовость. Интересно, что с точки зрения реализации, законы физики остаются неприступной границей, однако подбираться к ней можно бесконечно близко.
Хочешь больше скорости, расширяй рабочую полосу спектра или увеличивай количество состояний и частоту. Сильно не расширишься, да и по частотам не попрыгаешь как хочется, везде разное затухание и потери. Но можно подобрать в старых границах то что раньше не смогли, потому что точности не хватало.
Чем больше количество состояний тем меньше между ними разницы, тем больше вероятность спутать одно с другим и ошибиться, поэтому и здесь предел вполне ощутимый.

В итоге, в одном чипе (пишут что впервые) удалось уместить 3x400Гбит/c (1,2Tбит/c) в одном канале внутри датацентра, увеличив ширину спектра до 150ГГц, эволюция начиналась с 50. В рамках города уже 2x400, дальше меньше - сильнее потери, надо меньше состояний, другая модуляция. Ждём пока доберётся до персоналок, а пока ищем в DWDM решениях.

​​Ого-го!

Лаборатория Касперского анонсировала бесплатный доступ к своему Threat Intelligence Portal для всех желающих!

https://opentip.kaspersky.com/

Первая моя ассоциация была примерно такой: Ого, появился русский аналог VirusTotal! Но в блоге, посвященном анонсу, ребята из ЛК это опровергают и выделяют следующие причины: их продукт использует больше технологий обнаружения, чем это делает зарубежный аналог, весь анализ проводится собственными средствами и технологиями, без привлечения внешних систем, а результаты анализа не доступны широкому кругу подписчиков, как это сделано на VirusTotal.

Хотя платная подписка для получения той самой Threat Intelligence все же присутствует :)

Бложик: https://eugene.kaspersky.com/2019/10/24/open-tip/

Если у вас вдруг когда нибудь возникал вопрос, почему стандартное разрешение текстового терминала 80x25, то вот вам ответ - https://exple.tive.org/blarg/2019/10/23/80x25/
Читать долго, но интересно. Давным, давно... всё началось из-за денег.

Инструмент мониторинга состояния префиксов на различных точках обмена трафиком от Oracle. Проверяет подписи RPKI, записи в IRR, наличие в SPAMHAUS и BOGONS (специальные, не публичные, не назначенные префиксы). Есть общая статистика по каждой IXP, наших нет, зато других много. Префиксы можно просмотреть отдельно и там своя статистика.
Общая информация есть в блоге, там же беглый обзор возможностей.

В начале недели состоялась Internet Measurement Conference /19, много серьёзных публикаций от более чем серьёзных докладчиков. Темы очень разные и всё читать, наверное, не имеет смысла, но интересные должны найтись.

Мой взгляд зацепился за анализ первой проведённой смены мастер ключа DNS - KSK Rollover, кто следил за ситуацией должно быть интересно узнать чем всё кончилось. Много графиков и подробностей. Дело сложное и совсем гладко оно пройти не могло, об этом стоит прочитать.

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

Почему-то, в связи с этими рассуждениями вспомнилась давнишняя статья про Fault Management System и как автор видел идею этого в NOC Project: https://habr.com/ru/post/126051/

Grafana делятся своими предположениями о будущем observability

1. Больший акцент на корреляциях между метриками, логами и трейсами
2. Использование новых сигналов для анализа (как, например, профайлеры)
3. Аггрегация логов без индексов

#observability

Кто старое помянет, тому глаз вон - как собрать dial-up сервер у себя на столе, включая телефонную станцию, используя доступные (современные) решения.
Модемный доступ не совсем история, не везде. Не знаю как это выглядело в то время, в комментариях пишут что точь в точь. Мне кажется, у провайдеров побольше модемы какие-нибудь стоечные были и многоканальные.

Вчера был день рождения у netcat, инструмент который стоит ввести в свой арсенал, если он ещё не там. А завтра обещают юбилей Интернету, но праздновать можно всю неделю :)

​Ещё один привет из вечности - цветной ANSI ASCII Art. Настоящее искусство.

Обязательно к прочтению: хронология аварии - пожар в датацентре. Взгляд со стороны админов Одноклассников. Лучший способ научиться на чужом опыте, или хотя бы задуматься. Даже для ситуаций на которые объективно нельзя повлиять, надо быть готовыми к тому чтобы встать, выйти и выключить за собой свет, возможно остаться в живых.
Пожар случился вот здесь. По ссылке оценка ситуации со стороны датацентра.

Не DMVPN единым, если хочется построить большую, масштабируемую, распределённую корпоративную сеть. Подробная концепция с описанием использования 6rd совместно с GETVPN для замены более традиционного подхода от Nicholas Russo в pdf.

Если просто включить OSPF то он будет работать что скорее всего устроит большинство. Но можно немного настроить и получить отсутствие или минимальный простой в передаче трафика при наличии резервного линка. Для этого есть механизм fast reroute: RFC5286 и связанные с ним. Суть которого в том, чтобы подготовить альтернативный маршрут заранее и не тратить время на его поиски в момент аварии.
Как это настроить (не сложно) для Juniper и Cisco.

Про bmon на tecmint.com - утилита для оперативного мониторига с картинками прямо на сервере. Может показывать и строить статистику по очередям, типам трафика и ошибкам. Последняя версия 4.0.

Для работы со множеством одинаковых хостов можно использовать почти традиционные инструменты, такие как Cluster SSH. Выглядит интересно - много окошек сессий SSH в которые одновременно вводятся команды. Статья про то как поставить, настроить и начать работать.
С сотней узлов, да даже с десятком такого не провернёшь, не говоря про тысячи, да и не надо там другие механизмы и подходы.

Мне подсказывают, за что вам отдельное спасибо, что для одновременного ввода достаточно tmux - режим synchronize-panes. Для использования с ssh, можно самим заскриптовать или использовать готовое.

​В холиваре CLI против GUI точку поставить вряд ли удастся, потому что каждому своё. Но добавлять новые аргументы никто не мешает. Статья с научным подходом, правда основа онлайн опрос, но всё по полочкам разложено - статистика по возрасту, опыту, в общем всё как надо, с ссылками на другие работы. Вся суть исследования на прикреплённых картинках - разным целям, разные интерфейсы.

Минутка программерского юмора, пусть немного и с бородой:

function f() {
sleep "$1"
echo "$1 "
}
while [ -n "$1" ]
do
f "$1" &
shift
done
wait
echo

$ ./sleepsort.sh 5 3 1 7 5 10 3 2 4
1 2 3 3 4 5 5 7 10

sleep сортировка. Запускаем n параллельных процессов по числу элементов которые нужно отсортировать. Каждый процесс перед завершением ждёт количество времени пропорциональное значению элемента. Процессы с меньшей паузой, меньшим элементом, выведут результат раньше. После завершения всех процессов получим отсортированную строку с элементами от меньшего к большему.
Ограничений у данного способа довольно много, а из плюсов - предсказуемое время этой самой сортировки. На практике применять не стоит ;)
Вообще, над сортировкой достаточно часто шутят, один из основополагающих элементов.