50 MIOPS, 1,6 Тбайт в секунду, до 10Пбайт в одной стойке. Новая хранилка ClusterStor E1000 от Cray - можно заказывать.

*BSD ламповая система, там даже у root есть настоящее имя. А ещё написано про то зачем используется амперсанд в конце поля полного имени.

sudo для Windows, привыкшим к Linux админам должно пригодиться.

Можно скачать бинарники или воспользоваться скриптом установки, только надо в него заглянуть и поправить каталог назначения.

З.Ы. Пока вспомнил. Как правило я ставлю и использую (как минимум пытаюсь) все инструменты которые упоминаю, некоторые приживаются - за полтора года с PopCom могу только похвалить, реально удобно.

Интересно наблюдать за тем как меняется баланс от: "Используем протоколы и формализованное взаимодействие между частями системы на готовых реализациях, изменяя лишь дозволенные настройки" - условно, "админский" подход. В сторону "программного" подхода: "Формализуем только данные и их форматы и делаем с ними что хотим".

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

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

Многие серверные инструменты поддерживают возможность, наравне с определением параметров поведения протоколов, задавать скриптовую обработку, определять поведение непосредственно. Причём выбор того или иного варианта использования часто равнозначны, можно написать перловый скрипт для FreeRADIUS, а можно то же сделать с помощью настроек. Всё зависит что полезно в конкретном контексте: гибкость, уникальность, переносимость, унификация, удобство поддержки.

Производительность CPU современных сетевых устройств давно доросла до возможности использовать универсальные языки и программные подходы для решения специфических сетевых задач, налету. В то же время, универсальные платформы доросли до производительности передачи трафика специализированных сетевых устройств. Итого в современности, мы можем используя Python получить BGP Flowspec от соседа и сформировать нужные ACL самостоятельно, даже если такая возможность не реализована на данном устройстве. Это видео с коротким описанием проблематики и подхода, кусками использованного кода и настроек, так что финальное решение всё равно придётся писать самостоятельно, главное что это можно сделать.

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

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

Есть у Juniper добротный проект Day One+. Это на случай если ты всю жизнь примусы починял, но вдруг тебе неожиданно понадобилось стать сетевиком, а ты езернета в руках не держал.
Ну то есть это просто набор пошаговых инструкций для совсем зелёных новичков, где расписано и как в стойку железку поставить, и как основные вещи настроить и куда бежать за документацией на все случаи жизни.
Молодцы, одним словом.

А у других вендоров есть нечто подобное?

https://www.juniper.net/documentation/dayoneplus/en_US/day-one-plus

​Marek Majkowski из CloudFlare ускоряет выборку уникальных значений из большого (очень большого списка) с 2 мин до 12 секунд, а потом ещё в два раза до 7 секунд. Делает он это путём реализации новой утилиты, код которой можно найти на GitHub. В статье немного математических терминов, про фильтр Блума надо будет почитать где-нибудь в другом месте, и много профилирования кода, а ещё про кеш и современные процессоры.

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

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

В ядро Linux хотят добавить расширенную поддержку для работы с заголовками IPv6, в частности, упросить добавление новых опций в заголовки расширений. По стандарту они уже могут там быть в TLV, что наверное максимально гибко, но в ядре не было соответствующего стандартизированного механизма.

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

Про базовые подходы проектирования маршрутизации в опорной сети, в данном случае, для интернет провайдера с радиодоступом, что никак не отражается в смысле статьи. В основном про выбор способов управления трафиком и глубину этого способа - от коммутируемой сети и дальше, плюсы и минусы каждого подхода, без особых подробностей всё на понятийном уровне. Про всякие SD* и SR* не упомянули. Где-то за сценой видны ушки Микротика, но статья не про это.
При том что вендор, несомненно, влияет на расстановку акцентов в подаче материала. Читаешь, например, Cisco MPLS где всё начинается с LDP, а дальше всё остальное. А читаешь Juniper MPLS, а там LDP называют не очень полезным протоколом и вообще речь про него заходит только после того как две главы про RSVP-TE подробнейшим образом расписали. Вот и как тут выбор сделать, тем более правильный.

Ещё один клиент для многих утилит сканирования сети - GoScan. Интерактивный интерфейс, готовый набор команд, база данных с результатами работы. Работает в Linux и для Docker всё готово, куда теперь без него.
Может мне кажется, но в последнее время в поле зрения попадает много обёрток над проверенными годами инструментами, а новых оригинальных инструментов которые на слуху, не видно?

С приходом универсальных инструментов на специализированные устройства происходят интересные казусы. Например, SSH пытается разрешить обратное имя по IP и у него обычно это получается, так как DNS обычно настроен на серверах, чего нельзя сказать про коммутаторы. Поэтому либо настраиваем, либо отключаем: UseDNS no в sshd_config. Похожая, но другая классическая проблема у Cisco, решается по другому.

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

Большая статья про URL и историю современного Интернета в блоге CloudFlare. Много общеизвестных вещей, много отступлений не совсем по делу, но интересные детали тоже присутствуют. Повествование построено на разборе составных частей URL, для каждой из которой дано описание и какие-то исторические сведения. По сегодняшним меркам, из-за объёма, не тянет на лёгкое чтение, но в итоге получился такой исторический ликбез, без погружения, то что, предполагается, должны знать все.

​Прямо ухх статья, про Unix-way и вообще философию CLI, что мы потеряли или не потеряли за всё прошедшее время. Классический подход, одна утилита - одна функция, отсюда есть отдельно cat и tac. При этом количество аргументов стандартных утилит выросло иногда в разы. Плохо это или хорошо? Чем отличается в сложности построить конвейер из 10 элементов или применить 10 опций у одной утилиты? Автор достаточно критично проходится по "старой школе", что наверное не плохо, нельзя держаться за реалии 50 летней давности.

С другой стороны, очевидный минус который я вижу это наименование опций командной строки для разных утилит, когда "-L" всякий раз значит что-то разное. Не всегда, но полагаться на то что опции одинаковые для разных инструментов не стоит. И тут разница, запомнить 10 утилит с 5 опциями в каждой, или 5 со 100. Может быть вообще можно обойтись и одной утилитой, но чего не отнять - сложность увеличилась. Наличие конвейера всё же заставляло поставлять более менее стандартизированный поток вывода, иначе не заработает.

Но тут опять стоит согласиться с автором, мало кто запоминает ВСЕ опции. Наличие возможности быстро найти то что нужно нивелирует многие спорные моменты. Да и совместимость никуда не делась, можно писать в old school стиле и всё будет работать.

Сделал себе DoH сервер, на всякий случай, а потом подумал, почему только себе и решил поделиться с вами https://host-correct.ru/doh, чем мы хуже Cloudflare :)

Побочным эффектом запилил munin плагин для Knot Resolver (переделал из Unbound плагина). Быстро не нашёл готового, поэтому немного поразмял мозги.

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

Мне очень нравится организация файла конфигурации у Juniper: строгая, иерархическая и структурированная. Правда, как оказалось, после того как у нас появился Juniper, самый не очевидный момент для моих коллег это включение интерфейса из состояния disable. Вот такая конструкция delete interfaces xe-0/0/0 disable, вызывает минимум удивление, а максимум эмоций я описывать не стану. При этом Juniper самый логичный из всех - установить настройку всегда set, убрать настройку всегда delete.

В Нuawei используется undo, чтобы убрать настройку, но там в целом подход больше похожий на Cisco CLI - undo shutdown, включит интерфейс.

У Brocade в контексте интерфейса можно написать как no disable, так и просто enable. Где-то не далеко D-Link у которого есть пара enable/disable для сервисов и конструкция conf ... state disable/enable для интерфейсов.

А вот больше всего удивления от delete interfaces xe-0/0/0 disable. Что-то в этом delete не то для нашего брата админа, ассоциации вызывает другие, может слишком знакомое слово, Juniper на заметку.

Junos маршрутизатор собственными руками? Не вопрос!
Теперь вы можете собрать его используя cRPD и LinuxKit
"На момент написания этой статьи бесплатная пробная версия для cRPD отсутствует" - пишет автор статьи. "Но когда это нас останавливало?"- скорее всего подумали вы.
"Тем не менее, многие из Juniper работают над тем, чтобы cRPD стал доступнее."- ответит вам автор.

Что такое сRPD?
cRPD берет некоторые из лучших частей Junos (RPD, MGD), дезагрегирует и упаковывает их в легкий образ контейнера.

Что такое LinuxKit?
Linuxkit - это "набор инструментов для сборки настраиваемых минимальных, постоянных дистрибутивов Linux".
Он позволяет вам собрать свой собственный легковесный дистрибутив Linux, используя контейнеры.

Пойду приготовлю себе маршрутизатор! - 🔥
Меня это не остановит!  -💪
Не, не надо! - 😏

Хотите обсудить? Айда в чат - https://t.me/automate_devnet

#juniper #crdp #linuxkit

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

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

Итого, инфраструктура вплоть до симметричного гигабит канала до конечного абонента у нас была построена уже лет 10-15 как. И как минимум один переход с обычного Ethernet до Fast Ethernet операторы уже пережили и многим это обошлось только в смену оборудования, не кабельной инфраструктуры (если изначально не сильно экономили), замена которой обходится дороже всего. Сейчас вялотекущий переход от Fast Ethernet к Gigabit Ethernet, найти парочку операторов с тарифами больше 100Мбит/c не проблема.

Почему у нас так, потому что у нас не было ничего, а тем у кого было строить заново очень сложно, вот коаксиал и дотянул до последнего. Но переход на 10Гбит/с легко не дастся никому. И тут мы уже можем оказаться в отстающих и использовать свою кабельную инфраструктуру до последнего, вместо того чтобы строить новую.

На этой неделе ко мне подошёл коллега, кого я обманываю, конечно, написал в чате, и говорит: "Хочу IPv6 себе домой, можно?". В такой безвыходной ситуации я ответил что можно, вот у нас туннель настраивай и подключайся, всё работает последние много лет. Но он оказался настойчивый, от туннеля отказался и потребовал себе всё нативно.

И это странно. Простому абоненту в домашних условиях не нужен IPv6. Точнее ему всё равно что там с той стороны экрана - картинки открываются, музыка играет, вот основная цель. И своё мнение я не изменил за прошедшие 6 лет. В первую очередь это надо провайдеру, по многим причинам, и как продать это абоненту, или директору, или инвестору уже его проблемы. Иногда бывает, что в IPv4 не работает и случается повышение интереса именно к IPv6 - с 0 до 10 в год ;). Но обычно в IPv4 всё быстро чинится, или в IPv6 быстро становится нерабочим. В наших реалиях это когда РКН что-то блокирует, хотя бывает и по-другому.

Несомненно, мой коллега не является обычным абонентом и у него другой интерес к этому, что не может меня не радовать, но и чуть печалить, потому что такое случается не чаще раза в три года. Зато теперь на одного абонента IPv6 в мире больше.

Наш проект законсервирован и уже давно, но многие другие работают и делятся опытом - видео с IETF104 2019 год и презентация в PDF:

1. Deutsche Telekom. Простая сеть без туннелей и PPPoE. "Модные" IPoE и даже термин такой звучит. IPv6 only опорная сеть.
2. DHCP Relay и PD. Описаны типичные проблемы, у нас такие же были при внедрении.
3. Несколько разных /56 абоненту в CPE, чтобы дифференцировать услуги, их провижининг. А вот это чуть необычно и вызвало вопросы в зале, в том числе. Но каждый строит так как ему удобнее, значит так было надо.
4. Про MTU, куда без этого.

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