Mikrotik openflow что это

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

Доступность пакетов может отличатся от выбранной платформы (mipsle, mipsbe, ppc, x86). Главным пакетом является пакет system, его нельзя удалить, он является дефолтным на всех роутерах. Кроме него "с коробки" довольно большое количество пакетов включено в поставку для устройства Mikrotik. Это и пакет DHCP, ppp и другие. Стоит помнить, что эти пакеты не являются обязательными и могут быть отключены или удалены с маршрутизатора.

Список пакетов

advanced-tools (mipsle, mipsbe, ppc, x86) calea (mipsle, mipsbe, ppc, x86) dhcp (mipsle, mipsbe, ppc, x86) gps (mipsle, mipsbe, ppc, x86) hotspot (mipsle, mipsbe, ppc, x86) ipv6 (mipsle, mipsbe, ppc, x86) mpls (mipsle, mipsbe, ppc, x86) multicast (mipsle, mipsbe, ppc, x86) ntp (mipsle, mipsbe, ppc, x86) openflow (mipsle, mipsbe, ppc, x86) ppp (mipsle, mipsbe, ppc, x86) routerboard (mipsle, mipsbe, ppc, x86) routing (mipsle, mipsbe, ppc, x86) security (mipsle, mipsbe, ppc, x86) system (mipsle, mipsbe, ppc, x86) ups (mipsle, mipsbe, ppc, x86) user-manager (mipsle, mipsbe, ppc, x86) wireless (mipsle, mipsbe, ppc, x86) arlan (x86) isdn (x86) lcd (x86) radiolan (x86) synchronous (x86) xen ( discontinued x86) kvm (x86) tr-069 (mipsle, mipsbe, ppc, x86) routeros-mipsle (mipsle) routeros-mipsbe (mipsbe) routeros-powerpc (ppc) routeros-x86 (x86)
Читайте также:  Сводная таблица из нескольких файлов excel

Пакеты можно устанавливать в разделе /system package.

Для домашнего или офисного роутера достаточно оставить минимальное количество пакетов – для экономии ресурсов маршрутизатора. Это advanced-tools – пакет для диагностики сети, dhcp – пакет DHCP-сервера и клиента, ppp – VPN-сервер и клиента, security – безопасное подключение к WinBox, system – дефолтный пакет, wireless – пакет поддержки беспроводной сети.

Для того, что-бы отключить пакет нужно выделить его и нажать на кнопку “Disable” – это запланирует отключение пакета при следующей перезагрузке устройства. Если нажать кнопку “Uninstall” – пакет будет удален во время перезагрузки. Кнопка “Unschedule” – удалит запланированное задание для выделенного пакета.

OpenFlow — протокол управления процессом обработки данных, передающихся по сети передачи данных маршрутизаторами и коммутаторами, реализующий технологию программно-конфигурируемой сети.

Протокол используется для управления сетевыми коммутаторами и маршрутизаторами с центрального устройства — контроллера сети (например, с сервера или даже персонального компьютера). Это управление заменяет или дополняет работающую на коммутаторе (маршрутизаторе) встроенную программу, осуществляющую построение маршрута, создание карты коммутации и т. д.. Контроллер используется для управления таблицами потоков коммутаторов, на основании которых принимается решение о передаче принятого пакета на конкретный порт коммутатора. Таким образом в сети формируются прямые сетевые соединения с минимальными задержками передачи данных и необходимыми параметрами.

Версии микропрограмм с поддержкой Openflow разработаны для устройств многих производителей, включая Extreme Networks, Juniper, Cisco, HP, IBM, NEC, MikroTik. [1]

Архитектура [ править | править код ]

Путь прохождения данных (datapath) состоит из таблицы потоков (flow table) и действий, назначенных для каждой записи в таблице. Сами таблицы могут касаться как Ethernet (или других протоколов канального уровня), так и протоколов вышестоящих уровней (IP, TCP). Точный список действий может меняться, но основные это: форвардинг (пересылка фрагмента данных – пакета, фрейма – в заданный порт), пересылка фрагмента данных на контроллер через безопасный канал для дальнейшего исследования, отбрасывание фрагмента данных (drop). Для устройств, совмещающих openflow и обычную обработку пакетов средствами микропрограммы устройства, добавляется четвёртый тип действия: обработка фрагмента данных обычными средствами. Оборудование, поддерживающее эти четыре действия являются Type0-устройствами.

Устройство OpenFlow состоит, как минимум, из трёх компонент:

  • таблицы потоков (англ. flow table );
  • безопасного канала (англ. secure channel ), использующегося для управления коммутатором внешним «интеллектуальным» устройством (контроллером);
  • Поддержки протокола OpenFlow protocol, использующегося для управления. Использование этого протокола позволяет избежать необходимости писать программу для управляемого устройства;

Каждая запись в таблице потоков имеет три поля: заголовок PDU (фрагмента данных), который позволяет определить соответствие PDU потоку, действие и поле со статистикой (число байтов и PDU, соответствующее потоку, время прохождения последнего соответствующего потоку PDU).

Заголовок может состоять из множества полей разного уровня (например, MAC-адресов отправителя и получателя, полей из заголовка IP-пакета, полей из заголовка TCP-сегмента). Следует отметить, что в текущей версии протокола [2] не поддерживается проверка, к примеру, флага SYN в заголовке TCP-сегмента. Каждое поле может иметь особое значение (астериск), означающее соответствие любому значению соответствующего поля в PDU. [3]

Устройства type1, которые будут обеспечивать трансляцию сетевых адресов, поддержку классов и приоритетов, запланированы, но их спецификация пока не определена.

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


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

OpenFlow, как составляющая часть концепции SDN в виде протокола управления между соответствующими контроллерами и коммутаторами, появился по мерками компьютерной индустрии уже сравнительно давно — 31 декабря первая версия стандарта отметит свое пятилетие. Что же в итоге мы получили? Давайте смотреть и разбираться, тем более, что история весьма интересная.

Читайте также:  Уравнения с квадратным корнем примеры с решением

Сперва давайте вспомним, что подразумевает концепция Программно Конфигурируемых Сетей (Software Defined Networks, SDN), в рамках которой подразумевается использование OpenFlow.

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

В целом, алгоритм действий, вызываемых приходом пакета на порт коммутатора, радикальных изменений не претерпел, поменялись лишь функциональные модули алгоритма: контроллер стал дальше и централизованным, а локальные таблицы — более сложными.

Вся сетевая инфраструктура получила высокую степень виртуализации — виртуальные порты и коммутаторы управляются точно также, как и физические.

Положив руку на сердце скажем честно: та самая вышедшая аккуратно под новый год первая версия стандарта OpenFlow 1.0, ответственного за связь коммутаторов и контроллеров и, по большому счету, вообще за маршрутизацию данных в сети, была скорее ознакомительной, чем реально рабочей. Да, она описывала базовое функционирование в рамках нового протокола, но в ней не было поддержки настолько большого количества необходимых функций, что говорить о реальном применении не приходилось. Поэтому последующие 2,5 года шло допиливание стандарта: добавляли множественные таблицы обработки, поддержку меток, поддержку IPv6, гибридный режим работы коммутаторов, контроль скорости потоков, резервные каналы связи коммутаторов и контроллеров, — уже по одному этому списку можно понять, насколько неполным был исходный стандарт. Поэтому лишь после 25 июня 2012 года с появлением версии 1.3.0 можно говорить о готовности стандарта к использованию. Дальнейшее развитие до текущей версии 1.4 можно охарактеризовать уже как незначительные изменения с ликвидацией ошибок.

Ну хорошо, вот уже два года как у нас есть полноценный стандарт, про который нам рассказывали, что это новая парадигма построения сетей, все будет стильно-модно-молодежно, OPEX и CAPEX упадут ниже плинтуса и прочие полагающиеся в таких случаях вещи. Так почему же до сих пор не видно повсеместного энтузиазма в вопросах внедрения новинки? Тому есть несколько причин из категории «гладко было на бумаге, да забыли про овраги».

Несложно догадаться, что при такой концепции всей системы особенно важным становится выбор контроллера OpenFlow. Именно его быстродействие станет решающим фактором при возникновении любых экстренных ситуаций, именно его алгоритмы будут определять эффективность работы всей сети, именно его сбой с большой степенью вероятности «положит» всю сеть. На первый взгляд выбор контроллеров более чем велик: Open DayLight, NOX, POX, Beacon, Floodlight, Maestro, SNAC, Trema, Ryu, FlowER, Mul… есть даже RUN OS, разработанный в России ребятами из ЦПИКС. И это все не считая контроллеров от грандов, таких как Cisco, HP, IBM.
Проблема в том, что если мы берем контроллер с открытой архитектурой, то получаем, по большому счету, не готовое решение, а заготовку, в которую надо вложить изрядное количество сил, приводя ее возможности к необходимым в рамках вашей задачи. Для компаний уровня Google или Microsoft это, очевидно, не является проблемой. Для всех остальных, рангом пониже, это приводит к необходимости в собственном штате программистов, великолепно разбирающихся в сетевых технологиях. Ну и, естественно, требует существенного времени на подготовку проекта к запуску, а также создает изрядные риски, связанные с уникальностью и невозможностью широкомасштабного длительного тестирования.
Альтернативным вариантом является приобретение готовых коммерческих контроллеров. Но здесь мы получаем то, от чего все стремятся уйти, выбирая варианты, начинающиеся со слова «Open» — закрытые архитектуры с их неизвестной логикой работы, полная зависимость от поставщика при любых проблемах, вопросы совместимости, проприетарный дополнительный функционал, привязывающий, опять же, к конкретному производителю.

2. Вопросы архитектуры

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

  • Что происходит в случае выхода контроллера из строя?
  • В случае резервирования контроллеров как осуществляется их связь и принятие решения о главенстве/передачи функций?
  • По каким каналам связи осуществляется взаимодействие контроллера/ов и коммутаторов, по основной структуре передачи данных или параллельной? Что происходит при проблемах на линии связи?
Читайте также:  Где располагается почтовый ящик абонента

И решение этих вопросов без права на ошибку должно происходить на этапе планирования сети.

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

4. Готовность коммутаторов

Если мы выносим план управления из коммутаторов — они должны стать проще. Так, да не совсем: новый протокол, а точнее огромное количество учитываемых по умолчанию полей в таблицах маршрутизации выдвигает повышенные требования к объемам памяти на коммутаторах.

Знаменитые 12 tuples базового стандарта

Они же, расширенные метками

Тут необходимо вспомнить, что в современных высокоскоростных коммутаторах для хранения таблиц используется TCAM (Ternary Content Addressable Memory) — это единственный адекватный по скорости поиска информации способ хранения данных, от которого невозможно никуда деться, если мы хотим заниматься коммутацией и маршрутизацией на скоростях интерфейса. И стоит TCAM достаточно дорого. Поэтому даже коммутаторы на мощных относительно современных ASIC’ах порой могут поддерживать OpenFlow исключительно формально, обеспечивая менее тысячи OF-записей в TCAM. В принципе, можно было бы организовать многоуровневое хранение записей, сделав в TCAM буфер для самых актуальных записей и сложив в оперативную память все остальное, но для этого необходимо весьма ощутимо модифицировать платформу коммутаторов, большинство существующих моделей на такое просто не способно.
И это не говоря о том, что многие ASIC в принципе не способны поддерживать часть заявленных в OpenFlow функций, поскольку попросту не имеют их поддержки «в кремнии».

Пример реально поддерживаемых полей и экшенов

Конечно, этот недостаток легко купируется добавлением к ASIC сетевых процессоров (NPU) с высокой степенью программируемости, но это сразу влечет ощутимый рост как энергопотребления, так и стоимости. А это уже, в свою очередь, вызывает вопрос о целесообразности всей затеи, поскольку вместо упрощения и удешевления конечных устройств мы получим строго обратное.

Так что же, все плохо и у нового стандарта нет шансов?
Вовсе нет, если не верить всем обещаниям восторженных апологетов новых технологий и здраво оценивать возможности нового стандарта, то его уже сейчас вполне можно использовать себе на благо.

Большую часть вопросов, озвученных выше, можно успешно решить на стадии проектирования сети, тщательно подойдя к выбору оборудования. Хорошо выбранный контроллер (коммерческий или открытый, но дописанный «под себя»), продуманная архитектура, подобранные коммутаторы (например, такие как Eos420 на матрице Broadcom Trident 2 или Eos 410i, построенный на матрице Intel FM6764 с одной из самых больших в классе таблиц TCAM), и работоспособная сеть на OpenFlow 1.3 становится реальностью.

Не верите, что это доступно кому-либо, не являющемуся огромной Корпорацией Добра? Спросите компанию Перформикс, вот уже год имеющую стабильную сеть на OpenFlow в продакшн.

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

Матрица Intel FM6764 уже обещает программируемость (для хардкорных любителей регистров), текущие продукты остальных разработчиков менее открыты.

Недостаток аппаратных возможностей остальных современных ASIC обещают решить в следующих поколениях, которые выйдут на рынок в 2015 году. Такие продукты показал Broadcom — его матрица Tomahawk может настраиваться для поддержки разных forwarding/match/action.

В свою очередь, Cavium обещает полностью программируемую матрицу XPliant, в которой будет возможно добавлять новые протоколы по мере их появления с сохранением line-rate скорости обработки.

Да и спрос на OpenFlow решения со стороны традиционных операторов связи подстегнет прогресс.

“>

Оцените статью
ПК Знаток
Добавить комментарий

Adblock
detector