Network: Packet Broker, Balancer (пакетные брокеры и балансировщики)

Пакетные брокеры с функционалом балансировки. Часто встречаемое решение в последнее время, особенно в фин. секторе.
L7 балансировщики
Yandex с главной страницы балансирует по URL новостные запросы – в таком случае в URL добавляет l7-balancer-8080-BAL. Причем балансируется зашифрованный трафик (видимо балансировщик после дешифр). Если же ту же саму новость открыть не с главной – инфы о l7 balancer не будет, хотя ID новости тот же a3cbfaf4-c013-57d7-80c8-2a21d7cb9a3c. Так же интересно UTM_SOURCE=MORDA_DESKTOP (UTM_SOURCE это метка маркетологов откуда пришел клиент).
https://yandex.ru/news/story/Centrobank_opustil_klyuchevuyu_stavku_do17--601bc5ec66c5df7645cdd0b4a80a023c?lang=ru&from=main_portal&fan=1&stid=nFljArpY8qPmdvRgHWH5&t=1649442076&persistent_id=191863751&story=a3cbfaf4-c013-57d7-80c8-2a21d7cb9a3c&lr=213&msid=1649442758848230-3203246510001223466-vla1-5781-vla-l7-balancer-8080-BAL-1112&mlid=1649442076.glob_225.601bc5ec&utm_source=morda_desktop&utm_medium=topnews_news

https://yandex.ru/news/story/Centrobank_opustil_klyuchevuyu_stavku_do17--601bc5ec66c5df7645cdd0b4a80a023c?lang=ru&rubric=business&fan=1&stid=nFljArpY8qPmdvRgHWH5&t=1649442076&tt=true&persistent_id=191863751&story=a3cbfaf4-c013-57d7-80c8-2a21d7cb9a3c

https://yandex.ru/news/story/Vrach_ZHuravleva_tonometr_obyazatelno_dolzhen_byt_vdomashnej_aptechke_ulyudej_starshe_35_let--d98f0906cdfdcd1f3eb603f8ff2459e3?lang=ru&from=reg_portal&fan=1&stid=Q1HKyU4lq9VzALucg6NS&t=1649321568&persistent_id=191810526&story=11fde233-b36c-5017-b22d-16a1b263591d&lr=213&msid=1649322116560800-16977679295608403134-vla1-0726-vla-l7-balancer-8080-BAL-4985&mlid=1649321568.geo_213.d98f0906&utm_source=morda_desktop&utm_medium=topnews_region

https://yandex.ru/news/story/Poklonskaya_svyazala_sobytiya_vBuche_snenavistyu_kukraincam_i_russkim--e613013bf4207669cb906b5ec91882ed?lang=ru&from=main_portal&fan=1&stid=q3tat_5rx1J59pHqxYk3&t=1649243987&persistent_id=191778989&story=25164cc2-25a2-5d8b-97f4-e7cd362f9bf5&lr=213&msid=1649244516302469-9420224403173302044-sas6-5259-79d-sas-l7-balancer-8080-BAL-1180&mlid=1649243987.glob_225.e613013b&utm_source=morda_desktop&utm_medium=topnews_news
Gigamon
Считается топовым вендором в контексте сетевых брокеров.
Ixia
Основной функционал.
Dedicated hardware acceleration provides a Zero packet loss architecture.
- Forward traffic to the right tools, including load balancing:
  - security
  - monitoring
- Deduplication
- Filtering of traffic so that each monitoring or inline security tool receives exactly the right data
- Aggregation of traffic from multiple TAPs or SPAN ports
- L7 application awareness efficiently allows for packet processing based on unique applications
- SSL decryption to quickly detect emerging threats encrypting exploits within application traffic
Ixia пишет, что в отличии от других брокеров (неназванных), в ее брокерах на одной железке можно включить весь функционал, а не делать chaining брокеров с разными фичами, которые не поддерживаются на одной железке.
.
Импортозамещение
НПП цифровые решения (dsol) – ds integrity

    • Массовые серии продуктов начались недавно – подозреваю что СВО сделало большой вклад в спрос решений этого вендора
    • Помимо пакетных брокеров так же выпускают коммутаторы Fenix
      • каждый!!! серийный! свич проходит порядка 300 тестов -> комплекс тестирования занимает 24 часа на одно изделие!
    • Разрабатывают схематехнику, ПО; этапы
      • разрабатывают структурную схему изделия, объединяют основные узлы
      • разработка электрической принципиальной схемы
      • разработка топологии печатных плат (тут проверяется качество разводки/тестирвание платы/отсутствие кз/входной контроль)
      • закупка компонентов (экб – соответствие закупленному)
      • собирается плата – наносятся компоненты
      • изготовление платы на заводе – как западные так и РФ
    • Более 20 лет занимаются разработкой аппаратных решений, ошибались везде, поэтому рекомендуют тестировать все 😀 на этапе RnD тестируют именно так, при серийном производстве меньше тестов
      • схематехника – peer review (один разработал, другой инженер проверил на соответствие стандартов/унификацию элементной базы/типовые ошибки)
      • тестирование стабильности питания
      • тестирование отсутствия битовых ошибок в ОП – иначе могут бвть очень сложные для диагностики баги
      • проверка шин i2c, spi – проверка связи между cpu и всеми комплнентами платы
      • проверка высокоскоростных интерфейсов (более 10G) – про оценку см. глазковые диаграммы
      • в климатической камере тестируют с максимальной нагрузкой по трафику сутки! при максимальной и минимальной температурах
      • виброиспытания – тестирование перевозки ПАК
      • тестирование к статическому разряду (ESD) – бывало такое, что из-за стат. разряда (свитер) на корпус девайса срабатывал датчик вскрытия и кирпичил девайс, пришел дорабатывать девайс чтобы избегать такого (улучшать заземление корпуса, добавлять фильтры на линию датчика вскрытия)
      • электромагнитная совместимость – не мешает соседним устройствам работать
      • тестирование ВПО (встраиваемое ПО) – встраиваемым считает то, что работает только применимо к конкретной платформе (ПЛИС/FPGA)
        • ВПО тестируют совместно с целевой аппаратной платформой
        • или для тестов эмулируя целевую аппаратную платформу (data plane) для ВПО через виртуализацию – конкретная платформа в таком случае у них описывается универсальным P4 коммутатором; пакуется в виде виртуальной машины, которую могут использовать тестировщики/разрабы; такой подход в том числе позволил
          • ускорить разработку т.к. разработчики ПО (control/management plane) не ждут готовности прошивки data plane
          • использовать созданные VM для тестирования в виртуализированных топологиях – EVE NG
      • для тестирования основного функционала у них автостенды, в том числе включенные в CI/CD pipeline на базе gitlab (после commit разработчика запускаются тесты), причем используют промежуточный коммутатор на котором оценивают корректность коммутации трафика DUT, например трафик vlan при передаче на порт получен только с того порта, с которого ожидается
      • нагрузочные тесты используют Spirent и закупили Xinertel (им нравится, явно stateless)
      • релизные версии так же тестируют и вручную – сложные топологии, неправильные вводы команд, разные задержки ввода/отклика
      • у них порядка 20 тестовых стендов, стараются в них использоваться разные SFP модули – разных производителей/аппаратных ревизий;
        • по практике работы с разными модулями они не выдвигали рекомендаций по неиспользованию (т.е. бану) какого либо из модулей, обычно алгоритм ‘поддержки’ неработающего модуля был – они запрашивали модуль к себе в лабу, идентифицировали проблему и устраняли
          • если проблема по физике диагностировали глазковой диаграммой (определяли что сигнал плохой/на грани/с минимальным запасом) и настраивали serdes – увеличение фронтов, условия “если модуль -вот_это_говно – то вгружаем. нестандартные настройки serdes”
          • иногда выходили напрямую на вендора SFP модулей и общались с ними (ошибки бывали с обеих сторон)
        • пример кейса – модули не работали/зависали в определенной группе портов, подключили модули, по сигналу на i2c шине SFP модуль реагирует (получает и “вешает” шину) на ту команду, которую должен игнорировать (она предназначена не ему)
        • у трансивера есть EEPROM и часть параметров – большая часть параметров на read, но есть и read-write (управление). Они не используют никакой настройки модулей со стороны SFP модулей (берут все что отдается по read only по страницам A0/A2 и читают DOM, медь по DOM ничего не отдает) и в целом не встречали доступ к настройке serdes на модулях. Им кто-то предлагал перепрошивать модули, которые к ним подключаются, но они не стали это делать.
Брокеры сетевых пакетов (DS Integrity)

Типовая конфигурация брокеров для балансировки на кластер NGFW
    • Hash
      • между разными ПАК-брокерами  используется один алгоритм хеширования, поэтому синхронизация сессий при отказоустойчивости не нужна
      • symmetric hash
      • resilient hash
      • есть возможность настройки балансировки как 5tuple, так и 3tuple (полезно для ftp когда контрольная и дата сессия имеют разные порты), так и только по src или только по dst
    • heartbeat между брокерами (помимо других способов детекции проблем – падение линка/активные запросы icmp-tcp-http) для контроля отказа ноды кластера, причем он двухсторонний (т.е. оба брокера отсылают) – в итоге отвал на одной стороне приведет к полному отключения с обеих
    • на схемах нарисовано по два брокера с двух сторон (четыре брокера всего), но в целом отказоустойчивость реализуема и на двух брокерах всего, если на каждом брокере держать и in и out трафик (главное чтобы портов хватало)
    • отказоустойчивая схема с резервными брокерами между кластером ngfw и роутером обеспечивается за счет
      • L3: ospf, поэтому скорость сходимости при отказе брокера зависит от настроенных таймеров ospf на файрволах и роутере/поддержки на них bfd; можно было бы чисто за счет поднятия/падения линков на брокере – но соседям нужно явно дать сигнал на переключение, схема с роутингом это нативно обеспечивает; брокер подменяет DST MAC на корректный для балансируемой ноды; есть так же fault propagation (по сути простой скрипт), когда падение аплинка на брокере приводит к принудительному отключению всех даунлинков
      • L2: за счет lag с lacp – по сути lag между коммутатором и файрволом насквозь брокер. Схема для тех кто не хочет по каким либо причинам L3 (нет/мало роутеров, не хотят ospf и проч). Клиенты терминируются по L3 на NGFW. Все служебные пакеты (включая lacp) пролетают прозрачно через брокер (он прикидывается для них проводом, с точки зрения lag его по сути нет), для основного трафика (можно по определенному критерию ip/tcp/etc создать группу балансировки) брокер балансирует его и подменяет DST MAC на корректный для балансируемой ноды.
общее описание

  • текущая платформа брокера
    • до 4х100G
    • до 8х40G
    • до 32х10G
    • есть вариация с оптическим байпасом – в случае отказа питания происходит замыкание в байпасе и линк через упавший брокер продолжает работать
    • защита от всплесков при передачи от многих к одному линку за счет как понимаю буфферизации (весь объем RAM как буфер)
  • изначально брокер делался для снятия зеркала трафика с сети, его предобработки и отправки на системы аналитики ИБ (см. пример кейса в NTA)
  • можно делать сразу несколько действий – помимо балансирования трафика на mgfw часть трафика ответвлять на NTA
Агрегация
Сбор трафика различных точек сети c 32 линков в один выходной порт для обработки единого потока одной системой DPI

Фильтрация на основании внешних и вложенных заголовков для обеспечения передачи на средства DPI только целевого трафика

  • Удаление дублирующихся пакетов для уменьшения объема трафика (в 2 и более раз), обрабатываемого системами DPI
  • Оптимизация пакетов (детуннелирование vlan/mpls/vxlan/gre, удаление заданного количества байт/поля данных) для снижения нагрузки на системы DPI; в том числе может балансировать по вложенным пакетам в туннели
  • Инкапсуляция трафика в туннель GRE для безопасной передачи между несколькими офисами или центрами обработки данных
  • Формирование и передача статистических данных об информационных потоках системам DPI без установки дополнительных сенсоров
    • Ответвители сетевого трафика (TAP)
    • Коммутаторы 3 уровня

 

DS proxima

планируют выпустить апаратный балансировщик

    • 20 gbps считают это зона софтварных балансировщиков, они нацелены на болшие скорости (от 20 до сотни gbps) с учетом аппаратного решения
    • балансировка не только на основе hash пакета, но и на основе текущей загрузки девайсов в кластере (не обязательно firewall, возможно и обычные сервера приложений) – напр. по времени отклика на http запрос; при этом уже сейчас есть статические веса для балансировки – подходит, когда заранее знаешь, что один сервер в 2 раза более производительнее чем другой
    • (как и сейчас) контроль живости нод кластера на уровнях от L1 (линк) до L7 (http get)
    • Conntrack – помимо resilient hashing нужен контроль того, что при восстановлении ноды на нее не балансировались активные сессии, а только новые
    • использование не отдельных мелких lag между коммутатором и файрволами (с точки зрения согласования lacp насквозь через брокер), а один большой lag между коммутатором и балансировщиком
    • возможно поддержка MC Lag
    • поддержка vrrp
    • поддержка HA
    • не будет прозрачным девайсом, это L3 девайс с поддержкой BGP/OSPF, будет терминировать на себя трафик, который должен балансироваться с анонсом от себя балансируемого адреса

 

 

 

rdp

RDP. Есть даже решение от RDP 1RU 8x100G, 48x10G. По факту аппаратная база вся на базе Inventec, ПО видимо RDP.

https://shop.nag.ru/catalog/15596.servisnye-shlyuzy/47785.paketnye-brokery/44824.elb-1020

Пакетный брокер ELB-1020 обеспечивает доступ к сетевому трафику для систем анализа и мониторинга, таких как DPI, СОРМ, URL-фильтрация и аналитика, системы безопасности и т.д.
Автоматизированная система управления и мониторинга с функцией перенаправления трафика EcoDPI Balancer c ПО EcoDPIOS-LB, ELB-1020, 48 x 10GE SFP+, 8 x 100GE QSFP28.

Leave a Reply