Картуччо Опубликовано 23 января, 2013 · Жалоба В последнее время все больше и больше производителей телекоммуникационного оборудования, а особенно компаний разработчиков программного обеспечения устремили свои взоры в сторону так называемой концепции SDN (Software Defined Network http://en.wikipedia.org/wiki/Software-defined_networking ). Т.е. Когда интеллектуальный уровень сети выносится в отдельное облако, а все железки установленные на сети по сути являются инструментами для увеличения портовой емкости и осуществления локальной коммутации.Cisco уже делает шаги в данном направлении - появилась среда разработки собственных приложений OnePK. Сейчас доступна версия только для моделей Cisco Catalyst, Cisco ISR и Cisco ASR1000. Постепенно планируется расширять и для других устройств. В апреле будет доступно для ASR9K. По стоимости, - похоже, что бесплатно. Маркетинговый булшит или что-то реальное, как думаете ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Прохожий Опубликовано 23 января, 2013 · Жалоба Идея проста как педаль: централизовать control plane, т.е. по сути все функции управления коммутацией, маршрутизацией и т.д. вынести в единую точку (ну или ограниченно-распределенную для устойчивости, что и называется "отдельным облаком)), оставив в железках только непосредственно передвигание пакетов по готовым таблицам коммутации/маршрутизации/фильтрации. То есть если сейчас сообщения протоколов маршрутизации порождаются и обрабатываются управляющими процессорами маршрутизаторов, то по этой концепции они просто отсутствуют: "центр" знает и отслеживает всю топологию, изменения которой железяки репортят ему, периодически рассылая железякам рабочие таблицы, по которым те и фигачат пакеты. Идея вполне рабочая при соблюдении длинного списка граничных условий. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Sergey Gilfanov Опубликовано 23 января, 2013 (изменено) · Жалоба Идея вполне рабочая при соблюдении длинного списка граничных условий. Первое из них - все железки должны бить одного производителя. Или вы думаете, что они что-то стандартное и совместимое придумают? Изменено 23 января, 2013 пользователем Sergey Gilfanov Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DelSt Опубликовано 23 января, 2013 · Жалоба Стоит погуглить OpenFlow еще, в том числе на ENOG4 был доклад на эту тему. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Картуччо Опубликовано 23 января, 2013 · Жалоба Связь с "облаком" должна быть хорошая иначе видится большой геморой. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Mikler Опубликовано 23 января, 2013 · Жалоба А где здесь конкурентные преимущества и выгода для провайдера? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 23 января, 2013 · Жалоба А где здесь конкурентные преимущества и выгода для провайдера? Преимущества очевидны, не надо траблшутить high cpu usage(хотя тут есть нюансы относительно того вся ли сигназация направляется в центр) на каком-нибудь дохлом свитче, вместо этого один(два) большой(их) control plane, который не так просто убить трафиком, направленным к CPU, не надо держать в голове сразу несколько CLI(даже у одного вендора CLI может сильно отличаться) Выгоды для провайдера скорее всего никакой, как с IPv6 - преимущества есть, но нет выгоды. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Картуччо Опубликовано 23 января, 2013 · Жалоба Может быть как выгода - сокращение персонала. Если конечно управление многочисленными устройствами станет проще и часть типовых функций на себя возьмёт автоматика. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 23 января, 2013 · Жалоба Может быть как выгода - сокращение персонала. Если конечно управление многочисленными устройствами станет проще и часть типовых функций на себя возьмёт автоматика. Для сокращения персонала есть NMS - решает ту же самую задачу(централизация и автоматизация управления оборудованием) (если решение от одного вендора, полноценных мультивендорных NMS я не видел, но прогресс в этом направлении есть). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zi_rus Опубликовано 23 января, 2013 · Жалоба Связь с "облаком" должна быть хорошая иначе видится большой геморой. а еще при конфигурировании потоков в этой сети не приводили к отвалу от центра, а следовательно фактически нужна вторая сеть под управление. для ДЦ уже сейчас есть рекомендации (по крайней мере от Cisco) что для управления надо использовать oob (out of bandwidth) порты, да и различные уже реализованые продукты вроде VSS (virtual switching system) или FEX (fabric extention) гворят что SDN здесь самое логичное продолжение. для провайдера я такого не вижу, мне кажется слишком сложно и дорого будет строить двойную сеть, или же решение окажется ненадежным Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Прохожий Опубликовано 24 января, 2013 · Жалоба а еще при конфигурировании потоков в этой сети не приводили к отвалу от центра, а следовательно фактически нужна вторая сеть под управление. Либо нужна серьезная топологическая избыточность. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alks Опубликовано 24 января, 2013 · Жалоба а еще при конфигурировании потоков в этой сети не приводили к отвалу от центра, а следовательно фактически нужна вторая сеть под управление. Либо нужна серьезная топологическая избыточность. Угу, а это зачастую подороже выйдет чем иметь на сети девайсы со своими мозгами Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
