Как стать автором
Обновить

Комментарии 39

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

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

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

Как с этим дела в 2024?

НЛО прилетело и опубликовало эту надпись здесь
Передергивает от слова «свитч». Хотите использовать родную терминологию — так пишите английское switch, уверен что все поймут. А на русском лучше уж использовать «коммутатор». Хотя… может это я один такой чувствительный :)
стараюсь писать «коммутатор», но иногда просто лениво, короче просто «свич» (причем без «т», т.к. она не произносится в оригинале, да и в русской кальке тоже).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории