MPLS наконец-то стал стабильным?

До сих пор нет многопоточной обработки и аппаратного разгрузки, но если для вас это неважно, то работает отлично.

Раньше я работал с 12 роутерами CCR2216 с настройками ospf, mpls, ldp, mp-bgp, и в целом всё шло нормально, но единственная проблема была в том, что загрузка одного ядра процессора была почти 100% или на 100%, а все остальные ядра почти не использовались.

Именно по этой причине мы перешли к другому поставщику, потому что не было никакого очевидного решения для некоторых функций, которые нам нужны как провайдеру. Удачи MT, особенно сейчас, когда они занимаются EVPN — это откроет новую пачку проблем (надеюсь, к лучшему). Это MPLS точно уйдет на второй план, и я надеюсь, что у MT нет намерения убрать MPLS из кода и заменить его на EVPN+VXLAN. Докажите, что мы ошибаемся, MikroTik.

Если вы используете MPLS как P-роутер или в роли PE с VPLS, то сейчас это в целом довольно стабильно, даже при взаимодействии ROSv6 и ROSv7. Большинство проблем с MPLS всё ещё связаны с L3VPN и пропускной способностью/использованием ресурсов.

Одна вещь, которую многие упускают в сети MikroTik MPLS — это синхронизация таймеров IGP и LDP, так как функции синхронизации LDP/IGP нет. Очень важно, чтобы таймеры LDP совпадали с таймерами OSPF/IS-IS — это ключ к стабильной работе MikroTik-сети. Это помогает избежать зависания маршрутов в таблице пересылки MPLS, если таблица маршрутизации IGP изменилась.

Также важно использовать фильтры на вход и выход, чтобы ограничить количество LDP-префиксов, особенно в больших сетях.

Производительность VPLS стала гораздо лучше, но это всё ещё в процессе доработки, поскольку оптимизируют использование нескольких ядер процессора. Аппаратное ускорение тоже могло бы значительно помочь.

Надеюсь, что нет. VxLAN как способ инкапсуляции в канальном уровне отлично подходит для дата-центров, корпоративных сетей и некоторых провайдеров, но MPLS по-прежнему остаётся золотым стандартом для почти всех провайдеров в мире при организации оверлеев и реализации управления трафиком. К тому же, теперь, когда мы знаем, что MikroTik работает над EVPN, хотелось бы, чтобы они разрабатывали это с учётом MPLS. SR-MPLS в канальном уровне — вот для чего изначально создавался EVPN, а VxLAN добавили уже потом.

Почему ты думаешь, что создание ветки v8 что-то изменит? По моему мнению (и это просто предположение) MT действительно выиграли бы от реорганизации и создания отдела исследований и разработок, посвящённого именно корпоративным сетям. Конечно, приоритеты и направление развития зависят от их целевой аудитории.

Синхронизированы ли у вас таймеры IGP/LDP? Такое поведение, которое вы описали, может происходить даже в ROSv6, и настройка таймеров LDP/IGP на совпадение — особенно таймера hello — всегда была решением. Если вы этого не сделали, скорее всего, поэтому у вас всё ещё возникают проблемы.

Именно, BIRD и FRR — классные, но ни один из них даже близко не сравнится с возможностями маршрутизации в MikroTik. Это не значит, что я считаю MikroTik идеальным или не допускаю, что его можно улучшить, но в мире открытого ПО нет ничего, что поддерживало бы SR-MPLS + EVPN + интеграцию L2 ELINE/ELAN/VLAN с EVPN MAC VRF. Если ты думаешь иначе, @millenium7, пожалуйста, укажи мне на этого единорога, лол.

Да, совпадение таймеров hello между LDP и OSPF обычно помогает держать таблицы маршрутизации IPv4/IPv6 и таблицы пересылки MPLS в синхронном состоянии, ведь они обе очищаются одновременно, если сосед падает или появляется флап. В Cisco, Juniper и других есть протокол для этого — LDP/IGP синхронизация, но просто выставить таймеры в совпадение дает похожий эффект. Также разумно фильтровать LDP, оставляя только нужные маршруты. Если у вас только VPLS, достаточно разрешить только лупбэки на вход и выход. Вот похожая тема по той же проблеме в ROSv6 http://forum.mikrotik.com/t/mpls-ldp-still-not-stable/148729/1