Комментарии 56
Вы пишите про отказ от L2 и STP, и, как я понимаю, это камень преткновения «нового мира», о котором повествует данный топик. А чем «новый мир» принципиально отличается от хорошо известной концепции local-vlan, когда vlan не выходит за границы аксесс-коммутатора и двух дистрибьюшен-коммутаторов? Т.е. при использовании loca-VLAN у вас STP только на краю сети, а ядро исключительно L3 с использованием OSPF/ISIS?
Второй момент — сейчас Cisco производит L3 аксесс коммутаторы 2960 XR, которые поддерживают IGP, т.е. они позволяют строить сети, где STP сужен до размера коммутатора, т.е. вся сеть, включая access получается маршрутизируемой без STP. Т.е. не понятно, чем отличается Leaf-Spine от обычной практики построения сетей на основе L3-коммутаторов.
Второй момент — сейчас Cisco производит L3 аксесс коммутаторы 2960 XR, которые поддерживают IGP, т.е. они позволяют строить сети, где STP сужен до размера коммутатора, т.е. вся сеть, включая access получается маршрутизируемой без STP. Т.е. не понятно, чем отличается Leaf-Spine от обычной практики построения сетей на основе L3-коммутаторов.
1) >Т.е. при использовании loca-VLAN у вас STP только на краю сети, а ядро исключительно L3 с использованием OSPF/ISIS?
абсолютно верно
2) Тут два подпункта. 2.1 — мы предлагаем помнить о существовании описанной выше архитектуры. Конечно же, она не уникальна, и та же Cisco регулярно о ней напоминает, но очередная волна напоминаний пошла примерно год назад, в том числе и по причине второго подпункта
2.2. — мы предлагаем строить сети на BMS (железках без ОС) и ставить на них сторонние ОС (а не проприетарные ОС производителей железа). Почему именно так? Это дает свободу в выборе железа и ОС (не понравилось — сменил вендора) и, в общем, сильно дешевле. 2960xr — хорошая серия, но для высоконагруженных фабрик 1G как-то мало, очень хорошо бы 10G.
абсолютно верно
2) Тут два подпункта. 2.1 — мы предлагаем помнить о существовании описанной выше архитектуры. Конечно же, она не уникальна, и та же Cisco регулярно о ней напоминает, но очередная волна напоминаний пошла примерно год назад, в том числе и по причине второго подпункта
2.2. — мы предлагаем строить сети на BMS (железках без ОС) и ставить на них сторонние ОС (а не проприетарные ОС производителей железа). Почему именно так? Это дает свободу в выборе железа и ОС (не понравилось — сменил вендора) и, в общем, сильно дешевле. 2960xr — хорошая серия, но для высоконагруженных фабрик 1G как-то мало, очень хорошо бы 10G.
Это дает свободу в выборе железа и ОС (не понравилось — сменил вендора) и, в общем, сильно дешевле
Лукавите.
1) ОС и железо требуют длительного тщательного тестирования на предмет дружбы друг с другом и с другими ОС/железом. Мало у кого будет подходящая лаба для такого тестирования.
2) Оркестраторы и мониторинг наверняка придется переделывать.
3) Сама по себе замена сетевой ОС в масштабах крупной сети — жутко сложное мероприятие. Заменить уже купленное железо еще сложнее.
4) А кто будет саппортить BMS? Вон у меня коллеги серверные админы периодически ругаются на то, что HP и VMWare норовят переводить стрелки друг на друга. В случае цискиного железа если выявлено аномальное поведение свитча, то вендор не отвертится.
Не нужна свобода. Нужно, чтобы «воткнул и поехали», желательно без перепиливания серверного софта (оно может выйти дороже, чем покупка насквозь проприетарного сетевого железа).
1) Давайте начнем с того, что железо у нас делится на
а) коммутационную матрицу и обслуживаемые ей порты
б) память-проц-накопитель-матплату-БП, компьютер, короче
А софт делится на собственно ОС и драйвер+приложения, управляющие работой матрицы.
Так вот, если речь идет о «тщательном тестировании» сочетания компьютера и железа, то тут мы имеем ядро Debian и стандартное железо. И вот тут вам будет очень сложно убедить нас, что у «больших парней» в лабораториях получается лучше, чем у debian-сообщества. Остается вторая часть: матрица+ее управление. На текущий момент список поддерживаемых матриц крайне невелик и пролезть в список поддерживаемого оборудования крайне непросто — слишком жесткие требования с обоих сторон.
2) про оркестраторы и мониторинг будет чуть позже :) если кратко — все зависит от того, чем вы пользуетесь, линуксовые версии подхватываются без проблем (напоминаю, с точки зрения ОС перед вами Debian)
3) в масштабах крупной сети, насколько нам известно, обычно руководствуются принципом «работает — не трогай». И замену организовывают либо необходимости ввести критически важное обновление, либо если требуется замена железа на более производительное. Где проще переезд — надо сравнивать. Но спору нет, частично заменить инфраструктуру будет сложно.
4) смотря что саппортить. Сдох вентилятор или глючит память? К производителю BMS-ки. Обнаружился баг в ОС? К писателям ОС.
Кстати, просто в качестве примера: тут вон недавно все бегали с shellshock'ом. Cumulus отбился апдейтом 30 сентября
support.cumulusnetworks.com/hc/en-us/articles/203776163-Security-Update-for-apt-and-bash-Packages-Shellshock-Fix
— Воткнул и поехали — это идеал. Когда он появится — у всевозможных сервисных отделов и служб технической поддержки станет радикально меньше дел. Но пока он недостижим и все по-прежнему упирается в баланс стоимости установки, обслуживания и рисков.
а) коммутационную матрицу и обслуживаемые ей порты
б) память-проц-накопитель-матплату-БП, компьютер, короче
А софт делится на собственно ОС и драйвер+приложения, управляющие работой матрицы.
Так вот, если речь идет о «тщательном тестировании» сочетания компьютера и железа, то тут мы имеем ядро Debian и стандартное железо. И вот тут вам будет очень сложно убедить нас, что у «больших парней» в лабораториях получается лучше, чем у debian-сообщества. Остается вторая часть: матрица+ее управление. На текущий момент список поддерживаемых матриц крайне невелик и пролезть в список поддерживаемого оборудования крайне непросто — слишком жесткие требования с обоих сторон.
2) про оркестраторы и мониторинг будет чуть позже :) если кратко — все зависит от того, чем вы пользуетесь, линуксовые версии подхватываются без проблем (напоминаю, с точки зрения ОС перед вами Debian)
3) в масштабах крупной сети, насколько нам известно, обычно руководствуются принципом «работает — не трогай». И замену организовывают либо необходимости ввести критически важное обновление, либо если требуется замена железа на более производительное. Где проще переезд — надо сравнивать. Но спору нет, частично заменить инфраструктуру будет сложно.
4) смотря что саппортить. Сдох вентилятор или глючит память? К производителю BMS-ки. Обнаружился баг в ОС? К писателям ОС.
Кстати, просто в качестве примера: тут вон недавно все бегали с shellshock'ом. Cumulus отбился апдейтом 30 сентября
support.cumulusnetworks.com/hc/en-us/articles/203776163-Security-Update-for-apt-and-bash-Packages-Shellshock-Fix
— Воткнул и поехали — это идеал. Когда он появится — у всевозможных сервисных отделов и служб технической поддержки станет радикально меньше дел. Но пока он недостижим и все по-прежнему упирается в баланс стоимости установки, обслуживания и рисков.
И вот тут вам будет очень сложно убедить нас, что у «больших парней» в лабораториях получается лучше, чем у debian-сообщества.
Тут можно холиварить на тему того, что лучше — результат работы группы парней с отлаженным процессом и серьезными бюджетами на разработку и тестировании, или «сообщества» («каждый сам за себя»).
На текущий момент список поддерживаемых матриц крайне невелик и пролезть в список поддерживаемого оборудования крайне непросто — слишком жесткие требования с обоих сторон.
Допустим, невелик. И?
Сдох вентилятор или глючит память? К производителю BMS-ки. Обнаружился баг в ОС? К писателям ОС.
Допустим, свитч перезагрузился. К кому вопрос?
Не будем холиварить, да. Хотя ваша уверенность в универсальности знаний «группы парней» (мы же говорим о написании общекомпьютерной части) несколько удивляет. Список известных ошибок в прошивках той же Cisco вызывает некоторые сомнения в профессионализме той самой группы парней и отлаженности их процесса. При этом со стороны пользователя все ваши возможности — стучаться в ТП.
Да он без всяких доступов очень невелик. Создателям ОС не приходится учитывать нюансы большого числа разнообразных матриц, код проще, точек для ошибок меньше.
Смотрим логи. Если ошибка аппаратная — идем к создателю BMS, программная — к техподдержке ОС.
Если в логах пустота — проверяется повторяемостью на аналогичном железе.
Допустим, невелик. И?
Да он без всяких доступов очень невелик. Создателям ОС не приходится учитывать нюансы большого числа разнообразных матриц, код проще, точек для ошибок меньше.
Допустим, свитч перезагрузился.
Смотрим логи. Если ошибка аппаратная — идем к создателю BMS, программная — к техподдержке ОС.
Если в логах пустота — проверяется повторяемостью на аналогичном железе.
Хотя ваша уверенность в универсальности знаний «группы парней»
Ну бесконечное число обезьян, конечно, рано или поздно напишет «войну и мир», вместе с исправленными версией, где Пьер Безухов обретает бессмертие и зверски отрезает Наполеону голову…
Список известных ошибок в прошивках той же Cisco вызывает некоторые сомнения в профессионализме той самой группы парней и отлаженности их процесса.
Зато честно публикуют. Хотя да, бывают интересные баги.
При этом со стороны пользователя все ваши возможности — стучаться в ТП.
И обычно довольно быстро получить фикс или воркараунд. Альтернатива — самостоятельно изучать код, разрабатывать патч, тестировать его вместе с остальным функционалом на тысячах кейсов (вдруг что-то еще сломалось?)…
Создателям ОС не приходится учитывать нюансы большого числа разнообразных матриц, код проще, точек для ошибок меньше.
А какое число матриц и на каком числе чипов разных вендоров поддерживается?
Смотрим логи.
В логах говорится, скажем, про какой-то exception и какой-то kernel panic.
Если в логах пустота — проверяется повторяемостью на аналогичном железе.
Ну-ну, удачи. Примерно 80% багов, с которыми я сталкиваются, не воспроизводятся у вендора. Из этих багов половина стабильно воспроизводится у меня (иногда только на одной железке, но на другой с почти такой же конфигурацией — нет).
Ну бесконечное число обезьян, конечно, рано или поздно напишет «войну и мир»
Не знаем, как там на тему бесконечного числа обезьян и художественной литературы, но в мире серверов x86+ открытые ОС мягко говоря более популярное решение, чем закрытые Unix'ы.
Альтернатива — самостоятельно изучать код, разрабатывать патч
Зачем? У вас есть производитель ОС, которому вы заплатили за поддержку и в его интересах максимально быстро сделать фикс, чтобы вы со своими деньгами не ушли к его конкуренту.
А какое число матриц и на каком числе чипов разных вендоров поддерживается?
Ну вот на примере Cumulus:
-четыре 1G модели, десять 10G моделей, четыре 4G моделей
-чипы Broadcom Firebolt2, Broadcom Triumph2, Broadcom Apollo2, Broadcom Trident, Broadcom Trident +, Broadcom Trident II
Итого 18 коммутаторов и 6 чипов.
у Pica8 — 12 моделей на 5 чипах.
Примерно 80% багов, с которыми я сталкиваются, не воспроизводятся у вендора
И какая в таком случае разница, BMS у вас или один вендор? В любом случае вы будете упираться в то, что для решения проблемы ее надо повторить и показать вендору. Если она вообще невоспроизводима на другом железе — идем к производителю железа и обоснованно ему говорим «эта железка не пашет, а другая пашет». Если проблема воспроизводится только в ваших условиях — в подавляющем большинстве случаев это вопрос софта.
но в мире серверов x86+ открытые ОС мягко говоря более популярное решение, чем закрытые Unix'ы.
И о чем это говорит? Может, о том, что в мире большинству серверов не требуется максимально возможная надежность? :) Из того, что я вижу вокруг себя: критические вещи обычно работают на Solaris/AIX…
Зачем? У вас есть производитель ОС, которому вы заплатили за поддержку и в его интересах максимально быстро сделать фикс, чтобы вы со своими деньгами не ушли к его конкуренту.
А чем это отличается от «со стороны пользователя все ваши возможности — стучаться в ТП»?
Итого 18 коммутаторов и 6 чипов.
Это одновременно и очень мало, и очень много. Мало с точки зрения разнообразия для конечного пользователя, много с точки зрения качественной поддержки вендором.
В любом случае вы будете упираться в то, что для решения проблемы ее надо повторить и показать вендору.
Прямо сейчас у меня есть кейс, по которому у меня проблема воспроизводилась четко, у вендора не воспроизвелась, но вендор сделал патч… Эвона как бывает!
Если она вообще невоспроизводима на другом железе — идем к производителю железа и обоснованно ему говорим «эта железка не пашет, а другая пашет».
Софтовый вендор скажет «проблема в железе».
Железный вендор говорит «ничего не знаю, видимо, есть какие-то программные различия во взаимодействии с соседями» (тоже может быть правдой).
Я же говорю, мои коллеги постоянно через это проходят. HP вообще как-то раз пытался убедить их, что свитчи виноваты в одновременном дергании двух линков блейд-сервера к двум физически и логически независимым корзинным свитчам. Когда коллеги сами объяснили ему, что он не прав — он начал переводить стрелки на VMWare. Те показывают пальцем обратно на HP. И вот хрен поймешь, почему сервер потерял связь с миром примерно на две минуты, и никто из вендоров не хочет этим всерьез заниматься… Вы, как я понимаю, гарантируете, что такого бардака не будет? :)
критические вещи обычно работают на Solaris/AIX…
Да ради бога. Мир состоит не только из критических вещей.
Вот, навскидку, статистика по итогам 2013:
— Linux server demand continued to be positively impacted by cloud infrastructure deployments, as hardware revenue increased 14.4% year over year to $4.1 billion in 4Q13. Linux servers now represent 28.5% of all server revenue, up 4.6 points when compared with the fourth quarter of 2012.
— Microsoft Windows server hardware revenue increased 0.1% year over year in 4Q13 with quarterly server hardware revenue totaling $6.5 billion, representing 45.7% of overall quarterly factory revenue, up 2.0 points over the prior year's quarter.
— Unix servers experienced a revenue decline of -20.2% year over year to $1.9 billion representing 13.6% of quarterly server revenue for the quarter.
— After four consecutive quarters of revenue growth, IBM's System z mainframe running z/OS revenue declined -36.8% year over year to $1.1 billion, representing 8.0% of all server revenue in 4Q13
А чем это отличается от «со стороны пользователя все ваши возможности — стучаться в ТП»?
Если стук безрезультативен — меняем поставщика ОС. Это дешевле, чем менять поставщика железа.
Прямо сейчас у меня есть кейс, по которому у меня проблема воспроизводилась четко, у вендора не воспроизвелась, но вендор сделал патч… Эвона как бывает!
ВАУ! А можете раскрыть тему? А то у нас техсаппорт прям запрыгал от идеи того, что можно запатчить невоспроизводимую проблему.
Не, серьезно: если это не корпоративный секрет — опишите?
Вы, как я понимаю, гарантируете, что такого бардака не будет? :)
Мы не боги :) Но как производитель серверов мы крайне регулярно участвуем в подобных разборках. Обычно локализовать проблему на уровне виновного (железо, драйвер, софт) удается довольно быстро.
У вас, кстати, получился несколько неудачный пример: вы продемонстрировали работу техподдержки HP, который вполне себе большой вендор с проприетарным железом.
Ну да не в этом дело. Бардак будет всегда. Вопрос в его размерах и скорости ликвидации. Пока особых нареканий на поставщиков ОС не видно.
Вот, навскидку, статистика по итогам 2013:
Объясните: как считается продажа серверов под Linux? Я не понимаю.
Но допустим, цифры верны. Это говорит о том, что в мире огромное количество не слишком критичных серверов. В идеальном мире, конечно, любой сервис должен глазом не моргнув пережить падение любого из образующих его серверов, но так бывает не всегда.
А с сетью сложнее, там надобно, чтобы железо работало максимально надежно. Падение свитча уровня доступа — неприятность (если нет L2 между ним и соседом, или подключенная к нему система не имеет резервирования, что тоже не редкость — большая неприятность). Неполная деградация data plane у такого свитча — серьезных размеров жопа, так как может не быть триггером к фейловеру.
А вообще, даже цискины IOS-XE и NX-OS уже переехали на ядро Linux. Только оно там серьезно доработанное, эти ОС частично являются real-time ОС. И ведь все равно временами падают…
Если стук безрезультативен — меняем поставщика ОС. Это дешевле, чем менять поставщика железа.
В идеальном мире. А в реальном будет либо шило на мыло, либо потеря функционала, либо разного рода несовместимости. Interop-тестирование доставит много головной боли. Даже несмотря на то, что RFC вроде бы одни и те же…
А можете раскрыть тему?
Обычный, скучный четверг. Обновление маршрутизатора ASR1k до новой версии софта. После загрузки через несколько минут падение. Откат до старой версии. Core dump направлен в TAC. Те по нему выяснили, что проблема в подсистеме h.323. По h.323 с той железкой только сервер Avaya общался, и то исключительно кипалайвами. Сказали «ща соберем ES образ, накати, проверь, продолжит ли падать, а то мы не на 100% уверены в работоспособности и потому не можем сходу включить фикс в следующий релиз». На предложение самим проверить, так как нет у меня желания устраивать тестовую среду из продуктивной, согласились, и я передал им дамп пакетов типичного обмена с той системой. Где-то сейчас собирают или уже гоняют лабу. Самого авайского сервера у них, конечно, нет.
Вот как-то так. Платформа падает, но перед смертью сбрасывает на диск сотни мегабайт информации (память, содержание процессорных регистров и т.д.), и по этой информации как правило удается локализовать и победить баг даже без repro. Было уже несколько раз.
Если, конечно, упала не ES версия — от нее build файлы временами могут теряться, и тогда дампы бесполезны.
вы продемонстрировали работу техподдержки HP, который вполне себе большой вендор с проприетарным железом.
Ну извиняйте. Я, конечно, краем уха слышал о том, что Ричард Столлман работает на ноутбуке с 100% опенсорсным железом, но вживую таких чудес не видел. Серверов — тем более.
Пока особых нареканий на поставщиков ОС не видно.
Ну а что еще может сказать вендор железа, продажи которого непосредственным образом зависят от качества работы других вендоров? :)
Объясните: как считается продажа серверов под Linux? Я не понимаю.
www.idc.com/tracker/showproductinfo.jsp?prod_id=7
А в реальном будет либо шило на мыло
В реальном бывает все: например, факапы у гигантов класса google или проблемы с поддержкой со стороны больших вендоров (там есть свои, вполне очевидные нюансы: там, где небольшой производитель будет ценить даже небольшого клиента, большой и неповоротливый гигант может просто отмахнуться, погонять по этапам бюрократии, отложить в долгий ящик). Но да, выбор поставщиков ОС пока не очень богатый, но мы надеемся на развитие событий.
Обычный, скучный четверг...
ага, спасибо
Ну а что еще может сказать вендор железа, продажи которого непосредственным образом зависят от качества работы других вендоров? :)
Ну вы же догадываетесь, что если мы не хотим вылететь с рынка, то качество работы других вендоров мы оцениваем весьма тщательно? :)
Впрочем, подавляющее большинство «железных вендоров» зависят от качества других — крайне сложно полностью жить исключительно на своем железе, слишком многое приходится производить. Вопрос в степени зависимости от остальных и уровне входного контроля.
2.1 Cisco об этом не просто упоминает, а это стандартный дизайн всех современных сетей, де-юре и де-факто. Если Вы строите сеть на Cisco у Вас собственно только два возможных варианта — Local-Vlan или L3 на аксессе, end-to-end vlan должны избегаться. Как на это смотрят другие вендоры я не знаю, возможно для кого-то сети без STP — действительно откровение.
сейчас Cisco производит L3 аксесс коммутаторы 2960 XR
Даже сама Cisco не понимает, зачем они выпустили эту серию — стоящую почти как куда более совершенные 3650. Которые, кстати, тоже вовсе не для ЦОДов создавались.
Как я понимаю политику Cisco, теперь все коммутаторы должны быть L3, потому что традиционно 2960 всегда был аксесс коммутатором L2. Т.е. выпуском данной серии вроде бы как приканчивается L2 на аксессе, по крайней мере в ближайшей перспективе. При этом Cisco не кричат о новом мире, для них это всё та же иерархическая модель, и про полностью L3-ethernet без STP рассказывается ещё в учебниках примерно 10-летней давности. Т.е. пост чистой воды маркейтинговый, технологически ничего нового.
теперь все коммутаторы должны быть L3, потому что традиционно 2960 всегда был аксесс коммутатором L2
Нет, серьезно — циска реально не понимает, зачем выпустили XR модификацию. По моей информации, партнерам рекомендовано не слишком активно впаривать их. И подобные ошибки у них не так уж редки в последнее время — см. Nexus 6001 например. Чем он так отличается от 5к, что его надо выносить в отдельную группу? Да вообще ничем, это то же самое железо.
Остальные 2960 тоже умеют маршрутизировать (только в очень ограниченном виде — ЕМНИП, только статика и всего 16 маршрутов). Вероятно, сейчас сделать L3-aware L2 ASIC ничуть не дешевле, чем просто нативный L3 с микроскопическим TCAM. Кто-то догадался разрешить задействовать L3 функционал. Потом кто-то другой предложил чуть добавить TCAM'ов и control plane фич (IGP) и выпустить полноценный L3 свитч. Продавать его за копейки нельзя — он повредит продажам 3ХХХ. Остается продавать практически как 3ХХХ, но те ведь намного совершеннее (3650 и 3850 действительно прекрасны, их, пожалуй, можно назвать объективно лучшими компактными гигабитными свитчами на рынке), лучше немного доплатить и брать их…
2960 ни в каком виде не является датацентровым коммутатором. Он в основном предназначен для топологий маленького офиса — один роутер, один свитч, может — один сервер. Там от свитча не требуется терминировать L3.
Ну и про полный отказ от L2 — помните, что, например, у серверов бывает четное число линков, которые неплохо бы подключить в резервированном режиме к разным свитчам, причем попав в один VLAN, иначе фейловера по щелчку пальцев не будет. Да и вообще, если говорим про кампусную сеть и характерные для нее объемы трафика, то ничего особо страшного в блокировании STP половины транков нет, и даже переподписка 1:100 и выше может не означать высокую нагрузку на аплинки. Правда, остаются периодически возникающие по любым причинам кольца, но в кампусной сети не те требования к доступности.
пост чистой воды маркейтинговый, технологически ничего нового.
Не только «нет ничего нового», но и «есть много чего устаревшего».
Вряд ли кто-то будет оспаривать удобность того, что можно купить сервер одного производителя, поставить на него ОС другого, и дополнить ее программным обеспечением третьего.
Ну что тут можно сказать про эту нелепую аналогию…
Приложение — это самое важное что есть в сети. Сеть работает для того, чтобы работало Приложение. С точки зрения Приложения, Сеть — это такой патч-корд. Чем он примитивнее, тем лучше (нечему ломаться), но в реальном мире и при серьезных масштабах делать сеть безмозглой нельзя — она рухнет под собственным весом. Потому от control plane Сети нужны Фичи, позволяющие Сети разрастаться вширь и вверх и при этом не тормозить работу Приложения.
Т.е. неважно, на каком ПО работает этот навороченный патч-корд. Важно, как именно он работает (чем незаметнее, тем лучше). В случае Приложения ситуация совершенно иная — оно бывает очень разным в зависимости от задач. И оно должно работать, грубо говоря, на любом железе. Именно ради Приложения и закупается гора серверного и сетевого железа, именно оно приносит деньги.
От Сети требуется железобетонная стабильность и возможность подстроиться под работу Приложения (в определенных пределах). Ваше оборудование не предлагает ни того, ни другого.
1) Стабильность. «Традиционные» вендоры тщательно тестируют работу каждой новой версии софта с небольшим перечнем их железа. И оно все равно может глючить. Будете говорить, что Cumulus Linux компилируется с использованием волшебного порошка и потому безбажнее NX-OS/JunOS? А еще большинство компаний не являются Гуглом и не могут писать и тестировать собственный софт под свое сетевое оборудование. Даже Яндекс не может.
2) У вас нет фич. Вы предлагаете одну-единственную архитектуру, и Приложение должно подстроиться под нее. Где-то это будет работать, но обычно — нет. Как я понимаю, вас интересуют в качестве клиентов лишь компании вроде того же Яндекса, где Приложение пишется самостоятельно и потому может адаптироваться. Но Яндекс вон активно (совместно с той же циской) пилит Segment Routing — чем не Фича?
Что при этом категорически не устраивает в традиционной схеме?
-Резкое снижение производительности при отказе на уровне агрегации;
-Недостаточная масштабируемость, вызываемая уровнем агрегации:
MAC / ARP
VLAN'ы
перегруженность точек обмена горизонтальным трафиком;
-резкое возрастание сложности структуры при увеличении надежности;
-Множество проприетарных вариантов используемых протоколов (MLAG, vPC, варианты STP, UDLD, Bridge Assurance, LACP, FHRP, VRRP, HSRP, GLBP, VTP, MVRP...)
По порядку:
— TRILL к примеру. Вот маршрутизация на L2, не накладывающая дополнительных требований на Приложение (помните, кто в сети главный?)
— Тот же TRILL. А еще ACI прикольный. Он к примеру может передавать пакеты, напрочь игнорируя L2 информацию и не распространяя ARP'ы и другой широковещательный трафик. Концепции VLAN'а, конечно, тоже нет. Но Приложение думает, что есть.
— Тут роутинг, там роутинг.
— Опять вы почему-то забыли упомянуть TRILL… А еще половина указанных протоколов является открытыми стандартами (глядя на перечисление, появляется ощущение, что вы про них вообще ничего не знаете, особенно «FHRP, VRRP, HSRP, GLBP», где первый обозначает не протокол, а класс протоколов, а UDLD например вообще сидит ниже и отвечает за физический уровень).
Ох.
1) Стабильность.
Удовлетворите наше любопытство: вы смотрели, сколько сейчас существует в мире BMS, поддерживаемых Cumulus или Pica8? Полюбопытствуйте — список весьма невелик, а уж с точки зрения матриц — тем более. Развернутый ответ чуть выше.
Кстати о писании собственного софта. Мы тут завтра (уже сегодня) будем предлагать готовый набор разработчика. Не хотите попробовать? Поверьте, вы будете в этом деле не первым.
2) Отдельный выбор ОС и железа — фича.
Цена — фича.
Использование приложений на коммутаторе — фича.
Архитектуру мы предлагали исключительно в рамках этой статьи. Вы же не считаете, надеемся, что из BMS и ОС для них наглухо выдран весь L2?
— Кратко: да, TRILL — тоже вариант. И под него мы, например, готовы предложить Intel ONS. Насколько нам известно, та же Pica8 вполне подумывает о вводе поддержки TRILL.
1) Стабильность.
Удовлетворите наше любопытство: вы смотрели, сколько сейчас существует в мире BMS, поддерживаемых Cumulus или Pica8? Полюбопытствуйте — список весьма невелик, а уж с точки зрения матриц — тем более. Развернутый ответ чуть выше.
Кстати о писании собственного софта. Мы тут завтра (уже сегодня) будем предлагать готовый набор разработчика. Не хотите попробовать? Поверьте, вы будете в этом деле не первым.
2) Отдельный выбор ОС и железа — фича.
Цена — фича.
Использование приложений на коммутаторе — фича.
Архитектуру мы предлагали исключительно в рамках этой статьи. Вы же не считаете, надеемся, что из BMS и ОС для них наглухо выдран весь L2?
— Кратко: да, TRILL — тоже вариант. И под него мы, например, готовы предложить Intel ONS. Насколько нам известно, та же Pica8 вполне подумывает о вводе поддержки TRILL.
список весьма невелик
Так опять же, кто-то всерьез занимается тестированием?
Не хотите попробовать?
Как-то нет у меня желания быть бетатестером…
Отдельный выбор ОС и железа — фича.
Цена — фича.
Использование приложений на коммутаторе — фича.
Из этих трех пунктов только третий является фичей (но с поправкой на то, что у свитча список data plane фич ограничивается весьма малыми возможностями merchant silicon, т.е. по факту ничего особо вкусного на вашем железе не будет никогда).
Вы же не считаете, надеемся, что из BMS и ОС для них наглухо выдран весь L2?
Ну судя по тому, как вы пиарите L3, по части L2 фич ваше оборудование актуально на момент начала века…
Merchant silicon — да. Но мы вроде как и не замахиваемся на сверхуникальные решения с ценами реактивных самолетов. Но ведь не только ими живет вендор, у вендора хватает устройств на том же merchant silicon. И вот здесь мы предлагаем задуматься, а нужно ли оно, по такой цене. Именно поэтому мы и называем цену фичой — одним строго необходим набор определенных вкусностей в проекте, а другим нужен базовый функционал с хорошей производительностью по невысокой цене.
По части L2 — ну Trident же.
По части L2 — ну Trident же.
У них там в какой-то статье до этого TRILL был назван «костылем». После этого дальше можно не читать, так как объективность вещающего падает до нуля.
Сама по себе идея BMS хороша. Но в большинстве случаев выхлопа не будет, так как весь этот BMS требует внимания куда как больше…
Сама по себе идея BMS хороша. Но в большинстве случаев выхлопа не будет, так как весь этот BMS требует внимания куда как больше…
После этого дальше можно не читать, так как объективность вещающего падает до нуля.
Так это же вендор. Какая еще объективность?
Сама по себе идея BMS хороша.
Я не уверен, что лучше — возможность полностью заменить софт на сетевом оборудовании, или наличие родного вендорского софта, но с многочисленными разноуровневыми API. Склоняюсь к последнему. Если вы не гугл, то первое означает либо неиспользование преимуществ BMS (хоть так, хоть эдак будете сидеть на родном софте, причем наверняка написанном «для галочки»), либо массу увлекательнейших приключений при диагностике сетевых глюков.
Ну и кстати железо на merchant silicon вседа отстает по фичам от проприетарной логики.
Вообще, тут можно привести аналогию с айфонами. Большинство пользователей вообще не понимает, что там какая-то «ОС» работает. Есть айфон, есть самсунг — всё. Звонить позволяет, фейсбук показывает, другого не надо.
Иногда никакие API не помогут. Ну вот не написал вендор фичу и привет. А вам надо, причем очень. Вот тут BMS может и пригодится. А может и нет.
Так что само наличие подобных продуктов на рынке я приветствую. Буду ли использовать сам — скорее всего нет.
Ну и кто знает, может кто-то на этих BMS сделает то, что в свое время сделал Торвальдс со своим линуксом. Кооперативная модель всегда побеждает конкурентную. Вопрос в том, будут ли силы и желание в этой кооперации.
Так что само наличие подобных продуктов на рынке я приветствую. Буду ли использовать сам — скорее всего нет.
Ну и кто знает, может кто-то на этих BMS сделает то, что в свое время сделал Торвальдс со своим линуксом. Кооперативная модель всегда побеждает конкурентную. Вопрос в том, будут ли силы и желание в этой кооперации.
Иногда никакие API не помогут. Ну вот не написал вендор фичу и привет.
Если мы говорим о сетевом оборудовании, то проблема скорее в аппаратной поддержке фичи со стороны ASIC'ов. Вот например не может Trident 2 делать VXLAN routing, хоть ты тресни. И не могут никакие свитчи кроме цискиных (тех, что на базе UADP — 3650, 3850, 4500/Sup8) терминировать data plane CAPWAP трафик с точек доступа.
Но иногда вендоры могут из маркетинговых соображений вести себя некрасиво. Например, текущее поколение Cat6500 поддерживает Fabricpath с точки зрения железа. А поддержка в софте будет вряд ли.
И все-таки не верю я в стабильную и одновременно функциональную реализацию BMS в рамках сети (хотя как ultra-low-cost с очень базовыми возможностями может и сработать). Посмотрим, что будет дальше.
А щас асики все более и более универсальные и запрограммировать их можно на много чего. В mpls это уже давно. В ЦОДах, учитывая опенгной и и2рс, через пару лет. Так что 90% фич будет делаться софтом без замены аппаратной платформы.
В mpls это уже давно.
Вот тоже интересный пример. Помнится, Trident 2 может видеть IP заголовок только через 4 метки, не более того. А видеть IP заголовок полезно для ECMP.
Что до openflow — так и он ведь просто дает более прямое доступ к возможностям железа. Магии не произойдет — если железо не умеет преобразовывать 802.11 в 802.3, то никакой SDN тут не поможет. Ну разве что что-нибудь отправляющее пакеты на обработку стороннему узлу (DPSS?), но вот это уж точно костыль.
Вот например документ, на 8-й странице которого говорится, что не умеет и никогда не научится делать Trident 2.
А еще для ECMP полезно уметь fat pw. Которые любой разумный инженер сделает и без вендора и 4 меток ему хватит в 99% случаев.
Магия произойдет когда асики поумнеют.
Магия произойдет когда асики поумнеют.
Ну не могут асики уметь всё. FPGA могут, но их пришлось бы делать резиновыми, они бы сильно грелись, тормозили (трафика-то надо прокачать сотни гигабит в секунду как минимум) и стоили бы как авианосец. Как только асики освоят все имеющиеся сейчас протоколы и инкапсуляции — выйдут новые, первыми подтянутся софтовые реализации (вот тут действительно можно всё, были бы ресурсы), а последним — merchant silicon.
Все могут уметь «универсальные» процы по типу как в ASR.
В ASR1k аппаратных ограничений — мама не горюй. Он может многое, но далеко не всё (по сравнению со софтовой платформой).
А еще QFP жутко тормозной по сравнению с установленными в свитчах ASIC'ами. Десятки гигабит на чип, не сотни и тем более не терабиты.
А еще QFP жутко тормозной по сравнению с установленными в свитчах ASIC'ами. Десятки гигабит на чип, не сотни и тем более не терабиты.
Я имел ввиду 9к, у 1к кмк внутри совсем не то.
А… Ну так Тайфун внутри современных 9k тоже весьма ограниченный по возможностям.
Вот платформы на базе QFP в общем и целом неплохо косят под софтверные роутеры. Возможности огромны.
Вот платформы на базе QFP в общем и целом неплохо косят под софтверные роутеры. Возможности огромны.
И чем же там ограничены около 140 практически универсальных цпу?
Путаете с ASR1k, у которого QFP состоит из кучи маленьких PPE, каждое из которых — многопоточное RISC ядро.
И даже несмотря на это, у него полно именно аппаратных ограничений. На которые всегда напарываешься внезапно, ожидая, что вон та комбинация фич не может не заработать.
А Trident и Typhoon — вполне обыкновенные ASIC'и.
И даже несмотря на это, у него полно именно аппаратных ограничений. На которые всегда напарываешься внезапно, ожидая, что вон та комбинация фич не может не заработать.
А Trident и Typhoon — вполне обыкновенные ASIC'и.
QFP есть и в asr9k. И дело не в том кто и чем там ограничен. А в том что по фичам это в разы гибче и быстрее железок класса 7600.
QFP есть и в asr9k.
В виде отдельного SIP. Так неинтересно. 7600 тоже прибавляет в фичах при добавлении SIP.
по фичам это в разы гибче и быстрее железок класса 7600
Старенький PFC3b (которых в 7600 можно насовать по числу линейных карт) дает 400mpps. Крутейший ESP200 под ASR1k с четырьмя чипами QFP дает 130mpps. Гибче — да, но не быстрее. И намного дороже.
Зачем вы все время тащите сюда аср1к? Сравните возможности NP в 7600 в ее расцвете и в аср9к. Во времена 7600 такого понятия как NP можно сказать и не было.
Зачем вы все время тащите сюда аср1к?
Потому что именно он построен на QFP, а для других платформ QFP — чужеродный элемент.
Сравните возможности NP в 7600 в ее расцвете и в аср9к.
Между PFC4 и Typhoon нет никакой пропасти в фичах, они во многом похожи по возможностям. Но любой из них сильно отстает от QFP.
ASR9K лидирует в основном в количественных характеристиках, а также в программных плюшках IOS-XR.
Зачем вы опять тащите qfp и pfc4 про которые я ничего не писал?
Нет пропасти в фичах — сравните bng тут и там.
Нет пропасти в фичах — сравните bng тут и там.
Зачем вы опять тащите qfp и pfc4 про которые я ничего не писал?
Вы писали и про QFP в качестве крутого NP, и про PFC3/PFC4 (говоря про 7600).
Нет пропасти в фичах — сравните bng тут и там
Это — лишь маркетинговое название для маленькой группы фич. Давайте я скажу «DMVPN/FlexVPN» (хардварно) или «VOIP» (медиатрафик обрабатывается хардварно, только установление вызовов тратит ресурсы RP), и 9K сразу сдуется :)
Тут можно посмотреть список других фич. Для ASR1k выберете к примеру софт 3.11.0 (по более новым список составлялся совсем халтурно).
Функционал ASR1k (и соответственно его QFP в роли форвардера, так как платформа аппаратная) покрывает очень существенный процент функционала программных ISR платформ. Особенно по части QoS, где распределенной платформе (9k) вообще нечего ловить по сравнению с централизованной.
Меня обманывает поиск или буквы QFP в этом треде впервые встречаются не в моем комментарии?
Вы сначала сравните, а потом рассуждайте где маркетинг, а где нет. На mpls форуме видимо продаваны презентациями меряются.
Для VPN нужна лишь инкапсуляция, чего asr9к умеет хардварно. Что вы хотите делать с воипом на такой железке я не очень понимаю. Транскодинг сильно далеко от области передачи пакетов. А sbc если нужен, то лучше воспользоваться специальными решениями, так как все равно 99% там в сигнализации, которую без разницы где разбирать.
Когда цыска выпустила asr9000 например trill был еще в зачатках. Но тем не менее платформа может быть под него запрограммирована. В 7600 такой фокус только заменой железа. Трудно отрицать очевидное.
Вы сначала сравните, а потом рассуждайте где маркетинг, а где нет. На mpls форуме видимо продаваны презентациями меряются.
Для VPN нужна лишь инкапсуляция, чего asr9к умеет хардварно. Что вы хотите делать с воипом на такой железке я не очень понимаю. Транскодинг сильно далеко от области передачи пакетов. А sbc если нужен, то лучше воспользоваться специальными решениями, так как все равно 99% там в сигнализации, которую без разницы где разбирать.
Когда цыска выпустила asr9000 например trill был еще в зачатках. Но тем не менее платформа может быть под него запрограммирована. В 7600 такой фокус только заменой железа. Трудно отрицать очевидное.
Меня обманывает поиск или буквы QFP в этом треде впервые встречаются не в моем комментарии?
В вашем. Вы начали говорить про QFP.
Вы сначала сравните, а потом рассуждайте где маркетинг, а где нет.
Еще раз: BNG — маркетинговое название для комбинации фич. Слово «маркетинговое» не подразумевает «несуществующее».
Для VPN нужна лишь инкапсуляция, чего asr9к умеет хардварно.
Инкапсуляции бывают разные. Чтобы ASIC поддерживал любую конкретную инкапсуляцию… Он должен ее поддерживать. В него должна быть заложена соответствующая аппаратная логика. А чтобы еще и шифровать трафик, железо должно быть обучено 3DES/AES.
А sbc если нужен, то лучше воспользоваться специальными решениями
Так ASR1k и есть такое специальное решение :) Транскодировать не умеет, но по CPS и одновременным вызовам он весьма конкурентоспособен. Софтсвитчи шустрее, но они не SBC.
Когда цыска выпустила asr9000 например trill был еще в зачатках. Но тем не менее платформа может быть под него запрограммирована. В 7600 такой фокус только заменой железа.
Текущее поколение 6500/7600 (и карт под них) с точки зрения железа поддерживает TRILL (инфа 100%). Были ни разу не технические причины (ссылкой не поделюсь, но так мне говорили непосредственно участвовавшие в разработке платформы люди), по которым этот функционал решили не внедрять на уровне софта.
Вы поймите — ASR9k лишь эволюция 6500/7600 в сторону сегмента SP. «Быстрее, выше, сильнее», это да, но он остается весьма ограниченной по фичам платформой. Впрочем, весьма эффективно работающей с теми задачами, под которые ее разрабатывали.
Я говорил про универсальные процы. Не про QFP именно, на которых вас заклинило.
И что при чем тут маркетинговость термина? От этого процы по другому работают?
asr9k умеет любую инкапсуляцию, цыфрование все равно на специальных микросхемах. При чем тут это все?
Зачем асру цпс? Зачем его сравнивать с софтсвитчами? Это все никак к процессу форвардинга не относится вообще.
И зачем мне текущее когда меседж в том, что железо или может научиться новым фичам, или нет? аср может. Старые 7600 нет. Новые наверно тоже, в цыске не дураки работают. И скорее это 7600 эволюционирует до аср. А не наоборот.
И что при чем тут маркетинговость термина? От этого процы по другому работают?
asr9k умеет любую инкапсуляцию, цыфрование все равно на специальных микросхемах. При чем тут это все?
Зачем асру цпс? Зачем его сравнивать с софтсвитчами? Это все никак к процессу форвардинга не относится вообще.
И зачем мне текущее когда меседж в том, что железо или может научиться новым фичам, или нет? аср может. Старые 7600 нет. Новые наверно тоже, в цыске не дураки работают. И скорее это 7600 эволюционирует до аср. А не наоборот.
Я говорил про универсальные процы. Не про QFP именно
Вы говорили про QFP — относительно универсальный процессор на полторы сотни ядер.
аср может. Старые 7600 нет. Новые наверно тоже, в цыске не дураки работают.
Это же циска. Они просто решили, что IOS свитчи должны работать в кампусе, а NX-OS — в датацентре, а FP/TRILL и OTV нечего делать в кампусе. Ну и IOS свитчи не должны конкурировать с NX-OS свитчами.
А еще вы к примеру заметили, что под Cat6500 больше нет плат с PoE? Ага, это теперь свитч уровня ядра/распределения, а на доступ надо ставить 4500 и ниже.
Вот что про OTV писалось:
Is there an FCS date for OTV on the 6500 platform?
OTV is on our radar/roadmap for CY13. Hardware is capable to support OTV. We have to enable it in software.
Еще 6500 еще на Sup720-10G поддерживали quad-sup SSO для VSS (active/hot/hot/hot вместо active/hot/cold/cold для четырех супов и отсутствие надобности перезагружать одно из шасси при фейле активного супа). Решено задействовать эту фичу как преимущество нового Sup2T, чтобы народ поскорее обновлялся…
Это, кстати, теоретически может быть одним очком в копилку BMS. Не должно там быть такого, когда функционал поддерживается аппаратно, но программно его никто не реализует.
asr9k умеет любую инкапсуляцию
Точно любую? Покажите мне CAPWAP на ASR9k. MGRE тоже не припомню.
CAPWAP, как неуловимый Джо никому не нужен.
А mGRE судя по fn на asr9000 есть. Начиная с 3.7.
А mGRE судя по fn на asr9000 есть. Начиная с 3.7.
Я думаю, это не про стабильность и не про фичи, это про стоимость. Т.е. в среднее железо всунут протоколы/фичи минимум 10 летней выдержки. Так обеспечится совместимость. Протестируют ряд наборов «железо/софт/конфигурация» — будет, типа, бест практик, саппортим только их. Многих это устроит, думаю даже очень многих, если цена будет в десятки раз меньше…
И да, есть места, где 99% доступности одной железки — достаточно.
И да, есть места, где 99% доступности одной железки — достаточно.
это ответ к ссобщению выше (
Ну скажем так, про «среднее железо» на наш взгляд вы несколько погорячились, но тут все зависит от точки зрения. Сугубо на наш взгляд: 10G порты в качестве основного канала к серверам и 40G на аплинках / уровне Leaf-Spine — на текущий момент является весьма неплохим предложением, к 25-100G весь мир пока только готовится.
Что там с набором протоколов/фич… очень сильно зависит от того, что именно вам нужно. Проприетарщины нет, конечно же, а вот свободного и задокументированного в ассортименте. ПРоще будет если назовете, что именно вам интересно.
А вот стоимость — да, тут все очень достойно, можно даже сказать, уникально.
Ряд наборов «железо/софт/конфигурация» действительно невелик. С одной стороны, есть производители BMS, которым нужны недорогие и доступные ASIC'и, с другой — производители софта, которым нужен открытый доступ к управлению матрицей. Но список растет.
«Десятки раз меньше» — тут вы все же малость погорячились. «Большие парни» не настолько жадные, чтобы за бренд прям настолько задирать цену. А большая часть стоимости железа все равно упирается в общую для всех стоимость портов.
Что там с набором протоколов/фич… очень сильно зависит от того, что именно вам нужно. Проприетарщины нет, конечно же, а вот свободного и задокументированного в ассортименте. ПРоще будет если назовете, что именно вам интересно.
А вот стоимость — да, тут все очень достойно, можно даже сказать, уникально.
Ряд наборов «железо/софт/конфигурация» действительно невелик. С одной стороны, есть производители BMS, которым нужны недорогие и доступные ASIC'и, с другой — производители софта, которым нужен открытый доступ к управлению матрицей. Но список растет.
«Десятки раз меньше» — тут вы все же малость погорячились. «Большие парни» не настолько жадные, чтобы за бренд прям настолько задирать цену. А большая часть стоимости железа все равно упирается в общую для всех стоимость портов.
а размер ТСАМ? сколько ipv4 маршрутов влезет? ipv6, openflow?
trill, PBB (mac-in-mac), SPB (802.1aq) или хотя бы ERPSv2.
я уверен, что со временем количество софта для открытой платформы должно вырасти, но потом. (может даже EIGRP кто-то напишет)
возможно и погарячился ))), но разница между полюсами очень большая, там же не только бренд, там и свои собственные асики, и более обкатаный софт, и техподдержка и полное отсутствие всего на противоположном полюсе.
trill, PBB (mac-in-mac), SPB (802.1aq) или хотя бы ERPSv2.
я уверен, что со временем количество софта для открытой платформы должно вырасти, но потом. (может даже EIGRP кто-то напишет)
возможно и погарячился ))), но разница между полюсами очень большая, там же не только бренд, там и свои собственные асики, и более обкатаный софт, и техподдержка и полное отсутствие всего на противоположном полюсе.
MAC address table
- 32K entries - Hardware capable of 288K entries through Algorithmic LPM expansion;
Routes / Prefixes
- 32K entries through Algorithmic LPM expansion (32K IPv4/ 16K IPv6), Hardware Capable of 128K — Minimum Software Release: CL 2.1.0
- Alternate 16K TCAM-only mode — Default mode for CL 2.0.x releases (8K IPV4/ 4K IPV6 (64 bit mask), 2K IPv6 (128 bit mask))
Host Routes
- 16K Host Entries (16K IPv4 / 8K IPv6) - Hardware capable of 112K entries through Algorithmic LPM expansion
Дальше начинается самое интересное: OpenFlow нет в Cumulus, зато есть в BigSwitch, Pica8 и ONS. Про TRILL мы писали выше: в Cumulus нет, в Pica8 готовится, в Intel ONS есть. Каждый из производителей ОС сейчас старается найти для себя специализацию: это им позволяет особо открыто не конфликтовать и равномерно развиваться. Cumulus делает ставку на классический L2/L3, OSPFv3, iBGP, quagga, ECMP, VXLAN. BigSwitch ставит на SDN и OpenFlow. Pica8 где-то между ними. Несколько в стороне, но при этом очень интересен Intel ONS на Intel/Fulcrum матрице.
Что же касается цен — выше есть ссылка на наши предложения BMS, например, www.etegro.ru/configurator/network/eos520/buy
Можете сами оценить, во сколько обходится само железо с ONIE-средой, сколько стоит «заводская» ОС, сколько стоит Cumulus. Ну и сравнить с аналогами.
- 32K entries - Hardware capable of 288K entries through Algorithmic LPM expansion;
Routes / Prefixes
- 32K entries through Algorithmic LPM expansion (32K IPv4/ 16K IPv6), Hardware Capable of 128K — Minimum Software Release: CL 2.1.0
- Alternate 16K TCAM-only mode — Default mode for CL 2.0.x releases (8K IPV4/ 4K IPV6 (64 bit mask), 2K IPv6 (128 bit mask))
Host Routes
- 16K Host Entries (16K IPv4 / 8K IPv6) - Hardware capable of 112K entries through Algorithmic LPM expansion
Дальше начинается самое интересное: OpenFlow нет в Cumulus, зато есть в BigSwitch, Pica8 и ONS. Про TRILL мы писали выше: в Cumulus нет, в Pica8 готовится, в Intel ONS есть. Каждый из производителей ОС сейчас старается найти для себя специализацию: это им позволяет особо открыто не конфликтовать и равномерно развиваться. Cumulus делает ставку на классический L2/L3, OSPFv3, iBGP, quagga, ECMP, VXLAN. BigSwitch ставит на SDN и OpenFlow. Pica8 где-то между ними. Несколько в стороне, но при этом очень интересен Intel ONS на Intel/Fulcrum матрице.
Что же касается цен — выше есть ссылка на наши предложения BMS, например, www.etegro.ru/configurator/network/eos520/buy
Можете сами оценить, во сколько обходится само железо с ONIE-средой, сколько стоит «заводская» ОС, сколько стоит Cumulus. Ну и сравнить с аналогами.
Решил сравнить цены. Ваш Eos 420 c предустановленной ОС по конфигуратору стоит примерно 10к долл. А цисковый N3K-C3172PQ-10GE (тоже на trident 2) — 20к в GPL, то есть где-то 11к в партнерских ценах. Там, правда, есть некоторые ограничения в роутинге, но разница в цене не сказать, чтобы катастрофическая.
не туда
По поводу менее 100$ за 10G-порт это вы как-то врёте, если судить по ценам, приведенным на вашем же сайте.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Дом, который построил Клоз или Leaf-Spine архитектура: меняем L2 на L3