Comments 39
Мммм… Хотеть. Оно уже у кого-нибудь из массовых вендоров есть?
Да хоть на домашний роутер можно ставить: www.openflow.org/wk/index.php/OpenWrt
Xenserver DVS, железячные только только готовят бета прошивки с поддержкой openflow. БОльшая проблема не в коммутаторах (понятно что они тупы и должны просто соответствовать спецификациям), а в контроллерах- есть только экспериментальные поделки и что-то платно-закрытое. Из того, что я нарыл самый адекватный NOX, но это даже не контроллер, а API-прослойка, для удобства написания своего контроллера на C++ или python =)
Смотря какой вендор для вас является массовым. Народ говорит купить можно у NEC.
У Brocade, Cisco и Juniper есть решения которые так или иначе решают теже текущие вопросы фабричным методом.
У Brocade, Cisco и Juniper есть решения которые так или иначе решают теже текущие вопросы фабричным методом.
UFO just landed and posted this here
Скажем так — в рамках одного датацентра (даже в рамках аренды стойки в датацентре) можно уже получить неслабый профит, избавляясь от DDOS шевелением мизинца левой руки. А дома — разве что для экспериментов :)
К сожалению на данный момент вообще непонятно кому это нужно, народ бает что реально используют это дело на данный момент вроде в Google и в Yahoo, но проверить это не просто, поэтому можно только верить или нет.
Практически все что предлагается в рамках этой концепции можно решить на существующем железе, суть в том, что это не про железо это про софт.
Практически все что предлагается в рамках этой концепции можно решить на существующем железе, суть в том, что это не про железо это про софт.
Не совсем понятно что будет если количество специальных пакетов по которым нужно принимать решения будет достаточно большим? Банально ошиблись в одном правиле на СКВЗ и наши же свичи его же и положат запросами. И как происходит изменение уже существующего правила?
Для изменения есть специальная команда Modify, а с пакетами очень просто — после анализа пакета добавляется новое правило и шлется команда Barrier, т.е. сначала добавить правило, и только потом продолжать дальнейшую обработку.
Ну а за тем, чтобы не налажать в правилах — наверное, админ должен сам следить
Ну а за тем, чтобы не налажать в правилах — наверное, админ должен сам следить
Вот ссылка на видео с недавнего мероприятия как раз по данной теме. Практически все темы подробно раскрыты.
Насколько я понимаю, эта технология предполагает наличие двух сетей — control и user-plane? И при этом control-plane сеть строится каким-либо традиционным способом?
Нет, подключение к контроллеру идет по обычной сети по ssh. В принципе, ничто не мешает находиться контроллеру где-то в облаках с гарантированной доступностью
Может я что-то упускаю из виду, но если контрольные пакеты ходят по той же самой сети, у нас все-таки есть возможность навлечь на себя дальнюю дорогу, накосячив с правилами для контрол-плейн траффика?
Есть такая штука — SNMP (v3, допустим). Он, если исходная железка поддерживает его, позволяет по сети управлять кучей всяких вещей, в том числе — по проприетарным МИБам — и конфигами, вплоть до настроек policy-based filtering, VLANs, mirroring etc. Правильно ли я понимаю, что OpenFlow — это такое обобщение SNMP, чтобы все управляющие запросы-ответы были если не стандартизованы, то хотя бы близки к этому?
И ещё вопрос — в чём упрощение для L3, за счёт которого стоимость должна упасть? Я не знаком с продукцией Cisco (что за чипы у них внутри), но вот чипы от Broadcom позволяют уже сейчас настроить фильтры и рулы прямо в железе, в том числе и для процессинга IP-пакетов, в том числе и IPv6. Где будет упрощение «от OpenFlow»?
И ещё вопрос — в чём упрощение для L3, за счёт которого стоимость должна упасть? Я не знаком с продукцией Cisco (что за чипы у них внутри), но вот чипы от Broadcom позволяют уже сейчас настроить фильтры и рулы прямо в железе, в том числе и для процессинга IP-пакетов, в том числе и IPv6. Где будет упрощение «от OpenFlow»?
Нет, вы немного неправильно поняли. Ключевое отличие в том, что через SNMP или еще как вы задаете статическую конфигурацию коммутатора. Т.е. пока вы не измените какие/либо правила или настройки, он будет обрабатывать пакеты по одним и тем же правилам.
В OF же каждый пакет, не попавший под уже существующие правила, отправляется на контроллер, тот его анализирует и далее дает команду коммутатору добавить то или иное правило обработки схожих по каким либо параметрам пакетов (например, по MAC src) или/и отправить пакет на порт/порты.
Теоретически вы можете используя примитивнейший коммутатор L3 (который может аппаратно править заголовки пакетов) и соответствующий OF контроллер (работающий на среднем сервере) получить приличный BGP роутер за смешные деньги =)
В OF же каждый пакет, не попавший под уже существующие правила, отправляется на контроллер, тот его анализирует и далее дает команду коммутатору добавить то или иное правило обработки схожих по каким либо параметрам пакетов (например, по MAC src) или/и отправить пакет на порт/порты.
Теоретически вы можете используя примитивнейший коммутатор L3 (который может аппаратно править заголовки пакетов) и соответствующий OF контроллер (работающий на среднем сервере) получить приличный BGP роутер за смешные деньги =)
То есть основное отличие в том, что контроллер способен генерировать правила для свичей/роутеров динамически, на основе анализа трафика, который под существующий набор не попадает, и эти правила потом запихивать в свичи? Иными словами, главная фишка — не в протоколе как таковом, а в логике построения новых правил?
В тех свичах, с которыми я имел дело, пакеты, с которыми «незнамо что делать», тоже шли на контроллер — просто он расположен был в виде CPU на той же плате, что и свич-чип. Я потому и спрашиваю, что пытаюсь понять принципиальное отличие от такого подхода.
В тех свичах, с которыми я имел дело, пакеты, с которыми «незнамо что делать», тоже шли на контроллер — просто он расположен был в виде CPU на той же плате, что и свич-чип. Я потому и спрашиваю, что пытаюсь понять принципиальное отличие от такого подхода.
«IPv6. Впрочем, о покойниках или хорошо, или ничего.» — мне как неспециалисту непонятно. Не поясните?
Пока в протоколе нет управления ipv6 трафиком. Крайне рекомендую почитать www.openflow.org/documents/openflow-spec-v1.1.0.pdf Документ совсем небольшой, что еще раз напоминает о том, что технология только-только вылезла из пеленок =)
Просто IPv6 как был мертворожденным, так и останется в попытках реанимирования, пока не придумают толковый IPv8, и на него все перейдут с 4го, минуя шестой.
Ага, значит я правильно понял вашу фразу. Есть какие-то реальные предпосылки к его появлению? Пока, насколько я вижу на свой непросвещённый взгляд, с трудом внедряется лишь IPv6.
Глядя на нынешние расклады, можно смело расчитывать еще на 6-8 лет полноценного v4, а там уж и свежак подоспеет:
IPv8 is closer than you think...IPv16 is even closer…
ipv8.dyndns.tv
ipv8.yi.org
ipv8.dyns.cx
ipv8.no-ip.com
ipv8.no-ip.org
ipv8.no-ip.biz
ipv8.no-ip.info
ipv8.myip.us
ipv8.dyn.ee
ipv8.community.net.au
www.iana.org/assignments/ipv4-address-space
www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt
IPv8 is closer than you think...IPv16 is even closer…
ipv8.dyndns.tv
ipv8.yi.org
ipv8.dyns.cx
ipv8.no-ip.com
ipv8.no-ip.org
ipv8.no-ip.biz
ipv8.no-ip.info
ipv8.myip.us
ipv8.dyn.ee
ipv8.community.net.au
www.iana.org/assignments/ipv4-address-space
www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt
Кстати! Решил в гугле проверить — так ведь таки да! lists.ripe.net/pipermail/ripe-org-closed/1993/msg00024.html
UFO just landed and posted this here
Передергивает от слова «свитч». Хотите использовать родную терминологию — так пишите английское switch, уверен что все поймут. А на русском лучше уж использовать «коммутатор». Хотя… может это я один такой чувствительный :)
Sign up to leave a comment.
OpenFlow for dummies