Открыть список
Как стать автором
Обновить

Комментарии 28

Наши постоянные читатели наверняка догадались к чему мы клоним: все верно, открытые сетевые операционные системы типа Cumulus на коммутаторах без ОС имеют здесь существенные бонусы за счет выбора хардварной платформы (матрицы Broadcom) и гибкости на уровне построения программной части.

А какие конкретно броадкомовские чипы (и соответственно — какое именно из вашего оборудования) умеют делать VXLAN routing?
На текущий момент никакие: именно поэтому в младших Cisco (3064, например) его нет, а в старших оно реализуется дополнительным чипом, что ведет к соответствующему увеличению цены оборудования.

Хотите хардварного роутинга? Пожалуйста: intel fm6764. Подсказать, в каких коммутаторах оно есть?
а в старших оно реализуется дополнительным чипом, что ведет к соответствующему увеличению цены оборудования.

Но тот чип может много чего другого, что и не снилось merchant silicon :)
Кстати, нексус 5672 например вовсе не старшая модель, а среднячок. На нем заявлена полная аппаратная поддержка VXLAN, в отличие от :)
Хотите хардварного роутинга? Пожалуйста: intel fm6764.

То ли я дурак, то ли интел тщательно прячет информацию о том, что конкретно поддерживается в их фичах. Да, слово «VXLAN» вижу. Оно есть и в описании броадкомовских чипов. Пожалуй, это как писать «поддерживает 802.3». Ну поддерживает. А что позволяет с ним делать?
| Но тот чип может много чего другого, что и не снилось merchant silicon :)

Поэтому merchant silicon развивается и в следующем поколении будет поддерживать и это.
А пока нексус 5672 — это броадком + NPU, что выдает себя в увеличенной в два раза switching latency :)

| То ли я дурак, то ли интел тщательно прячет информацию о том, что конкретно поддерживается в их фичах.

Скорее, никто в подробностях не пишет возможности матриц в публичных документах.

| Ну поддерживает. А что позволяет с ним делать?

VXLAN routing позволяет в merchant silicon, вы же этого хотели?
А пока нексус 5672 — это броадком + NPU, что выдает себя в увеличенной в два раза switching latency

А зачем гадать, если информация о его содержимом открыто публикуется? :)
Нет там броадкома. Там собственный ASIC, названный Carmel. Умеет много чего вкусного. Да, задержка колоссальная, целая микросекунда. За сокращением этой цифры в несколько раз — к некоторым представителям 3к…
Скорее, никто в подробностях не пишет возможности матриц в публичных документах.

Офигеть. А вендор, выпускающий насквозь проприетарное железо только для собственного пользования, публично дает подробную информацию о его возможностях. Что-то в этом мире не так, если про внутренности BMS и опенсорса известно меньше, чем про проприетарщину…
VXLAN routing позволяет в merchant silicon

Но вы точно в этом уверены? Можно ли пруф о том, что оно держится как железом, так и софтом?
| Там собственный ASIC, названный Carmel.

Исходя из открытого содержимого — Carmel и есть NPU, стоящий перед hardware forwarding at 1.44 Tbps, который и есть… :D

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

Ой, вы таки не рассказывайте. Производители матриц — отдельная когорта товарищей. Те, кто делает на них устройства — всё рассказывают и показывают.

| Но вы точно в этом уверены?

Почитав документацию разработчика на API — таки да. Есть в ней соответствующие вызовы. Да и исходя из возможностей FlexPipe — можно добавлять даже то, чего не существовало на момент создания матрицы.
Исходя из открытого содержимого — Carmel и есть NPU, стоящий перед hardware forwarding at 1.44 Tbps

Ткните пальцем.
Архитектура например относительно неплохо разобрана тут.
Те, кто делает на них устройства — всё рассказывают и показывают.

Но это же BMS. Конечному пользователю в этом случае куда важнее иметь информацию о заложенных в железе возможностях, чем в случае проприетарщины.
Почитав документацию разработчика на API — таки да. Есть в ней соответствующие вызовы.

Очень круто. Но из данного хождения вокруг да около я делаю неизбежный вывод, что данный функционал на практике не реализован, т.е. поддержка VXLAN крайне ограниченная :)
Да и исходя из возможностей FlexPipe — можно добавлять даже то, чего не существовало на момент создания матрицы.

По сравнению с нативной поддержкой — it doesn't scale. Даже если вдруг каким-то чудом заработает. В чем никакой уверенности. И опять же, если это возможно — должны быть практические реализации за пределом искажающего реальность поля Powerpoint. Они есть? Видимо, нет, раз вы не можете их показать. Так чем такая поддержка отличается от отсутствия поддержки для конечного пользователя?
| Архитектура например относительно неплохо разобрана тут.

Судя по 34 и 37 слайдам — так оно и есть.

| Но это же BMS. Конечному пользователю в этом случае куда важнее иметь информацию о заложенных в железе возможностях, чем в случае проприетарщины.

Вот вам производитель свича и операционки все рассказывает! Что умеют, как умеют, зачем умеют. Совсем как Циска. Вам, почему-то, это не нравится.

| По сравнению с нативной поддержкой — it doesn't scale.

doesn't scale куда? Обработчик приблизили к процессору общего назначения, это же прекрасно.
Судя по 34 и 37 слайдам — так оно и есть.

То есть вы называете UPC творением броадкома? Правильно?
Вот вам производитель свича и операционки все рассказывает!

Рассказывает один конкретный человек. Которому запросто могли ранее не задавать таких вопросов, и который мог что-то понять неправильно. Или который, уж простите, может врать с целью впарить железо, а дальше пусть уже технари разбираются, да и вообще формат форума никого ни к чему не обязывает :)

Вот документации или хотя бы спецификациям доверия больше. Так что покажите мне, где написано, что если я возьму BMS железку X с ОС Y, то получу роутинг VXLAN. Прямо сейчас, а не затратив год на разработку софта.
Обработчик приблизили к процессору общего назначения, это же прекрасно.

Это — фантастика. Сейчас не существует хотя бы относительно универсальных NP, способных работать на типовых для свитча скоростях. Если напихать их много, то стоить такой свитч (даже с базовыми 48х10G и 4x40G) будет как авианосец. А простой матчинг по байтам по определенному смещению не канает.

Это все волшебный, искажающий реальность мир Powerpoint. Есть такой класс продуктов — «Slideware». Где можно почитать про то, как (с каким функционалом, с какой скоростью) оно работает на практике в реальном мире?

(если в вашем комментарии не будет ссылок, то я обижусь)
| То есть вы называете UPC творением броадкома? Правильно?

Про него Циска скромно умалчивает, а по спеке похож, ой похож.

| Рассказывает один конкретный человек.

Ну да, а документация на сайте производителя операционки выложена случайно. Чтобы никто-никто не ознакомился с возможностями.

| Так что покажите мне, где написано, что если я возьму BMS железку X с ОС Y, то получу роутинг VXLAN.

Подменять тему нехорошо. Сначала вы хотели узнать модели чипов, которые это умеют. Теперь сразу готовое изделие, где это реализовано.

| Это — фантастика.

Приблизили != сделали как универсальный процессор.
Вы постоянно пытаетесь сменить «это можно сделать на merchant silicon» на требование «а дайте мне уже сейчас».
Да, это программируемый парсер.

Кстати, скажите — в Arista 7150 роутинг vxlan есть?
Про него Циска скромно умалчивает

А как думаете, какой чип зовется Carmel?

Кстати, про линейку N9K открытым текстом говорили «это merchant+, тут броадком + наши чипы под те задачи, где броадком не канает»…
а документация на сайте производителя операционки выложена случайно.

Любопытный вендор — на любой вопрос отправляющий в гугл, даже если попытка загуглить обречена на провал :) И я укрепляюсь во мнении, что вы плохо представляете себе те материи, про которые говорите. Так что тем более я хочу увидеть конкретные ссылки.
Подменять тему нехорошо.

Но это не подмена темы, а взгляд сверху. Так можно или нельзя? Вот я как гипотетический клиент хочу видеть этот функционал. Я могу купить у вас железку, накатить определенный софт и получить этот функционал? Да или нет?
Да, это программируемый парсер.

Так покажите мне реализацию требуемого функционала на нем. Это сразу подскажет, возможно или нет.
Кстати, скажите — в Arista 7150 роутинг vxlan есть?

Поискал — не нашел. Терминировать VXLAN (представать в роли VTEP) вроде может. Свитчевать segment ID (то, о чем и идет речь)? Что-то я такого не вижу. Вероятно, не может.
| А как думаете, какой чип зовется Carmel?

Вы так любите BRKARC-сы, что стыдно не знать. 3452, 63 страница, чёрным по серому ;)
Сильномогучая Циска не осилила нормальную быструю матрицу, поэтому сочиняет костыли как умеет.

| Любопытный вендор — на любой вопрос отправляющий в гугл

Ой, вы таки опять подменяете. Сравнение шло — кровавая гэбня Циска против BMS. И те и те (производители матриц в вендоры BMS не входят) все рассказывают и показывают без стеснения.
Если же брать возможности матриц, то очевидно, что возможности железки раскрывает операционка. Железка может уметь много больше, чем софтина, но воспользоваться не выйдет. Поэтому спросите конкретику о возможностях связки BMS + NOS, вам ответят. Вопросы общего вида о возможностях матриц практического смысла не имеют.
Кстати, как мы уже выяснили выше, насквозь проприетарный вендор не дает подробностей о своем железе. Вот гады, а?

| Я могу купить у вас железку, накатить определенный софт и получить этот функционал? Да или нет?

VXLAN routing сейчас нет.

Но вы не переживайте, юникс динозавры тоже долго рассказывали про свою незаменимость. Так и померли :)))

| Так покажите мне реализацию требуемого функционала на нем. Это сразу подскажет, возможно или нет.

Документация на матрицу прилагается к набору для разработчика ;)
Вы так любите BRKARC-сы, что стыдно не знать. 3452, 63 страница, чёрным по серому

Ага, оно самое.
Сильномогучая Циска не осилила нормальную быструю матрицу

Для тех, кому важна разница между полмикросекунды и микросекундой, есть четверть микросекунды и ниже. Но давайте признаемся, что из читающих этот комментарий примерно никто не сталкивался с задачами, где эта разница в задержке будет видна…
Поэтому спросите конкретику о возможностях связки BMS + NOS, вам ответят.

Я же спрашивал.
насквозь проприетарный вендор не дает подробностей о своем железе.

Как это не дает?
VXLAN routing сейчас нет.

Так почему в топике не сказано, что ваше оборудование имеет лишь ограниченную поддержку VXLAN?
юникс динозавры тоже долго рассказывали про свою незаменимость. Так и померли

Ну не знаю… В моей весьма крупной конторе и в других весьма крупных конторах всё критическое работает именно на юниксах вроде той же солярки… Обычное дело для финансового сектора, где господствуют ущербные архитектуры ПО, требующие максимальной надежности работы каждого из узлов.
Документация на матрицу прилагается к набору для разработчика ;)

То есть, как я понимаю, ваше оборудование стоит на несколько десятков процентов ниже оборудования той же циски, потому что покупатель должен быть разработчиком и самостоятельно пилить под него софт?
| Я же спрашивал.

И на какой вопрос вы не получили ответа?

| Как это не дает?

Где признание, что везде стоит Броадком?
Наоборот, бессовестно выдают за своё поделие под названием UFC.

| Так почему в топике не сказано, что ваше оборудование имеет лишь ограниченную поддержку VXLAN?

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

| В моей весьма крупной конторе и в других весьма крупных конторах всё критическое работает именно на юниксах вроде той же солярки…

Рынок показывает, что юниксы умирают.

| То есть, как я понимаю, ваше оборудование стоит на несколько десятков процентов ниже оборудования той же циски, потому что покупатель должен быть разработчиком и самостоятельно пилить под него софт?

Вы опять подменяете. Мы пишем о том, что наше оборудование умеет с текущим софтом. Параллельно пишем про то, что не даст вам больше никто — мы можем дать инструменты для работы с железом.
Кстати, востребованная вещь ;)

Ну а теперь встречные вопросы:
1. Как решена проблема VXLAN routing на Циске?
Не общими словами «мы придумали модный ASIC», а в подробностях, учитывая суть проблемы роутинга протоколов с инкапсуляцией. Где, кто, как и куда?
Желательно со ссылкой на документы, а то будет обидно.

Вполне понятно, почему это не умеет Трайдент. Если это решено именно таким способом, как я предполагаю, то:
2. С какой латентностью это происходит?
3. Насколько актуален вопрос VXLAN routing как таковой?
4. Ну и наконец, почему merchant silicon умеет делать line-rate single-pass routing in the switch chips, а Циске приходится изобретать костыли в виде ASIC и выдавать это за инновации?
Где признание, что везде стоит Броадком?

А с чего им признаваться, если такого нет? 5672 может много такого, чего броадком не может. Навскидку: фексы, SPAN пакетов по превышению латентности или дропу, тот же VXLAN и так далее.

А на 9к признались. Смысл скрывать?
Полная работа с NSX и VXLAN поддерживается, VMware в курсе возможностей матриц и умело обоходится существующими возможностями.

Так это нормальная практика. Если в железе нельзя, но можно в софте уровнем повыше, то выбираем последнее, пока железо не научится.
Рынок показывает, что юниксы умирают.

Какой рынок?
Юниксы — нишевый продукт. И в обозримом будущем они никуда из этой ниши не уйдут. А то, что под линуксом больше вебсайтов, никакого отношения к этому не имеет.
Мы пишем о том, что наше оборудование умеет с текущим софтом. Параллельно пишем про то, что не даст вам больше никто — мы можем дать инструменты для работы с железом.
Кстати, востребованная вещь ;)

Как сказать. В прошлой теме я уже говорил, что свитч не сервер, от него не требуется безграничной кастомизируемости, от него требуется тупо гонять через себя трафик с определенными лукапами и реврайтами. Чем лучше он это делает из коробки и чем меньше требует вмешательства со стороны администратора, тем лучше.
1. Как решена проблема VXLAN routing на Циске?
Не общими словами «мы придумали модный ASIC», а в подробностях, учитывая суть проблемы роутинга протоколов с инкапсуляцией. Где, кто, как и куда?

Прежде чем начну искать: что конкретно вам непонятно в той весьма неплохой статье Пепельняка по поводу того, как должны происходить лукапы и реврайты и почему броадком так не может?
С какой латентностью это происходит?

Заявлено 1мкс со всеми фичами. В целом, можно поискать.
Насколько актуален вопрос VXLAN routing как таковой?

Отвечу вопросом на вопрос. Насколько актуален вопрос VXLAN как таковой? Я не знаком с людьми, которые его разворачивали бы :) Но в крупной сети маршрутизировать между сегментами было бы очень здорово.
почему merchant silicon умеет делать line-rate single-pass routing in the switch chips, а Циске приходится изобретать костыли в виде ASIC и выдавать это за инновации?

Вы сейчас про 9к? Я же уже много раз давал картинку. Если вкратце: броадкомовская логика не может достаточно глубоко видеть data plane трафик, не может так гибко манипулировать им (в отсутствие контроллера, который выполняет только management обязанности, чем радикально отличается от openflow). Т.е. для ACI merchant silicon не годится. Но разрабатывать свой SOC, покрывающий всё, дорого (особенно в такой рисковой сфере как SDN). Потому навесили пару чипов. Теряются сотни наносекунд? Почти все клиенты наклали на это. Несущественно. Куда интереснее знать точную суммарную задержку и джиттер отдельного потока от порта до порта, без поддержки на стороне клиента и сервера. Ну и вообще в ACI много чего другого теоретически вкусного и наверняка кому-то полезного (типичное описание чего угодно связанного с SDN).
Скрытый текст


Есть другой чип, который они очень активно пиарят (он весьма крут) — UADP. Разработка стоила вроде сотни миллионов долларов или около того.
| 5672 может много такого, чего броадком не может. Навскидку: фексы, SPAN пакетов по превышению латентности или дропу, тот же VXLAN и так далее.

Это реализовано на NPU.

| Юниксы — нишевый продукт. И в обозримом будущем они никуда из этой ниши не уйдут.

Ниша стремительно исчезает ;)

| Как сказать. В прошлой теме я уже говорил, что свитч не сервер, от него не требуется безграничной кастомизируемости

Вы не там смотрите, применение этой платформы не ограничено простым свичом ;)
Есть много задач, где нужна система с матрицей, но существующий софт не годится. У тех людей это и востребовано.

| что конкретно вам непонятно в той весьма неплохой статье Пепельняка по поводу того, как должны происходить лукапы и реврайты и почему броадком так не может?

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

| Вы сейчас про 9к?

Что вы, я же дал ссылку. Это про Аристу 7150, которая сделана на базе вульгарного merchant silicon Intel Alta (к вопросу о его парсере и программируемости).
Что возвращает нас к вопросу о выдаче костылей за инновации.
Это реализовано на NPU.

Ну да. А NPU — custom ASIC.
Ниша стремительно исчезает

Вам так кажется, потому что вы с ней не сталкиваетесь. Точно так же мне кажется, что ниша суперкомпьютеров стремительно исчезает, как и Big Data :)
Есть много задач, где нужна система с матрицей, но существующий софт не годится. У тех людей это и востребовано.

За рамками задач передачи пакетов с определенными реврайтами?
Есть вполне определенное подозрение о способе реализации

Вы про рециркуляцию наверное? Про такое всегда пишут. И по дефолту обычно не включают. Например, 6500 не способен без рециркуляции коммутировать из MPLS в GRE, и по умолчанию рециркуляция не производится (т.е. трафик блекхолится, очень мило).
Что вы, я же дал ссылку. Это про Аристу 7150

Нет, это про циску. Цитирую:
«а Циске приходится изобретать костыли в виде ASIC и выдавать это за инновации».
Вопрос — про какую циску? Вероятно, про 9000 как единственный на данный момент пример объединения разных чипов. Вот я и говорю, что custom asic там для много чего другого.

Что до аристы — там все вообще забавно. Например:
HW RESOURCE CONFLICT: IP NAT hardware resources are already in use for Vxlan.
Severity: Error
Explanation: The switch encountered resource conflict between IP NAT and Vxlan features. It will not be able to
support both Vxlan and IP NAT at the same time.
Recommended Action: To solve this issue, remove both IP NAT and Vxlan on the switch and reconfigure only IP
NAT. Please contact your technical support representative if you need additional assistance.

Две весьма базовые фичи нельзя задействовать одновременно на одной железке (даже на разных интерфейсах). Не расскажете, почему так?
| Вам так кажется, потому что вы с ней не сталкиваетесь.

Это отчеты о падении продаж не-x86 систем ;)

| За рамками задач передачи пакетов с определенными реврайтами?

Да. Дальше секретность и нам не говорят :)

| Нет, это про циску.

Вопрос состоял из утверждения (merchant silicon умеет делать line-rate single-pass routing in the switch chips) со ссылкой, а потом уже непосредственно про циску с изобретением NPU для этих задач.

И я не могу за аристу объяснять их проблемы.
Это отчеты о падении продаж не-x86 систем ;)

Да, они падают. Только системы на базе к примеру Power все равно продолжают продаваться. У них есть своя ниша. Небольшая в процентном соотношении.
Дальше секретность и нам не говорят

Так не интересно.
Вопрос состоял из утверждения (merchant silicon умеет делать line-rate single-pass routing in the switch chips) со ссылкой, а потом уже непосредственно про циску с изобретением NPU для этих задач.

Еще раз. VXLAN — мелочь. Кастомные асики под много чего другого задействованы.
И я не могу за аристу объяснять их проблемы.

А я могу. Фича реализована адскими костылями. И не удается совместить это с NAT'ом (и чем еще другим?) в одном TCAM'е. И именно поэтому я вместо ссылок на dev guide'ы просил информацию о практической имплементации. Интересно, сколько еще там ограничений? Каковы размеры таблиц?

Кстати, почему-то в официальной документации не нашел упоминаний… То, что об этом пишет какой-то реддитор, утверждающий, что она работает в аристе — это круто, но не совсем.
| У них есть своя ниша. Небольшая в процентном соотношении.

И естественный результат. Меньше ниша — выше себестоимость. Уменьшается ниша — растет себестоимость — дальше схлопывается ниша.

| Так не интересно.

Сами страдаем!

| Кастомные асики под много чего другого задействованы.

Не беда, merchant silicon тоже развивается — посмотрите XPliant и Tomahawk.

По аристе и ее проблемам все таки лучше писать в аристу.
Меньше ниша — выше себестоимость. Уменьшается ниша — растет себестоимость — дальше схлопывается ниша.

Не совсем. В абсолютных цифрах оно не сказать чтобы уж сильно падало.
Не беда, merchant silicon тоже развивается — посмотрите XPliant и Tomahawk.

Но при этом всегда на пару шагов отстает от кастомного железа :)
По аристе и ее проблемам все таки лучше писать в аристу.

Но вы же приводите это в качестве аргумента, доказывающего наличие данного функционала… А потом оказывается, что данный функционал как-то довольно коряво прикручен и много чему другому мешает.

Но то ариста, тоже проприетарщина. А под BMS на интеле кто-то это сделал?
| Не совсем. В абсолютных цифрах оно не сказать чтобы уж сильно падало.

Это почти в два раза за последние 9 лет не сильно?

| Но при этом всегда на пару шагов отстает от кастомного железа :)

Вы хотели сказать — от кастомных костылей? :)
Ничего, Cavium уже пообещал полную программируемость.

| Но вы же приводите это в качестве аргумента, доказывающего наличие данного функционала…

Функционал есть? Есть.
Хотеть от нас комментариев проблем в неактуальных релизах ОС от аристы некорректно.

| А под BMS на интеле кто-то это сделал?

Как вам уже совершенно честно сказали — нет.
Но в процессе.
Это почти в два раза за последние 9 лет не сильно?

Конечно не сильно. За это время линукс отхапал всякие вебсервера, HPC и т.д.
Вы хотели сказать — от кастомных костылей?

Так какие это костыли, если функционал изначально заложен в ASIC'е и как-то не мешает остальному функционалу?
Cavium уже пообещал полную программируемость.

Ну так обещать — не значит жениться. Кто знает, какие у него грабли будут?
Хотеть от нас комментариев проблем в неактуальных релизах ОС от аристы некорректно.

А в актуальных исправлено?
Как вам уже совершенно честно сказали — нет.

Может, вам известны причины, по которым открытый софт на открытом железе так тормозит в развитии в сравнении с проприетарщиной?
| Конечно не сильно. За это время линукс отхапал всякие вебсервера, HPC и т.д.

И все это увеличивает долю стоимости разработки в цене изделия. Ударное падение продаж как в штуках, так и в деньгах подтверждает тенденцию.

| если функционал изначально заложен в ASIC'е

Ой, вчера заглядывали представители компании, разрабатывающие как раз такие асики. Да и спека была до подозрения похожа :D

| Ну так обещать — не значит жениться. Кто знает, какие у него грабли будут?

Список багов Циски вспомните?

| Может, вам известны причины, по которым открытый софт на открытом железе так тормозит в развитии в сравнении с проприетарщиной?

Всё только начинается. Слишком мало кто занимается разработкой софта, производители матриц еще не готовы делать открытые решения. В матрицах часто куча недокументированных возможностей, причины разные — от нестабильной работы фичи до ограничений ОЕМ контрактов, они еще не готовы к смене парадигмы.
И все это увеличивает долю стоимости разработки в цене изделия.

Так и работает это изделие как правило на high-end серверах с 7-значными ценниками. Ну выше стоимость — и что? Клиент есть, он может себе это позволить. Все равно железо и ОС стоят ничтожных денег в сравнении с ПО, которое там крутится. И пара небольших сбоев приведут к более высоким потерям, чем стоили железо и ОС…
Ой, вчера заглядывали представители компании, разрабатывающие как раз такие асики. Да и спека была до подозрения похожа :D

Так объясните — какой вендору смысл заявлять «мы используем merchant и custom» по одной серии и при этом врать про неиспользование merchant другую? Вы допускаете, что циска действительно разрабатывает собственные чипы (вроде это все знали), просто на несколько лет опережает остальных? Ну например UADP, превращающий 802.11 в 802.3 (а они жутко разные) и обратно, на что похож?
Список багов Циски вспомните?

Ох, молчи грусть, молчи… Хотя у кого багов меньше? В смысле реально меньше, а не просто дырявое документирование.
производители матриц еще не готовы делать открытые решения. В матрицах часто куча недокументированных возможностей

А это проблема.
Покупая x86 сервер, я знаю, на что он способен. Есть общая производительность процессора, есть наличие расширений, есть память, накопители, опубликованные бенчмарки и т.д. А как выбирать матрицу? Что делать с модным у вендоров термином investment protection — вы например можете пообещать, что если я сейчас куплю интелевую матрицу, то через пару лет смогу роутить между segment ID, причем не потеряв другой функционал, а также заглядывать глубоко в data plane трафик и тому подобное?

Или, как я понимаю, брать матрицы надо исключительно ориентируясь на уже прикрученные к ним весьма скромные возможности и не заглядывая в будущее?
| Ну выше стоимость — и что? Клиент есть, он может себе это позволить.

Как показала практика — в какой-то момент дешевле перейти на X86, чем продолжать тянуть багаж. Именно так оно и происходит.

| при этом врать про неиспользование merchant другую?

Не врать, а не упоминать. Разница в нюансах.

| Вы допускаете, что циска действительно разрабатывает собственные чипы (вроде это все знали), просто на несколько лет опережает остальных?

Конечно допускаю, что разрабатывает. Несколько лет опережения нет и быть не может, причина проста как валенок — NPU фиксированное устройство, выполняющее только определенные функции. Невозможно сделать его настолько гибким, чтобы можно было добавлять новые протоколы после выхода. Как показывает текущая практика, поддержка новых протоколов/востребованных фич у всех появляется +- одинаково (если не брать собственные закрытые разработки).

| Хотя у кого багов меньше?

Все хороши, кто спорит?

| вы например можете пообещать, что если я сейчас куплю интелевую матрицу, то через пару лет смогу роутить между segment ID, причем не потеряв другой функционал, а также заглядывать глубоко в data plane трафик и тому подобное?

С Интелом — сможете. Программируемый парсер позволяет. Вопрос только в том, кто будет это программировать.

| Или, как я понимаю, брать матрицы надо исключительно ориентируясь на уже прикрученные к ним весьма скромные возможности и не заглядывая в будущее?

Так все сейчас делают. Да и выхода особо нет, ориентироваться можно только на то, что разработчик матрицы обещает. Обещает Кавиум программируемую матрицу — хорошо. Обещает фиксированную конфигурацию — живем с ней или придумываем NPU для заплаток.
Не врать, а не упоминать. Разница в нюансах.

То же самое.
Так зачем так делать в одном случае и не делать в другом, причем аж в рамках одного BU? Откуда берутся такие теории заговоров? Вам сложно принять, что проприетарные чипы, опережающие по возможностям merchant silicon, могут иметь маленькие и несущественные недостатки вроде задержки аж в микросекунду?
причина проста как валенок — NPU фиксированное устройство, выполняющее только определенные функции

А теперь смотрите. У циски новые протоколы обычно появляются на несколько лет раньше, чем у конкурентов, потому что циска не следует за индустрией и IETF, а IETF следует за циской и годы спустя стандартизирует протоколы, ранее являвшиеся проприетарными. Из последнего: стандарт TRILL никак не могут допилить? Плевать. Выпускаем свой Fabricpath. Cisco и Brocade первыми выпустили свои TRILL'образные решения, причем много лет назад. А стандарт вроде до сих пор не дописан?
(если не брать собственные закрытые разработки).

Надо их брать. Надо. Можно или плестись в хвосте, строго следуя RFC, или разрабатывать нечто свое. Ведущие сетевые вендоры разрабатывают свое (ну и в последнее время пишут informational RFC). Вспомните например, что до 802.1q был ISL, до LDP был TDP, до LACP был PAGP, до VRRP был HSRP и так далее. Есть задача от клиентов — вендор ее решает, не дожидаясь, пока IETF что-то стандартизирует. Спустя несколько лет то решение может стать стандартом в том же или похожем виде.
С Интелом — сможете. Программируемый парсер позволяет.

«NPU фиксированное устройство, выполняющее только определенные функции. Невозможно сделать его настолько гибким, чтобы можно было добавлять новые протоколы после выхода.»
Это не мои слова. Причем в NPU как раз обычно заложена гибкость в определенных пределах, в ущерб производительности и стоимости.

Вы точно гарантируете, что можно будет роутить VXLAN «at scale», не потеряв никакого другого функционала, не приобретя нерешаемых аппаратных проблем? И ведь механизм «ищем байты по такому-то смещению, находим в TCAM, по результату из TCAM подменяем те байты» будет работать лишь в очень-очень ограниченных случаях.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.