Как построить сеть, когда каждый байт на счету и ваши GPU не могут простаивать не секунды? Infiniband, UltraEthernet, RoCEv2, MRC и куча других страшных слов и аббревиатур. Чем одно отличается от другого, зачем все это придумали и что сейчас происходит в индустрии, какие технологии ещё только зреют, а какие уже используются в продакшене при построении AI/ML-сетей. Как строят кластеры большие дяди? Хочешь узнать обо всем этом, тогда приходи послушать доклад ж-)

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

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

В классических сетях измерить задержку относительно просто: маршруты стабильны, топология предсказуема. Но что делать, если ваши оконечные узлы движутся? А теперь представьте, что движутся ещё и промежуточные узлы, которые передают ваши данные! Для погружения в проблему расскажу про динамические беспроводные Mesh сети с академической стороны на простом инженерном языке с примерами. Посмотрим на такую сеть как на живую инженерную систему, где задержка зависит от движения, радиосреды, плотности узлов и алгоритмов маршрутизации. Где такие сети нужны и как с ними работать. Отдельно разберу разработанный метод измерения задержек в динамически изменяющихся сетях, когда привычные методы диагностики дают неполную или искаженную картину.

В реальных инфраструктурах межсетевые экраны и VPN-шлюзы часто обслуживают сотни и тысячи правил, объектов, маршрутов, сертификатов и пользователей. Ручное выполнение операций через графический интерфейс становится медленным, подверженным ошибкам и плохо масштабируемым. Поэтому возникает необходимость в автоматизации рутинных задач через API.
В докладе расскажу как используя API «Континент 4» можно автоматизировать типовые операции администрирования, снизить количество ошибок и повысить скорость внесения изменений в инфраструктуру сетевой безопасности.

Разберем кейсы применения supervised и unsupervised machine learning - детект выбросов, кластеризация, ассоциативные правила, градиентный бустинг. Для каких типов атак они хорошо работают, для каких не подходят. Как бороться с ложными срабатываниями и вычислительной сложностью. Open-source и сommunity решения в качестве альтернативы - NTA vs NGIDS.

Многие инженеры считают, что Wi-Fi на MikroTik «плохо работает» и построить на нём хорошую беспроводную сеть невозможно. В докладе я разберу, откуда появились такие утверждения, какие технические и исторические причины за ними стоят, и насколько они актуальны для современных версий RouterOS и новых Wi-Fi-пакетов.

Скорости передачи постоянно растут. ИИ кратно увеличила объем гоняемого трафика (распределенное обучение). Старые технологии передачи (DWDM C-band, DP-QPSK, G652) близки к исчерпанию емкостей, а прокладывать много магистральных кабелей на 10ки тысяч километров дорого. Обзорный научно-инженерный доклад на тему актуальных исследований и разработок. Мультидиапазонность, скоростные ЦАП/АЦП, раман в каждый дом, интегральная оптика, "живая" сеть, полые волокна.

У нас в Okko есть свой CDN, а в нём больше 180 аплинков (от 10 до 600 Гбит/с каждый). Пиковый трафик более 8 Тбит/с. Управлять этим вручную стало очень сложно.

В докладе расскажу, как мы пришли к созданию Uplink Load Balancer (ULB) - сервиса, который автоматически балансирует трафик между аплинками, не допускает перегрузок и учитывает стоимость каналов.

Поговорим о:
— зачем вообще что-то разрабатывать;
— песочнице с FullView (и зачем она вообще нужна);
— архитектуре ULB;
— механизме резервирования полосы;
— cost-based balancing - учёт тарифов, предоплаченной полосы и burst’ов.

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

В докладе расскажу как мы реализовали и внедрили в эксплуатацию систему контроля доступа на сетевое оборудование. Расскажу об опыте эксплуатации и реальных проблемах, которые пришлось при этом решать.

... или почему в Яндексе до сих пор его используют? Так ли хорош вендор на букву F, как его рисуют? Как слезть с его иглы и зажить жизнью добропорядочного гражданина? Рассмотрим основные киллер-фичи этого вендора и как собрать тоже самое, но на правильной OS.

Широкие L3-каналы с потребностью в ГОСТ VPN предъявляют повышенные требования к производительности криптографической инфраструктуры. Отдельной VPN-платформы в реальной сети с миксованным трафиком может оказаться недостаточно для использования на канале с пропускной способностью 10 Гбит/с и выше.
Доклад посвящён масштабированию ГОСТ VPN с помощью фермы криптокоммутаторов. Будут рассмотрены принципы построения такой схемы, особенности распределения трафика, влияние VPN-инкапсуляции на MTU, а также практическая реализация на тестовом стенде с настройкой ключевых компонентов и проверкой работы решения. Отдельно будет проведено сравнение с альтернативным подходом — применением аппаратного криптографического ускорителя VPN производительностью 40 и 100 Гбит/с: его преимущества, ограничения и сценарии применения.

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

При разработке СЗИ возникает сложность, связанная с отсутствием возможности генерирования реалистичного трафика. Из-за этого усложняется процесс функционального/нефункционального тестирования, связаного с трудоёмкостью процесса: требуется вручную конфигурировать каждый тест (настраивать окружение, объект тестирования и др.), затрачивать значительное время на измерение и анализ результатов, найти дорогостоящее оборудование для некоторых измерений, а так же многократно повторять процедуру тестирования. В докладе разберем, как мы решили эту проблему, разработав платформу на базе Kubernetes, которая позволяет автоматизировать тестирование в процессе разработки СЗИ и не только, и не требует дорогостоящего оборудования.

В крупных инсталляциях на базе oVirt получение метрик через стандартные механизмы может занимать десятки минут и создавать значительную нагрузку на систему управления. Использование REST API для извлечения метрик в таких сценариях плохо масштабируется, а хранение метрик в реляционной базе данных усложняет работу с ними. У себя мы переработали этот слой: реализовали единый REST API для метрик, перевели хранение текущих значений в in-memory и встроились в существующий процесс сбора данных, перехватывая поток метрик. Все данные объединены в одном endpoint в формате Prometheus, включая метрики с хостов через Node Exporter, который теперь устанавливается и настраивается «из коробки». В результате мы сократили время получения состояния инфраструктуры до секунд и получили расширяемую систему сбора метрик с возможностью добавления новых источников и простой интеграцией с внешними системами мониторинга. Обсудим ограничения подхода, сложности, вставшие на пути, и способы их решения.

Расскажу почему мы отказались от концепции NGFW в пользу открытой архитектуры опенсорса, как заменили PaloAlto на FreeBSD и как держим нагрузку в 140 тыс RPS.

Когда зависеть от одного вендора стало опасно, мы собрали мультивендорную EVPN-фабрику на открытых протоколах и упёрлись в то, что один и тот же сервис на Juniper, Huawei и B4COM настраивается по-разному, а устройство не всегда делает то, что ответило. Так появился NSD - сервис поверх NetBox, который прячет вендорские различия за набором примитивов, применяет конфигурацию с перепроверками, смешивает NETCONF и CLI в одном плане и диагностирует конкретику, а не всё устройство. Расскажу, как он устроен, как мы выводили NETCONF-формы из обычных CLI-команд, на какие особенности вендоров наткнулись по дороге.

Спойлер: наш SDN — это OVN. Раньше связность оверлея с физической фабрикой держалась на собственном сервисе — агенте, который анонсировал маршруты в фабрику. Затем в OVN появилась нативная поддержка интеграции с L3-фабрикой через BGP, а позже её расширили до BGP-EVPN.

В докладе расскажу, как переход от самописного агента к нативному BGP-EVPN в OVN упростил настройку сети и на стороне облака, и на стороне андерлея, с какими проблемами мы столкнулись, какие сценарии это открывает и куда мы планируем двигаться дальше.

Десятки лет мы строили слои абстракций, позволяющие среднестатистическому питон-разработчику выживать в этом мире: архитектура компьютера, PCIe, ОС с kernel+user space, TCP/IP/Ethernet.

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

Смотрим, как устроены сервер, GPU-карта, чем плохи Kernel и TCP, где нам тут сэкономить миллисекунды и как ситуацию спасют RDMA, Infiniband и RoCE.

Большой объём телеметрии создаёт ощущение полного контроля, но на деле может увеличивать нагрузку на системы, усложнять работу аналитиков и скрывать действительно значимую активность. В докладе рассмотрим инженерный подход к оценке событий: от категоризации источников и определения минимально достаточного контекста до построения единой модели данных и проверки принятых решений в реальной эксплуатации. На телеметрию мы посмотрим одновременно с двух сторон: как разработчики EDR, определяющие состав и структуру событий, и как специалисты SOC, использующие эти данные для обнаружения угроз, threat hunting и расследований. Поговорим о том, как отделить полезную наблюдаемость от информационного шума и превратить оптимизацию телеметрии в цикличный процесс, результаты которого можно подтвердить измеримыми показателями.

До того как появились Pikabu, LOR, Habr и VK, IT-шники 90-х сидели в Фидонете. Это была полностью децентрализованная, асинхронная и некоммерческая сеть с уникальным контентом, работающая поверх аналоговых телефонных линий. В этот раз мы раскопаем стюардессу: разберем архитектуру адресации 2:5077/22.10, посмотрим на "микросервисы 90-х" (мейлеры, тоссеры и трекеры), вспомним, как бились за аппаратные модемы US Robotics, и узнаем, где зародился весь токсичный IT-фольклор рунета. А главное — выясним, почему FidoNet до сих пор жив.

Честный рассказ о разрыве между красивым DRP в Confluence и тем, что происходит в 3 часа ночи, когда оба дата-центра зашифрованы. Без теории и маркетингового булшита: как выглядит реальное восстановление, почему документ всегда проигрывает реальности — и что строить вместо иллюзии готовности, даже если бюджет закончился на стойке списанных серверов.
Для тех, кто отвечает за непрерывность бизнеса и устойчивость процессов. И для тех, кто ни разу не запускал восстановление в реальных условиях. Таких большинство.

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

У нас давно существует проблема добавления поддержки новых сетевых железок. Это занимает много времени, требует большого погружения в разные проекты и, желательно, сетевого бекграунда у разработчика, иначе все будет еще дольше. Дольше - это недели, а то и месяцы перепинывания разных частей задачи между командами. Есть альтернатива - некоторые участники команды в целом могут в одно лицо это проделать, но, как правило, заняты более срочными или важными задачами и даже у них это займет неделю. Появилась идея, что в наш век победивших ai агентов можно всю эту нескриптуемую, но понятную и последовательную работу свалить на них. Мы попробовали и таки да, так можно. Как именно, что отваливается и насколько ai агенту тяжело объяснить разницу между разными диалектами одного вендора - в этом докладе.

В сети банка цена опечатки в конфиге - это не "ой, сейчас поправлю", а потерянные бизнесом и клиентами деньги. Поэтому ручные правки в CLI - уже давно моветон в индустрии, и мы тоже держим марку. Нюанс в том, что основа сети наших дата-центров собрана из очень разных платформ: сегодня это EVPN/VXLAN-фабрика на Cisco NX-OS и кластеры файрволов на FreeBSD, а завтра может приехать ещё какой-нибудь вендор и, возможно, не один. Поэтому наша оркестрация сделана так, чтобы не зависеть от того, что именно стоит в стойке. Расскажу, как GitLab CI стал дирижёром для управления сетью: от наливки нового железа с нуля (ZTP) до повседневных изменений с использованием подхода Network as Code. Почему мы научили пайплайн генерировать себя на лету и катить только то, что реально изменилось из сотен устройств. Почему так важно иметь возможность отлавливать дрейф конфигурации, и как это делаем мы. С какими подводными и наземными камнями столкнулись, и к чему стремимся привести нашу систему в обозримом будущем.

Это второй доклад из цикла "А что, если это - не это, а то - не то" от ребят от "До нас дошло". Мы поговорим о том, как радикально менялась сама суть мобильного телефона: от футуристической «рации» в 1960-х до статусного «кирпича» в 1990-х. Разберем переломный момент 2000-х, когда устройство перестало быть «звонилкой» с цветным экраном и совершило рывок в сторону первых WAP-порталов и GPRS. Где та невидимая черта, после которой «сидеть в Интернете» заменило «позвонить»? И какую роль в этой трансформации сыграли 2020-е с их тотальной облачной зависимостью.

Доклад про наблюдаемые на практике упускаемые из вида проявления и заблуждения в DDoS-атаках и защите от них.

• Атаку запустил, в хост чекерах всё красное, а сайт работает
• Защиту запустил, в хост чекерах всё зеленое, а сайт не работает
• Просканировал сеть, а всё порты открыты
• Syn-cookies vs syn-proxy
• Отражение DDoS-атаки - это не то о чем вы подумали
• L7 Flood не только HTTPS, а защита HTTPS не только с расшифровкой

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

Публичный OperatorHub не подходит для закрытых и регулируемых сред. Решение — собственный приватный каталог операторов на базе CatalogSource и внутреннего registry, полностью совместимый с OLM. В докладе разберём архитектуру OLM и покажем как собрать индекс-образ каталога, опубликовать его и подключить в кластер, а также как контролировать безопасность и рассмотрим отличия от Helm.