Еще году в 2007 старший Компелла (который Кириетти, автор draft-kоmpella, rfc 6624 и др.) говорил нам на очередной конференции: «Парни, скоро MPLS будет в ваших домашних рутерах». И тогда сквозной QoS, TE… С тех пор прошло пять лет, до домашних маршрутизаторов MPLS еще не добрался, но из провайдерской технологии уверенно шагнул в корпоративный сектор. Я не говорю здесь про большие компании, где MPLS появился почти вместе с провайдерским сетями. Имею ввиду средний (а иногда и мелкий) корпоративный сектор, где MPLS сети активно развиваются, что особенно заметно по зарубежным компаниям.
Может возникнуть вопрос – а зачем это? Чем не годятся обычные IGP, а порой и просто «растянутый по физике» L2? Если говорить в общем, то, на мой взгляд, это логическая простота, если хотите, красота и эффективность решений на базе MPLS. С появлением поддержки MPLS на entry-level устройствах от разных производителей, появилась возможность делать элегантные и не дорогие решения, обладающие, вместе с тем, широким функционалом и потенциалом развития. MPLS перестал быть технологией «больших» и «избранных», из чего-то малопонятного и малодоступного, он постепенно превращается в commodity.
Что делают чаще всего в корпоративном секторе с MPLS? В основном то же, что и в провайдерах, с поправкой на масштабы – L2 & L3 VPNы, VPLS, плюс их защита и обеспечение QoS на базе TE. Эта статья описывает простой пример, как на базе устройств HP 5800 серии построить MPLS VPNы, VPLS и защитить их с помощью механизмов TE. Вот сеть:
В ней есть три PE (Provider Edge, в приложении к корпоративному сектору, уровень агрегации), один P (Provider, ядро) и три CE (Customer Edge, три офисных сети).
Сначала на PE поднимаем базовый MPLS и сигнализацию LDP (или MPBGP). Чтобы не растягивать статью, позволю себе пропустить базовые настройки, вроде настроек IGP/BGP в backbone-е. Так как дальше будем использовать TE, то делаем настройки MPLS сразу с поддержкой TE, вот так:
Еще не забыть включить в OSPF backbone поддержку Opaque LSA вот этой командой «opaque-capability enable», чтобы работал TE. Если в качестве сигнализации используется MBGP, то нужно поднять BGP peering между PE и включить в BGP поддержку нужных AF (Address Families). В нашем примере будем использовать VPLS и L3 VPN, соответственно, их поддержку и настраиваем, вот так:
Затем на PE поднимаем и привязываем к интерфейсам сервисы. В нашем случае, как я уже говорил, это VPLS и L3 VPNы. Настраиваем L3 VPN Instance (vpn1 в нашем примере) и VPLS VSI (vlan103, 104 в нашем примере) и привязываем L3 VPN к VLAN-интерфейсу, а VPLS к BA (BridgeAggregation)-интерфейсу (так как с CE на PE приходит агрегированный канал), вот так:
В L3 VPN, чтобы не плодить «статику», между CE и PE поднимаем OSPF и «редистрибутим» маршруты с OSPF CE-PE (ospf 201 в нашем примере) в BGP, для того, чтобы увидеть их на других сайтах. На другой стороне проводим обратную операцию, «вынимаем» маршруты из BGP и «кладем» их в клиентский OSPF, вот так:
Настройки на СЕ приводить не буду, СЕ настраивается как маршрутизатор, ничего про MPLS не знающий.
И в завершении, чтобы защититься от падения каналов, настраиваем TE. Чтобы не перегружать пример, настроим один туннель для защиты VSI vlan104 и защитим его двумя путями. Пути будем прописывать руками и затем привяжем защищенный туннель к сервису через tunnel-policy и pw-class, вот так:
Теперь, в случае падения основного пути, весь трафик внутри VSI vlan104 автоматически «переедет» на резевный маршрут, простроенный в обход отказавшего. В итоге получается вот такая картина:
Между сайтами настроены прозрачный для CE L3 VPN и защищенный при помощи ТЕ VPLS VSI с инкапсулированным в него 104 VLANом (также прозрачным для CE). Конфигурации P-роутера (P4 на картинке) приводить не стал, так как там есть только базовый MPLS с поддержкой TE, сервисы на нем не терминируются, соответственно, никаких специальных настроек нет.
ссылка на оригинал статьи http://habrahabr.ru/company/hp/blog/156533/
Добавить комментарий