[Умник]

по ссылке просто чьи-то ванильные фантазии

Если бы вы видели количество патчей в списке рассылки netdev на тему поддержки "rocker switch" и патчи на тему H/W offload иже с ним (все это началось буквально пол-года назад), вы бы так не говорили.

[pfexec]

Если бы вы видели количество патчей в списке рассылки netdev на тему поддержки "rocker switch" и патчи на тему H/W offload иже с ним (все это началось буквально пол-года назад), вы бы так не говорили.

я не понимаю, оно же просто "еще один бридж для линагза". как это связано с закрытостью asic'ов от тех 2.5 контор, которые эти асики делают ? планируете построить свитч вокруг ксеона с N-надцатью портами ? да флаг вам в руки. :)

[Умник]

построить свитч вокруг ксеона с 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 пользователем Умник

[DVM-Avgoor]

Если вы теперь чисто о софтовом решении, то уже построили. И даже не свитч, а роутер.

 

Ну и? Отличный кстати пример. Вот есть dpdk с описанным API (интел всё же молодцы в этом плане), с полным howto по применению. И где опенсорс? Плевал опенсорс на это, они там точат свою розовую ваниль, им не до роутеров. А проприетарщики пилят, делают продукт, продают и поддерживают. Дык в чем же польза от dpdk в опенсорсе?

[pavel.odintsov]

Если вы теперь чисто о софтовом решении, то уже построили. И даже не свитч, а роутер.

 

Ну и? Отличный кстати пример. Вот есть dpdk с описанным API (интел всё же молодцы в этом плане), с полным howto по применению. И где опенсорс? Плевал опенсорс на это, они там точат свою розовую ваниль, им не до роутеров. А проприетарщики пилят, делают продукт, продают и поддерживают. Дык в чем же польза от dpdk в опенсорсе?

 

Вы так говорите, как будто "опенсорц" - это нечто абстрактное :) А это на самом деле вполне осязаемые и понятные люди, который живут не так далеко от Вас :) Ставьте задачу, пишите ТЗ, собирайте людей, а там народ подтянется, если будет интерес.

[Умник]

Кстати, DPDK в качестве datapath уже давно интегрирован в Open vSwitch. Нужно только контроллер написать. :) Правда не уверен, что там все хорошо с производительностью на всех случаях. Вообще, мне так думается, что opensource роутер/свитч с производительностью как у 6wind просто дело времени. Не знаю, поживем - увидим.

[DVM-Avgoor]

Кстати, DPDK в качестве datapath уже давно интегрирован в Open vSwitch. Нужно только контроллер написать. :) Правда не уверен, что там все хорошо с производительностью на всех случаях. Вообще, мне так думается, что opensource роутер/свитч с производительностью как у 6wind просто дело времени. Не знаю, поживем - увидим.

 

Работаю очень плотно с OVS, говно редкостное.

 

Вы так говорите, как будто "опенсорц" - это нечто абстрактное :) А это на самом деле вполне осязаемые и понятные люди, который живут не так далеко от Вас :) Ставьте задачу, пишите ТЗ, собирайте людей, а там народ подтянется, если будет интерес.

 

Продукт - дело больших усилий. Усилия == время, время бесплатно не бывает, есть надо на что-то.

[Умник]

говно редкостное

Что именно плохо? Интересно.

[DVM-Avgoor]

Что именно плохо? Интересно.

 

Там много особенностей, в т.ч. и пресловутое быстродействие, как бы смешно не звучало. Не уверен что имею право рассказывать все, поэтому уж увольте :)

[pavel.odintsov]

OVS еще и проц жрет люто :) Имеем-с в собственной ферме его на паре машин под роутинг openvz. Решительно лучше бриджей, но решительно хуже чего-то нормального :) Но за не имением аналогов - увы.

Изменено 2 марта, 2015 пользователем pavel.odintsov

[alks]

Хочу дешевый быстрый NAT задешево, FPGA как понимаю здесь не катит?

[DVM-Avgoor]

Хочу дешевый быстрый NAT задешево, FPGA как понимаю здесь не катит?

 

В вопросе уже есть ответ.

[pavel.odintsov]

А вот и подоспел полностью открытый Linux: https://github.com/opennetworklinux/ONL с поддержкой тех же Broadcom комутационок. Итого, за $4000 можно собрать приличный top of rack почти полностью на открытом софте.

[pavel.odintsov]

Ну и чтобы добить совсем - Broadcom открыл спецификации и открыл SDK для своих последних поколений свичей: http://www.zdnet.com/article/broadcom-opens-up-switch-api-to-third-party-developers/

[ollsanek]

по теме, проблема в том, что поддерживаются только те протоколы которые и так уже есть в линукс, просто они "проваливаются" в асик свича.

т.е. у кумулуса нет МСТП (фигассе свич, да?), не говоря уже о всяких ерпс, пбб, макинмак, трилл и т.п.

 

OVS еще и проц жрет люто :) Имеем-с в собственной ферме его на паре машин под роутинг openvz. Решительно лучше бриджей, но решительно хуже чего-то нормального :) Но за не имением аналогов - увы.

так openvz же только на старых ядрах, а OVS с поддержкой DPDK только на новых.

именно из-за этого начинаем косится в сторону докера но ...

пока если что-то критичное по трафику, то суём в КВМ и отправляем на тазик с новым ядром.

[nuclearcat]

Еще на кумулусе нет PBR/FBF

[kisa]

А я бы ставил на 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 свитча. Теоретически сотни гигабит.

[pfexec]

Еще на кумулусе нет PBR/FBF

ему оно и не надо. это жи свичи для датацентров: всё что им надо это толстые порты и буферы потолще. но толстые порты есть у всех, а буферы у всех одинаковые. так что чуда нет, разве что дешевле, т.к. нету кучи фич и имплементить их некому.

control plane - на тазике с линуксом и quagga (можно bird, можно любой софт маршрутизации, главное, чтобы на линуксе), a dataplane на железном OpenFlow свитче.

ну примерно тоже самое делают циски, жунепиры и ко, со своими "виртуальными" asr и mx. разница в том что у них оно будет стоить денег и будет уметь фичи, а опенсурс квагга как ничо не умела, так и не будет уметь, + баги, за которые мы все так любим кваггу. :D

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

дело же не в опенфлоу, а в оборудовании. опенфлоу магии не явит же. если свич не рожден делать нат, то его там не будет.

Изменено 23 марта, 2015 пользователем pfexec

[kisa]

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

дело же не в опенфлоу, а в оборудовании. опенфлоу магии не явит же. если свич не рожден делать нат, то его там не будет.

 

От версии OpenFlow много чего зависит. Например, в версии 1.0, выше которой пока нет поддержки в большинстве железок (могу ошибаться), не было принципиальной

возможности создавать правила для манипуляции TTL пакета или пересчета его checksum. Поэтому от openflow нужна поддержка базовых инструментов для манипуляции с полями пакетов, необходимых для выполнения нат. Затем нужна железка, реализующая эту версию openflow. Про нат железке вообще ничего не надо знать, в этом суть SDN и openflow в частости. Вся логика NAT должна быть реализована в контроллере, управляющего свитчем.

[pfexec]

Про нат железке вообще ничего не надо знать, в этом суть SDN и openflow в частости. Вся логика NAT должна быть реализована в контроллере, управляющего свитчем.

lolwut?! :D

[kisa]

Про нат железке вообще ничего не надо знать, в этом суть SDN и openflow в частости. Вся логика NAT должна быть реализована в контроллере, управляющего свитчем.

lolwut?! :D

 

Ну вот посмотрите на RouteFlow, запустите их лабу, где реализован по этой архитектуре пример L3 сети на openflow коммутаторах, где в качестве IGP работает OSPF.

Теперь загляните на один из OpenFlow коммутаторов, в его flowdatabase, где здесь хоть один след OSPF?!? только правила форвардинга потоков, которые есть результат

работы OSPF, запущенного на софтовом контроллере, а не на свитче. Свитч ничего не знает про OSPF. И это работающее решение.

 

Теперь о чем говорю я: о этой же архитектуре, только добавляем чуть больше чем раутинг. Добавляем NAT.

[pfexec]

Свитч ничего не знает про OSPF. И это работающее решение.

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

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

Теперь о чем говорю я: о этой же архитектуре, только добавляем чуть больше чем раутинг. Добавляем NAT.

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

ну и с надежностью там всё тоже очень печально.

 

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

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

Изменено 23 марта, 2015 пользователем pfexec

[dmvy]

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

[kisa]

Свитч ничего не знает про OSPF. И это работающее решение.

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

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

Теперь о чем говорю я: о этой же архитектуре, только добавляем чуть больше чем раутинг. Добавляем NAT.

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

ну и с надежностью там всё тоже очень печально.

 

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

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

 

Так в реалиях еще ничего и нет. Это начало пути.

 

Как раз реализацией подобия ldp и всех возможностей mpls сети в планах у сообщества sdn. Проектов много, за некоторыми есть вендоры, университеты.

Кто знает что получится. Мне интересно наблюдать. Подход революционный.

 

А ни по одному из вышеперечисленного я и не собирался спорить. Под рабочим решением я имел ввиду prof of concept. Не более.

Хотя у них и есть продакшн, он далек от от боевых условий, но уже больше чем лаба.

 

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

[pfexec]

Так в реалиях еще ничего и нет. Это начало пути.

ну с такими замашками, этому пути еще N десятков лет идти...

Как раз реализацией подобия ldp и всех возможностей mpls сети в планах у сообщества sdn. Проектов много, за некоторыми есть вендоры, университеты.

Кто знает что получится. Мне интересно наблюдать. Подход революционный.

lldp != ldp.

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

 

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

которые с какой-то ненулевой вероятностью могут выстрелить и уже имеют первые практические реализации.

до практики там очень и очень далеко. как я выше говорил - либо вундервафлю ценой в death star, либо софтовый слоупок, бесполезный и беспощадный. всё что посередине будет иметь те или иные ограничения, которые только добавят проблем в сущестующую коробку ванили. :)

Хороший OpenFlow коммутатор должен обладать больших TCAM, т.к. все flow, записанные в коммутатор должны где-то храниться.

ну не обязательно, flow можно агрегировать по, скажем, dst-mac + dst-interface и этим забить таблицу форвардинга свища и готово. но это "компромиссы", которые не взрывают инфраструктуру и не делают из свища, скажем, фаервол. просто другой способ заполнения fdb. впрочем и проблем оно никаких не решает. вобщем НИОКР ради НИОКРа, кмк. ну пусть думают, может быть что-то придумают.