Привет. На связи linkmeup.

А что значит на связи? На какой связи? Когда мы стали так говорить? 

Или тот же Stay Tuned? Ну олды-то знают, а новое поколение?

Почему телефонную трубку чаще вешают, чем кладут?

Как вести дела с пацанами, которые уехали в Америку, но забыли изобрести не то что телеграф, а даже паровой двигатель?

Как отправить по почте ребёнка? 

Что делать, когда тебе 20, а ты ещё ничего не изобрёл?

Кем надо быть, чтобы в 19-м веке выбить лютую гору бабла из Англии на совершенно дикий проект - бросить через Атлантику 4000 км кабеля диаметром 2см на глубину 3-4 км. Пять раз. Выбить гору бабла. Четыре попытки провалить.

Итак, вы гиперскейлер, давайте отталкиваться от этого. Потому что если нет — собирайте хоть 3-tier на OSPF. А гиперскейлер вы в том случае, если у вас большая сеть на тысячи хостов, а лучше стоек. Вы уже попробовали топологию Клоза. Сначала вам очень нравилось. Она вся такая плотная, регулярная и масштабируемая — просто прелесть.

Как только кластер начал грозить вырасти за 2000 хостов, вы стали надстраивать ещё один уровень коммутации и докидывать в него всё новые и новые группы стоек. И продолжаете расти на десятки тысяч узлов. У вас отработанный дизайн, автоматизация ввода нового оборудования. Всё на потоке.

Но отчего‑то вы несчастливы. Вам плохо спится. Гложут сомнения и дурные мысли.
А всё дело в эпохе 400G! Вы долгие годы строили свою сеточку на 25+100, и всего всегда хватало. Раньше. А теперь надо на хосты соточку спустить. А значит и аплинки надо расширять, да вы и сами уже понимаете, что пора: ещё несколько лет — и эта сеть станет устаревшей. 200G, 400G, SerDes по 100 Гб/с на PSM4. Тут думать надо.

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

Вот есть у вас сотня коммутаторов или маршрутизаторов. Это много или мало?

Ну вроде как мало. А если надо на всех разом нового сотрудника добавить? А потом удалить уволившегося? А потом поротировать скомпрометированные пароли и ключи?

И тут приходит служба безопасности, которая, во-первых, хочет централизованно контролировать, у кого какие доступы, во-вторых, актуальны ли они на железках, в-третьих, ещё и смотреть, кто что когда запускал, да ещё и разрешать или запрещать это делать («Просто продолжай, не останавливайся» © СИБ).

Ну вот совсем уже и не мало. Чувствуете, чем это пахнет? Даааа, TACACS-ом.

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

Я в целом человек довольно безалаберный. В первую очередь, потому что память у меня короткая. Единственное, что я (как мне кажется) не забываю - это отдавать деньги.

Когда я был инженером, и когда у меня не было троих детей, я с горем пополам ещё удерживал в своей голове все дела и обещания.

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

Но потом: отец детей, мать проекта, руководитель людей, хобби какие-то начали появляться.

Сетевой стек Linux не прост даже на первый взгляд: приложение — в юзерспейсе, а всё, что после сокета, — в ядре операционки. И там тысяча реализаций TCP. Любое взаимодействие с сетью — системный вызов с переключением контекста в ядре.

Чтобы лишний раз не дёргать ядро прерываниями, придумали DMA — Direct Memory Access. И это дало жизнь классу софта с режимом работы kernel bypass: например при DPDK (Intel Data Plane Development Kit). Потом был BPF. А за ним — eBPF. 

Но даже помимо хаков работы с ядром есть такие штуки, как sk_buff, в которой хранятся метаданные всех миллионов протоколов. Есть NAPI (New API), которая призвана уменьшить число прерываний. Есть 100500 вариантов разных tables.

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

Привет. Я Марат Сибгатулин — сетевик в Яндексе, работаю в команде Yandex Infrastructure. И сегодня я расскажу вам одну поучительную историю.

Жили были два сервера. Да и не сервера вовсе, а виртуальные машины. Жили не тужили, добро наживали, скриптами разными обрастали. Три года они трудились на славу облака да во имя автоматизации. Пока не наступили чёрные дни для RAID-массива на гипервизоре.

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

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

Это вторая статья - техническо-практический разбор протоколов и интерфейсов автоматизации сети.

Если хочется исторической справки, я отсылаю читателя к статье-спутнику, в которой мы двигаемся от начала времён в будущее человечества. Какую роль сыграли в нашем настоящем IETF, ISO, олдовые и современные вендоры и даже просто люди.
В этой же мы раскрываем дерево XML, пробуем на вкус капабилити NETCONF, шлём первые RPC и наконец уже расставим в правильном порядке буквы YANG, OpenConfig, gNMI.

Практическую пользу вам принесут только обе прочитанные статьи. Вторая без первой будет непонятна. Первая без второй - беллетристика.

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

• 0. АДСМ. Часть Нулевая. Планирование
• 1. АДСМ. Часть первая (которая после нулевой). Виртуализация сети
• 2. АДСМ. Часть Вторая. Дизайн сети

• Одна версия дизайна везде.
• Два вендора, образующих две плоскости сети.
• Один ДЦ похож на другой как две капли воды.

Содержание

• Введение и краткая история виртуализации
• Типы виртуальных ресурсов — compute, storage, network
• Виртуальная коммутация
• Инструменты виртуализации — libvirt, virsh и прочее
• Заключение

Миран