Кстати, если пользуетесь ssh на плохих каналах, то рекомендую mosh отзывчивость консоли сильно повышается. + в некоторых случаях даже скрин не нужен будет. И есть роаминг.
Вдоволь помучавшись с гетерогенными/мультивендорными сетями, в свое время пришел к выводу, что это зло. Гартнер конено же авторитетные товарищи, но я все же посмотрел оригинал. Исследование высасоно из пальца. Ни одного факта. И сплошной батхерт.
Некоторые цитаты:
Training and Talent Myth: The market is filled with Cisco Certified Internetwork Expert (CCIE)
and other Cisco accredited network professionals, while finding certified staff for other vendors is
much more difficult.
CCIE в основном прячутся по партнерам и огромным корпорациям. Далеко не все организации, могут себе из позволить. Поэтому их ни так уж и много. Вот данные Cisco «Today, CCIE certification holders represent less than 3% of all certified Cisco professionals and less than 1% of the networking professionals worldwide.»
Все же организациям прийдется раскошелиться еще и на специалистов по другим вендорам…
Interoperability Myth: It's impossible to get two vendors' products reliably working together in a
network.
Говорят, что миф. Я могу сказать, что не миф. Особенно, если поддержка только от одного вендора с которой «не угадали». Говорю это т.к. часто мы решаю проблемы, которые другие вендоры решить не могут.
Complexity Myth: Adding another network infrastructure vendor more than doubles the
complexity of the architecture.
В примере сложности приводят примеры бардака, который развели организации… И считают, что это вендор сложный. Бред…
Staffing Myth: Double the number of network infrastructure vendors means increasing the
number of network staff.
Сложный пункт. Тут двояко. Если каждый уровень сети дублировать вторым вендором, то конечно потребуется больше персонала. Если разделять вендоров на разные уровни, то нет. Я бы кстати задумался, что вы хотите делать у своих заказчиков. Полность параллельно две сети на разных вендорах? В моем понимании это ад… Хотя конечно есть компании которые так живут. Не по своей воли в большинстве случаев, а по причине поглащения/слияния.
Equipment and Maintenance Cost Myth: Loyalty to the incumbent vendor provides an
opportunity to negotiate the best deals and keep costs under control.
Хорошее заявление на успех. Давайте купим лажовую поддержку у вендора, который её не предоставляет… За-то дешево.
Network Management Myth: Adding a second vendor will require the purchase of a lot of extra
management tools.
Соглашусь. Миф. Но только, если нет изначальной заточки на вендоре. В противном случае попадаем на расходы по внедрению новой системы.
Мои выводы:
1.Если разделяете вендоров на разных уровнях, то все хорошо. Главное чтобы устраивал функционал и производительность. И чтобы этот вендор был Cisco :)
2. Если используете для обеспечения отказоустойчивости на одном уровне, то будут огромные расходы на проектирование. Ведь начать надо будет с лаборатории 1-в-1.
3. Если разные вендоры для обеспечения отказоустойчивости в параллельных сетях, то по большей части повторяет пункт 2 + доп расходы на обеспечение отказоустойчивости внутри каждой сети.
И все это выводы только для тех сетей, которые будут строиться с нуля. При модернизации уже имеющихся, затраты всегда больше.
Я бы все же не отказывался от проприетарных технологий обеспечения отказоустойчивости. В большинтсве случаев будет намного лучше чем в мультивендорной сети. Главное правильный дизайн.
Ни чего удивительно впрочем как и странного. Чаще всего пользуются контрактом 8x5 NBD. Описанное вами уже не 8х5. Поэтому нет смысла сравнивать изначально разные сервисы. Кому реально надо покупает премиум контракт и получает доставку в течении 4-х часов. Кому не надо — NBD и в большинстве случаев получает замену на следующий день. О масштабах России тоже не стоит забывать, это не UK.
У всех свои правила. Если кто-то что-то себе придумал, не снимает с него ответсвенности прочитать контракт и понять как на самом деле.
1. Не во всех компонентах её можно заменить. В некоторых 720-х супервизорах, память распаяна.
2. Если ставите аналоги, то про гарантию/поддержку можно забыть. Но работать скорее всего будет.
Хочу уточнить. NBD — это не значит, что вы получите замену на следующий день. Это означает, что она отгрузиться со склада Cisco на следующий день. Обычно это одно и тоже. Особенно если находитесь там же, где есть склад. Но если Вы, скажем, в Усинске, то время доставки будет зависеть от работы курьеров.
С премиум доставкой все обстоит как ожидается. В течении 4-х часов, после оформления RMA, замена будет у вас.
Проблема с повышенным расходом аккамулятора присутсвует только на моделях с дискретной графикой. На старых моделях это решалось, на MBPr все еще нет. На air и pro retina 13 все хорошо.
Заключается она в том, что невозможно переключиться на интегрированную в процессор графику. В результате заряда хватает примерно на 2 часа. Ну и нагрев соответсвующий. На коленки/пузо лучше не класть.
Планов делать Quad sup SSO для vs-s720 пока нет. Это действительно намного сложнее чем для s2t. Если появится бизнес кейс, возможно начнут реализацию, но мне с трудом верится, что кто-то захочет в это вкладываться. 720-е потихоньку уходят в eos/eol
Safe Harbor — программа тестирования. Включает очень большое количество сценариев типичного использования коммутаторов и взаимодействия фич между собой. + конечно же учитываются дефекты.
Да, и еще. Алгоритм выбора OS очень простой.
Если IOS не end of support. Нет дефекта или уязвимости, которые могут доставить вам неприятности. Нет новой нужной фичи, которую вы давно ждали. => Не обновляйтесь.
Параметров много. Разработчики делаю регулярный анализ дефектов. Присваивают им веса. По результатам дают рекомендации. TAC не имеет права рекомендовать конретную версию IOS в кейсе. Можно сказать лишь, когда испраление дефекта было включено в релиз. Ну или посмотреть, что советуют разработчики в общем случае, для конкретной платформы.
Установка последней версии часто является требованием разработчиков.
Посмотрите когда был релиз 12.2.(55)SE8 и 12.2(58)SE. Многое станет ясно. 12.2(57)SE не было. 12.2(58)SE была выпущена для очень узких потребностей. Показали, и больше её не развивали/не фиксили.
Заказчики разные есть. Согласен с вами. У Cisco есть отличная служба — Advanced Services. Они могут авторитетно заявить, что лучше конкретно для вас.
Боюсь Вы меня не правильно поняли. Я всего лишь сказал, что ED ни когда не считалась версией только с фиксами багов и попросил не вводить в заблужение других.
По поводу остального, это всего лишь ваши домыслы. Думаю наберетесь опыта и будет все лучше. Судя по всему желание есть.
Только MD являются 100% баг фиксами по отношению к предыдущей версии. Ну или engineering special как исключение, которого нет на CCO. Приведенного вами Release Notes хватает, что бы релиз стал ED.
Некоторые цитаты:
CCIE в основном прячутся по партнерам и огромным корпорациям. Далеко не все организации, могут себе из позволить. Поэтому их ни так уж и много. Вот данные Cisco «Today, CCIE certification holders represent less than 3% of all certified Cisco professionals and less than 1% of the networking professionals worldwide.»
Все же организациям прийдется раскошелиться еще и на специалистов по другим вендорам…
Говорят, что миф. Я могу сказать, что не миф. Особенно, если поддержка только от одного вендора с которой «не угадали». Говорю это т.к. часто мы решаю проблемы, которые другие вендоры решить не могут.
В примере сложности приводят примеры бардака, который развели организации… И считают, что это вендор сложный. Бред…
Сложный пункт. Тут двояко. Если каждый уровень сети дублировать вторым вендором, то конечно потребуется больше персонала. Если разделять вендоров на разные уровни, то нет. Я бы кстати задумался, что вы хотите делать у своих заказчиков. Полность параллельно две сети на разных вендорах? В моем понимании это ад… Хотя конечно есть компании которые так живут. Не по своей воли в большинстве случаев, а по причине поглащения/слияния.
Хорошее заявление на успех. Давайте купим лажовую поддержку у вендора, который её не предоставляет… За-то дешево.
Соглашусь. Миф. Но только, если нет изначальной заточки на вендоре. В противном случае попадаем на расходы по внедрению новой системы.
Мои выводы:
1.Если разделяете вендоров на разных уровнях, то все хорошо. Главное чтобы устраивал функционал и производительность. И чтобы этот вендор был Cisco :)
2. Если используете для обеспечения отказоустойчивости на одном уровне, то будут огромные расходы на проектирование. Ведь начать надо будет с лаборатории 1-в-1.
3. Если разные вендоры для обеспечения отказоустойчивости в параллельных сетях, то по большей части повторяет пункт 2 + доп расходы на обеспечение отказоустойчивости внутри каждой сети.
И все это выводы только для тех сетей, которые будут строиться с нуля. При модернизации уже имеющихся, затраты всегда больше.
Я бы все же не отказывался от проприетарных технологий обеспечения отказоустойчивости. В большинтсве случаев будет намного лучше чем в мультивендорной сети. Главное правильный дизайн.
У всех свои правила. Если кто-то что-то себе придумал, не снимает с него ответсвенности прочитать контракт и понять как на самом деле.
2. Если ставите аналоги, то про гарантию/поддержку можно забыть. Но работать скорее всего будет.
С премиум доставкой все обстоит как ожидается. В течении 4-х часов, после оформления RMA, замена будет у вас.
Заключается она в том, что невозможно переключиться на интегрированную в процессор графику. В результате заряда хватает примерно на 2 часа. Ну и нагрев соответсвующий. На коленки/пузо лучше не класть.
Если IOS не end of support. Нет дефекта или уязвимости, которые могут доставить вам неприятности. Нет новой нужной фичи, которую вы давно ждали. => Не обновляйтесь.
Установка последней версии часто является требованием разработчиков.
New in Cisco IOS Release 15.0(2)SE5
— Catalyst 3750-X and 3560-X switches now support Universal Power over Ethernet (UPoE).
Заказчики разные есть. Согласен с вами. У Cisco есть отличная служба — Advanced Services. Они могут авторитетно заявить, что лучше конкретно для вас.
По поводу остального, это всего лишь ваши домыслы. Думаю наберетесь опыта и будет все лучше. Судя по всему желание есть.
С уважением, ваш TAC инженер.
Для большинства access коммутаторов рекомендуется 12.2(55)SE8.