| То есть вы называете UPC творением броадкома? Правильно?
Про него Циска скромно умалчивает, а по спеке похож, ой похож.
| Рассказывает один конкретный человек.
Ну да, а документация на сайте производителя операционки выложена случайно. Чтобы никто-никто не ознакомился с возможностями.
| Так что покажите мне, где написано, что если я возьму BMS железку X с ОС Y, то получу роутинг VXLAN.
Подменять тему нехорошо. Сначала вы хотели узнать модели чипов, которые это умеют. Теперь сразу готовое изделие, где это реализовано.
| Это — фантастика.
Приблизили != сделали как универсальный процессор.
Вы постоянно пытаетесь сменить «это можно сделать на merchant silicon» на требование «а дайте мне уже сейчас».
Да, это программируемый парсер.
Кстати, скажите — в Arista 7150 роутинг vxlan есть?
Исходя из открытого содержимого — Carmel и есть NPU, стоящий перед hardware forwarding at 1.44 Tbps, который и есть… :D
| А вендор, выпускающий насквозь проприетарное железо только для собственного пользования, публично дает подробную информацию о его возможностях.
Ой, вы таки не рассказывайте. Производители матриц — отдельная когорта товарищей. Те, кто делает на них устройства — всё рассказывают и показывают.
| Но вы точно в этом уверены?
Почитав документацию разработчика на API — таки да. Есть в ней соответствующие вызовы. Да и исходя из возможностей FlexPipe — можно добавлять даже то, чего не существовало на момент создания матрицы.
| Но тот чип может много чего другого, что и не снилось merchant silicon :)
Поэтому merchant silicon развивается и в следующем поколении будет поддерживать и это.
А пока нексус 5672 — это броадком + NPU, что выдает себя в увеличенной в два раза switching latency :)
| То ли я дурак, то ли интел тщательно прячет информацию о том, что конкретно поддерживается в их фичах.
Скорее, никто в подробностях не пишет возможности матриц в публичных документах.
| Ну поддерживает. А что позволяет с ним делать?
VXLAN routing позволяет в merchant silicon, вы же этого хотели?
На текущий момент никакие: именно поэтому в младших Cisco (3064, например) его нет, а в старших оно реализуется дополнительным чипом, что ведет к соответствующему увеличению цены оборудования.
Хотите хардварного роутинга? Пожалуйста: intel fm6764. Подсказать, в каких коммутаторах оно есть?
Ну в принципе, архитектура там стандартная, x86, так что поставить бсд можно. SDK/API мы предоставим, но сможете ли вы с их помощью реализовать функционал матрицы и в какой степени — зависит только от вас.
В реальном бывает все: например, факапы у гигантов класса google или проблемы с поддержкой со стороны больших вендоров (там есть свои, вполне очевидные нюансы: там, где небольшой производитель будет ценить даже небольшого клиента, большой и неповоротливый гигант может просто отмахнуться, погонять по этапам бюрократии, отложить в долгий ящик). Но да, выбор поставщиков ОС пока не очень богатый, но мы надеемся на развитие событий.
Обычный, скучный четверг...
ага, спасибо
Ну а что еще может сказать вендор железа, продажи которого непосредственным образом зависят от качества работы других вендоров? :)
Ну вы же догадываетесь, что если мы не хотим вылететь с рынка, то качество работы других вендоров мы оцениваем весьма тщательно? :)
Впрочем, подавляющее большинство «железных вендоров» зависят от качества других — крайне сложно полностью жить исключительно на своем железе, слишком многое приходится производить. Вопрос в степени зависимости от остальных и уровне входного контроля.
Да ради бога. Мир состоит не только из критических вещей.
Вот, навскидку, статистика по итогам 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, который вполне себе большой вендор с проприетарным железом.
Ну да не в этом дело. Бардак будет всегда. Вопрос в его размерах и скорости ликвидации. Пока особых нареканий на поставщиков ОС не видно.
Merchant silicon — да. Но мы вроде как и не замахиваемся на сверхуникальные решения с ценами реактивных самолетов. Но ведь не только ими живет вендор, у вендора хватает устройств на том же merchant silicon. И вот здесь мы предлагаем задуматься, а нужно ли оно, по такой цене. Именно поэтому мы и называем цену фичой — одним строго необходим набор определенных вкусностей в проекте, а другим нужен базовый функционал с хорошей производительностью по невысокой цене.
Ну бесконечное число обезьян, конечно, рано или поздно напишет «войну и мир»
Не знаем, как там на тему бесконечного числа обезьян и художественной литературы, но в мире серверов 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 у вас или один вендор? В любом случае вы будете упираться в то, что для решения проблемы ее надо повторить и показать вендору. Если она вообще невоспроизводима на другом железе — идем к производителю железа и обоснованно ему говорим «эта железка не пашет, а другая пашет». Если проблема воспроизводится только в ваших условиях — в подавляющем большинстве случаев это вопрос софта.
Не будем холиварить, да. Хотя ваша уверенность в универсальности знаний «группы парней» (мы же говорим о написании общекомпьютерной части) несколько удивляет. Список известных ошибок в прошивках той же Cisco вызывает некоторые сомнения в профессионализме той самой группы парней и отлаженности их процесса. При этом со стороны пользователя все ваши возможности — стучаться в ТП.
Допустим, невелик. И?
Да он без всяких доступов очень невелик. Создателям ОС не приходится учитывать нюансы большого числа разнообразных матриц, код проще, точек для ошибок меньше.
Допустим, свитч перезагрузился.
Смотрим логи. Если ошибка аппаратная — идем к создателю BMS, программная — к техподдержке ОС.
Если в логах пустота — проверяется повторяемостью на аналогичном железе.
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. Ну и сравнить с аналогами.
Ох.
1) Стабильность.
Удовлетворите наше любопытство: вы смотрели, сколько сейчас существует в мире BMS, поддерживаемых Cumulus или Pica8? Полюбопытствуйте — список весьма невелик, а уж с точки зрения матриц — тем более. Развернутый ответ чуть выше.
Кстати о писании собственного софта. Мы тут завтра (уже сегодня) будем предлагать готовый набор разработчика. Не хотите попробовать? Поверьте, вы будете в этом деле не первым.
2) Отдельный выбор ОС и железа — фича.
Цена — фича.
Использование приложений на коммутаторе — фича.
Архитектуру мы предлагали исключительно в рамках этой статьи. Вы же не считаете, надеемся, что из BMS и ОС для них наглухо выдран весь L2?
— Кратко: да, TRILL — тоже вариант. И под него мы, например, готовы предложить Intel ONS. Насколько нам известно, та же Pica8 вполне подумывает о вводе поддержки TRILL.
Ну скажем так, про «среднее железо» на наш взгляд вы несколько погорячились, но тут все зависит от точки зрения. Сугубо на наш взгляд: 10G порты в качестве основного канала к серверам и 40G на аплинках / уровне Leaf-Spine — на текущий момент является весьма неплохим предложением, к 25-100G весь мир пока только готовится.
Что там с набором протоколов/фич… очень сильно зависит от того, что именно вам нужно. Проприетарщины нет, конечно же, а вот свободного и задокументированного в ассортименте. ПРоще будет если назовете, что именно вам интересно.
А вот стоимость — да, тут все очень достойно, можно даже сказать, уникально.
Ряд наборов «железо/софт/конфигурация» действительно невелик. С одной стороны, есть производители BMS, которым нужны недорогие и доступные ASIC'и, с другой — производители софта, которым нужен открытый доступ к управлению матрицей. Но список растет.
«Десятки раз меньше» — тут вы все же малость погорячились. «Большие парни» не настолько жадные, чтобы за бренд прям настолько задирать цену. А большая часть стоимости железа все равно упирается в общую для всех стоимость портов.
1) Давайте начнем с того, что железо у нас делится на
а) коммутационную матрицу и обслуживаемые ей порты
б) память-проц-накопитель-матплату-БП, компьютер, короче
А софт делится на собственно ОС и драйвер+приложения, управляющие работой матрицы.
Так вот, если речь идет о «тщательном тестировании» сочетания компьютера и железа, то тут мы имеем ядро Debian и стандартное железо. И вот тут вам будет очень сложно убедить нас, что у «больших парней» в лабораториях получается лучше, чем у debian-сообщества. Остается вторая часть: матрица+ее управление. На текущий момент список поддерживаемых матриц крайне невелик и пролезть в список поддерживаемого оборудования крайне непросто — слишком жесткие требования с обоих сторон.
2) про оркестраторы и мониторинг будет чуть позже :) если кратко — все зависит от того, чем вы пользуетесь, линуксовые версии подхватываются без проблем (напоминаю, с точки зрения ОС перед вами Debian)
3) в масштабах крупной сети, насколько нам известно, обычно руководствуются принципом «работает — не трогай». И замену организовывают либо необходимости ввести критически важное обновление, либо если требуется замена железа на более производительное. Где проще переезд — надо сравнивать. Но спору нет, частично заменить инфраструктуру будет сложно.
— Воткнул и поехали — это идеал. Когда он появится — у всевозможных сервисных отделов и служб технической поддержки станет радикально меньше дел. Но пока он недостижим и все по-прежнему упирается в баланс стоимости установки, обслуживания и рисков.
1) >Т.е. при использовании loca-VLAN у вас STP только на краю сети, а ядро исключительно L3 с использованием OSPF/ISIS?
абсолютно верно
2) Тут два подпункта. 2.1 — мы предлагаем помнить о существовании описанной выше архитектуры. Конечно же, она не уникальна, и та же Cisco регулярно о ней напоминает, но очередная волна напоминаний пошла примерно год назад, в том числе и по причине второго подпункта
2.2. — мы предлагаем строить сети на BMS (железках без ОС) и ставить на них сторонние ОС (а не проприетарные ОС производителей железа). Почему именно так? Это дает свободу в выборе железа и ОС (не понравилось — сменил вендора) и, в общем, сильно дешевле. 2960xr — хорошая серия, но для высоконагруженных фабрик 1G как-то мало, очень хорошо бы 10G.
Если вам не нужно быстрое восстановление при сбоях (чтобы погибший диск не убивал рабочий процесс на весь период замены и копирования данных) — никакого.
Про него Циска скромно умалчивает, а по спеке похож, ой похож.
| Рассказывает один конкретный человек.
Ну да, а документация на сайте производителя операционки выложена случайно. Чтобы никто-никто не ознакомился с возможностями.
| Так что покажите мне, где написано, что если я возьму BMS железку X с ОС Y, то получу роутинг VXLAN.
Подменять тему нехорошо. Сначала вы хотели узнать модели чипов, которые это умеют. Теперь сразу готовое изделие, где это реализовано.
| Это — фантастика.
Приблизили != сделали как универсальный процессор.
Вы постоянно пытаетесь сменить «это можно сделать на merchant silicon» на требование «а дайте мне уже сейчас».
Да, это программируемый парсер.
Кстати, скажите — в Arista 7150 роутинг vxlan есть?
Судя по 34 и 37 слайдам — так оно и есть.
| Но это же BMS. Конечному пользователю в этом случае куда важнее иметь информацию о заложенных в железе возможностях, чем в случае проприетарщины.
Вот вам производитель свича и операционки все рассказывает! Что умеют, как умеют, зачем умеют. Совсем как Циска. Вам, почему-то, это не нравится.
| По сравнению с нативной поддержкой — it doesn't scale.
doesn't scale куда? Обработчик приблизили к процессору общего назначения, это же прекрасно.
Исходя из открытого содержимого — Carmel и есть NPU, стоящий перед hardware forwarding at 1.44 Tbps, который и есть… :D
| А вендор, выпускающий насквозь проприетарное железо только для собственного пользования, публично дает подробную информацию о его возможностях.
Ой, вы таки не рассказывайте. Производители матриц — отдельная когорта товарищей. Те, кто делает на них устройства — всё рассказывают и показывают.
| Но вы точно в этом уверены?
Почитав документацию разработчика на API — таки да. Есть в ней соответствующие вызовы. Да и исходя из возможностей FlexPipe — можно добавлять даже то, чего не существовало на момент создания матрицы.
Поэтому merchant silicon развивается и в следующем поколении будет поддерживать и это.
А пока нексус 5672 — это броадком + NPU, что выдает себя в увеличенной в два раза switching latency :)
| То ли я дурак, то ли интел тщательно прячет информацию о том, что конкретно поддерживается в их фичах.
Скорее, никто в подробностях не пишет возможности матриц в публичных документах.
| Ну поддерживает. А что позволяет с ним делать?
VXLAN routing позволяет в merchant silicon, вы же этого хотели?
Хотите хардварного роутинга? Пожалуйста: intel fm6764. Подсказать, в каких коммутаторах оно есть?
Например OVS ускорили.
Сможете поднять матрицу — и как коммутатор будет работать :)
www.idc.com/tracker/showproductinfo.jsp?prod_id=7
В реальном бывает все: например, факапы у гигантов класса google или проблемы с поддержкой со стороны больших вендоров (там есть свои, вполне очевидные нюансы: там, где небольшой производитель будет ценить даже небольшого клиента, большой и неповоротливый гигант может просто отмахнуться, погонять по этапам бюрократии, отложить в долгий ящик). Но да, выбор поставщиков ОС пока не очень богатый, но мы надеемся на развитие событий.
ага, спасибо
Ну вы же догадываетесь, что если мы не хотим вылететь с рынка, то качество работы других вендоров мы оцениваем весьма тщательно? :)
Впрочем, подавляющее большинство «железных вендоров» зависят от качества других — крайне сложно полностью жить исключительно на своем железе, слишком многое приходится производить. Вопрос в степени зависимости от остальных и уровне входного контроля.
Да ради бога. Мир состоит не только из критических вещей.
Вот, навскидку, статистика по итогам 2013:
Если стук безрезультативен — меняем поставщика ОС. Это дешевле, чем менять поставщика железа.
ВАУ! А можете раскрыть тему? А то у нас техсаппорт прям запрыгал от идеи того, что можно запатчить невоспроизводимую проблему.
Не, серьезно: если это не корпоративный секрет — опишите?
Мы не боги :) Но как производитель серверов мы крайне регулярно участвуем в подобных разборках. Обычно локализовать проблему на уровне виновного (железо, драйвер, софт) удается довольно быстро.
У вас, кстати, получился несколько неудачный пример: вы продемонстрировали работу техподдержки HP, который вполне себе большой вендор с проприетарным железом.
Ну да не в этом дело. Бардак будет всегда. Вопрос в его размерах и скорости ликвидации. Пока особых нареканий на поставщиков ОС не видно.
По части L2 — ну Trident же.
Не знаем, как там на тему бесконечного числа обезьян и художественной литературы, но в мире серверов x86+ открытые ОС мягко говоря более популярное решение, чем закрытые Unix'ы.
Зачем? У вас есть производитель ОС, которому вы заплатили за поддержку и в его интересах максимально быстро сделать фикс, чтобы вы со своими деньгами не ушли к его конкуренту.
Ну вот на примере Cumulus:
-четыре 1G модели, десять 10G моделей, четыре 4G моделей
-чипы Broadcom Firebolt2, Broadcom Triumph2, Broadcom Apollo2, Broadcom Trident, Broadcom Trident +, Broadcom Trident II
Итого 18 коммутаторов и 6 чипов.
у Pica8 — 12 моделей на 5 чипах.
И какая в таком случае разница, BMS у вас или один вендор? В любом случае вы будете упираться в то, что для решения проблемы ее надо повторить и показать вендору. Если она вообще невоспроизводима на другом железе — идем к производителю железа и обоснованно ему говорим «эта железка не пашет, а другая пашет». Если проблема воспроизводится только в ваших условиях — в подавляющем большинстве случаев это вопрос софта.
Да он без всяких доступов очень невелик. Создателям ОС не приходится учитывать нюансы большого числа разнообразных матриц, код проще, точек для ошибок меньше.
Смотрим логи. Если ошибка аппаратная — идем к создателю BMS, программная — к техподдержке ОС.
Если в логах пустота — проверяется повторяемостью на аналогичном железе.
- 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. Ну и сравнить с аналогами.
1) Стабильность.
Удовлетворите наше любопытство: вы смотрели, сколько сейчас существует в мире BMS, поддерживаемых Cumulus или Pica8? Полюбопытствуйте — список весьма невелик, а уж с точки зрения матриц — тем более. Развернутый ответ чуть выше.
Кстати о писании собственного софта. Мы тут завтра (уже сегодня) будем предлагать готовый набор разработчика. Не хотите попробовать? Поверьте, вы будете в этом деле не первым.
2) Отдельный выбор ОС и железа — фича.
Цена — фича.
Использование приложений на коммутаторе — фича.
Архитектуру мы предлагали исключительно в рамках этой статьи. Вы же не считаете, надеемся, что из BMS и ОС для них наглухо выдран весь L2?
— Кратко: да, TRILL — тоже вариант. И под него мы, например, готовы предложить Intel ONS. Насколько нам известно, та же Pica8 вполне подумывает о вводе поддержки TRILL.
Что там с набором протоколов/фич… очень сильно зависит от того, что именно вам нужно. Проприетарщины нет, конечно же, а вот свободного и задокументированного в ассортименте. ПРоще будет если назовете, что именно вам интересно.
А вот стоимость — да, тут все очень достойно, можно даже сказать, уникально.
Ряд наборов «железо/софт/конфигурация» действительно невелик. С одной стороны, есть производители BMS, которым нужны недорогие и доступные ASIC'и, с другой — производители софта, которым нужен открытый доступ к управлению матрицей. Но список растет.
«Десятки раз меньше» — тут вы все же малость погорячились. «Большие парни» не настолько жадные, чтобы за бренд прям настолько задирать цену. А большая часть стоимости железа все равно упирается в общую для всех стоимость портов.
а) коммутационную матрицу и обслуживаемые ей порты
б) память-проц-накопитель-матплату-БП, компьютер, короче
А софт делится на собственно ОС и драйвер+приложения, управляющие работой матрицы.
Так вот, если речь идет о «тщательном тестировании» сочетания компьютера и железа, то тут мы имеем ядро 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
— Воткнул и поехали — это идеал. Когда он появится — у всевозможных сервисных отделов и служб технической поддержки станет радикально меньше дел. Но пока он недостижим и все по-прежнему упирается в баланс стоимости установки, обслуживания и рисков.
абсолютно верно
2) Тут два подпункта. 2.1 — мы предлагаем помнить о существовании описанной выше архитектуры. Конечно же, она не уникальна, и та же Cisco регулярно о ней напоминает, но очередная волна напоминаний пошла примерно год назад, в том числе и по причине второго подпункта
2.2. — мы предлагаем строить сети на BMS (железках без ОС) и ставить на них сторонние ОС (а не проприетарные ОС производителей железа). Почему именно так? Это дает свободу в выборе железа и ОС (не понравилось — сменил вендора) и, в общем, сильно дешевле. 2960xr — хорошая серия, но для высоконагруженных фабрик 1G как-то мало, очень хорошо бы 10G.