Комментарии 67
«но в результате появилась проблема другая проблема – назначение одинаковых IP адресов разному оборудованию в рамках одной сетевой инфраструктуры» — не очень понял, как DHCP-сервер послужил причиной таких коллизий, которые он как раз призван устранить.
Я не понял, я чем их MPLS не устроил?
Поддерживаю вопрос. Звучит вообще все интересно и прикольно, но непонятно, чего они такое могут сделать, чего я не могу сделать с помощью MPLS.
Даже в сетях MPLS всё же каждое устройство принимает решение более-менее самостоятельно, с учётом известной ему информации на основе топологии, полученной от IGP. В опенфлоу весь интеллект не размазан по всей сети, а сосредоточен в одном месте, благодаря чему решения принимаются с учётом цельной картиной. Отсюда проистекает несколько теоретических преимуществ, начиная с моментальной сходимости (как только обнаружен сбойный участок), более интеллектуальном управлением ресурсами (нет необходимости в RSVP, с помощью которого резервируется ресурсы сети, а это всё-таки время), более низким требованиям к мозгам отдельных устройств и тому подобные плюшки. Имхо, как-то так.
То есть имеем Single point of failure.
Кроме того, у меня например на рабочих сетях, требование к сходимости при разрыве линка/падении узлы — 50 мс. Это конечно не моментально, но зачем больше?
Требования к мозгам: я так понимаю что к примеру BGP-маршрутизаторов вообще не существует, а на пограничные устройства просто заливается FIB из контролера?
Кроме того, у меня например на рабочих сетях, требование к сходимости при разрыве линка/падении узлы — 50 мс. Это конечно не моментально, но зачем больше?
Требования к мозгам: я так понимаю что к примеру BGP-маршрутизаторов вообще не существует, а на пограничные устройства просто заливается FIB из контролера?
Естественно, про единую точку отказа тоже люди подумали, поэтому контроллер может быть зарезервирован (несколько контроллеров с синхронизированными данными, находящихся в разных частях сети). По поводу пограничных маршрутизаторов — ничего не могу сказать конкретного, но мне кажется, что и их интеллектуальные функции (вычисление маршрутов, фильтрация трафика и решение о пересылке) можно с успехом возложить на контроллер.
>>Кроме того, у меня например на рабочих сетях, требование к сходимости при разрыве линка/падении узлы — 50 мс.
Биржевые игроки негодуэ.
Биржевые игроки негодуэ.
Биржевые игроки не строят сетей ;) Они тянут волокно из NASDAQ прямо в сервер. Да ещё считают у кого волокно короче получится :).
Но вообще да, согласен, там желательно и меньше, но мне вот интересно какой реально им SLA обеспечивают? Потому как 50 мс у нас, это то, что написано в ТЗ, по факту выходит обычно около 15-20 мс. Хотя наверно этого тоже не хватит.
Но вообще да, согласен, там желательно и меньше, но мне вот интересно какой реально им SLA обеспечивают? Потому как 50 мс у нас, это то, что написано в ТЗ, по факту выходит обычно около 15-20 мс. Хотя наверно этого тоже не хватит.
начиная с моментальной сходимости (как только обнаружен сбойный участок
MPLS TE с FRR — обещается в районе 50мс.
более интеллектуальном управлением ресурсами (нет необходимости в RSVP, с помощью которого резервируется ресурсы сети, а это всё-таки время)
А передать информацию о новом потоке на контроллер и получить ответ — не занимает времени?
RSVP используется применительно к MPLS TE, и он работает на туннель целиком, а не на каждый из потоков. О других применениях RSVP (на данный момент времени) я не слышал.
более низким требованиям к мозгам отдельных устройств
И колоссальным требованиям к мозгам и доступности контроллера.
и тому подобные плюшки
…
Да, я знаю гипотетические преимущества (ни одно из них не было упомянуто), но мне было бы интересно услышать мнение других.
Ну одно дело передать пакет с информацией о новом потоке контроллеру и получить ответ, а другое дело ждать, пока каждый из маршрутизаторов на пути следования потока будет решать, сможет ли он выделить необходимые ресурсы, и пересылать RSVP пакеты дальше.
На счёт мозгов контроллера — их всего несколько штук надо будет на сеть с учётом резервирования. Да и для контроллера не нужен будет суперкомпьютер. А в данный момент если у вас интеллектуальная сеть, то каждое устройство должно обладать не хилыми такими мозгами и поддерживать кучу фич.
Может мои ответы сумбурны, но Вы уж извините меня.
На счёт мозгов контроллера — их всего несколько штук надо будет на сеть с учётом резервирования. Да и для контроллера не нужен будет суперкомпьютер. А в данный момент если у вас интеллектуальная сеть, то каждое устройство должно обладать не хилыми такими мозгами и поддерживать кучу фич.
Может мои ответы сумбурны, но Вы уж извините меня.
Ну одно дело передать пакет с информацией о новом потоке контроллеру и получить ответ, а другое дело ждать, пока каждый из маршрутизаторов на пути следования потока будет решать, сможет ли он выделить необходимые ресурсы, и пересылать RSVP пакеты дальше.
FRR заранее подбирает обходной маршрут. Потому даже не надо дожидаться, пока контроллер примет решение. Ну и можно не бояться, что сеть упала в сторону самого контроллера ;)
А в данный момент если у вас интеллектуальная сеть, то каждое устройство должно обладать не хилыми такими мозгами и поддерживать кучу фич.
Вот смотрю я на один из своих cat6500.
cisco WS-C6504-E (R7000) processor (revision 2.0) with 983008K/65536K bytes of memory.
Processor board ID FOX…
SR71000 CPU at 600Mhz, Implementation 0x504, Rev 1.2, 512KB L2 Cache
Это еще считающийся модным супервизор 720-10G. Ведь отстой, верно? Однако, этого хлама хватает с избытком. Ведь свитч не отстеживает и не запоминает отдельные потоки, ему это не надо… А теперь представьте себе железку, которая сможет смаршрутизировать те же 720гб/с, но с запоминанием состояний.
На то он и коммутатор — попробуйте в него фуллвью влить и посмотреть, как он загнётся, так как пересылка пакета требует больших мозгов, нежели коммутация (которая выполняется на ASIC, поэтому и цпу мощный не нужен).
Может Вы невнимательно читали, но контроллеру не нужно маршрутизировать 720 гб/c, а достаточно выполнить маршрутизацию для первого и единственного пакета из потока, после чего все остальные кадры, принадлежащие этому потоку будут коммутироваться теми же ASIC на всех устройствах сети на скорости порта. И не нужно Вам будет на каждой циске по «модному супервайзеру».
Может Вы невнимательно читали, но контроллеру не нужно маршрутизировать 720 гб/c, а достаточно выполнить маршрутизацию для первого и единственного пакета из потока, после чего все остальные кадры, принадлежащие этому потоку будут коммутироваться теми же ASIC на всех устройствах сети на скорости порта. И не нужно Вам будет на каждой циске по «модному супервайзеру».
попробуйте в него фуллвью влить и посмотреть, как он загнётся, так как пересылка пакета требует больших мозгов, нежели коммутация (которая выполняется на ASIC, поэтому и цпу мощный не нужен).
Угадайте, какая железка держит BGP в MSK-IX :)
(Ну или держала до недавних пор, пока не уперлись в плотность 10G портов на слот.)
Вы путаете. Современные ASICи запросто принимают решения о форвардинке на L2-L4, не роняя производительность. Да, 6500-му плевать, коммутировать или маршрутизировать трафик.
И нет, размер FIB никак не влияет на пропускную способность. Просто на хардварных свитчах ее размер не резиновый. До миллиона записей на XL модификации, если мне память не изменяет.
достаточно выполнить маршрутизацию для первого и единственного пакета из потока, после чего все остальные кадры, принадлежащие этому потоку будут коммутироваться теми же ASIC на всех устройствах сети на скорости порта.
Это очень похоже на fast switching в цискиных терминах (безнадежно устаревший подход). CEF передает все без исключения пакеты потока строго хардварно.
6500-й устарел. Можете посмотреть на нексусы 7000. Там емкость — по 550гб/с на слот. Вплоть до line-rate шифрования, не говоря уже о банальном роутинге и тем более свитчинге.
Недавно были обзоры L3 коммутаторов Force10, там емкость еще выше.
Так в чем преимущества-то?
Официальные источники утверждают, что в качестве роутсервера используется программный маршрутизатор BIRD. А до этого использовалась Quagga. И так на многих площадках обмена трафиком.
www.msk-ix.ru/download/forum2010/Ilin_PF2010_1.pdf
Да, похоже — я неправильно их понял.
Да, похоже — я неправильно их понял.
«подход строго лабораторный, для тестов в университетах, а в практической жизни скорей всего неприменим»
Вроде как AT&T и eBay используют технологии Nicira в своих сетях.
Вроде как AT&T и eBay используют технологии Nicira в своих сетях.
Имелось в виду, что технология пока слишком новая и слишком не опробованная на реальных инфраструктурах, чтобы полностью переводить на ПКС такие гиганты как eBay или AT&T. Насколько я поняла, в случае практического подтверждения всех характеристик, эти компании, а также Google готовы будут на нее перейти. Но вначале тесты, тесты, тесты
в случае практического подтверждения всех характеристик, эти компании, а также Google готовы будут на нее перейти.
Опять же, не надо поминать гугл всуе. То, на что он перейдет, даже отдаленно не будет походить на общедоступные решения. Разве что общей концепцией. Потому нельзя говорить «гугл использует SDN, так что покупайте Nicira, Bigswitch и прочих!».
Очень интересно, как большие вендоры вроде Cisco и Juniper отнесутся к тому, что какая-то стороняя софтина, разработанная индусскими студентами (это же пока университетский ресерч, не так ли) будет управлять потоками трафика на их железе. Пока такого рода управление (вынесенное в отдельный control plane, либо по-старинке в ядре операционки) делается проприетарным софтом, существуют понятия «ответственность», «саппорт», «SLA» и т.п. А если этим занимается нечто, к которому вендор (кроме API) имеет мало отношения, кому конечный пользователь станет предъявлять претензии?
Мне кажется, до реальных продуктов с SDN еще очень далеко. Это тема — для диссертаций, симуляций в OpNET Modeler, как это случилось в свое время c G-MPLS.
Можно понять VMware, она железа не делает, и опыт с Nexus 1000v оказался вполне успешным. Но другим большим игрокам IMHO это нафиг не надо.
Мне кажется, до реальных продуктов с SDN еще очень далеко. Это тема — для диссертаций, симуляций в OpNET Modeler, как это случилось в свое время c G-MPLS.
Можно понять VMware, она железа не делает, и опыт с Nexus 1000v оказался вполне успешным. Но другим большим игрокам IMHO это нафиг не надо.
Реальные продукты уже есть и у крупных вендоров. Основных я перечислила в статье. Cisco вообще начали разрабатывать отдельную платформу под Open Flow — Cisco One. А почему вы думаете, что другим большим игрокам это не надо?
Cisco вообще начали разрабатывать отдельную платформу под Open Flow — Cisco One.
У них свой подход — они не вынимают мозги из сетевых устройств. Просто предоставляют фреймворк для манипуляции отдельными потоками.
Cisco сейчас борется за свой рынок. За развитием ПКС еще интересно наблюдать и с точки зрения маркетинга. Сейчас ряд экспертов вполне обоснованно полагают, что если все заявленные характеристики подтвердятся, то рынок может сильно измениться. И Cisco в том числе в этом видят угрозу со стороны конкурентов
Большим игрокам это очень надо, но решения будут проприетарными. Джунипер делает JunOS Space, циска Cisco One, наверняка за этим последуют и другие. Направление централизации управления и выноса части мозгов в control plane где-то в сети (чтобы как минимум руками не конфигурить правила для mpls te) — вполне здравое.
Но вот во что я не верю, так в абстрактный university research, который придумал нечто феерическое и пытается впарить это VMware, Inc.
В прошлой жизни я сам поработал некоторое время в классическом западном computer science и мужики вроде основателей Nicria были моими коллегами. Да, они знали Кнута наизусть и могли в ночи разбуженные воспроизвести алгоритм Дейкстры на Алголе. Но такие люди страшно далеко оторваны от реалий. Маршрутизатор они в глаза не видели, а BGP для них — набор RFC, а не двести строчек конфига. Они, наверное, могут придумать что-то интересное, но посмотрите сами — 95% научных статей по компьютерной тематике (не в журнале Хакер, а в тех что издает IEEE) — не применимая в жизни туфта. Неприменимая потому, что у университетских исследователей, и у больших корпораций очень, очень разные задачи, проблемы, финансирование, образ мыслей. Редко когда какие-то наработки находят применение в реальном продукте, и еще реже, когда получается надвендорный продукт.
Но вот во что я не верю, так в абстрактный university research, который придумал нечто феерическое и пытается впарить это VMware, Inc.
В прошлой жизни я сам поработал некоторое время в классическом западном computer science и мужики вроде основателей Nicria были моими коллегами. Да, они знали Кнута наизусть и могли в ночи разбуженные воспроизвести алгоритм Дейкстры на Алголе. Но такие люди страшно далеко оторваны от реалий. Маршрутизатор они в глаза не видели, а BGP для них — набор RFC, а не двести строчек конфига. Они, наверное, могут придумать что-то интересное, но посмотрите сами — 95% научных статей по компьютерной тематике (не в журнале Хакер, а в тех что издает IEEE) — не применимая в жизни туфта. Неприменимая потому, что у университетских исследователей, и у больших корпораций очень, очень разные задачи, проблемы, финансирование, образ мыслей. Редко когда какие-то наработки находят применение в реальном продукте, и еще реже, когда получается надвендорный продукт.
Хочу задать пару вопросов:
Получается, что первый пакет, который коммутатору неизвестно куда дальше отправить, висит в памяти, десятки (микро\мили)секунд?
А что делать если контроллер не знает куда это пакет отправить?
Какие характеристики у защищенного канала (latency, bandwidth) предполагаются?
То есть подразумевается, что в поля уровня IP/TCP/UDP смотреть будут сами коммутаторы, передавая информацию в Центральный контроллер и от него ожидая информации куда отправить пакет?
L2 подразумевает использования ARP/RARP протокола (или аналогичного), его присутствие предполагается в SDN?
Иначе коммутатор по защищенному каналу отправляет запрос на Центральный контроллер сети OpenFlow
Получается, что первый пакет, который коммутатору неизвестно куда дальше отправить, висит в памяти, десятки (микро\мили)секунд?
А что делать если контроллер не знает куда это пакет отправить?
Какие характеристики у защищенного канала (latency, bandwidth) предполагаются?
прокладывать связи «каждый с каждым» на уровне L2, не прибегая к IP-маршрутизации
То есть подразумевается, что в поля уровня IP/TCP/UDP смотреть будут сами коммутаторы, передавая информацию в Центральный контроллер и от него ожидая информации куда отправить пакет?
L2 подразумевает использования ARP/RARP протокола (или аналогичного), его присутствие предполагается в SDN?
Но непосредственно управлять принятием решения нельзя – можно лишь конфигурировать контроллер, задавая определенные наборы правил и приоритетов.
Как-то коряво высказано… Openflow предлагает то же: заранее настроить контроллер, который затем будет программировать FIB на коммутаторах.
Это позволяет оптимизировать продвижение пакетов данных, и, в частности, прокладывать связи «каждый с каждым» на уровне L2, не прибегая к IP-маршрутизации (рис. 2).
Откройте для себя TRILL :)
Только вот full mesh — крайне отвратительная топология. Никто так не делал и делать не собирается. Даже с SDN. И никому не нужна связь «каждый с каждым». Зачем?
Протокол позволяет выделять IP-адрес на ограниченный период времени («время аренды») или до отказа клиента от адреса — в зависимости от того, что произойдет раньше. Это в какой-то мере решило проблему ограниченности IP адресов в сетях IPv4, но в результате появилась проблема другая проблема – назначение одинаковых IP адресов разному оборудованию в рамках одной сетевой инфраструктуры.
Чушь какая-то…
1) DHCP не имеет никакого отношения к экономии адресов.
2) Централизованный DHCP исключает коллизии.
Ну и надо ли говорить, что SDN не может заменить DHCP? Может, у вас перемешались DHCP и NAT? Но NAT будет устранен куда раньше появления серьезных реализаций SDN, ибо IPv6.
Ну и я очень сомневаюсь, что SDN сможет хоть немного попинать BGP в плане глобальной маршрутизации.
НЛО прилетело и опубликовало эту надпись здесь
Можно для этого использовать 100 адресов, а можно 51
В конкретно вашем случае можно спокойно выделить на всех сеть /24.
В общем случае — вместо DHCP можно просто каждый раз руками прописывать адрес. Плохая альтернатива, спору нет, но адресное пространство будет точно так же экономиться.
Никто никогда не экономит адресное пространство средствами DHCP. Если нужно, чтобы некие ресурсы получали глобально маршрутизируемые адреса (а именно их и полагается экономить), то по сотне разных причин эти адреса будут назначать вообще статически. Если допустим PAT, то используем приватные сети — а их много, любая, сколь угодно крупная компания может позволить себе хотя бы банальные полтора адреса на порт.
Надо понимать, что есть голое теоретизирование, а есть практические аспекты некой предметной области.
так что сомневающиеся в BGP ещё есть
Та цитата была произнесена 13 лет назад. Теперь наши космические корабли уже бороздят просторы вселенной, а BGP был сильно доработан.
Альтернативы?
Дело даже не в самом BGP, а в подходе к передаче пакетов. BGP — всего лишь протокол динамической маршрутизации. Неповоротливый, тяжелый, но чертовски функциональный, гибкий и выносливый. SDN полностью меняет парадигму, теперь контроллер вынужден следить за каждым индивидуальным потоком. Что-то мне не верится, что в предложенном виде он сможет осилить сотни гигабит мелких потоков (а в случае крупного ЦОДа может быть и больше). Ведь каждый раз обращаться к серверу по поводу того, куда деть очередной поток — это ужасно. От этого все давно уже отказались.
И мне кажется в IT надо быть аккуратнее с фразой «Чушь какая-то…», особенно когда речь идёт об университетских исследования
А у меня есть серьезные подозрения, что данная фраза — не выражение мыслей исследователей, а какая-то отсебятина. Если не отсебятина, то придется признать, что исследователи вообще не имеют представления о положении дел в реальном мире. Такое, кстати, бывает сплошь и рядом.
Я ведь так и не понял, что имелось в виду под словами «назначение одинаковых IP адресов разному оборудованию в рамках одной сетевой инфраструктуры». Нечаянно? Нет, при грамотном дизайне такого не будет. Можно даже парой команд на порту коммутатора запретить статическую конфигурацию IP адресов. Умышленно? На здоровье, MPLS VPN для того и разрабатывался, плюс двухсторонний NAT между VRFами. Где проблема-то?
НЛО прилетело и опубликовало эту надпись здесь
А может действительно стоит прочитать эти жалкие 56 страниц
Вы же их не читали, в отличие от меня (пусть и по диагонали) ;)
Предложенный вами сценарий не имеет отношения к реальной жизни. И, честно говоря, про текущую реализацию openflow можно сказать то же самое…
Лично у меня заявления о том как всё везде правильно должно быть настроено ассоциирутся только со следующим
У вас проблемы с пониманием письменной речи? Ок, больше не буду приставать. А пока подумайте, кто из нас Филипп Филиппович, а кто — Шариков ;)
А если этим занимается нечто, к которому вендор (кроме API) имеет мало отношения, кому конечный пользователь станет предъявлять претензии?
В данном случае конечный пользователь — админ. Если он настолько глуп, чтобы использовать стороннюю софтину для управления коммутацией и при этом жаловатся на производителя железа… «Таня не шлюха? Ну извините...»
Количество сетевых адресов в новом протоколе IPv6 такое, что на 1 м2 поверхности Земли приходится 6,7*1023 адресов (фактически, это количество устройств, которое потенциально могут быть подключены к сетям).
Эта фраза выглядит нелепо и похожа на вышеупомянутый «маркетинговый буллшит». Во-первых, в практическом плане это число ничего нам не говорит. В обозримом будущем мы и близко к нему не приблизимся. Это всего лишь теоретический предел. Во-вторых, потенциально может быть подключено и больше устройств. NAT можно использовать и в IPv6.
1) IPv6 транжирится бешеными темпами. Можно смело половину разрядов изъять. Но да, все равно остается много.
2) В IPv6 не существует никакого PAT. Хотя теоретически могут и добавить.
2) В IPv6 не существует никакого PAT. Хотя теоретически могут и добавить.
Да, согласна. Но, к примеру, Cisco в одном из отчетом дает прогноз, что через 5-7 лет на каждого жителя планеты (кроме стран третьего мира) будет приходится до 7 устройств подключенных в сеть. Прибавьте еще корпоративную инфраструктуру, промышленные и военные объекты и поймете, что в принципе этот пределе так уж и недостижим.
Как пример: В начале 80-х прогнозировали, что к концу ХХ века в мире должно насчитываться 80 миллионов персональных компьютеров. Реально же такое количество РС в конце века продавалось всего за полгода.
Предел теоретический, но думаю, что вряд ли сейчас кто-то будет ручаться, что он будет недостижим.
Как пример: В начале 80-х прогнозировали, что к концу ХХ века в мире должно насчитываться 80 миллионов персональных компьютеров. Реально же такое количество РС в конце века продавалось всего за полгода.
Предел теоретический, но думаю, что вряд ли сейчас кто-то будет ручаться, что он будет недостижим.
Я, конечно, ни разу не цискарь и не спец по сабжу. Но что-то мне кажется, что комментаторы-скептики, когда наткнутся на свои высказывания лет через 5, либо не поверят, что они такое писали, либо заявят в очередной раз «ну кто ж мог знать...»:).
Кстати, НЯП, и в 70-е, и даже раньше много кто предсказывал будущий экспоненциальный рост компьютерных сетей; скорее всего, причина была в другом — думали, что это будут уже какие-то другие сети, созданные с нуля (еще в 90-х фантасты часто описывали, как в будущем интернет был «заменен» на какую-то другую сеть, как будто это можно сделать так просто, повсеместно и в один момент), а текущие разработки создавались как временные и то, что именно они лягут в основу дальнейшей непрерывной эволюции Сети на десятки лет, мало кому приходило в голову.
Кстати, НЯП, и в 70-е, и даже раньше много кто предсказывал будущий экспоненциальный рост компьютерных сетей; скорее всего, причина была в другом — думали, что это будут уже какие-то другие сети, созданные с нуля (еще в 90-х фантасты часто описывали, как в будущем интернет был «заменен» на какую-то другую сеть, как будто это можно сделать так просто, повсеместно и в один момент), а текущие разработки создавались как временные и то, что именно они лягут в основу дальнейшей непрерывной эволюции Сети на десятки лет, мало кому приходило в голову.
Еще меня очень интересует вопрос скорости работы SDN. У традиционных сетей есть оборудование на ASIC-платах (аппаратная реализация некоторых фич вроде L2 коммутации и ACL), которые позволяют обрабатывать данные на скоростях почти равных максимальной скорости интерфейса. В SDN же по определению используются программа, которая и принимает решение о маршрутизации. А быстродействие программы в 10-100 раз меньше быстродействия полностью аппаратного решения. Как рассчитывается адаптировать такую сеть, да еще и централизованную, к лавинообразному росту трафика?
Программа обрабатывает только первый пакет, по которому генерируется шаблон и действие. Остальные пакеты этого потока опять-таки пролетают с максимальной скоростью.
Про быстрое действие сможем сказать, когда сами физически у себя эту сетку настоим. Это как раз будет в конце августа. Обещаю все детально описать
Было бы замечательно. Но про программную обработку — через ACL надо пропускать каждый фрейм, от этого никуда не денешься. И как будет SDN работать при необходимости отфильтровать именно пару адресов? Или как в нем могут быть организованы системы — аналоги QoS или VLAN с централизацией и без потерь в производительности?
Но про программную обработку — через ACL надо пропускать каждый фрейм
Любой приличный L3 коммутатор уже давно умеет применять ACL, QoS, PBR наряду с банальной маршрутизацией строго аппаратно, на line-rate. Вот только ACL достаточно применить к потоку один раз, только к первому пакету. Остальные будут иметь ту же L3/L4 информацию. Если не будут, то это уже другой поток.
Или как в нем могут быть организованы системы — аналоги QoS или VLAN с централизацией и без потерь в производительности?
«достаточно выполнить маршрутизацию для первого и единственного пакета из потока»
Т.е. без потерь в производительности — абсолютно никак.
Я уже упоминал про быстродействие современного enterprise оборудования. Но цена L3 коммутатора с ASIC весьма высокая. Вопрос в том, как быстро будет работать тот же QoS и ACL в SDN с относительно слабыми и дешевыми периферийными свичами. Если в каждый такой свич пихать ASIC – свичи выйдут дорогими, а если вешать это все на центральный «сервер» — сеть может оказаться неприменимой к современным распределенным корпоративным сетям, LFN и ЦОДам. При малой нагрузке и малых расстояниях передающих линий эта сеть наверняка обладает большим быстродействием и сходимостью. При большей – сильно сомневаюсь, но описывается SDN именно как решение для более высоконагруженных сетей будущего.
Но цена L3 коммутатора с ASIC весьма высокая.
А openflow свитч будет уличной магией на line-rate менять L3/L4/L2.5 заголовки? Правильно, в него напихают те же самые ASICи :)
При малой нагрузке и малых расстояниях передающих линий эта сеть наверняка обладает большим быстродействием и сходимостью.
Сама архитектура SDN подразумевает, что быстродействие и сходимость для нее будут хуже, чем для классической сети, в которой некие протоколы заранее предусмотрели обходные маршруты. См. MPLS fast reroute для TE туннелей, IP fast reroute для OSPF, feasible successor для EIGRP и так далее. А если засунуть в свитч мощные мозги (например, Nexus 7k использует интеловский 2-ядерный ксеон одного из последних поколений — исключительно для control plane, транзитные пакеты через него не проходят ни при каких условиях) — время расхождения LSU и перерасчета таблицы топологии наверняка будет примерно соответствовать времени получения отклика от openflow контроллера. Без всяких FRR.
Для падения линка — да, SDN будет реагировать медленнее. Но линки в современных сетях падают не слишком часто. А вообще коммутация обрабатывается быстрее маршрутизации, поэтому SDN могут штатно работать быстрее классических сетей. В лабораторных условиях, где сервер находится недалеко от любого устройства, а коммутируемых потоков относительно немного. И сравниваются они не ЦОДовскими железками, иначе это сравнение мотоцикла и спортивной машины. Просто по моему мнению у SDN есть преимущества, но все они нивелируются при увеличении маштабов сети. И в периферийные «умные» свичи, по стоимости ниже классического корпоративного L2 свича мне не верится.
Для падения линка — да, SDN будет реагировать медленнее. Но линки в современных сетях падают не слишком часто.
Для всего остального SDN тем более будет медленнее.
Включаю между двумя соседними железками BFD, и получаю время обнаружения аварии для любого классического протокола маршрутизации в 150-200мс (если не слишком закручивать гайки). UDLD для оптики будет быстрее.
А вообще коммутация обрабатывается быстрее маршрутизации
С чего вы взяли?
(говоря об L3 свитчах)
На современных свитчах задержка передачи пакета может быть менее микросекунды (на 40G интерфейсе).
В лабораторных условиях, где сервер находится недалеко от любого устройства, а коммутируемых потоков относительно немного.
Скучно.
Давайте в лабораторных условиях с каким-нибудь Spirent TestCenter. Который способен прожечь бекплейн примерно любого свитча, генерируя терабиты любого трафика с любыми характеристиками и выдавая детальную информацию о качестве передачи данных (включая время сходимости с точности до микросекунд).
Просто по моему мнению у SDN есть преимущества, но все они нивелируются при увеличении маштабов сети.
То есть для ЦОДа не годятся. Для операторской сети — тоже. В мелких внедрениях запросто можно и софтовым роутером обойтись.
Так зачем же тогда нужен SDN?
Для всего остального SDN тем более будет медленнее.
Включаю между двумя соседними железками BFD, и получаю время обнаружения аварии для любого классического протокола маршрутизации в 150-200мс (если не слишком закручивать гайки). UDLD для оптики будет быстрее.
Да, это преимущество. Но как часто падают линки в правильно построенных сетях? Неужели это настолько весомое преимущество?
С чего вы взяли?
(говоря об L3 свитчах)
Хм. Что проще — развернуть пакет, посмотреть инфу L2, обернуть пакет в новый L2 заголовок и переслать его или сначала вынуть L3 заголовок, обработать его, завернуть его в новый L2 заголовок и тоже переслать его? Чем выше уровень OSI, тем больше времени уходит на декодировку пакета, иначе бы NBAR не был бы таким ресурсоемким.
Скучно.
Давайте в лабораторных условиях с каким-нибудь Spirent TestCenter. Который способен прожечь бекплейн примерно любого свитча, генерируя терабиты любого трафика с любыми характеристиками и выдавая детальную информацию о качестве передачи данных (включая время сходимости с точности до микросекунд).
Вы предлагаете нагрузочное тестирование лабораторных прототипов которые не существуют и двух лет? И считаете, что если Nexus выдержит такую нагрузку, а SDN нет, то SDN убыточная технология?
То есть для ЦОДа не годятся. Для операторской сети — тоже. В мелких внедрениях запросто можно и софтовым роутером обойтись.
Так зачем же тогда нужен SDN?
Сейчас — не годятся. В будущем — сомневаюсь, что будет годится. Пока это всего лишь идея, и годится она только для малых сетей с низкими задержками. Но и считать по поверхностному описанию идеи, что она убыточна глупо. Тем более, что за тот же Nexus создавали на существующей базе с проверенными наработками компания со стоимостью куда большей, чем 1,26 млр. долларов и периодом развития в 28 лет. Я думаю, что разница между ними весьма существенная. В конце концов, Arphanet в момент запуска тоже не мог похвастаться хорошей сходимостью и малыми задержками.
Да, это преимущество. Но как часто падают линки в правильно построенных сетях?
Чертовски часто. Правильно построенные корпоративные сети ходят поверх по-разному построенных операторских сетей.
И на самом деле я просто разбиваю миф про быструю сходимость у SDN.
Что проще — развернуть пакет, посмотреть инфу L2, обернуть пакет в новый L2 заголовок и переслать его или сначала вынуть L3 заголовок, обработать его, завернуть его в новый L2 заголовок и тоже переслать его?
Да примерно одинаково, около одного такта.
Найдите мне замеры, подтверждающие, что L3 свитч осуществляет L3 форвардинг медленнее L2 форвардинга.
Мы ведь говорим не про процессорную обработку, а про узкоспециализированные ASICи, заточенные под конкретные задачи.
Вы предлагаете нагрузочное тестирование лабораторных прототипов которые не существуют и двух лет?
Конечно. Чем раньше, тем лучше. Нужно сразу обнаружить узкие места и устранять их. А неторопливо пингать — это неинтересно.
Тем более, что за тот же Nexus создавали на существующей базе с проверенными наработками
Так и SDN не такая уж новая идея. Я уже писал — все это уже проходили. Только в пределах одного коммутатора. Ведь у любого коммутатора control plane сильно изолирован от forwarding plane.
О, кстати, а получается контроллер будет знать какой клиент с кем соединяется, значит проще следить за пользователями?
Он будет отслеживать поток, а не пользователя. Из потока можно получить данные пользователя, но это очень затратная по CPU технология. Хотя никто не мешает периферийному коммутатору как-то тэгировать каждый поток и различать их на этом основании.
а получается контроллер будет знать какой клиент с кем соединяется, значит проще следить за пользователями?
Умоляю… Netflow давно уже поддерживается всем железом. Он сбрасывает на коллектор информацию L3-L4 (т.е. с какого адреса на какой шел поток, по каким портам, плюс сколько данных было передано и так далее). Выше L4 есть операторского класса решения DPI. И то, и другое есть практически у всех провайдеров. SDN ничего нового с этой точки зрения не привнесет.
Так что ваш провайдер прямо сейчас имеет как минимум детальную статистику по всем сетевым соединениям с вашего адреса. А может, и на уровне HTTP анализирует.
Это все и так известно, самому провайдеру эта информация не более чем статистика, а вот определенному кругу лиц она точно была бы интересна.
Тут смысл в том, что эта статистика в глобальных масштабах (теоретически) станет доступна кому то одному, причем сразу вся и о всех соединениях. Конечно, для анализа нужно будет недурственый инструмент разработать, что не отменяет коварного плана и замысла все централизовать у предполагаемого (надеюсь, вымышленного) узурпатора власти на Земле.
Тут смысл в том, что эта статистика в глобальных масштабах (теоретически) станет доступна кому то одному, причем сразу вся и о всех соединениях. Конечно, для анализа нужно будет недурственый инструмент разработать, что не отменяет коварного плана и замысла все централизовать у предполагаемого (надеюсь, вымышленного) узурпатора власти на Земле.
самому провайдеру эта информация не более чем статистика, а вот определенному кругу лиц она точно была бы интересна.
Спецслужбы имеют доступ к статистике провайдера.
эта статистика в глобальных масштабах (теоретически) станет доступна кому то одному
Что за глупость? Вы понимаете, что глобальная маршрутизация по определению децентрализована?
что не отменяет коварного плана и замысла все централизовать у предполагаемого (надеюсь, вымышленного) узурпатора власти на Земле.
Паранойя? Сочувствую…
Вы понимаете, что глобальная маршрутизация по определению децентрализована?
Спасибо, с текущим состоянием дел я знаком.
Вы утверждаете это по отношению к SDN (на глобальном уровне контроллеры будет децентрализованы)?
про спецслужбы и паранойю я предпочту промолчать, ибо это оффтопик.
Вы утверждаете это по отношению к SDN (на глобальном уровне контроллеры будет децентрализованы)?
Конечно. SDN не сможет осилить глобальную маршрутизацию — когда через одну магистральную железку могут проходить сотни гигабит / терабиты мелких потоков, а таких железок много. Подобная железка не может ориентироваться на L4 потоки — и никаких ресурсов не хватит, и бессмысленно это. Классический destination-based routing и сейчас решает, и в обозримом будущем будет решать. Не будет там никакого SDN. Я вообще не вижу применений данной концепции для операторов связи в случае построения магистралей. Ладно еще ЦОД…
про спецслужбы и паранойю я предпочту промолчать, ибо это оффтопик.
А вроде нет. Вам же явно мнятся заговоры — все мечтают посниффить ваш трафик :)
Рад, что я не один так думаю про SDN!
Пакетная обработка данных при увеличении скорости потоков ведет к увелечению шины и\или частоты данных, которую надо обрабатывать, например если в 10GE всего 64 бит\156.25Mhz (характеристики XGMII), то для 100GE уже частота в два раза выше, и шина уже 320 бит… а обеспечить ровные задержки в распространении по столь широкой шине в кремнии — уже задача не тривиальная, даже если использовать специальный САПР. А 8-48 шин таких как разложить? техпроцесс уже нужен тоже соответствующий. В общем, я тоже склоняюсь, что в ближайшее время классические решения будут доминировать.
Про ЦОД не могу сказать, там уже давно поселился Infiniband, стоящий особняком.
а на трафик уже давно всем пофиг… кому надо тот уже все пароли знает)))
Пакетная обработка данных при увеличении скорости потоков ведет к увелечению шины и\или частоты данных, которую надо обрабатывать, например если в 10GE всего 64 бит\156.25Mhz (характеристики XGMII), то для 100GE уже частота в два раза выше, и шина уже 320 бит… а обеспечить ровные задержки в распространении по столь широкой шине в кремнии — уже задача не тривиальная, даже если использовать специальный САПР. А 8-48 шин таких как разложить? техпроцесс уже нужен тоже соответствующий. В общем, я тоже склоняюсь, что в ближайшее время классические решения будут доминировать.
Про ЦОД не могу сказать, там уже давно поселился Infiniband, стоящий особняком.
а на трафик уже давно всем пофиг… кому надо тот уже все пароли знает)))
а обеспечить ровные задержки в распространении по столь широкой шине в кремнии — уже задача не тривиальная
Тем не менее, уже есть решения и под 40G, и под 100G. Обычно в виде модульных коммутаторов. L3 само собой. С весьма широким бекплейном. Но они редко используются. Чаще на одной железке собирается много-много 10G, а в оптику мультиплексируются DWDM.
Про ЦОД не могу сказать, там уже давно поселился Infiniband
Внутри блейдовых шасси — да, но вот сеть между ними строится на старом добром езернете, который с годами продолжает набирать популярность. И блейдами мир серверов вовсе не исчерпывается.
Только не путайте «ЦОД» и «суперкомпьютер», это — сильно разные вещи.
кому надо тот уже все пароли знает
Зачем нужны пароли хомячков тому, кто имеет прямой доступ к базам? :)
Копипаста отсюда
habrahabr.ru/post/149126/
habrahabr.ru/post/149126/
Вы меня чуть не убили — я чуть было не впал в бесконечный цикл.
Я имел ввиду отсюда
www.osp.ru/lan/2011/09/13010353/
www.osp.ru/lan/2011/09/13010353/
* в очередной раз ничё не понял
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Программно-конфигурируемые сети — как это работает?