Моё мнение основано на нашем собственном тестировании, опыте и дальнейшем выборе пути JunOS/IOS после того, как мы попробовали MT, но не смогли обойти некоторые ограничения. Главная проблема в нашем тестовом процессе — иногда неудачные BGP-дизайны, которые приносит с собой ROS, и все здесь в форуме слышали шутку про ROS7 и про то, что он «починит» вещи. Проблема с импортом IP-адресов loopback через OSPF (IGP), особенно для IPv6, — это полный провал для любой конфигурации с route-reflector, да и между full-mesh-BGP-роутерами проблема сохраняется. Хотя можно обойти это с помощью статических маршрутов, это совсем не в духе создания отказоустойчивого ядра, которое потом намеренно ломается из-за статических маршрутов. (Здесь много обсуждений по BGP-проблемам, особенно по IPv6.)
На мощных виртуальных машинах BGP сходится довольно быстро, но аппаратные CCR сходятся крайне медленно — на самом деле, невероятно медленно импортируют полные таблицы, не говоря уже о нескольких полных таблицах. В повседневных задачах управления Winbox был бы очень кстати, но опять же приходится возвращаться к иногда довольно громоздкой CLI просто чтобы посмотреть маршрут. Работа с VRF — настоящий головняк, VPNV6 просто отсутствует, сообщества вроде gshut малоизвестны, а по дизайну невозможна непрерывная переадресация (nonstop-forwarding). Настройка HA, кроме VRRP — нет, защита контрольной плоскости (то есть CPU) должна делаться на уровне фаервола, что отключает IPv4 fast path; RP filter работает или на всех интерфейсах, или ни на одном, что для граничного роутера почти невозможно. Управление нельзя делать через mgmt-VRF, только через основную таблицу маршрутизации (опять дизайн-проблема). Пароли админов, очевидно, не хэшируются односторонне, что привело к последним уязвимостям безопасности — полный отказ от использования. BFD просто не работает, и даже MT советует его не использовать — серьёзная проблема, если у вас есть какое-то транспортное оборудование между вами и транзитным краевым роутером или между собственными ядровыми роутерами.
Большинство этих проблем сильно сглаживаются (или просто отсутствуют) при использовании «большого железа» с соответствующим ПО. Для нашей сети, которая проворачивает мультигигабитные пиры и транзиты, реализация MT в ядре и на краю транзита просто не стоит тех заморочек. Мы с удовольствием используем CCR на нескольких точках сети, где идёт тяжёлый трафик, но нам нужен полный и надёжный набор функций IPv4+IPv6, хорошо отлаженный BGP с исправлениями багов в срок, если что-то ломается в ядре или на транзитном крае. На уровне CPE мы довольно часто используем MT, так как они справляются на ARM-платформе с потоками по 2 Гбит/с без проблем, включая фаерволы и QoS. В конце концов, я знаю несколько провайдеров, которые работают на MT и CCR в ядре, и это в целом работает, но обычно их нагрузки не доходят до 10 Гбит/с, и им не особо нужны MPLS или другие продвинутые функции, часто IPv6 у них вообще не используется.
С уважением, hk
