Комментарии 35
Централизованное управление роутингом по MAC?
Как 1+1 redundancy для контроллера сделать?
Как 1+1 redundancy для контроллера сделать?
Ну прям вообще никаких недостатков у SDN нет :)
Расскажите:
1) Каким образом осуществляется доставка управляющего трафика от контроллера до коммутатора и обратно.
2) Каким образом осуществляется резервирование контроллеров.
3) Какие протоколы поддерживаются на стыке между SDN и традиционной сетями. Прямо сейчас.
4) Что произойдет, если пустить SYN флуд через SDN сеть на какую-нибудь сеть класса А с гигабитной скоростью.
5) Вообще — какую нагрузку держит ваша лаба? В первую очередь интересует значение CPS.
Ну и вы ведь понимаете, что концепция SDN чертовски похожа на концепцию модульных коммутаторов, и ничего особенно нового в ней нет, кроме сильного отдаления control plane от data plane (с соответствующими колоссальными рисками потерять между ними связь)?
Расскажите:
1) Каким образом осуществляется доставка управляющего трафика от контроллера до коммутатора и обратно.
2) Каким образом осуществляется резервирование контроллеров.
3) Какие протоколы поддерживаются на стыке между SDN и традиционной сетями. Прямо сейчас.
4) Что произойдет, если пустить SYN флуд через SDN сеть на какую-нибудь сеть класса А с гигабитной скоростью.
5) Вообще — какую нагрузку держит ваша лаба? В первую очередь интересует значение CPS.
Ну и вы ведь понимаете, что концепция SDN чертовски похожа на концепцию модульных коммутаторов, и ничего особенно нового в ней нет, кроме сильного отдаления control plane от data plane (с соответствующими колоссальными рисками потерять между ними связь)?
Вот здесь ответы на вопросы по существу о том, как работает Openflow — www.openflow.org/documents/openflow-spec-v1.1.0.pdf
Резервирование в тех релизах софта, которые мы тестировали, не поддерживается.
Нагрузку специально не тестировали, SYN флуд тоже не устраивали, можете попробовать — поделитесь результатами.
Резервирование в тех релизах софта, которые мы тестировали, не поддерживается.
Нагрузку специально не тестировали, SYN флуд тоже не устраивали, можете попробовать — поделитесь результатами.
Вы мне еще RFC дайте…
Вот есть топик, рекламирующий некоторую технологию. Причем технология преподносится как венец творения, превосходящая всё, что было ранее. Я задаю несколько простейших вопросов, без ответа на которые нечего и думать о реальной имплементации технологии в боевую инфраструктуру (причем вопросы по дизайну, а не по самому протоколу, а про дизайн). Вы меня тыкаете носом в доки, в которых про это ничего не говорится. Нда…
Ведь не зря современные L3 коммутаторы, расчитанные под приличные объемы данных (сотни гигабит, терабиты, десятки терабит), не отслеживают отдельные сессии и вообще не лезут выше L4. Это дорого и не нужно.
А главное преимущество традиционной схемы — автономность. Каждое устройство само по себе и ни от кого не зависит. Оно само принимает решения. Оно не превратится в тыкву, как только пропала связь с контроллером. Меньше шанс уронить всю сеть из-за сбоя одного устройства.
Так что будьте хоть немного объективны. А объективность говорит, что сейчас у SDN в чистом виде как-то и нет применений, кроме как в исследовательском смысле и из чистого любопытства.
Вот есть топик, рекламирующий некоторую технологию. Причем технология преподносится как венец творения, превосходящая всё, что было ранее. Я задаю несколько простейших вопросов, без ответа на которые нечего и думать о реальной имплементации технологии в боевую инфраструктуру (причем вопросы по дизайну, а не по самому протоколу, а про дизайн). Вы меня тыкаете носом в доки, в которых про это ничего не говорится. Нда…
Ведь не зря современные L3 коммутаторы, расчитанные под приличные объемы данных (сотни гигабит, терабиты, десятки терабит), не отслеживают отдельные сессии и вообще не лезут выше L4. Это дорого и не нужно.
А главное преимущество традиционной схемы — автономность. Каждое устройство само по себе и ни от кого не зависит. Оно само принимает решения. Оно не превратится в тыкву, как только пропала связь с контроллером. Меньше шанс уронить всю сеть из-за сбоя одного устройства.
Так что будьте хоть немного объективны. А объективность говорит, что сейчас у SDN в чистом виде как-то и нет применений, кроме как в исследовательском смысле и из чистого любопытства.
Ну, вы тоже слишком категоричны. Существующим протоколам и схемам не один десяток лет, а SDN всего-то пяток. Наработают ещё.
1) Доставка управляющего трафика — слабое место (поскольку чудес не бывает), но в версии 1.3.1 (может, и более ранних — не смотрел) предусмотрен fallback, когда устройство в отсутствие контроллера пускает всё традиционным путём. Так что хуже не будет.
2) Что вы имеете в виду под резервированием контроллеров? Если резервирование именно управляющей логики, когда одно падает — другое встаёт на том же месте, то для этого уже наработаны технологии — всякие бизнес-приложения же резервируются. Если имеется в виду резервирование в смысле «у устройства всегда должна быть голова (пусть и пустая :-)», то несколько контроллеров — чем не резервирование?
3) Никакие :-) Тут вообще ситуация не такая простая — непонятно, как сращивать автономные системы с централизованным «мозгом». Если добавить к этому упомянутый fallback, то ещё веселее.
4) Зависит от… Если каждый SYN пойдёт на контроллер, то вопрос мощности контроллера. Если же будет правило, обрубающее такие штуки — в принципе ничего страшного.
Но вообще я сам не спец в SDN, хотя что-то похожее уже видел-трогал.
1) Доставка управляющего трафика — слабое место (поскольку чудес не бывает), но в версии 1.3.1 (может, и более ранних — не смотрел) предусмотрен fallback, когда устройство в отсутствие контроллера пускает всё традиционным путём. Так что хуже не будет.
2) Что вы имеете в виду под резервированием контроллеров? Если резервирование именно управляющей логики, когда одно падает — другое встаёт на том же месте, то для этого уже наработаны технологии — всякие бизнес-приложения же резервируются. Если имеется в виду резервирование в смысле «у устройства всегда должна быть голова (пусть и пустая :-)», то несколько контроллеров — чем не резервирование?
3) Никакие :-) Тут вообще ситуация не такая простая — непонятно, как сращивать автономные системы с централизованным «мозгом». Если добавить к этому упомянутый fallback, то ещё веселее.
4) Зависит от… Если каждый SYN пойдёт на контроллер, то вопрос мощности контроллера. Если же будет правило, обрубающее такие штуки — в принципе ничего страшного.
Но вообще я сам не спец в SDN, хотя что-то похожее уже видел-трогал.
Наработают ещё.
Ну так может, не стоит тогда пиарить его как «переходите прямо сейчас»? :)
Молодость — не оправдание. Если кто-то хочет активно пиарить идеологию SDN — пусть докажет, что она хотя бы теоретически может работать. Пока видны сплошные пробелы. Нагрузку не держит, надежность никакая (мощная единая точка отказа в виде сервера, у которого, между прочим, запросто могут закоррпатиться таблицы, и тогда никакое резервирование не спасет), есть лишь единственный аргумент «удобно» (тоже под сомнением — есть немало централизованных решений, которые сами ходят по автономным железкам и набивают на них монотонные конфиги — актуально в случае MPLS TE у крупного оператора).
в версии 1.3.1 (может, и более ранних — не смотрел) предусмотрен fallback, когда устройство в отсутствие контроллера пускает всё традиционным путём. Так что хуже не будет.
То есть каждый openflow свитч таки должен работать со всеми традиционными протоколами маршрутизации? :)
Что вы имеете в виду под резервированием контроллеров?
Скорее горизонтальное масштабирование с фейловером, и, соответственно, с полной репликацией состояния между нодами. Справятся?
Если каждый SYN пойдёт на контроллер, то вопрос мощности контроллера.
В эпоху 10G/40G ни один контроллер не справится с таким потоком данных. И сеть ляжет. Вся. Целиком и полностью. А в классической схеме эти пакеты максимум загадят каналы (QoS, полисеры — и нет проблем).
Если же будет правило, обрубающее такие штуки — в принципе ничего страшного
Обрубающее SYN пакеты? :)
вы тоже слишком категоричны.
Я стараюсь быть объективным. И объективность говорит, что openflow в чистом виде неприменим к реальным сетям, тем более — территориально распределенным. Ну не вижу я ему применений. Отдельными потоками данных поуправлять — не вопрос (хотя PBR, MPLS TE и некоторые другие решения тоже дают некоторую гибкость в организации передачи данных), но не сетью «по дефолту».
не стоит тогда пиарить его как «переходите прямо сейчас»?
Вы странно воспринимаете написанное, где вы это прочли? Черным по белому сказано, что SDN — это один из major trend развития сетей.
Черным по белому сказано, что SDN — это один из major trend развития сетей.
«готова в ближайшем будущем превратиться в настоящий main stream развития сетей.» обычно понимается как «технология уже готова и буквально завтра на нее начнут повально переходить. А не „многие занимаются развитием технологии, и когда-нибудь ее допилят до адекватного состояния“.
Предложенная вами концепция „весь интеллект сети, управляемой через OpenFlow, размещается теперь на контроллерах“ вообще нежизнеспособна, и все с этим согласны. Да, да, я верю, что в лабе, где скорость передачи данных иногда достигает аж двух пингов в минуту, SDN работает классно, но лаба — это лаба, она не имеет отношения к продуктивной среде. Опять же, про „Нагрузку специально не тестировали“ — да в жизни не поверю. Любой уважающий себя ITшник первым делом устроит прожиг такой сети и попытается ее уронить. Вероятно, вы получили настолько смехотворные результаты, что ими и делиться стыдно. И исправить это едва ли удастся, потому что проблема — концептуальная.
Предложенная вами концепция „весь интеллект сети, управляемой через OpenFlow, размещается теперь на контроллерах“ вообще нежизнеспособна, и все с этим согласны.
Ну, во-первых, эта концепция предложена не мной (хотя спасибо, я польщен); во-вторых, если вы думаете, что концепция не жизнеспособна, то не обязательно так считают все остальные. С вами не согласны как минимум полусотни организаций, использующих openflow у себя в сетях.
И, в-третьих, вы снова манипулируете понятиями — major trend означает, что все игроки активно занимаются развитием этой технологии и уже есть вполе конкретные, жизнеспособные результаты; как только основные вендоры выпустят свои контроллеры, технология выйдет в main stream. Использовать или нет — ваше личное дело, ваше мнение снова услышано, спасибо.
эта концепция предложена не мной
Я про статью.
С вами не согласны как минимум полусотни организаций, использующих openflow у себя в сетях.
В чистом виде (описанном в статье) openflow не использует ни одна организация. А вот в качестве дополнительного средства traffic engineering'а (поверх уже собранной сети на традиционных протоколах) — да, такое есть. Google например. Про их сеть мало известно, но тот факт, что у них есть вкрапления SDN, был раскрыт. Только само собой — с openflow их SDN не имеет практически ничего общего, и у них все самописное от контроллера до прошивок свитчей.
То есть в общем и целом содержание топика описывает сферического коня в вакууме, который в нашей вселенной не живет, но нечто среднее между SDN и классическим роутингом появиться может (см. Cisco ONE как пример).
все игроки активно занимаются развитием этой технологии и уже есть вполе конкретные, жизнеспособные результаты
Тут я примерно описал, почему вендоры заинтересованы в SDN. А чистая реализация openflow свитча (т.е. строгое соответствие стандарту и не более того) никому включая HP не интересно. Так что поиграетесь — и тоже выпустите свой проприетарный платный контроллер и свои интеллектуальные комбинированные свитчи, как и все здравомыслящие конторы.
Примение уже есть. Не чистый OpenFlow конечно, как стандарт он еще не развит и есть много проприетарных штук, но тем не менее.
Для магистральных сетей технология не готова, факт.
А вот для ЦОДов, да еще и с большими фермами виртуальных машин — да, готово.
SDN идеально подходит для управления «гибридными», часть свитчей виртуальна, OVS какой-нибудь, а скажем сами серверы подключаются на железные SDN свитчи, и все это управляется из одной точки.
Система управления автоматически нарезает клиенту сеть с произвольной адресацией, vlan'ами и прочим. Траффик клиентов изолирован и четко балансируется итд итп. И да, 1 GBps.
Есть коммерческие линейки со всякой корпоративной поддержкой итд итп, и есть готовые решения, включая контроллер (которго у HP нет).
Для магистральных сетей технология не готова, факт.
А вот для ЦОДов, да еще и с большими фермами виртуальных машин — да, готово.
SDN идеально подходит для управления «гибридными», часть свитчей виртуальна, OVS какой-нибудь, а скажем сами серверы подключаются на железные SDN свитчи, и все это управляется из одной точки.
Система управления автоматически нарезает клиенту сеть с произвольной адресацией, vlan'ами и прочим. Траффик клиентов изолирован и четко балансируется итд итп. И да, 1 GBps.
Есть коммерческие линейки со всякой корпоративной поддержкой итд итп, и есть готовые решения, включая контроллер (которго у HP нет).
И да, 1 GBps.
Для ЦОДа? С большими фермами виртуальных машин? Смеетесь? :)
1гб/с — это линк от уровня доступа/агрегации до ядра для сетей конечных пользователей. А все более-менее современные ЦОДы уже перешли на 10G. Где-то и 40G на аплинках есть.
Я могу поверить, что SDN может работать в маленьком ЦОДе на несколько десятков хостов и несколько сотен виртуалок. Но зачем он там нужен? Поставил пару простых свитчей, и готово.
Изоляция и балансировка тоже давно реализованы (в случае последнего — обычно средствами хардварных балансировщиков, но это как раз тот случай, когда работающее строго на L3/L4 устройство не сможет обеспечить даже долю нужного функционала).
Вы в курсе, что в современных блейд-шасси на железном коммутаторе уже светятся аж порты виртуальных машин, а не только гипервизоров?
Удобство управления — сомнительно. У всех крупных сетевых вендоров есть решения по поводу того, как собрать как можно больше (виртуальных) портов на одной-двух центральных железках. Qfabric от Juniper например. Или vPC пара Nexus 7k с кучей FEXов (внешне похожи на свитчи, но фактически являются просто выноснями линейными картами и управляются с основной железки).
То есть преимущества толком и нет.
Ну не написал что есть порты для SFP 10G, и что? )
SDN — это не чудо юдо, а просто API для формирования FIB средствами выделенного контроллера. А без контроллера железка спокойно может работать как l2\l3 свитч.
>Вы в курсе, что в современных блейд-шасси на железном коммутаторе уже светятся аж порты виртуальных машин, а не только гипервизоров?
Это Вы к чему? Ну как бы да, в курсе… На самом деле могу порассказывать про детали этого всего )
Короче. В итоге TCO сети и ЦОДа будет меньше, и уже сейчас понятно как этого можно достичь. У крупных вендоров есть нормальные roadmap по функционалу этой технологии (только они стесняются их показывать, или боятся). Ура-революции разумеется не будет, и не везде оно будет работать, но свою нишу займет.
SDN — это не чудо юдо, а просто API для формирования FIB средствами выделенного контроллера. А без контроллера железка спокойно может работать как l2\l3 свитч.
>Вы в курсе, что в современных блейд-шасси на железном коммутаторе уже светятся аж порты виртуальных машин, а не только гипервизоров?
Это Вы к чему? Ну как бы да, в курсе… На самом деле могу порассказывать про детали этого всего )
Короче. В итоге TCO сети и ЦОДа будет меньше, и уже сейчас понятно как этого можно достичь. У крупных вендоров есть нормальные roadmap по функционалу этой технологии (только они стесняются их показывать, или боятся). Ура-революции разумеется не будет, и не везде оно будет работать, но свою нишу займет.
SDN — это не чудо юдо, а просто API для формирования FIB средствами выделенного контроллера. А без контроллера железка спокойно может работать как l2\l3 свитч.
То есть мы возвращаемся к тому, что железки будут обладать мозгами, дружить друг с другом по традиционным протоколам, но при этом контроллер может управлять отдельными потоками на них. Ок, не возражаю.
В итоге TCO сети и ЦОДа будет меньше
Вы однозначно работаете на какого-то из вендоров. Возможно, в technical marketing подразделении. Меня вот например всегда раздражали заявления той же циски вроде «increase operational efficiency», «lower TCO». Разумеется, речь идет про железки стоимостью в несколько сотен долларов. А я вот сижу и думаю: если бы у меня было, допустим, двадцать 2960-х с парой 3750-х в ядре — каким же образом смена этого зоопарка на какие-нибудь N7K позволит мне сэкономить? Упрощение конфигурирования? Чушь, усилия будут одинаковые. Повышение стабильности? В теории — возможно (хотя старое барахло лет за 5 ни разу не глюкнуло), вот только у нового железа обязательно будут детские болячки. Так где экономия?
В случае openflow никакой экономии тоже нет. TCO может и повыситься. Возможно, вам удастся сэкономить капекс (не факт), но вот с опексом будет проблема, и большая.
И уж точно внедрение SDN не упростит управление сетью.
То есть мы возвращаемся к тому, что железки будут обладать мозгами, дружить друг с другом по традиционным протоколам, но при этом контроллер может управлять отдельными потоками на них. Ок, не возражаю.
Обычно бьются за 2 крайности, но в итоге их не будет, а получим что-то среднее. Все верно.
Да, у вендора. Не скрываю, и нет, не маркетинг, просто это максимум того, что могу рассказать здесь.
Для существующих сетей — целесообразность замены вопрос открытый, каждый случай надо рассматривать отдельно.
И снова да, TCO стоит на первых позициях, в итоге мы все зависим от бизнеса, который формирует бюджет. И пока проблем с опексом не заметно.
Для существующих сетей — целесообразность замены вопрос открытый, каждый случай надо рассматривать отдельно.
Однако, примерно каждый вендор говорит «выкиньте свое барахло и купите наше — сразу начнете экономить». А я вот не понимаю, откуда возьмется экономия. Особенно в случае SDN.
И пока проблем с опексом не заметно.
Тоже отличная фраза…
До чего же вы, ребята, скользкие :)
«выкиньте свое барахло и купите наше — сразу начнете экономить»
Тут поддержу. Лихим продавцам, которые сегодня предлагают делать своп сущесвующих систем без полноценного исследования на SDN — «надо плевать в левый глаз». Свитчи есть, и почти все нормальные… А вот с контроллерами пока проблема…
А я даже знаю, как проблему с контроллерами в итоге решат. Будет опенсорс, строго следующий отсталому на каждый момент времени стандарту openflow. Будут проприетарные решения от каждого вендора, поддерживающие «продвинутые» API и, возможно, «legacy» стандарт openflow. Будут свитчи каждого вендора, поддерживающие все его проприетарные API. А все это вместе образует мощнейший, невиданный vendor lock-in. Не то чтобы это плохо, но разговоры об открытости стандарта можно будет даже не начинать.
Частично отвечу (к автору и компании никакого отношения не имею):
2) Контроллеры кластеризуются, и на сегодня у них достаточно жесткие треования по качеству линка между ними.
3) Зависит от реализации. MPLS нет.
4) То же самое что и с обычно сетью. Траффик ведь на контроллер доставляется только если в FIB нет правила для его обработки. Но, если руки прямые, а контролер и свитчи позволяют, то можно будет прописатьправила, которые будут это дело фильтровать.
Да в том то и дело что от модульных коммутаторов отличается в корне.
Например контроллер знает ВСЮ передаточню функцию сети. При условии прямых рук можно нарастить эффективность использования сети в 2 раза, за счет создания нескольких маршрутов меду 2мя точками в зависимости от нагрузки в момент времени.
В случае обрыва железка превращается просто в свитч, и сохраняет в себе таблицы маррутизации. Пропадет управление сетью.
2) Контроллеры кластеризуются, и на сегодня у них достаточно жесткие треования по качеству линка между ними.
3) Зависит от реализации. MPLS нет.
4) То же самое что и с обычно сетью. Траффик ведь на контроллер доставляется только если в FIB нет правила для его обработки. Но, если руки прямые, а контролер и свитчи позволяют, то можно будет прописатьправила, которые будут это дело фильтровать.
Да в том то и дело что от модульных коммутаторов отличается в корне.
Например контроллер знает ВСЮ передаточню функцию сети. При условии прямых рук можно нарастить эффективность использования сети в 2 раза, за счет создания нескольких маршрутов меду 2мя точками в зависимости от нагрузки в момент времени.
В случае обрыва железка превращается просто в свитч, и сохраняет в себе таблицы маррутизации. Пропадет управление сетью.
Траффик ведь на контроллер доставляется только если в FIB нет правила для его обработки.
Так что делать с флудом? Он уничтожит всю сеть?
При условии прямых рук можно нарастить эффективность использования сети в 2 раза, за счет создания нескольких маршрутов меду 2мя точками в зависимости от нагрузки в момент времени.
Потрясающе :) Практически цитируете маркетинговые материалы. В какие еще 2 раза, откуда эта цифра?
Поток данных может постоянно менять скорость. Свитчи будут постоянно докладывать контроллеру о состоянии каждого потока?
Вспомните: раньше уже была идея резервировать по полосе на каждый поток данных, сигнализируя о нем по всей цепочке сетевых устройств. RSVP. Конечно же не прижилось (глупая затея), и сейчас этот протокол используется только для сигнализации целых туннелей. И весьма успешно используется, позволяя добиться практически полной утилизации каналов без ущерба для данных.
Что до балансировки. Неравномерная балансировка в ЦОДе — бред, такого не бывает, забыли. Равномерная — тоже давно не проблема. У каждого вендора есть свои решения mLAG. Для большей масштабируемости (куда SDN даже смотреть не смеет) есть различные TRILL-образные технологии. Fabricpath у циски например. Фактически L2 роутинг. Поднимается двумя командами, работает отлично. Трафик будет довольно равномерно размазан по всем линкам, коих может быть много.
Кольца STP уже лет 5 как удаляются из ЦОДов, и на более-менее современных площадках их уже нет и быть не может.
Так в чем же преимущества?
Цифра — PoC, лабы, кое-где внедрения…
Внедрения — не верю. Лабы? Опишите, с чем сравнивали. Кольцо из десятка дэлинков в роли «классической неэффективной архитектуры» не считается.
То есть никакого влияния на control plane? Мне почему-то кажется, что это не совсем правда… Скорее будет что-то вроде цунами, сносящего всю сеть, по которой он проходит.
Эффект не будет сильно отличаться от воздействия на традиционную сеть.
То есть никакого влияния на control plane? Мне почему-то кажется, что это не совсем правда… Скорее будет что-то вроде цунами, сносящего всю сеть, по которой он проходит.
Ну не попадет syn-flood на контроллеры при нормальных правилах… И вообще проброс пакета на контроллер — мера экстренная и крайне нежелательная, и всем понятно почему.
Но при этом говорится как о главном преимуществе, что контроллер должен знать обо всех потоках, причем не только о самом факте наличия соединения (для этого традиционно *flow используют, и да, он может потребовать установки большого числа коллекторов), но и о битрейте (нагрузка повышается на порядки). По сравнению с этим проброс пакетов кажется несущественной мелочью. А если коммутатор будет молча передавать пакеты по заранее заданным правилам — это будет натуральный PBR в чуть более удобной обертке, а скорее — тот самый классический роутинг/свитчинг.
>Так что делать с флудом? Он уничтожит всю сеть?
Эффект не будет сильно отличаться от воздействия на традиционную сеть.
Эффект не будет сильно отличаться от воздействия на традиционную сеть.
SDN в массы! подскажите, цитата про «слабых людей» — откуда?
всё ж таки порадовали цитаты :) спасибо :)
Не показано ни настоящее, ни будущее.
Покажете честный roadmap соответсвующей линейки оборудования?
Покажете честный roadmap соответсвующей линейки оборудования?
Настоящее, как мне кажется, показано. Roadmap под NDA, здесб показать не могу
3 свитча под ноксом? ) больше на реферат похоже.
Что Вы можете рассказать про ControlPlane? Туннелирование ControlPlane поддерживаете?
Анализ нагрузки у Вас есть? Или только в рамках TCP\IP работаете? Например SCTP\IP параметры умеете разбирать?
Какую версию OpenFlow поддерживаете? Какие «фирменные» фичи?
Что у вас с обеспечением переключения на резервный маршрут под нагрузкой превышающей ширину резевного канала? Как себя поведет ваша лаба?
Что Вы можете рассказать про ControlPlane? Туннелирование ControlPlane поддерживаете?
Анализ нагрузки у Вас есть? Или только в рамках TCP\IP работаете? Например SCTP\IP параметры умеете разбирать?
Какую версию OpenFlow поддерживаете? Какие «фирменные» фичи?
Что у вас с обеспечением переключения на резервный маршрут под нагрузкой превышающей ширину резевного канала? Как себя поведет ваша лаба?
3 свитча под ноксом? ) больше на реферат похоже.договорились, пусть для вас это будет рефератом
Что Вы можете рассказать про ControlPlane?а что именно вы хотите про него услышать? и что понимаете под туннелированием? пробросить контрольный трафик между сеткой и контроллером через туннель? можно.
Анализ нагрузки у Вас есть? Или только в рамках TCP\IP работаете?опять же, нагрузки какой? по обработке flows на свиче? или нагрузка на контроллер? на свиче, если делать hw flows, процессор не грузится. точнее, грузится не сильнее, чем при традиционной коммутации. на контроллере — зависит (от мощности сервера, вариантов развертывания и т.д.)
Какую версию OpenFlow поддерживаете? Какие «фирменные» фичи?тестировали на софте, поддерживающим 1.0, про «фирменные фичи» — у НР позиция учавствовать в разработке стандартов, а не изобретать «фирменные фичи»; поэтому, что в стандарте есть, то и поддерживается.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Программно определяемые сети (Software Defined Networks): настоящее и будущее