Software Defined Network (SDN) на основе открытой платформы Intel ONS

    В данной статье мы хотим напомнить о такой концепции, как SDN и рассказать, как сейчас выглядит ее реализация в виде платформы Intel ONS.

    Сперва лайфхак для тех, кому лень читать много текста и смотреть картинки: в самом конце статьи приведены условия получения 10G коммутатора. «Без-воз-мез-дно, то есть даром», — как говорила Сова во всем известном мультфильме.

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



    Преимущества такого подхода:
    • Прямое программирование сети: разделение уровней управления позволяет создавать архитектуру напрямую.
    • Гибкость: Администратор может изменять правила работы сети «на лету» для адаптации к изменившимся требованиям.
    • Централизация управления: Все управление сетью сосредоточено (логически) в одном месте, в контроллере SDN. Для приложений сеть выглядит единым логическим коммутатором.
    • Программное конфигурирование: SND позволяет конфигурировать, управлять, задавать правила безопасности, оптимизировать сетевые ресурсы в сжатые сроки с помощью автоматизированных средств, в том числе собственной разработки.


    Концепт вызывает немало споров, но мы считаем направление перспективным.

    В прошлом году Intel представила ряд решений для коммутаторов, на основе приобретенной
    Fulcrum Microsystems, Intel Ethernet FM6000.

    идея матрицы

    Матрицы позиционируются как гибридные коммутаторы с возможностью простого перехода от традиционной коммутации к SDN. Главной особенностью считается возможность направлять потоки обработчику OpenFlow или обработчику традиционных пакетов. Обработчик в Intel FM6000 крайне гибок, он позволяет работать с любыми стандартами, даже если администратору захочется создать свой собственный протокол — не беда, это можно сделать. Основа такой гибкости — структура обработчика.

    Структура TCAM/RAM/MUX в обработчике

    Коммутатор на основе такой матрицы может одновременно работать в традиционных сетях и OpenFlow с рекордно низкими задержками и высокой производительностью.

    эталонный дизайн


    Модели в серии

    Для работы с такими замечательными матрицами Intel представил решение от Wind River — Open Network Software.

    Структура ONS

    Особенности:
    • Модульная, открытая и расширяемая архитектура с доступам к низкоуровневым функциям.
    • Системные интерфейсы с открытым API и вызовами RPC.
    • Программный интерфейс управления на основе XML-RPC.
    • Объектно-ориентированный дизайн с использованием XML и схем баз данных.
    • Application Development Kit для встраивания новых приложений на коммутатор.
    • Встроенная поддержка ряда протоколов и расширение через модули.

    Поддерживаются основные протоколы L2 и L3, функционал для ЦОД.

    Layer 2:
    • Port-based VLAN
    • 802.1Q VLAN
    • IGMP snooping
    • LACP
    • Storm Control
    • STP/RSTP/MSTP
    • Q-in-Q
    • QoS/DiffServ
    • L2/L3/L4 ACL
    • LLDP (802.1ab)

    Layer 3:
    • Static route
    • VLAN routing
    • OSPF v2
    • ECMP
    • ARP
    • IGMP*
    • PIM-SM*
    • VRRP*
    • OSPF v3*
    • PIM-SM6*
    • DHCPv6 relay
    • BGP

    Управление:
    • CLI/WEB/SNMP
    • IPv6 management
    • Auto-Installation

    Data Center Application:
    • 802.1Qaz (ETS)
    • 802.1Qbb (PFC)
    • DCBX
    • VM Tracer
    • EVB/802.1Qbg
    • OpenFlow v1.0
    • VXLAN
    • NVGRE*

    Отмеченное "*" будет поддерживаться в следующих версиях.

    Так выглядит идеальный коммутатор будущего (по мнению Intel):


    Что будет, если взять старшую модель матрицы Intel FM6764 и сетевой стек ONS? Отличный коммутатор!


    48 портов 10G SFP+, 4 порта 40G QSFP, USB порт, порты консоли и управления.


    Два блока питания, вентиляция с горячей заменой.


    Intel Core i3, 2GB оперативной памяти, 30 гигабайт SSD накопитель.

    В нашей лаборатории коммутатор успешно запущен и работает.

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

    Авторам самого интересного проекта, включая высоконагруженные решения на традиционной коммутации, один коммутатор будет подарен :)
    Подведение итогов — 31 марта.
    ETegro Technologies 22,87
    Компания
    Поделиться публикацией
    Похожие публикации
    Комментарии 29
    • +1
      Сколько миллионов flow эта штука способна обработать в час?
      • Как контроллер — больше 100К flows/sec.

        Как коммутатор — практически wire-speed.
        • 0
          То есть если какой-то засранец сгенерирует, например, миллион flow в секунду,… ладно, 150к flow в секунду, что станет с контроллером?
          • Используйте внешний! :)
            Если у вас есть план, как положить коммутатор нагрузкой — поделитесь, реализуем на практике и поделимся результатом с общественностью.
            • 0
              Начните с hping3 --flood --rand-source -p ++1 -S some_host
              • Как верно заметили ниже — флуд будет обрезан контроллером.

                Я просил несколько другое — план решения, с нагрузкой от которого коммутатор не справится.
                48 серверов, которые делают что-то полезное для общественности.
                • 0
                  входящий флуд будет обрезание контроллером? При том, что контроллер 100к флоу, а хпинг делает больше 300? Если -p ++1 кажется заманчивым, замените на -p 80.
                  • Все таки мы о разных вещах сейчас говорим.
                    Размещать контроллер SDN на коммутаторе можно, но не очень нужно, в нем стоит двухъядерный процессор.
                    Для того Control Plane и отвязывали от железки.

                    На коммутатор лучше разместить фаерволл, IPS и прочие задачи такого рода.
                    • 0
                      я говорю про контроллер на несколько коммутаторов внутри периметра. Если его надо прикрывать файволами/ids, то получившееся может и выживет, но надо ли такое?
                      • Вы рассматриваете сценарий, когда контроллер отслеживает каждый flow?
                        Зачем?
                        Такой вариант не масштабируется, будет медленным, да и пользы от отслеживания каждого flow не видно.
                        Составьте таблицу маршрутизации, дальше коммутатор съест любой поток.
                        • 0
                          Нет, я хочу, чтобы вы мне попытались описать такую конструкцию (условного интернет-сайта) с использованием SDN, в котором бы не было сценария, при котором школьник может с помощью hping/ab заставить каждый новый запрос обрабатываться как новая flow с отправкой на инспекцию. В принципе, я понимаю что ab — это уже другой уровень. Так что давайте начнём с hping'а. Как будет выглядеть инсталляция SDN, которая будет обрабатывать трафик из интернета с участием контроллера (то есть не «у нас всюду маршрутизация/коммутация, а контроллер для красоты»), и при этом сможет избежать проблемы с инспекцией каждого specially-crafted пакета?

                          У меня, конечно, есть нехорошая интонация «да фигня это всё», но разобраться я хочу серьёзно, потому что flow-flood сейчас моё самое главное и основное возражение против SDN IRL.
                          • Сферический школьник в вакууме отправляет запросы на фронт-енд сайта, его не волнует то, как его запрос обрабатывается дальше. Внутреннюю сеть школьник не видит.

                            Под таблицей маршрутизации я как раз понимал таблицу flows в коммутаторах, а контроллер для изначальной задачи таблицы/обновления по мере необходимости (появления новых destination).
                            Удобство от централизации остается, проблемы масштабирования и флуда снимаются.

                            Зачем каждый пакет инспектировать контроллером?
                            Вот тут примерно такое же мнение описано.
                            • +1
                              Перед тем, как будем разбирать пример, вы хотите сказать, что SDN не подходит для периметра сети, то бишь фронт-энда? (который принимает нефильтрованный трафик из интернетов)

                              Я, собственно, эту мысль и пытаюсь всё время донести: SDN — уютная игрушка для уютных задних сетей, а к реальной нагрузке оно не готово.

                              Проблема «flows в коммутаторе» сводится к тому, что мы либо из всех flow оставляем только dst_ip, который потом уже разбираем глубже внутри, либо мы должны мириться с невероятного размера флудом на контроллер.

                              Если мы весь SDN сводим к «dst-based policy», то это и есть обычная маршрутизация (с минусами внешнего контроллера), если пытаемся сделать что-то более умное — огребаем амплифицирующий само-DoS.
            • 0
              Возможно не совсем правильно понял, что подразумевается под flow в данном вопросе. Но, что касается самой идеологии SDN, то всё зависит от реализации контроллера сети. Если вопрос стоит в том, чтобы обязательно обработать всё, что приходит, то заткнуть можно всё что угодно. Если же говорить об устойчивости, то в SDN заложены богатые возможности по обнаружению «засранцев» и минимизации ущерба для нормальных пользователей. Вплоть до блокировки адресов и даже физических портов и перераспределения трафика между оставшимися. То есть при правильном контроллере почти все 150k (или даже 1000k) от «засранца» будут отброшены, а с контроллером ничго не случится.
              • 0
                каким образом это поможет при внешнем флуде?
                • 0
                  В упрощённом виде: все коммутаторы запускаются с одним правилом — все неизвестные пакеты (или их заголовки) отправлять контроллеру. Получив их, он добавляет необходимые правила для обработки, в идеале со временем действия. Кроме того, предусмотрены счётчики для измерения потоков (по портам, по правилам и т.п.) и оповещение контроллера о превышениях заданных порогов. При правильном наборе правил, простите за тафтологию, источник флуда будет временно отключён, с необходимыми корректировками остальных маршрутов, и не повредит сети в целом. Но отдельные порты или диапазоны адресов конечно можно блокировать такими атаками.
                  • +1
                    /facepalm.

                    Какой источник флуда? Интернет?

                    Если не поняли, повторяю: школьник на vds'ке запускает hping --flood --rand-source с целью на один из серверов внутри SDN. Кого куда что будет банить?
                    • 0
                      Если у вашей сети один порт для интернета и если у школьника проплаченный канал шире, чем у вашей сети, то да, будет временно забанен интернет. Хотя может быть отключён и только доступ извне к атакуемому серверу, с сохранением его для остальных машин сети. Всё зависит от баланса фантазии автора программы контроллера сети и вашего «школьника».
                      • 0
                        Не-не, ну что вы передергиваете. Допустим, у школьника 50 мегабит. Входящий канал в сеть с контроллером — 10 гигабит.

                        И, допустим, школьник достаточно умный, чтобы не только --rand-source сделать, но и долбануть не по одному IP, а по всем адресам АС.

                        Я и хочу понять, как в этих условиях sdn жить будет, когда 300к flow ежесекундно новых.

                        Это моя претензия к технологии sdn.
                        • 0
                          Странный получается диалог… Ну, например, контроллер может сортировать записи по степени активности и при заполнении таблиц удалять самые «пассивные». То есть ваш флуд будет забивать сам себя. Если вы надеетесь забить управляющий канал и будете настаивать что можете, то это приведёт к задержкам при установлении новых соединений.

                          И при чём здесь sdn? Что остальные варианты построения сети устойчивы к такому виду атак?
                          • 0
                            Так давайте начнём с более простого: контроллер просто не сможет обслуживать 300к запросов на новые флоу, то есть простой школьник с 20-50Мбит/с каналом сможет положить сеть почти любого размера.

                            Я ж это всё пишу не просто так. Старые версии openvswitch страдали ровно той же проблемой — флуд клал контроллер (который vswitchd) на колени при 15 мегабитах флуда. Это при том, что ядерный модуль был способен 7-10 гигабит перемолоть. В новой поправили, но так vswitchd — не полноценный openflow-контроллер, а всего лишь прослойка между нормальным контроллером или ручными правилами.

                            Я утверждаю, что из простенького 10G маршрутизатора и коммутатора могу изготовить решение, которое на 50Мбит пакетного флуда даже глазом не поведёт. И даже фильтровать не будет, а прямо до сервера донесёт (который тоже проигнорирует флуд).

                            Другими словами, SDN решение получается много более уязвимое, чем существующие технологии, и проблема тут не в реализации (конкретного вендора или софта), а в принципиальной идее «централизации обработки всех flow с отправкой образцов на инспекцию».
        • 0
          >Мы приглашаем разработчиков сетевых приложений и компании, которые собираются тестировать/внедрять SDN решения для апробации >коммутатора в реальных задачах.
          Куда и когда приглашаете? А может мы вас пригласим обсудить наш проект?

          Мы сейчас на стадии разработки решения для наших ЦОД на базе OpenStack и у нас (taximaxim.ru) есть идеи, как использовать подобный продукт для своих нужд.
          • +1
            Написал личное сообщение.
            • 0
              Я так понимаю, мне со своим трёхслойным проектом опенсорс/опенхардварь умного дома (который гарантированно не «засрёт» полосу) даже соваться бессмысленно? :)
              • 0
                а зачем умному дому SDN?
                • 0
                  сеть большая (точнее, в моём проекте — там три сети). Вряд ли, конечно, оно в пределах одного дома засрёт весь контроллер, даже если гонять видео/аудио от системы безопасности да ещё и мультирум через него же пустить, но «обычные домашние» решения тут уже не подойдут.
            • +1
              Ребят, я понимаю, что тут не совсем место, но не могли бы вы попросить там своих маркетологов не использовать SMS-спам для завлечения клиентов?
              А то у меня спам от вас пришёл спустя 10 часов после покупки новой сим-карты с новым номером. Я уже начал подозревать оператора в сговоре со спамерами :-/
              • 0
                а на #asterisk@rusnet стеснялся написать?
                у нас маркетологи на аутсорсе и они регулярно за это «получают»
                • 0
                  Да что-то как-то не подумал, что ты там и тут — один и тот же человек :)

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

            Самое читаемое