Умник Опубликовано 2 марта, 2015 · Жалоба по ссылке просто чьи-то ванильные фантазии Если бы вы видели количество патчей в списке рассылки netdev на тему поддержки "rocker switch" и патчи на тему H/W offload иже с ним (все это началось буквально пол-года назад), вы бы так не говорили. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pfexec Опубликовано 2 марта, 2015 · Жалоба Если бы вы видели количество патчей в списке рассылки netdev на тему поддержки "rocker switch" и патчи на тему H/W offload иже с ним (все это началось буквально пол-года назад), вы бы так не говорили.я не понимаю, оно же просто "еще один бридж для линагза". как это связано с закрытостью asic'ов от тех 2.5 контор, которые эти асики делают ? планируете построить свитч вокруг ксеона с N-надцатью портами ? да флаг вам в руки. :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Умник Опубликовано 2 марта, 2015 (изменено) · Жалоба построить свитч вокруг ксеона с N-надцатью портами Если вы теперь чисто о софтовом решении, то уже построили. И даже не свитч, а роутер. http://www.6wind.com/products/6wind-turbo-router/ Minimum price (1 sockets with less than 100 routers)per router is 950 euros plus maintenance Изменено 2 марта, 2015 пользователем Умник Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DVM-Avgoor Опубликовано 2 марта, 2015 · Жалоба Если вы теперь чисто о софтовом решении, то уже построили. И даже не свитч, а роутер. Ну и? Отличный кстати пример. Вот есть dpdk с описанным API (интел всё же молодцы в этом плане), с полным howto по применению. И где опенсорс? Плевал опенсорс на это, они там точат свою розовую ваниль, им не до роутеров. А проприетарщики пилят, делают продукт, продают и поддерживают. Дык в чем же польза от dpdk в опенсорсе? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pavel.odintsov Опубликовано 2 марта, 2015 · Жалоба Если вы теперь чисто о софтовом решении, то уже построили. И даже не свитч, а роутер. Ну и? Отличный кстати пример. Вот есть dpdk с описанным API (интел всё же молодцы в этом плане), с полным howto по применению. И где опенсорс? Плевал опенсорс на это, они там точат свою розовую ваниль, им не до роутеров. А проприетарщики пилят, делают продукт, продают и поддерживают. Дык в чем же польза от dpdk в опенсорсе? Вы так говорите, как будто "опенсорц" - это нечто абстрактное :) А это на самом деле вполне осязаемые и понятные люди, который живут не так далеко от Вас :) Ставьте задачу, пишите ТЗ, собирайте людей, а там народ подтянется, если будет интерес. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Умник Опубликовано 2 марта, 2015 · Жалоба Кстати, DPDK в качестве datapath уже давно интегрирован в Open vSwitch. Нужно только контроллер написать. :) Правда не уверен, что там все хорошо с производительностью на всех случаях. Вообще, мне так думается, что opensource роутер/свитч с производительностью как у 6wind просто дело времени. Не знаю, поживем - увидим. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DVM-Avgoor Опубликовано 2 марта, 2015 · Жалоба Кстати, DPDK в качестве datapath уже давно интегрирован в Open vSwitch. Нужно только контроллер написать. :) Правда не уверен, что там все хорошо с производительностью на всех случаях. Вообще, мне так думается, что opensource роутер/свитч с производительностью как у 6wind просто дело времени. Не знаю, поживем - увидим. Работаю очень плотно с OVS, говно редкостное. Вы так говорите, как будто "опенсорц" - это нечто абстрактное :) А это на самом деле вполне осязаемые и понятные люди, который живут не так далеко от Вас :) Ставьте задачу, пишите ТЗ, собирайте людей, а там народ подтянется, если будет интерес. Продукт - дело больших усилий. Усилия == время, время бесплатно не бывает, есть надо на что-то. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Умник Опубликовано 2 марта, 2015 · Жалоба говно редкостное Что именно плохо? Интересно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DVM-Avgoor Опубликовано 2 марта, 2015 · Жалоба Что именно плохо? Интересно. Там много особенностей, в т.ч. и пресловутое быстродействие, как бы смешно не звучало. Не уверен что имею право рассказывать все, поэтому уж увольте :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pavel.odintsov Опубликовано 2 марта, 2015 (изменено) · Жалоба OVS еще и проц жрет люто :) Имеем-с в собственной ферме его на паре машин под роутинг openvz. Решительно лучше бриджей, но решительно хуже чего-то нормального :) Но за не имением аналогов - увы. Изменено 2 марта, 2015 пользователем pavel.odintsov Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alks Опубликовано 3 марта, 2015 · Жалоба Хочу дешевый быстрый NAT задешево, FPGA как понимаю здесь не катит? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DVM-Avgoor Опубликовано 3 марта, 2015 · Жалоба Хочу дешевый быстрый NAT задешево, FPGA как понимаю здесь не катит? В вопросе уже есть ответ. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pavel.odintsov Опубликовано 12 марта, 2015 · Жалоба А вот и подоспел полностью открытый Linux: https://github.com/opennetworklinux/ONL с поддержкой тех же Broadcom комутационок. Итого, за $4000 можно собрать приличный top of rack почти полностью на открытом софте. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pavel.odintsov Опубликовано 12 марта, 2015 · Жалоба Ну и чтобы добить совсем - Broadcom открыл спецификации и открыл SDK для своих последних поколений свичей: http://www.zdnet.com/article/broadcom-opens-up-switch-api-to-third-party-developers/ Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ollsanek Опубликовано 21 марта, 2015 · Жалоба по теме, проблема в том, что поддерживаются только те протоколы которые и так уже есть в линукс, просто они "проваливаются" в асик свича. т.е. у кумулуса нет МСТП (фигассе свич, да?), не говоря уже о всяких ерпс, пбб, макинмак, трилл и т.п. OVS еще и проц жрет люто :) Имеем-с в собственной ферме его на паре машин под роутинг openvz. Решительно лучше бриджей, но решительно хуже чего-то нормального :) Но за не имением аналогов - увы. так openvz же только на старых ядрах, а OVS с поддержкой DPDK только на новых. именно из-за этого начинаем косится в сторону докера но ... пока если что-то критичное по трафику, то суём в КВМ и отправляем на тазик с новым ядром. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 22 марта, 2015 · Жалоба Еще на кумулусе нет PBR/FBF Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kisa Опубликовано 23 марта, 2015 · Жалоба А я бы ставил на OpenFlow и проекты типа RouteFlow. https://sites.google.com/site/routeflow/ У них уже в боевом режиме крутится такой вот распределенный маршрутизатор: control plane - на тазике с линуксом и quagga (можно bird, можно любой софт маршрутизации, главное, чтобы на линуксе), a dataplane на железном OpenFlow свитче. Трафик у них правда смешной - сотни мегабит и правил маршрутизации, которые превращаются в flow database, тоже немного. Но теоретически эта конструкция способна работать на скорости портов железки. Мне интересно, а можно ли по аналогии с их архитектурой запилить NAT. Мне кажется, новые версии OpenFlow имею все функции, чтобы выполнять небходимые для nat преобразования в пакетах. Дальше нужен демон, отслеживающий conntrack таблицу и преобразовывающий ее в openflow правила. Первые пакеты соединения, которое нужно занатить, проходят от хоста в контроллер, попадают в linux, он обрабатывает их, создавая запись в базе conntrack и flow запись в свитче, выпускает в мир. Затем, последующие пакеты уже со свистом пролетают через openflow свитч, т.к. он уже знает как их обрабатывать. Получаем nat на скорости портов openflow свитча. Теоретически сотни гигабит. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pfexec Опубликовано 23 марта, 2015 (изменено) · Жалоба Еще на кумулусе нет PBR/FBFему оно и не надо. это жи свичи для датацентров: всё что им надо это толстые порты и буферы потолще. но толстые порты есть у всех, а буферы у всех одинаковые. так что чуда нет, разве что дешевле, т.к. нету кучи фич и имплементить их некому.control plane - на тазике с линуксом и quagga (можно bird, можно любой софт маршрутизации, главное, чтобы на линуксе), a dataplane на железном OpenFlow свитче.ну примерно тоже самое делают циски, жунепиры и ко, со своими "виртуальными" asr и mx. разница в том что у них оно будет стоить денег и будет уметь фичи, а опенсурс квагга как ничо не умела, так и не будет уметь, + баги, за которые мы все так любим кваггу. :Dновые версии OpenFlow имею все функции, чтобы выполнять небходимые для nat преобразования в пакетахдело же не в опенфлоу, а в оборудовании. опенфлоу магии не явит же. если свич не рожден делать нат, то его там не будет. Изменено 23 марта, 2015 пользователем pfexec Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kisa Опубликовано 23 марта, 2015 · Жалоба новые версии OpenFlow имею все функции, чтобы выполнять небходимые для nat преобразования в пакетахдело же не в опенфлоу, а в оборудовании. опенфлоу магии не явит же. если свич не рожден делать нат, то его там не будет. От версии OpenFlow много чего зависит. Например, в версии 1.0, выше которой пока нет поддержки в большинстве железок (могу ошибаться), не было принципиальной возможности создавать правила для манипуляции TTL пакета или пересчета его checksum. Поэтому от openflow нужна поддержка базовых инструментов для манипуляции с полями пакетов, необходимых для выполнения нат. Затем нужна железка, реализующая эту версию openflow. Про нат железке вообще ничего не надо знать, в этом суть SDN и openflow в частости. Вся логика NAT должна быть реализована в контроллере, управляющего свитчем. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pfexec Опубликовано 23 марта, 2015 · Жалоба Про нат железке вообще ничего не надо знать, в этом суть SDN и openflow в частости. Вся логика NAT должна быть реализована в контроллере, управляющего свитчем.lolwut?! :D Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kisa Опубликовано 23 марта, 2015 · Жалоба Про нат железке вообще ничего не надо знать, в этом суть SDN и openflow в частости. Вся логика NAT должна быть реализована в контроллере, управляющего свитчем.lolwut?! :D Ну вот посмотрите на RouteFlow, запустите их лабу, где реализован по этой архитектуре пример L3 сети на openflow коммутаторах, где в качестве IGP работает OSPF. Теперь загляните на один из OpenFlow коммутаторов, в его flowdatabase, где здесь хоть один след OSPF?!? только правила форвардинга потоков, которые есть результат работы OSPF, запущенного на софтовом контроллере, а не на свитче. Свитч ничего не знает про OSPF. И это работающее решение. Теперь о чем говорю я: о этой же архитектуре, только добавляем чуть больше чем раутинг. Добавляем NAT. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pfexec Опубликовано 23 марта, 2015 (изменено) · Жалоба Свитч ничего не знает про OSPF. И это работающее решение.ну это очень громко называть чьи-то теоретические ванильные фантазии рабочим решением. вы вообще в курсе для чего оспф ? равно как и гора других "ненужных" с вашей точки зрения протоколов.еще раз, опенфлоу никакой магии не сделает. даже если считать что эта "сигнализация" будет всем в сети говорить что и как форвардить, то ей как минимум нужен будет слой протоколов для устройств, чтобы понимать топологию сети, понимать что за чем стоит и так далее, ну вроде того же lldp. и чем выше по уровням osi мы будем подниматься, тем больше ей этих протоколов или их заменителей будет нужно. иначе оно так и останется нежизнеспособным комком теорий. Теперь о чем говорю я: о этой же архитектуре, только добавляем чуть больше чем раутинг. Добавляем NAT.для того чтобы форвардить трафик на L2 нужно одно оборудования, для рутинга - другое, а для фаерволов и натов - третьей. так оно родилось не только по прихоти маркетинга, а по вполне обоснованным технологическим и финансовым причинам. да, в теории ничего не мешает сделать "универсальный" молоток, который будет и форвардить, и в пакетах с заголовком делать что угодно, да и до кучи чего еще делать будет. но вы же понимаете, что универсальный молоток только в сказке универсальный, а на деле он будет либо дорогой, как звезда смерти дарта вейдара, либо бесплатным слоупоком, обложенным багами и прочим опенсурсом.ну и с надежностью там всё тоже очень печально. я не против сдн и опенфлоу, но я определенно не понимаю как такие "крайности" могут существовать в реалиях. как компромисс - может быть, т.е. этот контроллер занимается конфигурированием контрол-плейнов конечных устройств со всем их многообразием протоколов, учитывая их предназначение: свичи свичуют, рутеры - рутят, наты - натят и т.д. тогда, может быть оно вылупится из яйца теории в суровую практику. а пока это всё еще фантазии. ну вобщем, как вариант сделать унификацию всем этим бесчисленным велосипедам по автоматизации конфигурирования сети - это оно может быть. а свершить революцию и выбросить всю сетевую инфраструктуру - это не сегодня и не завтра, и, возможно, не послезавтра. Изменено 23 марта, 2015 пользователем pfexec Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dmvy Опубликовано 23 марта, 2015 · Жалоба Хороший OpenFlow коммутатор должен обладать больших TCAM, т.к. все flow, записанные в коммутатор должны где-то храниться. Эта цифра должна быть несколько миллионов. Пока я знаю только Extreme BlackDiamond X8 с очень толстыми платами и Ericsson SSR. На них реально построить OpenFlow-железку. Остальное полумеры... Либо придумывать такой трафик, чтобы количетсво Flow не превышало определенного предела. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kisa Опубликовано 23 марта, 2015 · Жалоба Свитч ничего не знает про OSPF. И это работающее решение.ну это очень громко называть чьи-то теоретические ванильные фантазии рабочим решением. вы вообще в курсе для чего оспф ? равно как и гора других "ненужных" с вашей точки зрения протоколов.еще раз, опенфлоу никакой магии не сделает. даже если считать что эта "сигнализация" будет всем в сети говорить что и как форвардить, то ей как минимум нужен будет слой протоколов для устройств, чтобы понимать топологию сети, понимать что за чем стоит и так далее, ну вроде того же lldp. и чем выше по уровням osi мы будем подниматься, тем больше ей этих протоколов или их заменителей будет нужно. иначе оно так и останется нежизнеспособным комком теорий. Теперь о чем говорю я: о этой же архитектуре, только добавляем чуть больше чем раутинг. Добавляем NAT.для того чтобы форвардить трафик на L2 нужно одно оборудования, для рутинга - другое, а для фаерволов и натов - третьей. так оно родилось не только по прихоти маркетинга, а по вполне обоснованным технологическим и финансовым причинам. да, в теории ничего не мешает сделать "универсальный" молоток, который будет и форвардить, и в пакетах с заголовком делать что угодно, да и до кучи чего еще делать будет. но вы же понимаете, что универсальный молоток только в сказке универсальный, а на деле он будет либо дорогой, как звезда смерти дарта вейдара, либо бесплатным слоупоком, обложенным багами и прочим опенсурсом.ну и с надежностью там всё тоже очень печально. я не против сдн и опенфлоу, но я определенно не понимаю как такие "крайности" могут существовать в реалиях. как компромисс - может быть, т.е. этот контроллер занимается конфигурированием контрол-плейнов конечных устройств со всем их многообразием протоколов, учитывая их предназначение: свичи свичуют, рутеры - рутят, наты - натят и т.д. тогда, может быть оно вылупится из яйца теории в суровую практику. а пока это всё еще фантазии. ну вобщем, как вариант сделать унификацию всем этим бесчисленным велосипедам по автоматизации конфигурирования сети - это оно может быть. а свершить революцию и выбросить всю сетевую инфраструктуру - это не сегодня и не завтра, и, возможно, не послезавтра. Так в реалиях еще ничего и нет. Это начало пути. Как раз реализацией подобия ldp и всех возможностей mpls сети в планах у сообщества sdn. Проектов много, за некоторыми есть вендоры, университеты. Кто знает что получится. Мне интересно наблюдать. Подход революционный. А ни по одному из вышеперечисленного я и не собирался спорить. Под рабочим решением я имел ввиду prof of concept. Не более. Хотя у них и есть продакшн, он далек от от боевых условий, но уже больше чем лаба. А интересует меня в рамках данной темы просто академические идеи, которые с какой-то ненулевой вероятностью могут выстрелить и уже имеют первые практические реализации. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pfexec Опубликовано 23 марта, 2015 · Жалоба Так в реалиях еще ничего и нет. Это начало пути.ну с такими замашками, этому пути еще N десятков лет идти...Как раз реализацией подобия ldp и всех возможностей mpls сети в планах у сообщества sdn. Проектов много, за некоторыми есть вендоры, университеты.Кто знает что получится. Мне интересно наблюдать. Подход революционный. lldp != ldp.у нас уже есть пример несостоявшейся революции - ipv6, на который всем пофиг и где нет жизни. и так будет следующие N лет, а может и надцать. зачем дважды наступать в одно и тоже ? ну вендоры то придумают компромиссов каких-нибудь, в этом то я не сомневаюсь. оно будет работать, а ваниль и радугу скормят поням. которые с какой-то ненулевой вероятностью могут выстрелить и уже имеют первые практические реализации.до практики там очень и очень далеко. как я выше говорил - либо вундервафлю ценой в death star, либо софтовый слоупок, бесполезный и беспощадный. всё что посередине будет иметь те или иные ограничения, которые только добавят проблем в сущестующую коробку ванили. :)Хороший OpenFlow коммутатор должен обладать больших TCAM, т.к. все flow, записанные в коммутатор должны где-то храниться.ну не обязательно, flow можно агрегировать по, скажем, dst-mac + dst-interface и этим забить таблицу форвардинга свища и готово. но это "компромиссы", которые не взрывают инфраструктуру и не делают из свища, скажем, фаервол. просто другой способ заполнения fdb. впрочем и проблем оно никаких не решает. вобщем НИОКР ради НИОКРа, кмк. ну пусть думают, может быть что-то придумают. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...