[kisa]

Хороший OpenFlow коммутатор должен обладать больших TCAM, т.к. все flow, записанные в коммутатор должны где-то храниться. Эта цифра должна быть несколько миллионов. Пока я знаю только Extreme BlackDiamond X8 с очень толстыми платами и Ericsson SSR. На них реально построить OpenFlow-железку. Остальное полумеры... Либо придумывать такой трафик, чтобы количетсво Flow не превышало определенного предела.

А что rib, fib уже не надо нигде хранить?

Для маршрутизации не сильно больше flow надо чем префиксов.

 

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

[kisa]

Еще одно замечание по поводу размера памяти.

flow по природе своей динамические, у них есть время жизни. Не обязательно даже для всего классического fib иметь всегда в памяти столько же флоу.

Можно иметь "горячие" flow. А rib пускай себе живет на контроллере. Сколько % из full view у оператора разных уровней используется одномоментно, и как часто картинка использования префиксов реальным трафиком меняется?

[pavel.odintsov]

Я вот правда не понимаю один момент. Вот есть у меня матрица какой-нибудь Broadcom Trident. Я вот знаю, сколько он тянет префиксов по в4/в6, знаю сколько тянет ACL, а вот найти сколько опенфлоу рулесов - не могу. Kisa, просветите?

[Sergeylo]

у нас уже есть пример несостоявшейся революции - ipv6

Вот давайте тут не надо, ладно?

Революции особой не предвиделось - v6 неизбежно, в долгосрочной перспективе, вытеснит v4. Лет, скажем, через тридцать.

Бодрого внедрения не состоялось, потому что операторы не могут делать на v6 коммерции, и не заинтересованы во внедрении до самого последнего предела.

[pfexec]

сколько скепсиса и инерции.

это не скепсис, это обоснованное сомнение, что это всё будет работать в том виде в котором преподносит автор(ы).

а мир вообще инертен, надо привыкнуть к этому. посмотрите на ipv6, его с 2008ого года пытаются пропихнуть в массы, а оно всё там же. до тех пор пока новая революционная технология не позволяет заработать или сэкономить - она не нужна никому.

Можно иметь "горячие" flow. А rib пускай себе живет на контроллере. Сколько % из full view у оператора разных уровней используется одномоментно, и как часто картинка использования префиксов реальным трафиком меняется?

вам бы в матчасти работающих протоколов разобраться и разобраться в том как это работает сейчас, чтобы понимать что ваши "предложения" порождают больше вопросов, чем решают, если вообще что-то решают. :)

Бодрого внедрения не состоялось, потому что операторы не могут делать на v6 коммерции, и не заинтересованы во внедрении до самого последнего предела.

бодрого внедрения не состоялось не потому что кто-то против, а потому что на ipv6 нельзя заработать денег, а можно только потратить. и это касается всех: и операторов, и контент-генераторов.

Революции особой не предвиделось - v6 неизбежно, в долгосрочной перспективе, вытеснит v4. Лет, скажем, через тридцать.

ну как же, ipv6 как раз революционен по сравнению с ip4. это не просто же "адрес стал толще".

[kisa]

Я вот правда не понимаю один момент. Вот есть у меня матрица какой-нибудь Broadcom Trident. Я вот знаю, сколько он тянет префиксов по в4/в6, знаю сколько тянет ACL, а вот найти сколько опенфлоу рулесов - не могу. Kisa, просветите?

 

не, я не в курсе.

[pavel.odintsov]

Я тут поучаствовал в воркшопе с этим Cumulus. Впечатления двоякие.

 

С одной стороны - довольно удобно.

 

- Управление vlan и интерфейсами через обычный debian-style /etc/network/interfaces

- Управление коммутацией какого порта с каким - через brctl + стеройды.

- Управление состоянием портов - ethtool.

- Управление bonding - обычный Linux bond.

- Управление роутингом - ip route show

 

Для более сложного роутинга - BGP/OSPF/ISIS/Quagga.

 

Для фич, у которых нет аналогов в Лиунксе все сложнее, для рулежа ACL - своя тулза.

 

А вот когда речь доходе до вещей, у которых нет и не планируется аналогов в Linux - типа стекирования, MLAG, MPLS - тут дело труба.

 

Алсо, с моей стороны (я - Дата Центр) это идеальное решение для access/aggragation, ибо ничего кроме L2 в различных вариантах у меня в общем-то нету и все свичи работают как толстенные трафикокачалки эзернета. А вот операторам и провайдерам от этого не жарко не холодно.

 

По поводу NAT - очевидно, нужно почитать спеки чипов - Broadcom Trident и StrataXGS и убедиться, что никакого NAT оно не умеет, не умело и уметь не будет - это коммутационная матрица. Если есть мысли делать что-то на "контрол плейне", то спешу расстроить - там от силы мегагерц 400 и ширина линка между контролом и дата плейном - гигабит. Ни о каком NAT, роутинге - речи быть вообще не может, ну никак.

 

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

 

Но вопрос по поводу того, является ли Cumulus SDN или нет остается :) Но недавно открытые спеки Broadcom могут пролить на это свет.

 

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

[kisa]

Подолью еще масла по поводу отсутствия практических применений openflow - google заявил, что ее внутренняя сеть между датацентрами перешла на openflow, что позволило им достичь

в разы большую утилизацию линков и получить ту степень контроля на потоками данных, которую они хотели, но не могли получить с помощью традиционных подходов

статья: http://www.wired.com/2012/04/going-with-the-flow-google/all/1

[kisa]

По поводу NAT - очевидно, нужно почитать спеки чипов - Broadcom Trident и StrataXGS и убедиться, что никакого NAT оно не умеет, не умело и уметь не будет - это коммутационная матрица. Если есть мысли делать что-то на "контрол плейне", то спешу расстроить - там от силы мегагерц 400 и ширина линка между контролом и дата плейном - гигабит. Ни о каком NAT, роутинге - речи быть вообще не может, ну никак.

 

если речь про мысли что-то делать на "контрол плейне" в рамках openflow, то под контроллером в этом случае понимают внешнее по отношению к свитчу устройство, а не внутренний

процессор, который конечно никому не интересен.

 

 

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

Cуть dataplane этих устройств одна и таже - перекладывание пакетов из одного порта в другой, выполняя некоторые преобразования над пакетами.

 

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

 

 

Но вопрос по поводу того, является ли Cumulus SDN или нет остается :) Но недавно открытые спеки Broadcom могут пролить на это свет.

 

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

[Butch3r]

Подолью еще масла по поводу отсутствия практических применений openflow - google заявил, что ее внутренняя сеть между датацентрами перешла на openflow, что позволило им достичь

в разы большую утилизацию линков и получить ту степень контроля на потоками данных, которую они хотели, но не могли получить с помощью традиционных подходов

статья: http://www.wired.com/2012/04/going-with-the-flow-google/all/1

а поделятся ли они своими наработками с народом-gpl ?

[pfexec]

Именно физическое разделение этих двух вещей - суть sdn.

суть в том что вам надо разобраться с кашей в своей голове.

[DVM-Avgoor]

1. SDN еще очень далеко от реальности. Когда гугл говорит что у него сети SDN это не значит что он говорит о диких эротических связках OpenStack + OpenDaylight + Cumulus. Он просто пишет более свой велосипед.

2. SDN лохам не надо, его место не в сети на 10 писюков. И не на 20 и не на 50.

3. OpenFlow идеей интересен, но... Но как обычно это не наша идея, не телекомная. Эта идея рождена в умах контентщиков/сервисов, потому что см. 4.

4. Всё это реализация парадигмы "HELP ME IM STUPID". Можете верить маркетоидам с ихними "Our A helps B with C by giving economy in X" где любую из неизвестных можно заменить на Bullshit и ничего не изменится. А можете почитать спеки и git-репы этих проектов, и понять что ребята там борятся за то как натянуть REST-API на hello world и успешно этого добиваются тоннами кода.

[dazgluk]

Мне вот интересно, как с точки зрения SDN/Openflow решается простейшая задача резервирования канала?

Допустим у нас есть распределенная сеть, весь менеджмент соответственно in-band, ибо отдельную оптику для коммутаторов тянуть никто не будет.

И вот, есть у нас STP колечко, контроллер радостно генерит BPDU, свитчики по FLow table размыкают кольцо, никакой петли, красота, все хорошо работает.

Но вот рвется волокно...

Коммутатору с Alternate портом нужно бы сомкнуть кольцо и перестроить Flow table, но связи с контроллером то нет. Как предполагается решать эту задачу?

[DVM-Avgoor]

Мне вот интересно, как с точки зрения SDN/Openflow решается простейшая задача резервирования канала?

 

А вы use-cases-то почитали? :)

[dazgluk]

Мне к сожалению не удалось каких то более-менее поиземленных к реальному миру описаний протокола, нашёл упоминание в RFC7149, во вкладке non-goals

  o  Fully centralized control systems that are likely to raise some
     scalability issues.  Distributed protocols and their ability to
     react to some events (e.g., link failure) in a timely manner
     remains a cornerstone of scalable networks.  This means that SDN
     designs can rely upon a logical representation of centralized
     features (an abstraction layer that would support inter-PDP
     communications, for example).

Просто получается что без решения задачи резервирования линка контроллер<->свитч, полностью control plane в центр не утащить.

 

Мне понравилась фраза одного из докладчиком на cisco connect 2014, "поддержка sdn поверх mpls датаплейна", это по крайней мере понятно как, зачем, и применимо к телекому.

[DVM-Avgoor]

SDNу в телекоме не место, оно совсем не для того.

Ну а cisco пытается "поднять рынок", ибо 48х10Г за 4к$ это не дело, а вот с MPLS это продается гораздо интереснее. (Если вообще продается) :-)

[dazgluk]

SDNу в телекоме не место, оно совсем не для того.

Ну а cisco пытается "поднять рынок", ибо 48х10Г за 4к$ это не дело, а вот с MPLS это продается гораздо интереснее. (Если вообще продается) :-)

Everything is better with bluetoothMPLS :)

[DVM-Avgoor]

Everything is better with bluetoothMPLS :)

 

Напомнило :)

[pavel.odintsov]

Как подтвердил первоисточник - Cumulus - не умеет SDN, то есть использовать его как тупую железку и рулить извне - не выйдет. Не долго музыка играла, не долго фраер танцевал :)

[kisa]

1. SDN еще очень далеко от реальности. Когда гугл говорит что у него сети SDN это не значит что он говорит о диких эротических связках OpenStack + OpenDaylight + Cumulus. Он просто пишет более свой велосипед.

 

они не только программную часть написали, они вообще начали с того, что свою железку себе запилили

[pavel.odintsov]

1. SDN еще очень далеко от реальности. Когда гугл говорит что у него сети SDN это не значит что он говорит о диких эротических связках OpenStack + OpenDaylight + Cumulus. Он просто пишет более свой велосипед.

 

они не только программную часть написали, они вообще начали с того, что свою железку себе запилили

 

Пфф, железку собрать - это одно. А коммутационную матрицу - другое. Вот Фейсбук с тонной пиара вывалил свой монстро-свич. И что? технологично - для непосвященного может быть. А на деле внутри тот же Broadcom. Вот если Google/FB свою комутационную сделают - вот будет интересно.

 

Честно говоря, лично для себя я не вижу никакого профита в SDN. Клиенты счастливее не станут. Трафик быстрее бегать не начнет. Управляемее? Ну у меня и сейчас вроде управляемо (а чему быть неуправляемым на сотню свичей от силы-то?). А вот за качественный да открытый да быстрый роутер - я бы отвалил приличных денег :) И мне лично пофигу - на модном SDN или на немодном "делаю все в железе".

 

Кроме этого, я не понимаю желания выносить управление свичами на таз. Вот правда - не понимаю. За весь свой долгий опыт я не видел ни единого серьезного 10GE свича, который бы взял да умер на пустом месте. А вот тазов - каждый день по паре штук с багами класса "сотона его разберет". Имхо, как раз возможность иметь быстрый контрол плейн и с него рулить еще десятком дивайсов да чтобы еще этот контрол плейн фейлаверился по крупной группе свичей - вот это я понимаю - НАДЕЖНОСТЬ.

 

А пять свичей и слабо резервированный таз (который, к слову, не бесплатен) - не особо надежный подход. Но последнее время есть подвижки, иногда даже ставят i3 и даже i5 на контрол плейн ;) Ждем когда воткнут что-то класса e5-1660v3:)

[DVM-Avgoor]

они не только программную часть написали, они вообще начали с того, что свою железку себе запилили

 

Я еще раз говорю, что во-первых мы не знаем как оно было там доподлинно. Во-вторых нет в этом никакой магии, кастомный свитч по силам не только гуглу. Однако многие вещи и сейчас делаются в похожем ключе совершенно без OpenFlow и модных презентаций. Просто делается все через vendor locked API. Возможно это плохо и не по-столлмановски, но есть ли кому дело?

В-третьих - не надо будоражить черепную коробку вещами которые вряд ли кому вообще понадобятся, т.к. очень уж специфичны юзкейсы. У вас есть пара ДЦ с собственной инфраструктурой "на продажу"? Даже если ответ "да" это еще не значит что SDN вам уже как-то нужен.

[pavel.odintsov]

SDN, имхо, в первую очередь нужен, когда в ТВОЕМ ДЦ крутится ТВОЙ софт и надо очень умно линковать различные логические структуры (hadoop кластеры, кэши, фронты и проч.) наиболее оптимальным образом да еще и без кабельной работы.

 

Если речь идет о том, чтобы провести по куче вланов и выпустить в мир клиента с дедика - то я не знаю как тут SDN засобачить :)

[DVM-Avgoor]

SDN, имхо, в первую очередь нужен, когда в ТВОЕМ ДЦ крутится ТВОЙ софт и надо очень умно линковать различные логические структуры (hadoop кластеры, кэши, фронты и проч.) наиболее оптимальным образом да еще и без кабельной работы.

 

Почти так только можно без ДЦ, скорее как сервис для внутреннего или внешнего клиента.

[pvl19]

Quanta 24sfp+ сейчас уже по 500енотов только интерфейс там сложноватый и не все он понимает

кто то работал с Quanta ?? принимает все сфп+, но гиговые сфп не подимаются (((( кто то имел опыт решения ? может прошивка модулей ??

Изменено 22 декабря, 2016 пользователем pvl19