kisa Опубликовано 23 марта, 2015 · Жалоба Хороший OpenFlow коммутатор должен обладать больших TCAM, т.к. все flow, записанные в коммутатор должны где-то храниться. Эта цифра должна быть несколько миллионов. Пока я знаю только Extreme BlackDiamond X8 с очень толстыми платами и Ericsson SSR. На них реально построить OpenFlow-железку. Остальное полумеры... Либо придумывать такой трафик, чтобы количетсво Flow не превышало определенного предела. А что rib, fib уже не надо нигде хранить? Для маршрутизации не сильно больше flow надо чем префиксов. pfexec, сколько скепсиса и инерции. Многие из хороших вещей, что есть в сетях, когда-то были новыми и возможно революционными идеями. Без умения по новому посмотреть на существующую картину сложно идти вперед. Вот основатель так горячо любимого и внемогущего cisco один из таких примеров, он дислектик, которые славятся своими нестандартными решениями, потому что стандартного пути их природа лешила. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kisa Опубликовано 23 марта, 2015 · Жалоба Еще одно замечание по поводу размера памяти. flow по природе своей динамические, у них есть время жизни. Не обязательно даже для всего классического fib иметь всегда в памяти столько же флоу. Можно иметь "горячие" flow. А rib пускай себе живет на контроллере. Сколько % из full view у оператора разных уровней используется одномоментно, и как часто картинка использования префиксов реальным трафиком меняется? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pavel.odintsov Опубликовано 24 марта, 2015 · Жалоба Я вот правда не понимаю один момент. Вот есть у меня матрица какой-нибудь Broadcom Trident. Я вот знаю, сколько он тянет префиксов по в4/в6, знаю сколько тянет ACL, а вот найти сколько опенфлоу рулесов - не могу. Kisa, просветите? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Sergeylo Опубликовано 24 марта, 2015 · Жалоба у нас уже есть пример несостоявшейся революции - ipv6 Вот давайте тут не надо, ладно? Революции особой не предвиделось - v6 неизбежно, в долгосрочной перспективе, вытеснит v4. Лет, скажем, через тридцать. Бодрого внедрения не состоялось, потому что операторы не могут делать на v6 коммерции, и не заинтересованы во внедрении до самого последнего предела. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pfexec Опубликовано 24 марта, 2015 · Жалоба сколько скепсиса и инерции.это не скепсис, это обоснованное сомнение, что это всё будет работать в том виде в котором преподносит автор(ы).а мир вообще инертен, надо привыкнуть к этому. посмотрите на ipv6, его с 2008ого года пытаются пропихнуть в массы, а оно всё там же. до тех пор пока новая революционная технология не позволяет заработать или сэкономить - она не нужна никому. Можно иметь "горячие" flow. А rib пускай себе живет на контроллере. Сколько % из full view у оператора разных уровней используется одномоментно, и как часто картинка использования префиксов реальным трафиком меняется?вам бы в матчасти работающих протоколов разобраться и разобраться в том как это работает сейчас, чтобы понимать что ваши "предложения" порождают больше вопросов, чем решают, если вообще что-то решают. :)Бодрого внедрения не состоялось, потому что операторы не могут делать на v6 коммерции, и не заинтересованы во внедрении до самого последнего предела.бодрого внедрения не состоялось не потому что кто-то против, а потому что на ipv6 нельзя заработать денег, а можно только потратить. и это касается всех: и операторов, и контент-генераторов.Революции особой не предвиделось - v6 неизбежно, в долгосрочной перспективе, вытеснит v4. Лет, скажем, через тридцать.ну как же, ipv6 как раз революционен по сравнению с ip4. это не просто же "адрес стал толще". Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kisa Опубликовано 24 марта, 2015 · Жалоба Я вот правда не понимаю один момент. Вот есть у меня матрица какой-нибудь Broadcom Trident. Я вот знаю, сколько он тянет префиксов по в4/в6, знаю сколько тянет ACL, а вот найти сколько опенфлоу рулесов - не могу. Kisa, просветите? не, я не в курсе. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pavel.odintsov Опубликовано 24 марта, 2015 · Жалоба Я тут поучаствовал в воркшопе с этим 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 и он уже дает команду казнить либо помиловать, свич ее хавает и кэширует на заданное время либо до смерти потока. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kisa Опубликовано 24 марта, 2015 · Жалоба Подолью еще масла по поводу отсутствия практических применений openflow - google заявил, что ее внутренняя сеть между датацентрами перешла на openflow, что позволило им достичь в разы большую утилизацию линков и получить ту степень контроля на потоками данных, которую они хотели, но не могли получить с помощью традиционных подходов статья: http://www.wired.com/2012/04/going-with-the-flow-google/all/1 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kisa Опубликовано 24 марта, 2015 · Жалоба По поводу NAT - очевидно, нужно почитать спеки чипов - Broadcom Trident и StrataXGS и убедиться, что никакого NAT оно не умеет, не умело и уметь не будет - это коммутационная матрица. Если есть мысли делать что-то на "контрол плейне", то спешу расстроить - там от силы мегагерц 400 и ширина линка между контролом и дата плейном - гигабит. Ни о каком NAT, роутинге - речи быть вообще не может, ну никак. если речь про мысли что-то делать на "контрол плейне" в рамках openflow, то под контроллером в этом случае понимают внешнее по отношению к свитчу устройство, а не внутренний процессор, который конечно никому не интересен. Очень верно было подмечено, что свич - это свич, что роутер - это роутер и что фаерволл - это фаерволл. Это суть разные кейсы и они сугубо по разному решаются в железе и совмещать воедино - получится такой монстр за такие деньги, что ни у кого денег не хватит. Cуть dataplane этих устройств одна и таже - перекладывание пакетов из одного порта в другой, выполняя некоторые преобразования над пакетами. А вот контрол плейн - да, очень разный и его возможно будет интересно вынести в отдельную сущность, которая знает больше, чем контрол плейн отдельного классического устройства, видит всю сеть целиком, оперируя ей как одним целым. Именно физическое разделение этих двух вещей - суть sdn. Но вопрос по поводу того, является ли Cumulus SDN или нет остается :) Но недавно открытые спеки Broadcom могут пролить на это свет. А именно мой вопрос в том, что сама ли матрица решает куда и что вливать (грубо говоря на базе запрограммированных правил какой пор тс каким залинкован) либо же все новые flow влетают в контроллер на control plane и он уже дает команду казнить либо помиловать, свич ее хавает и кэширует на заданное время либо до смерти потока. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Butch3r Опубликовано 24 марта, 2015 · Жалоба Подолью еще масла по поводу отсутствия практических применений openflow - google заявил, что ее внутренняя сеть между датацентрами перешла на openflow, что позволило им достичь в разы большую утилизацию линков и получить ту степень контроля на потоками данных, которую они хотели, но не могли получить с помощью традиционных подходов статья: http://www.wired.com/2012/04/going-with-the-flow-google/all/1 а поделятся ли они своими наработками с народом-gpl ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pfexec Опубликовано 24 марта, 2015 · Жалоба Именно физическое разделение этих двух вещей - суть sdn.суть в том что вам надо разобраться с кашей в своей голове. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DVM-Avgoor Опубликовано 24 марта, 2015 · Жалоба 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 и успешно этого добиваются тоннами кода. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dazgluk Опубликовано 24 марта, 2015 · Жалоба Мне вот интересно, как с точки зрения SDN/Openflow решается простейшая задача резервирования канала? Допустим у нас есть распределенная сеть, весь менеджмент соответственно in-band, ибо отдельную оптику для коммутаторов тянуть никто не будет. И вот, есть у нас STP колечко, контроллер радостно генерит BPDU, свитчики по FLow table размыкают кольцо, никакой петли, красота, все хорошо работает. Но вот рвется волокно... Коммутатору с Alternate портом нужно бы сомкнуть кольцо и перестроить Flow table, но связи с контроллером то нет. Как предполагается решать эту задачу? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DVM-Avgoor Опубликовано 24 марта, 2015 · Жалоба Мне вот интересно, как с точки зрения SDN/Openflow решается простейшая задача резервирования канала? А вы use-cases-то почитали? :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dazgluk Опубликовано 24 марта, 2015 · Жалоба Мне к сожалению не удалось каких то более-менее поиземленных к реальному миру описаний протокола, нашёл упоминание в 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 датаплейна", это по крайней мере понятно как, зачем, и применимо к телекому. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DVM-Avgoor Опубликовано 24 марта, 2015 · Жалоба SDNу в телекоме не место, оно совсем не для того. Ну а cisco пытается "поднять рынок", ибо 48х10Г за 4к$ это не дело, а вот с MPLS это продается гораздо интереснее. (Если вообще продается) :-) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dazgluk Опубликовано 24 марта, 2015 · Жалоба SDNу в телекоме не место, оно совсем не для того. Ну а cisco пытается "поднять рынок", ибо 48х10Г за 4к$ это не дело, а вот с MPLS это продается гораздо интереснее. (Если вообще продается) :-) Everything is better with bluetoothMPLS :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DVM-Avgoor Опубликовано 24 марта, 2015 · Жалоба Everything is better with bluetoothMPLS :) Напомнило :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pavel.odintsov Опубликовано 24 марта, 2015 · Жалоба Как подтвердил первоисточник - Cumulus - не умеет SDN, то есть использовать его как тупую железку и рулить извне - не выйдет. Не долго музыка играла, не долго фраер танцевал :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kisa Опубликовано 24 марта, 2015 · Жалоба 1. SDN еще очень далеко от реальности. Когда гугл говорит что у него сети SDN это не значит что он говорит о диких эротических связках OpenStack + OpenDaylight + Cumulus. Он просто пишет более свой велосипед. они не только программную часть написали, они вообще начали с того, что свою железку себе запилили Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pavel.odintsov Опубликовано 24 марта, 2015 · Жалоба 1. SDN еще очень далеко от реальности. Когда гугл говорит что у него сети SDN это не значит что он говорит о диких эротических связках OpenStack + OpenDaylight + Cumulus. Он просто пишет более свой велосипед. они не только программную часть написали, они вообще начали с того, что свою железку себе запилили Пфф, железку собрать - это одно. А коммутационную матрицу - другое. Вот Фейсбук с тонной пиара вывалил свой монстро-свич. И что? технологично - для непосвященного может быть. А на деле внутри тот же Broadcom. Вот если Google/FB свою комутационную сделают - вот будет интересно. Честно говоря, лично для себя я не вижу никакого профита в SDN. Клиенты счастливее не станут. Трафик быстрее бегать не начнет. Управляемее? Ну у меня и сейчас вроде управляемо (а чему быть неуправляемым на сотню свичей от силы-то?). А вот за качественный да открытый да быстрый роутер - я бы отвалил приличных денег :) И мне лично пофигу - на модном SDN или на немодном "делаю все в железе". Кроме этого, я не понимаю желания выносить управление свичами на таз. Вот правда - не понимаю. За весь свой долгий опыт я не видел ни единого серьезного 10GE свича, который бы взял да умер на пустом месте. А вот тазов - каждый день по паре штук с багами класса "сотона его разберет". Имхо, как раз возможность иметь быстрый контрол плейн и с него рулить еще десятком дивайсов да чтобы еще этот контрол плейн фейлаверился по крупной группе свичей - вот это я понимаю - НАДЕЖНОСТЬ. А пять свичей и слабо резервированный таз (который, к слову, не бесплатен) - не особо надежный подход. Но последнее время есть подвижки, иногда даже ставят i3 и даже i5 на контрол плейн ;) Ждем когда воткнут что-то класса e5-1660v3:) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DVM-Avgoor Опубликовано 25 марта, 2015 · Жалоба они не только программную часть написали, они вообще начали с того, что свою железку себе запилили Я еще раз говорю, что во-первых мы не знаем как оно было там доподлинно. Во-вторых нет в этом никакой магии, кастомный свитч по силам не только гуглу. Однако многие вещи и сейчас делаются в похожем ключе совершенно без OpenFlow и модных презентаций. Просто делается все через vendor locked API. Возможно это плохо и не по-столлмановски, но есть ли кому дело? В-третьих - не надо будоражить черепную коробку вещами которые вряд ли кому вообще понадобятся, т.к. очень уж специфичны юзкейсы. У вас есть пара ДЦ с собственной инфраструктурой "на продажу"? Даже если ответ "да" это еще не значит что SDN вам уже как-то нужен. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pavel.odintsov Опубликовано 25 марта, 2015 · Жалоба SDN, имхо, в первую очередь нужен, когда в ТВОЕМ ДЦ крутится ТВОЙ софт и надо очень умно линковать различные логические структуры (hadoop кластеры, кэши, фронты и проч.) наиболее оптимальным образом да еще и без кабельной работы. Если речь идет о том, чтобы провести по куче вланов и выпустить в мир клиента с дедика - то я не знаю как тут SDN засобачить :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DVM-Avgoor Опубликовано 25 марта, 2015 · Жалоба SDN, имхо, в первую очередь нужен, когда в ТВОЕМ ДЦ крутится ТВОЙ софт и надо очень умно линковать различные логические структуры (hadoop кластеры, кэши, фронты и проч.) наиболее оптимальным образом да еще и без кабельной работы. Почти так только можно без ДЦ, скорее как сервис для внутреннего или внешнего клиента. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pvl19 Опубликовано 22 декабря, 2016 (изменено) · Жалоба Quanta 24sfp+ сейчас уже по 500енотов только интерфейс там сложноватый и не все он понимает кто то работал с Quanta ?? принимает все сфп+, но гиговые сфп не подимаются (((( кто то имел опыт решения ? может прошивка модулей ?? Изменено 22 декабря, 2016 пользователем pvl19 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...