понедельник, 18 июля 2016 г.

Лаба MPLS VPN. Первый взгляд.


Снято на утюг...
В прошлом посте писал, что закончу уже с MPLS. Начал писать уже постик по другой тематике, как вдруг почувствовал острое желание собирать лабу. Теория это, конечно же, хорошо. Однако надо эту теорию подкреплять практикой. В моем случае, я конечно же, просто обязан собрать лабу по MPLS VPN. В этом посте первый взгляд. Попробуем спланировать наиболее полную, но эффективную топологию, на которой можно будет отработать основные моменты. Как раз, заодно с этим, прикину, что именно я попробую настроить и запустить, какие ситуации обкатать и т.д. Короче, погнали...
Все посты про MPLS VPN можно посмотреть по тегу MPLS или в обобщающем посте.

Итак, прям как в школе.

Дано:

Традиционно, кручу я все на своем уютном "сервере" по проекту LackRack (фото в начале поста). Как-нибудь, возможно, опишу свою домашнюю инфраструктуру. Там ничего особенного, конечно, но OSPF и PIM имеется (как минимум). К сожалению, я не обладаю достаточным количеством свободных денег, поэтому железка более чем скромная. Сразу ясно, что на очень уж развитую лабу рассчитывать не приходится. Поэтому, придется экономить. На сервер установлена бесплатная версия VMware ESXi 5.5.0. Железо можно посмотреть на картинках ниже.


Как вы можете видеть, не очень густо. Поглядим на сколько хватит восьми Гигабайт оперативки и четырех ядер по 3 ГГц в каждом.

Картинку с установленными образами я приводить не буду, вдруг вендоры засудят... Скажу только, что я могу позволить себе "некоторую" такую мультивендорность в лабе.

Задача максимум:

  1. Лаба должна быть мультивендорной. Это позволит наступить не только на грабли в самом MPLS, но ещё и на грабли различных производителей. Что будет, конечно же, существенно раздражать. Одновременно с этим можно получить неплохой опыт.
  2. Топология должна быть достаточной и необходимой. Запустить большое количество образов просто не получится (оперативка упрется в полку).
  3. Попытаемся затронуть следующие задачи:
    1. Настройка внутреннего протокола маршрутизации под нужды Traffic Engineering. 
    2. Сигнализация транспортных туннелей 
      • LDP
      • RSVP-TE
      • LDPoRSVP
    3. Отказоустойчивость транспортного туннеля
      • Secondary LSP
      • Fast Reroute
    4. Настройка VLL на примере Epipe.
    5. VPLS и H-VPLS
    6. Отказоустойчивость в VLL и VPLS.
    7. VPLS BGP Auto-Discovery
    8. PBB-VPLS
    9. VPLS OAM. Чисто для ознакомления погонять LSP-trace, VCCV-ping и прочее.

Вендоры

Итак, в базовом варианте, нам понадобятся P и PE роутеры. Алкателевский подход мне пришелся по душе, поэтому пусть PE роутеры будут Alcatel-Lucent 7750 Virtual Service Router. Ядро сети, в теории, может быть другого вендора, потому как оно мало что будет знать о сервисах в сети. Его задача - ловко и быстро жонглировать метками. Я бы запустил ядро на Juniper и Cisco. Во-первых, это довольно типично. Во-вторых, я мало работал с Junos, В-третьих, они у меня в наличии. 

Решено. Используем:
  • PE - Alcatel-Lucent 7750 Service Router
  • P - Juniper vMX, Cisco IOS XRv
Пока открытым остается вопрос поддержки на этих виртуальных платформах MPLS. Но беглый просмотр спецификаций вроде как подтверждает наличие MPLS на всех железяках. Ну уж OSPF, IS-IS, BGP, я думаю, найдутся.

OSPF vs IS-IS

Тут все равно что выбирать, по большому счету. Мне больше нравится IS-IS, он более привлекателен и "свеж" для меня, но OSPF я знаю лучше. Так что, я думаю, OSPF.
Пользуясь случаем, повторно рекомендую канал коллеги Let's Lab. Там вы найдете все ответы на тему OSPF vs. IS-IS.

Решено. Используем OSPF TE.

CE

С клиентскими девайсами все не так-то просто. Так как мы будем эмулировать только VLL и VPLS, другими словами только L2 сервисы, то от CE устройства нам нужно только возможность настройки IP адреса и возможность выполнять ping. Ну там, ARP глянуть ещё. В условиях жесткой экономии ресурсов, я не смогу запускать свои XPшечки, потому что они слишком много жрут. Уж точно расточительным будет запускать полноценные роутерные инстансы. Наверное, есть смысл обратить внимание на какой-либо маленький дистрибутив Linux. Хочется, чтобы он все же с GUI был, но можно и без него, разумеется. Благо их много, для начала, будем пробовать TinyCore или Damn Small Linux.

Решено. Используем TinyCore Linux.

Топология

Тут придется порисовать. Конечно, с первого раза окончательный вариант сделать не получится, но попробуем учесть максимально много деталей.

Первая схема, которая пришла ко мне в голову, расположена ниже.
Все довольно стандартно. В ядре full-mesh между P роутерами, каждый PE подключен к двум P. К каждому PE подключим по одному-два CE (на рисунке не представлены). Такая топология позволит нам обкатать следующие задачи:
  • Сигнализация транспортных туннелей PE-PE (LDP и RSVP-TE)
  • Разбиение сети на несколько OSPF area, что позволит сигнализировать LDPoRSVP
  • Настройка Secondary LSP и FRR
  • Настройка VLL между двумя PE
  • Настройка VPLS между двумя PE (хотелось бы между тремя)
  • Настройка BGP-AD
  • Настройка PBB
В принципе, все более или менее нормально, если моё железо вытянет 6 роутеров. В таком конфиге не получится обкатать:
  • H-VPLS
  • Отказоустойчивость VPLS и VLL
Второй сразу отложим на будущее, потому как довольно сложно будет в условиях лабы что-то внятное настроить. Не уверен, что MC-LAG заработает, а просто сигнализировать по дополнительной pseudowire не интересно. C VPLS отказоустойчивостью дела обстоят ещё хуже. Нужно строить H-VPLS, а для него надо действительно много роутеров.

Так, попытаемся дополнить топологию. Возможно, уберем лишнее и попробуем впихнуть H-VPLS. Для начала добавим ещё один PE роутер и раскидаем CE (TinyCore) устройства. Два CE будут для отработки Epipe сервиса и ещё три для VPLS.
С H-VPLS все посложнее. Очевидно, что придется добавлять роутеры, что дорого по ресурсам. Возможно, что-то придется убирать. Первое, что пришло в голову, все P маршрутизаторы превратить в hub-PE, а все PE в spoke-PE.
Интересный вариант. По идее, мы сможем сигнализировать транспортные туннели spoke-PE-spoke-PE с использование FRR и Secondary LSP. Ядра у нас не будет, как такового. Но оно нам и не нужно, по идее... Есть несколько неясных моментов для такой топологии:
  • Получится ли организовать несколько зон OSPF?
  • А действительно ли получится обкатать Sec-LSP и FRR?
  • Можно ли допускать мультивендорность в такой конфигурации?
Ответить на эти вопросы сложно, особенно на второй. Я вообще пока не представляю как H-VPLS настраивается на Alcatel-Lucent. Да я его вообще особо в глаза-то никогда и не видел. К тому же, у меня остается вопрос знают ли hub-PE про сервисы в таком случае? Непонятно.

Наверное, стоит постепенно усложнять топологию. Обычно, я стараюсь сделать одну лабораторную на все технологии и пытаюсь совместить их. Видимо, здесь такой подход не уместен.

Ок. Тогда попробуем прикинуть глобальные этапы в лабе:
  1. Базовая топология. На ней же пытаемся работать над BGP.
  2. Делим базовую топологию на OSPF зоны, пробуем LDPoRSVP
  3. Пытаемся строить H-VPLS, а затем и PBB-VPLS.

Можно ли как-то уменьшить количество устройств?

Обратимся к прошлой схемке с четырьмя роутерами в ядре.
Давайте сравним. В топологии с четырьмя роутерами в ядре можно будет разнообразно поиграться с FRR. Можно строить транспортные туннели и с обходом линков и с обходом нод.
В топологии с тремя роутерами, мы получает примерно тоже самое. Возможно такая топология не очень близка к идеальной, зато подходит под легенду нищенского провайдера.

Кстати, в любой лабе стараюсь придумывать некую легенду. Очень сложно работать просто с голыми железками и синтетическими задачами. Возможно, когда буду писать про остальные, уже построенные лабы, станет понятно, что я уделяю этому большое внимание.
Под легенде вообще нищенского (обычного) провайдера, ещё больше подходит топология с двумя роутерами в ядре. Но тут как-то некрасиво будет брать под них разных вендоров... Можно, конечно, викинуть XRы и оставить в ядре два Juniper. В любом случае, два роутера в ядре не особо мешает нам строить транспортные туннели с FRR. Конечно, будет не очень разнообразно, но в целом и обход линка можно смоделировать, как и обход ноды.

Пока больше неясного, но уже можно определиться с чего я начну. Итак, результирующая топология будет выглядеть примерно так.
Три P маршрутизатора в ядре. Придерживаемся легенде, что провайдер местного уровня вышел на новые горизонты, а вернее зашел в ещё один город. У провайдера уже стояло два роутера IOS XR в одном городе, на которых все и терминировалось. В новый город решили поставить пока одну железку (вдруг не пойдет). Так же решено было попробовать ещё одного вендора - Juniper (вдруг меньше проблем будет :). Ну а так как PWE3 подход инженерам понравился, то на доступ решено было ставить что-нибудь типа Alcatel 7450. Именно они будут терминировать VPN сервисы для юрлиц, а в дальнейшем наш провайдер хочет и пресловутый Triple Play перетащить на них. Все будет заходить в эти Алкатели, а дальше уже через VPLS попадать на BRASы или куда там нужно.

Для того чтобы максимально использовать силу земли IP/MPLS VPN, инженеры решают строить транспортные туннели с максимальной заботой об отказоустойчивости, использую RSPV-TE с FRR и Sec-LSP. Но перед этим, они, наверное, попытаются пойти простым путем с LDP.

Все P маршрутизаторы должны быть соединены по схеме "каждый с каждым" (full-mesh). Пока что это касается только физических линков. Все PE маршрутизаторы пока не разбиваются по уровням hub/spoke. Соответственно, для предоставления сервисов все PE роутеры соединенны pseudowere-туннелями в full-mesh топологию. Потом, наверное, инженеры в провайдере подумают, что такая ситуация не очень масштабируется, да и FDB заканчивается уже, и задумается над H-VPLS и PBB, конечно же.

Чуть ранее наши коллеги обленятся и решат, что лучше недельку плотно поработать и внедрить BGP-AD, чем каждый раз лопатить конфиги и создавать pseudowire.

Ну как-то так. В следующий раз, пожалуй, пора начинать наступать на грабли.




Ярлыки: ,

Комментариев нет:

Отправить комментарий