Патчкорд

Краткая история PGP и сквозного шифрования доступного для всех, signal вроде как победил. Обязательно сходите по ссылкам из пункта про 2019 год: XMPP против Matrix и ещё один фронт защиты личных данных и децентрализованности.

Удобная и красивая обёртка для отладки и профилирования HTTP/HTTPS - htrace.sh. Может достаточно много, чтобы смело себе добавить в копилку с универсальными инструментами.

Стабильно плюс 60000 префиксов за год, может быть очень скоро нас ждёт таблица только из /24 процент которых растёт. А ещё порог 768k успешно прошли и ничего не упало, вроде бы. С IPv6 интереснее, что этот год что прошлый видно ускорение и почти 20000 прибавки. Сравниваем сами с прошлым годом, или смотрим за каждодневными изменениями здесь @bgp_table_bot.

Немного админского новогоднего настроения от моих любимых коллег - телеком ёлочка из DES-1005A. Это был не самый простой год для нас (а другие бывают?), но он уже почти закончился и можно чуть-чуть расслабиться, потому что в провайдерах не бывает выходных и праздников и с первого дня нового года начнётся такой же сложный и ответственный день и даже ещё сложнее, как и любой другой день года. С наступающим новым годом, мои поздравления специально для вас. И для всех коллег в телеком отрасли для кого каждый день эта работа, на нас всё держится :) и вы держитесь!

Is OpenBSD secure? https://isopenbsdsecu.re/

Немного пространные рассуждения по поводу управления трафиком в BGP, вывод из которых - полоса дешевле. Конечно можно утрамбовать 23Гбит/c в три канала по 10, 10 и 5Гбит/c даже на чистом BGP и даже со внешними провайдерами, но это будет как минимум не очень стабильно, в любом момент любое незначительное изменение приведёт к том что трафик уползёт в какую-либо сторону. Хорошо что современные магистралы научились считать трафик по 95 перцентилю и могут даже позволить залезть, внезапно, за границы оплаченного, но потом всё равно это припомнят. И даже комьюнити у многих есть, где можно сыграть тоньше, не у всех конечно. Но чтобы сохранить нервы вашей дежурной смены лучше брать побольше, заодно и от обрыва подстраховаться. С внутренними магистралями кажется проще, но это на первый взгляд. Чтобы красиво работало в динамике без бесконечных PBR и подкручивания веса интерфейсов надо иметь широкие равноценные каналы и IGP тут делу не поможет, скорее наоборот. А ещё не каждый SD-WAN настоящий и SR для простого TE может быть избыточен. Инженеры стоят дороже полосы, не надо скупиться.

В начале декабря грустили с другом, что мир ещё не родил альтернативу pgp, а вот и нет. https://t.me/cyberhermitage/460

От создателя GoBGP - RustyBGP. Управляется с помощью консольной утилиты gobgp и имеет такой же gRPC API, а производительность в 10 раз больше.

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

​Ждали новогоднюю IPv6 ёлочку? Вот она ipv6tree.bitnet.be В этом году скромнее, зато вернулись к привычной инсталляции. Пингуем 2a05:9b81:2020:1::XX:XX:XX, где XX цвет в RGB. Прямо сейчас видимо что-то подвисло, но наверное скоро заработает как надо.

Если никогда не применяли finger то вот вам повод - можно посмотреть прогноз погоды во многих населённых пунктах мира. Справка по использованию сервиса finger @graph.no. P.S. Ещё один прогноз погоды в curl.

Генератор псевдодеятельности на экране монитора, не потому что надо кого-то обмануть, хотя можно и так, а потому что красиво и технологично, даже для заставки годится. Есть несколько режимов, можно и в браузере если развернуть на весь экран будет тоже похоже. Есть ещё fakeupdate.net, но это не так завораживает.

Тест по BGP с упором на организацию внутренней архитектуры сервис провайдера: iBGP, MP-BGP, RR. 30 вопросов мне дались тяжеловато, темы которые до сих пор для меня сбоку. Но тесты для этого, в том числе, и нужны - показать где границы проходят.

На CNews собрали в кучу всю историю падения Айхора. Пострадавшие и так всё знают, а вот для остальных очень поучительная история получилась. https://www.cnews.ru/news/top/2019-12-18_vojna_vokrug_rossijskogo

Министерство обороны США планирует избавиться от своих IPv4 адресов не позднее чем через 10 лет и начать процесс продажи не позднее чем через 2 года: "S.1790 - National Defense Authorization Act for Fiscal Year 2020 / SEC. 1088. DISPOSAL OF IPV4 ADDRESSES". Всего 13 блоков по /8: 6.0.0.0/8, 7.0.0.0/8, 11.0.0.0/8, 21.0.0.0/8, 22.0.0.0/8, 26.0.0.0/8, 28.0.0.0/8, 29.0.0.0/8, 30.0.0.0/8, 33.0.0.0/8, 55.0.0.0/8, 214.0.0.0/8, 215.0.0.0/8 Оценить масштаб можно вот на этой карте (по ссылке в хорошем разрешении) ищем US Army и DoD. Карта 2007 года, на текущий момент считаем что unallocated регионов нет. Это примерно 1/20 всего теоретического адресного пространства. Вместе с отказом от IPv4 собираются списать и все устаревшие системы которые от них зависят и перейти на IPv6. Это же можно сделать уже и всем остальным, что уже больше похоже на скорое светлое будущее в мире где IPv4 больше никому не нужны, кроме спекулянтов. З.Ы. Спасибо большое за ссылку нашему подписчику, чуть не прошёл мимо этого, без вас никуда.

Если давно хотелось потрогать SD-WAN и понять из-за чего так много шума, но выглядит это сложно и не ясно с чего начать, то вам царский подгон. Лаба в стиле минимал техно =) https://neckercube.com/posts/2019-12-18-cisco-sdwan-basic-configuration-lab/

Из любой позиционной системы счисления в десятичную на bash: > echo $((2#111)) 7 > echo $((16#FF)) 255 > echo $((36#ZEBRA)) 59454982 На самом деле это просто, относительно, посчитать и в уме - никаких тебе делений, расставляй вес разряда умножай и складывай. Первые 255 можно в принципе в памяти держать, как и многие ключевые значения, вроде 0xFFFF. А вот обратно всё интереснее, но для этого bc есть. Там же из комментариев: > echo "ibase=2\n111"|bc 7 > echo "obase=2\n7"|bc 111

Сделать систему надёжной совсем не просто, даже если все нужные компоненты реализованы это ещё ничего не значит. Несколько правил, скорее вопросов которые сформулировал Mark Brooker: 1. Усложнение системы для обеспечения избыточности не должно ухудшать её доступность; 2. Система должна смочь запуститься в аварийном режиме; 3. Система должна гарантированно определять какие из компонентов рабочие, а какие нет; 4. Система должна иметь возможность вернуться в режим с резервированием. Каждый пункт тянет за собой массу подводных камней, например, если неверно определить что у вас упала сеть, а не компонент приложения и переключиться на резервный участок, ситуацию это как минимум не исправит, скорее всего добавит проблем из-за повышения нагрузки на другие компоненты системы. Стоит учитывать и чисто человеческие моменты, если инженер, пусть хороший или даже отличный сделает что-то, что для команды будет непонятным, общую доступность системы это вряд ли повысит, может даже ухудшит - люди ломаются чаще. Чем проще, тем надёжнее, как минимум для конкретного места в конкретное время.

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