OpenFlow for dummies

    imageПришла пора закрасить еще одно белое пятно на информационной карте Habrahabr. С удивлением обнаружил, что кроме пары вскользь упомянутых фактов, на нашем любимом сайте до сих пор не рассказано про близящийся прорыв в интернет-коммуникациях, к которому сейчас активно прикладывают руку такие монстры сетевых технологий, как Google, Juniper, Cisco и прочие не менее знаменитые компании.

    Сам протокол OpenFlow довольно молод, он был разработан в Сэндфордском университете всего лишь чуть больше пары лет назад, но с тех пор количество ресурсов, людских и технических, вовлеченных в его реализацию, растет лавинообразно. Пол-года назад и моя компания присоединилась к этой гонке, и теперь я попробую вкратце описать все плюсы и минусы этой технологии на уровне “чайников”, ибо монстры-админы и так найдут, где прочитать подробные спеки.

    Итак, попробую “на пальцах” описать, в чем тут суть. Возможно, многие из вас обращали внимание на небольшие коробочки с моргающими лампочками, через которые интернет попадает к вам в компьютер. У провайдеров почти такие же, только подороже и по-мощнее, но суть та же: принять пакет из одной дырки, посмотреть его содержимое и потом или положить его в другую дырку, или выбросить, или надругаться над ним другим способом. Что произойдет в итоге с каждым конкретным пакетом, решает стоящий внутри коробочки процессор. Он помнит, в какой дырке торчит провод к аплинку, он знает адрес сетевой карты Васи Пупкина, он не дает злобному хакеру из Китая исполнить грязные замыслы против Васиного компьютера.

    Беда в том, что “вас (пакетов) много, а я (процессор) один” и когда скорость прихода пакетов превышает возможность процессора их обработать — начинаются неизбежные задержки и потери. И вот здесь возникает закономерный вопрос — а зачем диспетчеру работать носильщиком? Давайте их разделим.

    Итак, в двух словах суть OpenFlow описывается именно так — перекладывает пакеты из дырки в дырку Тупой Железный Пакет-Процессор (ТЖПП) в соответствии с имеющейся у него таблицей, и если вдруг попадается ему необычный пакет, не подпадающий ни под какое правило, то ТЖПП просто пересылает этот пакет (завернутый в красивую подарочную упаковку) Серверу, Который Все Знает (СКВЗ).

    СКВЗ живет где-нибудь под боком у Самого Главного Админа и помнит внутри себя конфигурацию сети, где какой свитч стоит и кто к нему подключен. У каждого свитча есть свой уникальный номер и после включения питания он стучится к СКВЗ и получает от него полный список правил и действий (Matches & Actions) для своего ТЖПП, например “если к тебе пришел пакет с DstIP 1.2.3.4, то прилепи к нему VLAN тег 10 и отправь в 15 дырку” и так далее. В роли СКВЗ сейчас зачастую выступают NOX, BigSwitch или Beacon (есть и другие, но это тот набор, который мне пока что приходилось щупать своими руками).

    После начала работы СКВЗ имеет возможность на ходу менять конфигурацию свитчей в зависимости от происходящих событий. Например, посылается пакет на определенный порт, ТЖПП видит соответствующее правило и отправляет этот пакет контроллеру, контроллер в ответ добавляет правило, позволяющее в течение, например, часа выходить в интернет с определенного адреса. Или наоборот, дает доступ извне к какому-то сервису.

    Плюсы такого подхода:
    1) вся конфигурация сети хранится у админа на сервере и имеет единый интерфейс, для изменений и бекапов не надо логиниться куда-либо, и главное — перестает работать старая админская примета “менять удаленно сетевые настройки — к дальней дороге”, наконец-то можно экспериментировать в свое удовольствие
    2) Устоявшиеся потоки данных, не требующие вмешательства сервера, обрабатываются на максимальной скорости интерфейса.
    3) Стоимость свитча, по “умности” превосходящего нынешние L3, падает даже ниже стоимости самых примитивных L2
    4) Мечта многих пользователей — WiFi роуминг, переключающийся на ходу (проект OpenRoads)

    Разумеется, есть и минусы:
    1) АРРРРРГХ!!! Извините, не сдержался. Мне, как разработчику, очень обидно за тупость и непродуманность самого протокола, на фоне которого даже СМТП выглядит верхом изящества и утонченности. Впрочем, обещают в ближайшей следующей версии (текущая версия 1.1 была принята в марте этого года) его основательно изменить, а пока спасает только наличие так называемых Vendor Messages, где можно добавлять свою функциональность, однако с опасением скатиться в, извините за выражение, проприетарность. Кстати, 1.1 от 1.0 тоже отличался ощутимо, и я успел побегать по заботливо разложенным внутри протокола граблям.
    2) IPv6. Впрочем, о покойниках или хорошо, или ничего. Насчет зомби я не уверен.
    3) Работа с несколькими контроллерами. Сейчас в лабораторных условиях это делается через костыль по имени flowvisor, но в реальной жизни падение СКВЗ превращает умные железки в тупые свитчи.
    4) Пляски с бубном при реализации элементарных вещей, например проверка флага Syn в ТСП-пакете. Хотя это опять претензия к номеру 1.
    5) Было еще что-то неприятное, но я забыл из-за переполнивших меня после пункта 1 эмоций.

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

    UPD: Видео по теме от пользователя eek
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 38

      +1
      Мммм… Хотеть. Оно уже у кого-нибудь из массовых вендоров есть?
        0
        Да хоть на домашний роутер можно ставить: www.openflow.org/wk/index.php/OpenWrt
          0
          На домашнем роутере смысла от этого мало.
          Я имею в виду свитчи.
            0
            Да, забыл — для оператора связи.
              0
              В данный момент допиливается интеграция OF в имеющиеся прошивки, в том числе и в свичи чуть ли не десятилетней давности. Так что для включения этой радости будет достаточно всего лишь загрузки нового ROM-имиджа.
                0
                Думаю, в моих D-Link DES-3028 этого не будет :).
          0
          Xenserver DVS, железячные только только готовят бета прошивки с поддержкой openflow. БОльшая проблема не в коммутаторах (понятно что они тупы и должны просто соответствовать спецификациям), а в контроллерах- есть только экспериментальные поделки и что-то платно-закрытое. Из того, что я нарыл самый адекватный NOX, но это даже не контроллер, а API-прослойка, для удобства написания своего контроллера на C++ или python =)
            0
            Понял, спасибо. Интересно, даже очень. Но пока что, увы, придется закопать.
            0
            Смотря какой вендор для вас является массовым. Народ говорит купить можно у NEC.

            У Brocade, Cisco и Juniper есть решения которые так или иначе решают теже текущие вопросы фабричным методом.
            0
            Как я понял, технология раскрывается только в enterpize масштабах, когда географическое удаление узлов сети стремится к бесконечности? SOHO пользователям можно спать спокойно и не заморачиваться? =)
              0
              Скажем так — в рамках одного датацентра (даже в рамках аренды стойки в датацентре) можно уже получить неслабый профит, избавляясь от DDOS шевелением мизинца левой руки. А дома — разве что для экспериментов :)
                0
                К сожалению на данный момент вообще непонятно кому это нужно, народ бает что реально используют это дело на данный момент вроде в Google и в Yahoo, но проверить это не просто, поэтому можно только верить или нет.

                Практически все что предлагается в рамках этой концепции можно решить на существующем железе, суть в том, что это не про железо это про софт.
                +1
                Не совсем понятно что будет если количество специальных пакетов по которым нужно принимать решения будет достаточно большим? Банально ошиблись в одном правиле на СКВЗ и наши же свичи его же и положат запросами. И как происходит изменение уже существующего правила?
                  0
                  Для изменения есть специальная команда Modify, а с пакетами очень просто — после анализа пакета добавляется новое правило и шлется команда Barrier, т.е. сначала добавить правило, и только потом продолжать дальнейшую обработку.
                  Ну а за тем, чтобы не налажать в правилах — наверное, админ должен сам следить
                    +1
                    Как вы понимаете, и «и на старуху бывает порнуха». Пример с упавшим этим летом Яндексом это красноречиво подтверждает.
                      +1
                      Ну так ведь «прокладка между рулем и сиденьем» не зря считается самым слабым звеном…
                  0
                  Вот ссылка на видео с недавнего мероприятия как раз по данной теме. Практически все темы подробно раскрыты.
                    0
                    А ссылочки нету.
                      0
                      Я ее уже в текст заметки перенес.
                    0
                    Насколько я понимаю, эта технология предполагает наличие двух сетей — control и user-plane? И при этом control-plane сеть строится каким-либо традиционным способом?
                      0
                      Нет, подключение к контроллеру идет по обычной сети по ssh. В принципе, ничто не мешает находиться контроллеру где-то в облаках с гарантированной доступностью
                        0
                        Может я что-то упускаю из виду, но если контрольные пакеты ходят по той же самой сети, у нас все-таки есть возможность навлечь на себя дальнюю дорогу, накосячив с правилами для контрол-плейн траффика?
                          0
                          Там хитрее — правило для контрол-пакетов имеет максимальный приоритет, прописывается первым при загрузке и его невозможно удалить :)
                            0
                            Да, НО при этом мы можем запросто потерять доступ к самому контроллеру или коммутатору, хотя друг с другом они общаться будут, LFMF. Хотя опять же все зависит от конкретной реализации, в спеках протокола ничего конкретного по этому поводу не написано.
                      0
                      Есть такая штука — SNMP (v3, допустим). Он, если исходная железка поддерживает его, позволяет по сети управлять кучей всяких вещей, в том числе — по проприетарным МИБам — и конфигами, вплоть до настроек policy-based filtering, VLANs, mirroring etc. Правильно ли я понимаю, что OpenFlow — это такое обобщение SNMP, чтобы все управляющие запросы-ответы были если не стандартизованы, то хотя бы близки к этому?
                      И ещё вопрос — в чём упрощение для L3, за счёт которого стоимость должна упасть? Я не знаком с продукцией Cisco (что за чипы у них внутри), но вот чипы от Broadcom позволяют уже сейчас настроить фильтры и рулы прямо в железе, в том числе и для процессинга IP-пакетов, в том числе и IPv6. Где будет упрощение «от OpenFlow»?
                        +1
                        Нет, вы немного неправильно поняли. Ключевое отличие в том, что через SNMP или еще как вы задаете статическую конфигурацию коммутатора. Т.е. пока вы не измените какие/либо правила или настройки, он будет обрабатывать пакеты по одним и тем же правилам.
                        В OF же каждый пакет, не попавший под уже существующие правила, отправляется на контроллер, тот его анализирует и далее дает команду коммутатору добавить то или иное правило обработки схожих по каким либо параметрам пакетов (например, по MAC src) или/и отправить пакет на порт/порты.
                        Теоретически вы можете используя примитивнейший коммутатор L3 (который может аппаратно править заголовки пакетов) и соответствующий OF контроллер (работающий на среднем сервере) получить приличный BGP роутер за смешные деньги =)
                          0
                          То есть основное отличие в том, что контроллер способен генерировать правила для свичей/роутеров динамически, на основе анализа трафика, который под существующий набор не попадает, и эти правила потом запихивать в свичи? Иными словами, главная фишка — не в протоколе как таковом, а в логике построения новых правил?
                          В тех свичах, с которыми я имел дело, пакеты, с которыми «незнамо что делать», тоже шли на контроллер — просто он расположен был в виде CPU на той же плате, что и свич-чип. Я потому и спрашиваю, что пытаюсь понять принципиальное отличие от такого подхода.
                            0
                            Да, все правильно. В отличии от CPU в свиче, вы сами можете программировать контроллер как угодно вообще, не ограничиваясь возможностями конкретной прошивки конкретного коммутатора. Сам протокол OF лишь инструмент стандартизации, гарантирующий корректное общение между контроллером и коммутатором.
                              0
                              Спасибо. Давно ждал, когда светлые головы что-то такое сделают — дождался, похоже :-)
                        0
                        «IPv6. Впрочем, о покойниках или хорошо, или ничего.» — мне как неспециалисту непонятно. Не поясните?
                        0
                        Передергивает от слова «свитч». Хотите использовать родную терминологию — так пишите английское switch, уверен что все поймут. А на русском лучше уж использовать «коммутатор». Хотя… может это я один такой чувствительный :)
                          0
                          стараюсь писать «коммутатор», но иногда просто лениво, короче просто «свич» (причем без «т», т.к. она не произносится в оригинале, да и в русской кальке тоже).

                        Only users with full accounts can post comments. Log in, please.