Comments 25
Сделайте схемы больше\кликабильными. Не видно ж ничего
Исправили картинки.
Теперь понял, что и как.
То есть вы соединили TE туннелями два бранча. Это очень здорово, учитывая, что трафика между ними практически нет, всё оседает в area 0, который является ЦОДом :) Ну да, голосовой трафик скажет маленькое «спасибо». Но стоило ли оно всего геморроя по настройке TE в режиме full mesh?
Все-таки на картинке изображена не корпоративная, а операторская сеть…
То есть вы соединили TE туннелями два бранча. Это очень здорово, учитывая, что трафика между ними практически нет, всё оседает в area 0, который является ЦОДом :) Ну да, голосовой трафик скажет маленькое «спасибо». Но стоило ли оно всего геморроя по настройке TE в режиме full mesh?
Все-таки на картинке изображена не корпоративная, а операторская сеть…
Это — пример, в нем все упрощено, чтобы сделать наглядным
Вот вечно с вами, парнями из HP, так: предлагаете решение, но не можете внятно озвучить решаемую задачу :) Всё прямо как в топике про L2 DCI средствами VPLS.
Можно было бы уместить содержание всего поста в пять слов: «железо HP поддерживает MPLS TE». Ну здорово, поздравляю.
Огромная просьба на будущее: если пишете статью про какую-то архитектуру — постарайтесь сделать так, чтобы эта архитектура была обоснованной и правильной с точки зрения поставленной задачи. Или не касайтесь архитектуры, а просто сделайте обзор технологии. Например, если бы речь шла про MPLS VPN в корпоративной сети — вопросов нет, это реально нужно. Если про MPLS TE в операторской сети — аналогично. Но я вот из статьи так и не понял, зачем вообще нужны TE туннели в корпоративной сети. Вы об этом не сказали. Про FRR я догадался лишь посмотрев на конфиги. Про время сходимости в топике тоже не было сказано, так что сходу возник вопрос «зачем городить огород с TE, если IGP прекрасно перемаршрутизирует трафик при аварии на любом участке, а дополнительный функционал TE помимо explicit path не настраивается, и конфига QoS нету?».
Можно было бы уместить содержание всего поста в пять слов: «железо HP поддерживает MPLS TE». Ну здорово, поздравляю.
Огромная просьба на будущее: если пишете статью про какую-то архитектуру — постарайтесь сделать так, чтобы эта архитектура была обоснованной и правильной с точки зрения поставленной задачи. Или не касайтесь архитектуры, а просто сделайте обзор технологии. Например, если бы речь шла про MPLS VPN в корпоративной сети — вопросов нет, это реально нужно. Если про MPLS TE в операторской сети — аналогично. Но я вот из статьи так и не понял, зачем вообще нужны TE туннели в корпоративной сети. Вы об этом не сказали. Про FRR я догадался лишь посмотрев на конфиги. Про время сходимости в топике тоже не было сказано, так что сходу возник вопрос «зачем городить огород с TE, если IGP прекрасно перемаршрутизирует трафик при аварии на любом участке, а дополнительный функционал TE помимо explicit path не настраивается, и конфига QoS нету?».
ТЕ в корпоративной сети затем же, зачем и в провайдерской — защищать трафик и управлять им, писать про это академический пост смысла не вижу.
Статья не про «какую-то архитектуру», а про то, как на практике настроить MPLS VPN на железе HP и защитить его от падения каналов при помощи стандартных механизмов TE. Хотите использовать для этого в MPLS сети IP FRR или крутить ручки у IGP — ваше право. Я бы этого делать не рекомендовал. Время сходимости с ТЕ в этом примере в пределах 200 мс.
Пример упрощенный, QoS в сочетании с MPLS ТЕ — глубокая тема, про которую нужно писать отдельно, другие применения ТЕ в корпоративных сетях (управление трафиком) в этой статье не рассматривались.
Статья не про «какую-то архитектуру», а про то, как на практике настроить MPLS VPN на железе HP и защитить его от падения каналов при помощи стандартных механизмов TE. Хотите использовать для этого в MPLS сети IP FRR или крутить ручки у IGP — ваше право. Я бы этого делать не рекомендовал. Время сходимости с ТЕ в этом примере в пределах 200 мс.
Пример упрощенный, QoS в сочетании с MPLS ТЕ — глубокая тема, про которую нужно писать отдельно, другие применения ТЕ в корпоративных сетях (управление трафиком) в этой статье не рассматривались.
ТЕ в корпоративной сети затем же, зачем и в провайдерской — защищать трафик и управлять им
Капитанский ответ :) Снова внедряем технологию ради самой технологии?
крутить ручки у IGP — ваше право. Я бы этого делать не рекомендовал.
Вы не рекомендуете тюнить OSPF? Серьезно? Т.е. дефолтные таймеры (как hello, так и алгоритма SPF) на всех участках?
Время сходимости с ТЕ в этом примере в пределах 200 мс.
Так и напишите об этом в топике. «Задача — обеспечить время сходимости в пределах 200мс, решили ее вот как».
Пример упрощенный
Из примера вообще непонятно, ради чего всё делалось.
Если ответ «ТЕ в корпоративной сети… — защищать трафик и управлять им» — значит для вас «технология ради технологии», ок, пусть будет так… :)
Не выдергивайте из контекста, я не рекомендую решать стандартные задачи не стандартными для решения этих задач средствами .
Вы не рекомендуете тюнить OSPF?
Не выдергивайте из контекста, я не рекомендую решать стандартные задачи не стандартными для решения этих задач средствами .
Если ответ «ТЕ в корпоративной сети… — защищать трафик и управлять им» — значит для вас «технология ради технологии»
Ё-мое… Ну так и расскажите, как на железе HP реализовать именно защиту трафика. В топике рассказано лишь как с помощью кучи лишних телодвижений в точности воспроизвести средствами MPLS TE поведение обычного IGP (а то и статической маршрутизации, ибо нет dynamic туннелей), разве что с чуть более быстрым временем восстановления (разница в пределах секунды). Там, кстати, и необходимость разбиения на VRFы вовсе не очевидна.
«Защищать трафик и управлять им» — если так формулируется задача, то «OSPF» является отличным ее решением, причем несравнимо проще конфигурируется. А разворачивание full mesh туннелей для двадцати PE является весьма адской работой, которую надо проводить только если в этом есть объективная необходимость, а не просто «хочется управлять трафиком».
Еще раз, цель статьи — показать, как на HP делаются MPLS VPN-ы и при помощи каких технологий правильно защищать их трафик. Эта статья не отвечает цели продемонстрировать, почему в определенных случаях следует делать выбор в сторону MPLS, а не OSPF (и я написал об этом в самом начале статьи).
Чтобы ответить вам по сути, не вызывая следующих вопросов, нужно показать среднюю инсталляцию MPLS сети у заказчика (подробно — какие сервисы живут в сети, какие к ним есть требования, как там TE работает, как синхрится MPLS-ная сигнализация с IGP, по каким правилам LSP динамически простраиваются, как мапятся админ-группы на qos и т.д.), и сравнить с тем, как это может быть сделано на базе классического IGP. Обязательно напишу об этом, как будет время, спасибо, что стараетесь сделать нас лучше :)
Чтобы ответить вам по сути, не вызывая следующих вопросов, нужно показать среднюю инсталляцию MPLS сети у заказчика (подробно — какие сервисы живут в сети, какие к ним есть требования, как там TE работает, как синхрится MPLS-ная сигнализация с IGP, по каким правилам LSP динамически простраиваются, как мапятся админ-группы на qos и т.д.), и сравнить с тем, как это может быть сделано на базе классического IGP. Обязательно напишу об этом, как будет время, спасибо, что стараетесь сделать нас лучше :)
Так напишите статью про комплексную имплементацию MPLS сервисов. Я, как и многие другие, с удовольствием почитаю. А текущая статья как будто на коленке писалась за пару минут с целью сказать «мы умеем TE, поздравьте нас» (а может, действительно только недавно эта фича появилась? Гуглить лень). Причем тот, кто не знает, что такое TE, ничего не поймет из написанного, а кто знает — пожмет плечами или выразит недоумение от явного несоответствия решения поставленной задаче.
С картинками беда. Я так и не понял, откуда и куда пробрасываются туннели. А конфиги лучше в <_source> помещать.
На самом деле, необходимость TE в корпоративных сетях мне не вполне понятна. В вашем случае туннели сигнализируются лишь с целью FRR, но не для распределения нагрузки. Если есть требование исключительно быстрой сходимости — можно и IP FRR задействовать, с MPLS, но без TE. Уже меньше административной нагрузки. Или не париться и положиться на IGP, благо подавляющее большинство приложений переживет отсутствие связи в 1-2 секунды, да и с голосом ничего критического не произойдет.
Корпоративная сеть радикально отличается от провайдерской. Она не настолько глубокая, и у нее не бывает условий вроде «соединить два узла, гарантировав им определенную полосу, но заполисив их на этом уровне, с учетом наличия сотен других таких же каналов и сильно разветвленной сети между ними». А это ведь и есть основное применение TE, а вовсе не банальное ускорение сходимости.
Реальное применение MPLS в корпоративных сетях — средствами VRFов отделить DMZ от внутренней сети на одном и том же оборудовании, со сторонними файрволами между периметрами. Это чертовски удобно. И решения класса EoMPLS (в том числе VPLS) местами могут быть полезны. Но TE? Не знаю…
На самом деле, необходимость TE в корпоративных сетях мне не вполне понятна. В вашем случае туннели сигнализируются лишь с целью FRR, но не для распределения нагрузки. Если есть требование исключительно быстрой сходимости — можно и IP FRR задействовать, с MPLS, но без TE. Уже меньше административной нагрузки. Или не париться и положиться на IGP, благо подавляющее большинство приложений переживет отсутствие связи в 1-2 секунды, да и с голосом ничего критического не произойдет.
Корпоративная сеть радикально отличается от провайдерской. Она не настолько глубокая, и у нее не бывает условий вроде «соединить два узла, гарантировав им определенную полосу, но заполисив их на этом уровне, с учетом наличия сотен других таких же каналов и сильно разветвленной сети между ними». А это ведь и есть основное применение TE, а вовсе не банальное ускорение сходимости.
Реальное применение MPLS в корпоративных сетях — средствами VRFов отделить DMZ от внутренней сети на одном и том же оборудовании, со сторонними файрволами между периметрами. Это чертовски удобно. И решения класса EoMPLS (в том числе VPLS) местами могут быть полезны. Но TE? Не знаю…
«Реальное применение MPLS в корпоративных сетях — средствами VRFов отделить DMZ от внутренней сети на одном и том же оборудовании, со сторонними файрволами между периметрами.»
+
И не только ДМЗ, всякое бывает. Вплоть до банального «добиться того же эффекта, что дали бы route-map, когда их нет»
А WAN часто l3 vpn и там забота оператора обеспечить нужное QoS.
+
И не только ДМЗ, всякое бывает. Вплоть до банального «добиться того же эффекта, что дали бы route-map, когда их нет»
А WAN часто l3 vpn и там забота оператора обеспечить нужное QoS.
Каждому свое. Кому-то хватает IGP, в моей практике многим этого хватать перестало, делают MPLS с TE (эта статья и появилась по результатам очередного PoC для заказчиков). Балансировать трафик через туннели можно, просто не стал перегружать пример. Использовать IP FRR с MPLS лично я смысла не вижу, если уж подняли MPLS, то в нем для этого есть стандартный механизм FRR. Корпоративня сеть отличается от провайдерской, спора нет, но у многих она последнее время так усложняется и предъявляет такие требования к сервису, что люди начинают использовать провайдерские технологии.
если уж подняли MPLS, то в нем для этого есть стандартный механизм FRR.
Полностью полагающийся на сходимость IGP. И тогда это не FRR. Или я что-то не знаю про HPшную реализацию сервисов MPLS?
IP FRR как раз работает поверх MPLS, но TE туннели не задействует.
но у многих она последнее время так усложняется и предъявляет такие требования к сервису, что люди начинают использовать провайдерские технологии.
Ага. Но в последней картинке поста все-таки нарисована типичная провайдерская топология (с маленькими нюансами по части конфигурации арий OSPF). Как я уже писал — в корпоративной сети весь трафик будет оседать в area 0, TE туннели останутся практически незадействованными.
Тюнингом OSPF можно добиться времени сходимости значительно менее секунды (при достаточно мощном control plane на всех железках). Вашим заказчикам действительно этого не хватает?
Ну и раз «PoC» — значит, на практике нарисованная выше схема реализована лишь на бумаге или, максимум, в лабе?
Бог с вами, причем в MPLS FRR сходимость IGP… :)?
Писал уже — ваше право делать с сетями то, что считаете нужным — крутить ручки у OSPF, скрещивать IP FRR с MPLS-ом и т. д. В моем понимании стандартные задачи правильно решать стандартными способами.
Схема, которая приведена в статье — упрощенная схема собранного в лабе стэнда, чтобы протестировать определенный функционал для заказчика. Реальная сеть у заказчика — порядка 20 РЕ/10 P, соединенных оптикой, где-то full mesh, где-то кольцами, c RSVP TE в полный рост.
Писал уже — ваше право делать с сетями то, что считаете нужным — крутить ручки у OSPF, скрещивать IP FRR с MPLS-ом и т. д. В моем понимании стандартные задачи правильно решать стандартными способами.
Схема, которая приведена в статье — упрощенная схема собранного в лабе стэнда, чтобы протестировать определенный функционал для заказчика. Реальная сеть у заказчика — порядка 20 РЕ/10 P, соединенных оптикой, где-то full mesh, где-то кольцами, c RSVP TE в полный рост.
Реальная сеть у заказчика — порядка 20 РЕ/10 P, соединенных оптикой, где-то full mesh, где-то кольцами, c RSVP TE в полный рост.
Другой разговор. Если в сети разброд и шатание, с полным хаосом по части линков между роутерами, и разобраться в этом никак, то да, имеет смысл руками прописать n(n-1) туннелей и в 2 раза больше explicit path'ов (если не полагаться на dynamic), чтобы эффективно задействовать имеющуюся емкость каналов.
Можно узнать, в чем смысл выкладывать конфиги в виде изображений? Во-первых, мелкий текст, во-вторых, нельзя скопировать и сразу вставить в терминал.
UFO just landed and posted this here
Статья ни о чем.
CLI поразительно напоминает Huawei. Практически символ в символ. Наследие H3C?
Sign up to leave a comment.
MPLS VPN с TE в корпоративных сетях