Он будет отслеживать поток, а не пользователя. Из потока можно получить данные пользователя, но это очень затратная по CPU технология. Хотя никто не мешает периферийному коммутатору как-то тэгировать каждый поток и различать их на этом основании.
Для всего остального SDN тем более будет медленнее.
Включаю между двумя соседними железками BFD, и получаю время обнаружения аварии для любого классического протокола маршрутизации в 150-200мс (если не слишком закручивать гайки). UDLD для оптики будет быстрее.
Да, это преимущество. Но как часто падают линки в правильно построенных сетях? Неужели это настолько весомое преимущество?
С чего вы взяли?
(говоря об L3 свитчах)
Хм. Что проще — развернуть пакет, посмотреть инфу L2, обернуть пакет в новый L2 заголовок и переслать его или сначала вынуть L3 заголовок, обработать его, завернуть его в новый L2 заголовок и тоже переслать его? Чем выше уровень OSI, тем больше времени уходит на декодировку пакета, иначе бы NBAR не был бы таким ресурсоемким.
Скучно.
Давайте в лабораторных условиях с каким-нибудь Spirent TestCenter. Который способен прожечь бекплейн примерно любого свитча, генерируя терабиты любого трафика с любыми характеристиками и выдавая детальную информацию о качестве передачи данных (включая время сходимости с точности до микросекунд).
Вы предлагаете нагрузочное тестирование лабораторных прототипов которые не существуют и двух лет? И считаете, что если Nexus выдержит такую нагрузку, а SDN нет, то SDN убыточная технология?
То есть для ЦОДа не годятся. Для операторской сети — тоже. В мелких внедрениях запросто можно и софтовым роутером обойтись.
Так зачем же тогда нужен SDN?
Сейчас — не годятся. В будущем — сомневаюсь, что будет годится. Пока это всего лишь идея, и годится она только для малых сетей с низкими задержками. Но и считать по поверхностному описанию идеи, что она убыточна глупо. Тем более, что за тот же Nexus создавали на существующей базе с проверенными наработками компания со стоимостью куда большей, чем 1,26 млр. долларов и периодом развития в 28 лет. Я думаю, что разница между ними весьма существенная. В конце концов, Arphanet в момент запуска тоже не мог похвастаться хорошей сходимостью и малыми задержками.
Для падения линка — да, SDN будет реагировать медленнее. Но линки в современных сетях падают не слишком часто. А вообще коммутация обрабатывается быстрее маршрутизации, поэтому SDN могут штатно работать быстрее классических сетей. В лабораторных условиях, где сервер находится недалеко от любого устройства, а коммутируемых потоков относительно немного. И сравниваются они не ЦОДовскими железками, иначе это сравнение мотоцикла и спортивной машины. Просто по моему мнению у SDN есть преимущества, но все они нивелируются при увеличении маштабов сети. И в периферийные «умные» свичи, по стоимости ниже классического корпоративного L2 свича мне не верится.
Я уже упоминал про быстродействие современного enterprise оборудования. Но цена L3 коммутатора с ASIC весьма высокая. Вопрос в том, как быстро будет работать тот же QoS и ACL в SDN с относительно слабыми и дешевыми периферийными свичами. Если в каждый такой свич пихать ASIC – свичи выйдут дорогими, а если вешать это все на центральный «сервер» — сеть может оказаться неприменимой к современным распределенным корпоративным сетям, LFN и ЦОДам. При малой нагрузке и малых расстояниях передающих линий эта сеть наверняка обладает большим быстродействием и сходимостью. При большей – сильно сомневаюсь, но описывается SDN именно как решение для более высоконагруженных сетей будущего.
Было бы замечательно. Но про программную обработку — через ACL надо пропускать каждый фрейм, от этого никуда не денешься. И как будет SDN работать при необходимости отфильтровать именно пару адресов? Или как в нем могут быть организованы системы — аналоги QoS или VLAN с централизацией и без потерь в производительности?
Еще меня очень интересует вопрос скорости работы SDN. У традиционных сетей есть оборудование на ASIC-платах (аппаратная реализация некоторых фич вроде L2 коммутации и ACL), которые позволяют обрабатывать данные на скоростях почти равных максимальной скорости интерфейса. В SDN же по определению используются программа, которая и принимает решение о маршрутизации. А быстродействие программы в 10-100 раз меньше быстродействия полностью аппаратного решения. Как рассчитывается адаптировать такую сеть, да еще и централизованную, к лавинообразному росту трафика?
На мой вкус, все вопросы контакта ограничиваются целесообразностью этого самого контакта. Иначе говоря, полноценный контакт с инопланетной цивилизацией возможен лишь при равном уровне развития рас. А значит, наши контактеры еще не могут выбраться за пределы своих звездных систем. При более высоком развитии цивилизаций контакт просто не нужен одной из сторон. Мы же не идем из альтруизма строить современные мегаполисы и передавать все знания для отсталых племен своего вида на своей родной планете… А уж тем более не обучаем пользоваться компьютерами муравьев. Максимум что может достаться Земле при столкновении с внеземной и более развитой технически расой — аналог программы в зоопарке Майами по обучению орангутанов основам обращения с ipad'ами. Обратите внимание — не производства, а использования.
Это еще не самое прикольное. Интереснее всего было когда у меня лаба на экзамене CCNP ROUTE неправильно сработала, 40 минут на нее убил. Там надо было настроить передачу маршрутов между OSPF и EIGRP, чтобы еще весь трафик автоматом шел по резервному каналу при отказе основного. А вот при отказе основного канала в симуляторе местном пинг по резервному каналу с целевой системы не шел, EIGRP с удаленного роутера метрику до резервного канала не показывала, но подсети из OSPF нормально показывала. Пинг так и не пошел, хотя эту лабу похоже мне засчитали как правильную. Это к качеству эмуляторов оборудования cisco от производителей оборудования cisco…
Этот проект был сделан за несколько вечеров, только из интереса. Поэтому и никаких своих наработок там нет, за исключением костылей, которыми сшиты вместе все чужие компоненты)
Код сейчас с собой нет, представлю как домой приеду, но вообще это переделанная демка analytics из Raphael. raphaeljs.com/analytics.html Домой попасть я смогу либо на этих выходных, либо на следующих.
Да, это преимущество. Но как часто падают линки в правильно построенных сетях? Неужели это настолько весомое преимущество?
Хм. Что проще — развернуть пакет, посмотреть инфу L2, обернуть пакет в новый L2 заголовок и переслать его или сначала вынуть L3 заголовок, обработать его, завернуть его в новый L2 заголовок и тоже переслать его? Чем выше уровень OSI, тем больше времени уходит на декодировку пакета, иначе бы NBAR не был бы таким ресурсоемким.
Вы предлагаете нагрузочное тестирование лабораторных прототипов которые не существуют и двух лет? И считаете, что если Nexus выдержит такую нагрузку, а SDN нет, то SDN убыточная технология?
Сейчас — не годятся. В будущем — сомневаюсь, что будет годится. Пока это всего лишь идея, и годится она только для малых сетей с низкими задержками. Но и считать по поверхностному описанию идеи, что она убыточна глупо. Тем более, что за тот же Nexus создавали на существующей базе с проверенными наработками компания со стоимостью куда большей, чем 1,26 млр. долларов и периодом развития в 28 лет. Я думаю, что разница между ними весьма существенная. В конце концов, Arphanet в момент запуска тоже не мог похвастаться хорошей сходимостью и малыми задержками.