[wanderer_from]

Как будто я один? Судя по тому что я читаю, разработчики OF тоже щупают в темноте.

Для того, чтоб это утверждать - нужно быть немного в тусовке. На самом деле, поцоны делают ровно то, что делают :) я чуток "в тусовке", но Россия это такие задворки НТП, что иной раз стыдно :(

 

1. Лёд тронулся. Новый уровень программных систем пришёл в сети. Это — круто. Но это предполагает новые уровни ответственности и новые уровни технического ценза.

Я бы добавил еще "новые сервисы" и "новые бизнес-модели". Это действительно круто.

 

2. OF бесконечно долго будет существовать бок о бок с традиционными сетевыми решениями.

В технологии нет ничего бесконечного. Рано или поздно новое вытесняет старое. Хотя, "старое" (кавычки именно) иногда существует достаточно долго в определенных нишах. См. "телеграф" или "AOL". И да, хочу обратить особое внимание - OF != SDN. Это всего лишь протокол. Слон SDN - он сильно больше.

 

3. OpenFlow — попытка привнести Open Source идеологию в область сетевого оборудования.

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

 

4. SDN — это не новая техническая концепция. Это вариант реинжиниринга бизнес-процессов. Реинжиниринг приводит как к потрясающим успехам, так и к потрясающим же фейлам.

Фейлы они вообще на каждом углу подстерегают.

 

5. Это всё будет ой как нескоро.

Быстрее, чем ты думаешь :)

 

6. Вся надежда на китайцев коммодитизацию.

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

 

7. В настоящий момент SDN — 100% хайп.

Еще раз - чтоб это утверждать, нужно быть в тусовке. Или пытаться запилить новые бизнес-модели :)

 

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

Еще можно вписаться в тему и наблюдать изменения из первого ряда.

 

О вендорах: вот тут довольно неплохой ньюз-портальчик по теме. Если полистать, то можно обнаружить чуть не на каждой страничке всякие известные бренды: Cisco, HP, Brocade, Juniper, NEC. Там постоянная движуха идет - кто-то кого-то покупает. Постоянно появляются какие-то новые конторы, которые тут же оцениваются в сотни миллионов. Просто если наблюдать за движухой из нашего мухосранска - это действительно выглядит странно. Но там нет ничего странного - чуваки рубят бабло. Методы "навязать" давно устарели.

 

wanderer_from, кстати говоря более правильный термин не «коммодитизация» а white-box switch и brite-box switch (т.е. branded white-box). Он, правда, не имеет отношения к SDN... Хотя, ради этого всё и обычно затевается.

Ну, пусть так. "Коммодитазация утилитиз" - это старая шутка имени Слизеня :)

[Macil]

Еще можно вписаться в тему и наблюдать изменения из первого ряда.

А где продают билеты?

 

О вендорах

Лучше вот так: https://cumulusnetworks.com/support/linux-hardware-compatibility-list/ так: http://www.pica8.com/products/hardware-compatibility-list или так: http://ipfabrics.net/pages/cumulus-open-matrix

 

Ещё есть крайне интересная штука: Edgecore AS4610. Формально, это свитч уровня ДЦ, но на практике — вполне-себе обычный свитч уровня предприятия. А такими темпами и до телекома недалеко. Действительно: быстрее чем я думаю.

 

У Циски уже случился баттхёрт и бокс по переписке с HP (пока читал, съел весь поп-корн). Это вообще тема, заслуживающая отдельного обсуждения.

 

Я совершил стратегическую ошибку: копать нужно было со стороны ДЦ и top-of-the-rack. Вся движуха именно там. Другая часть движухи — в области 100G (Corsa и сотоварищи), там какая-то фундаментальная проблема производства универсальных решений, которую решает именно SDN. Но тут для меня тёмный лес.

[s.lobanov]

я чуток "в тусовке"

 

это про пакистанцев с микротиком, накатывающих openwrt вместо routeros, а потом раздувающих из этого "научные публикации"?

[rdntw]

ТС вам бы с ЦПКИС пообщаться.

они и толковые семинары в МГУ проводят, приглашают вендоров ( Brocade, zelax) и сами уже успели свой контроллер написать

 

http://arccn.ru/media/1721

[wanderer_from]

это про пакистанцев с микротиком, накатывающих openwrt вместо routeros, а потом раздувающих из этого "научные публикации"?

 

ты так говоришь, как-будто это что-то плохое

[stas_k]

stas_k, по линкам 1,2 миллиона устройств уязвимы. Примерно. Я бы не сказал, что это много.

1,2 миллиона - это непонятная оценка. Скорее всего это количество проданных устройств [конкретных моделей] заведомо подверженных уязвимости, проданных [в одном регионе] за некоторый период. Сколько устройств, подверженных уязвимости, было продано до, в другом регионе, или устройства про которые [пока] нет данных - не известно.

Видя как пишутся индусским методом копипастом собираются прошивки, считая в том числе и adsl и старые модели, думаю, можно смело умножать на сто. Это будет оптимистично заниженная оценка.

 

Но ведь мало простой пройти сквозь NAT. нужно чтобы внутренние ресурсы представляли осмысленную ценность, так что в принципе уязвимость не страшна. Просто дает еще одну возможность для действий злоумышленника.

[visir]

А теперь резонный вопрос: «А нафига всё это?». Даже не нафига это в операторских сетях, а нафига это *вообще*? Нет, мне как прирождённому параноику вопросы построения флоу очень даже близки... Но тут бодливой корове Бог рогов не дал... Крупным сетям может быть приглянется тегирование Q-in-Q, PBB или MPLS... Но свичи и так умеют это делать и без OpenFlow, и точно так же в соответствии с разумением отдельного вендора. QoS, «красивая» «раскраска» трафика? Опять всё вендорспецифично. Что-то замутить на клиентском уровне? Дык, где оно ж на клиентском-то...

 

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

 

После общения с несколькими фанатами OpenFlow выяснил следующее: они реально думают, что внутри все коммутаторы/маршрутизаторы работают по такому же принципу, как OpenFlow-коммутаторы, с той лишь разницей, что в качестве контроллера выступает слабенький управляющий CPU самого устройства, и его слабость является проблемой, а вместо OpenFlow используется проприетарный протокол. (К слову, первые L3 коммутаторы Cisco действительно работали так, в паре с маршрутизатором, это называли MLS. Но потом значение этого слова изменилось.)

[visir]

Ещё интересная ссылка https://www.opennetworking.org/images/stories/downloads/sdn-resources/solution-briefs/sb-network-monetization.pdf Монетизация. Негусто, но вот зацепила цитата

A better approach is to deploy only a simpler OpenFlow-enabled NID at the customer site, obviating the need to install and manage a separate router. Similarly, in the central office the expensive aggregation router can be replaced by a more cost-effective Layer 2+ OpenFlow-enabled switch

 

Т.е. в определённых условиях OpenFlow сможет снизить затраты на агрегацию?

 

Вендоры сейчас действительно пытаются продвигать vCPE, но без OpenFlow. Типа у пользователя тупое L2-устройство, канал от которого по L2 прокидывается до большой провайдерской сервисной коробки. На которой запущено множество экземпляров этих vCPE, работающих в качестве Router/Firewall/IDS/IPS/... .

[xcme]

Типа у пользователя тупое L2-устройство, канал от которого по L2 прокидывается до большой провайдерской сервисной коробки. На которой запущено множество экземпляров этих vCPE, работающих в качестве Router/Firewall/IDS/IPS/... .

 

В таком подходе упущен один интересный момент, а именно сама доставка трафика. Файрволл со стразами - это, конечно, круто, но чтобы доставить то же TV, нужны еще две интересные штуки на всем пути от источника до получателя. Первая - это QoS, вторая - IGMP Snooping. Тупое L2 устройство этого не умеет, соответственно "внизу" у абонента имеем кашу из трафика. В идеальной абстрактной сети спасает подход "один порт доступа = одно абонентское устройство", но на практике такого не будет. В итоге CPE должно быть так или иначе с мозгами, а при этом теряется прелесть "большой и умной провайдерской коробки".

[visir]

В таком подходе упущен один интересный момент, а именно сама доставка трафика. Файрволл со стразами - это, конечно, круто, но чтобы доставить то же TV, нужны еще две интересные штуки на всем пути от источника до получателя. Первая - это QoS, вторая - IGMP Snooping. Тупое L2 устройство этого не умеет, соответственно "внизу" у абонента имеем кашу из трафика. В идеальной абстрактной сети спасает подход "один порт доступа = одно абонентское устройство", но на практике такого не будет. В итоге CPE должно быть так или иначе с мозгами, а при этом теряется прелесть "большой и умной провайдерской коробки".

 

Ну, устройство может быть и не на столько тупым. Им может быть, например, обычный L2-коммутатор, умеющий и IGMP-snooping, и VLAN-ы.

Упущен гораздо более важный момент: подключение к двум операторам с целью резервирования (речь про корпоратов).

[Macil]

Вендоры сейчас действительно пытаются продвигать vCPE, но без OpenFlow.

Да, может быть. Но меня больше заинтересовала фраза "Similarly, in the central office the expensive aggregation router can be replaced by a more cost-effective Layer 2+ OpenFlow-enabled switch".

 

Хотя, теперь более-менее понятно что тут имеется ввиду. Во-первых, всё-таки имеется ввиду white-box (bare-metal, ... реквестую термин «цискины слёзки») свитчи. Во-вторых, OpenFlow — крайне любопытная штука... Её можно рассматривать как протокол, как модель работы устройства, а можно рассматривать как модель данных. Грубо говоря, для того чтобы добавить, допустим, запись в таблицу OpenFlow не обязательно посылать сообщение по OpenFlow. И действительно, в любом сферическом устройстве в вакууме «физическая» модель OpenFlow будет состоять из адской смеси состояний юзерспейса, ядра, и специализированного железа (буде таковое случится). Т.е. API на устройстве будет совершенно естественной штукой. Например, на свитче может стоять iBGP демон и спокойно рулить им напрямую, а *сам* свитч остается тупорылой L2+ железкой, но в то же время любой сторонний контроллер будет видеть все изменения. В-третьих, контроллер может работать и в реактивном режиме. Не учить свитч жизни, принимая решения на каждый чих (типа нового MAC на порту), а анализировать работу устройства (устройств) в целом.

 

Главная проблема, всё вышеперечисленное никак не стандартизовано. И, скорее всего, не будет. Опен-сорс и красноглазие таки добралось и до ethernet коммутаторов.

[karpa13a]

Упущен гораздо более важный момент: подключение к двум операторам с целью резервирования (речь про корпоратов).

 

 

а какая в прочем разница?)

[Macil]

 

нужны еще две интересные штуки на всем пути от источника до получателя. Первая - это QoS, вторая - IGMP Snooping. Тупое L2 устройство этого не умеет

Устройство этого не умеет, но у устройства есть внешние мозги в виде линукса (как ядра) и соответствющего софта. И тут вариантов масса, вплоть до тупой подачи попадающего под критерии пакета в сетевой стек линукса и отправка его на контроллер для последующего анализа.

[visir]

Устройство этого не умеет, но у устройства есть внешние мозги в виде линукса (как ядра) и соответствющего софта. И тут вариантов масса, вплоть до тупой подачи попадающего под критерии пакета в сетевой стек линукса и отправка его на контроллер для последующего анализа.

На самом деле у OpenFlow-коммутаторов control-plane на слабом CPU никуда не делся - именно на нем работает OpenFlow-клиент.

В связи с чем изначально надуманная проблема обычных коммутаторов:

После общения с несколькими фанатами OpenFlow выяснил следующее: они реально думают, что внутри все коммутаторы/маршрутизаторы работают по такому же принципу, как OpenFlow-коммутаторы, с той лишь разницей, что в качестве контроллера выступает слабенький управляющий CPU самого устройства, и его слабость является проблемой, а вместо OpenFlow используется проприетарный протокол. (К слову, первые L3 коммутаторы Cisco действительно работали так, в паре с маршрутизатором, это называли MLS. Но потом значение этого слова изменилось.)

в случае с OpenFlow как раз и становится реальной, а не надуманной, проблемой :-).

 

 

Еще про vCPE. В случае с физиками, вендоры предлагают влезть в домашнюю локалку пользователей операторским DLNA-сервером/NAS-ом/итп - то есть продавать их как сервис. Звучит красиво...

[Macil]

На самом деле у OpenFlow-коммутаторов control-plane на слабом CPU никуда не делся

Например, возьмём Edge-core AS4610, весьма и весьма жухлый по меркам OpenFlow коммутаторов. У него на борту двухядерный A9 Cortex 1GHz и 2 гига оперативки с ECC, 8 гигов флеша. Это даже близко не укладывается в определение «слабенький».

 

В более серьёзных решениях ставят интеловские процессоры. Можно ставить процессоры с HSA (как AMD, так и ARM когда появятся), и наслаждаться запредельной числодробильной мощностью , но пока это больше теория.

 

Короче говоря в wite-box по-определению будет мощный процессор.

[visir]

Например, возьмём Edge-core AS4610, весьма и весьма жухлый по меркам OpenFlow коммутаторов. У него на борту двухядерный A9 Cortex 1GHz и 2 гига оперативки с ECC, 8 гигов флеша. Это даже близко не укладывается в определение «слабенький».

 

В более серьёзных решениях ставят интеловские процессоры. Можно ставить процессоры с HSA (как AMD, так и ARM когда появятся), и наслаждаться запредельной числодробильной мощностью , но пока это больше теория.

 

Короче говоря в wite-box по-определению будет мощный процессор.

Но ведь тогда они будут дороже обычных коммутаторов...

[Macil]

Но ведь тогда они будут дороже обычных коммутаторов...

Почему? Я думаю у тебя в смартфоне процессор помощнее будет. Самое дорогое в свичах — коммутационная фабрика. Но это не «внедорская» разработка, а продукт компании бизнес-модель которой работает со значительно меньшей маржой.

[visir]

Почему? Я думаю у тебя в смартфоне процессор помощнее будет.

ИМХО если ставить Intel-овские процы, то их вклад в цену точно будет очень существенен. С ARM я может отстал от жизни, и мощные стоят ненамного дороже слабых - не знаю...

[Macil]

ИМХО если ставить Intel-овские процы, то их вклад в цену точно будет очень существенен.

Нет. Во-первых, у Интела большая проблема: рынок PC сливается в трубу отсюда эксперименты с линейками и форм-факторами. Во-вторых, интел является большим сторонником white-box свитчей. В-третьих, интел сама выпускает серьезные коммутационные фабрики (FM5000/FM6000).

[Sergey Gilfanov]

Еще про vCPE. В случае с физиками, вендоры предлагают влезть в домашнюю локалку пользователей операторским DLNA-сервером/NAS-ом/итп - то есть продавать их как сервис. Звучит красиво...

Какой-такой сервис? Те, кто понимают, в чем сервис заключается - с большой вероятностью пошлют и поставят свою железку у себя же. А тем, кто не понимает - продать не получится, ибо они не понимают, что им продать пытаются. Ситуация с 'сервисом' тут еще хуже, чем с IPv6.

[Ivan_83]

чтобы доставить то же TV, нужны еще две интересные штуки на всем пути от источника до получателя. Первая - это QoS, вторая - IGMP Snooping.

Отдавать юникастом и нет проблем.

Но даже в случае мультикаста QoS не очень чтобы обязателен, а IGMP Snooping есть в некоторых тупарях.

Подозреваю что так же на некоторых тупарях можно и QoS включить.

 

 

Еще про vCPE. В случае с физиками, вендоры предлагают влезть в домашнюю локалку пользователей операторским DLNA-сервером/NAS-ом/итп - то есть продавать их как сервис. Звучит красиво...

Я предлагаю запихивать DLNA в отдельные устройства абонента прямо через его любой роутер.

Но желающих что то нет.

А вообще, чтобы абоненту DLNA в хату предоставить достаточно чтобы маленькая программа - SSDP анонсер работала на любом устройстве в локалке абонента, хоть на компе, хоть на телефоне, хоть на роутере, хоть это отдельная коробочка будет.

В этой схеме про мультикаст ТВ можно забыть, ибо длна предполагает только хттп.

[xcme]

Но даже в случае мультикаста QoS не очень чтобы обязателен, а IGMP Snooping есть в некоторых тупарях.

Если абонент между своими устройствами перекачивает что-то, то ТВ не получит приоритета и развалится. Если же он качает только извне, тогда согласен - в этом случае справится коммутатор доступа.

А снупинг в тупарях есть, только стоят они раза в 3 дороже остальных тупарей. :(

[Ivan_83]

Если абонент между своими устройствами перекачивает что-то, то ТВ не получит приоритета и развалится. Если же он качает только извне, тогда согласен - в этом случае справится коммутатор доступа.

Это зависит от разных факторов, в целом не всегда.

 

А снупинг в тупарях есть, только стоят они раза в 3 дороже остальных тупарей. :(

Пару лет назад тут писали про какой то тплинк что ли на 5 портов где снупинг был, ценник на него был как на все остальные мыльницы с пятью портами.

[Macil]

Пару лет назад тут писали про какой то тплинк что ли на 5 портов где снупинг был, ценник на него был как на все остальные мыльницы с пятью портами.

Вообще-то в хомячковых мыльницах стоят весьма неплохие свитчи. В конце-концов, те же Микротики на них и работают. Другое дело, что без доступа ДШ (или ковыряния в исходиках линукса) сложно сложно сказать как именно всё происходит.

 

Просто первая попавшаяся ссылка: http://www.marvell.com/switching/assets/marvell_linkstreet_88E6350r_product_brief.pdf

[xcme]

Пару лет назад тут писали про какой то тплинк что ли на 5 портов где снупинг был, ценник на него был как на все остальные мыльницы с пятью портами.

Речь про эту модель? :) Он и тогда был дороже, а потом подорожал еще чуток, а потом рубль рухнул. :(

 

Вообще-то в хомячковых мыльницах стоят весьма неплохие свитчи.

Наоборот, практически везде отстой. Мало кто умеет, например, поднимать одновременно 10 и 100 мбит линки - по факту скорость режется до 10 мбит/сек, несмотря на 100 мбитное подключение. Несколько лет назад делал тест, у 100% сохо-роутеров так и у почти всех обычных тупарей. Только один коммутатор тогда попался без этой проблемы и тоже тплинк, кстати.

 

Что у новых "кинетиков" и т.п. - не знаю, может уже хорошая база.

 

p.s. Недавно бегло тестировал SRN-CPE, воткнув в него 4 приставки с HD-каналами. На каждой приставке был запущен модуль, регистрировавший пропуски CC. В общем 4 STB он не тащит, судя по графикам. Если 2, то нормально. А если порты в бридж переключить, тоже все хорошо, но тогда снупинг не работает и QoS тоже, скорее всего. Мне тут разработчик ответил, что "это не тот функционал, который вы ищете" ©. :)

 

p.p.s. Это я все к тому, что настоящий головняк в ISP начинается за "последней милей", когда какое то абонентское барахло не справляется с нагрузкой, а виноват провайдер. И как решать это все пока не очень понятно. Потому всякие там рюшечки и свистелки vCPE вряд ли будут нас интересовать до того момента, пока не появится по настоящему надежная "железная база", куда можно будет не боясь вливать абоненту 50 мегабит мультикаста и столько же торрента.