MPLS L2VPN. Inter-area MPLS TE

       ---area1--------area0------area2--
       ------R1-ABR1-R2-------ABR3-------
      |       \   |  /        |         |
      | R0     \  | /         |      R4 |
      | R5      \ |/          |         |
       ---------ABR2----------ABR4-------

*from RFC 4105 

Наконец-то появилось немного времени. Я уже радостно начал конфигурить RSVP-TE у себя в лабе, как вдруг наткнулся на упоминание абсолютно плоской IS-IS топологии на 500+ девайсов. IS-IS в этой топологии используется как backbone IGP, т.е. для связности всего MPLS облака. Причем, в описании этой топологии было явно указано, что сделано это было как раз для того, чтобы иметь возможность пользоваться всеми плюшками Traffic Engineering (CSPF, FRR...).

"Так-то да" - подумал я. Кому хочется заморачиваться с LDPoverRSVP... Но плоская IS-IS топология на 500+ девайсов (учитывая ещё и некий рост сети) это круто. Это я и пошел обсуждать с коллегой, который открыл мне глаза на то, что есть-таки нормальный способ строить RSVP-TE туннели с CSPF через уровни/арии и даже через разные AS. Спасибо, Жень! Есть даже RFC 4105 и RFC 4216 под это дело и имплементации у Alcatel-Lucent, Cisco и Juniper, как минимум.

Короче, я решил описать как эта штука работает. В свойственной мне манере - "на пальцах". Почитаем RFC и посмотрим как это можно настроить у Juniper, Cisco и Alcatel-Lucent. Сегодня про inter-area TE. В следующий раз разберем и inter-AS TE.

Перед тем как удариться во все тяжкие, хочу напомнить, что у меня есть пост, который обобщает все мои опусы по MPLS. Если хотите больше информации с самых "азов", переходите по ссылке.

Вспомним, что глобально есть два способа сигнализировать туннели через MPLS облако:

1. Средствами LDP. В таком случае, путь прохождения трафика будет определен IGP (OSPF или IS-IS). Сходимость так же будет определятся показателями сходимости IGP. Путем трафика мы можем управлять только тюнинуя IGP.
2. Средствами RSVP-TE. В этом случае, путь прохождения трафика будет определятся специльным протоколом CSPF, который просчитает наиболее выгодный путь с заданными условиями (bandwidth, скажем). Нас сегодня интересует именно этот случай.

При сигнализации RSVP-TE туннеля, весь просчет пути происходит на Head-End маршрутизаторе. На точке входа в туннель, иными словами. У такого маршрутизатора есть информацию о доступности всех других маршрутизаторов. Получил он такую информацию средствами link-state IGP (OSPF, IS-IS). Более того, у Head-End маршрутизатора есть так же нужная информацию о таких важных для traffic engineering параметрах, как пропускная способность и прочее такое. Эту информацию так же рассказал ему IGP, который умеет её распространять (OSPF TE, IS-IS TE). Далее, наш Head-End роутер запускает CSPF и вычисляет кратчайший пусть по заданным условиям. Отправлятся сообщение PATH по цепочке до выходного маршрутизатора, обратно пробегает RESV. Так же возможно включить дополнительные фишки типа FRR, например.

Вся логика описаная выше может происходить только в рамках одной зоны (area/layer), просто потому что наш Head-End маршрутизатор ничего не знает про соседнюю зону. Он не знает как проложить маршрут через неё наиболее выгодным путем, потому что у него есть только полная топология своей зоны. Ну, а уж про TE параметры и говорить нечего, про соседнюю зону наш Head-End не знает и этого.

Но, как известно, плоский дизайн в link-state протоколах не совсем хорошая идея, хотя бы потому, что каждый отдельный маршрутизатор должен хранить всю топологию своей зоны. А если зона большая, то и хранить придется довольно много информаци. Поэтому инженеры хотят, любят и разделяют свои уютные сети на зоны, тем самым увеличивая так называемый scalability - возможность системы осуществлять рост наиболее безболезненным способом.

А вот в сети разделенной на зоны, построить end-to-end туннель средствами CSPF уже не получится, а очень хотелось бы.

Как всегда, посмотрим на пример. К сожалению, я лишился того, на чем я рисовал ранее, так что на некоторое время мой блог лишится какого-то "шарма", которые дают рисунки от руки. Но я работаю над этим. Картинка ниже.

Допустим, вы хотите сигнализировать туннель от R1 до R2 через всю сеть. Находятся эти роутеры в разные OSPF area, которые соединены backbone area. Так же, допустим, вы хотите указать и дополнительные параметры. Остановимся на том же bandwidth. Построить маршрут в своей зоне не составит труда, у вас есть все входные данные. Это пытается изобразить картинка ниже.

А вот пройти backbone зону у нас не получится, у нас просто нет нужной информации о её топологии. Логичный вопрос - "А у кого есть?". Очевидный ответ - "У ABRа...". ABR на то и ABR, что хранит информацию о топологии сразу двух зон, куда смотрит линками. Ну вот пусть он и посчитает, как лучше проложить путь через backbone area.

В случае inter-area TE, ответсвенным за просчет пути является уже не только Head-End роутер, но и каждый ABR по пути. Head-End строит маршрут до ABR, этот ABR до следуюшего и так далее, пока последний в цепочке ABR не будет содержать в своей зоне последний Tail-End маршрутизатор.

В нашем случае, ABR все ещё не знает как проложить законченный путь для туннеля, потому что выходная точка все ещё находится в другой зоне. Эту калькуляцию для нас произведет следующий ABR. Он проложит путь через свою зону до точки выхода - R2.

Таким образом, у нас имеется LSP через всю OSPF сеть (в данном случае). Такой метод называется в литературе - ERO Expansion. В объекте ERO передается информация о том, через какие хопы должен пройти LSP. Этот объект передается в PATH сообщении, при установлении туннеля. В данном случае, ABRы распространяют этот объект на другие зоны. Отсюда и ERO Expansion.

Получается, что в подходе описанном выше есть одно существенное отличие от работы RSVP-TE в плоской топологии. В inter-area TE за просчет маршрута отвечает не только Head-End маршрутизатор, но и ABRы, через которые проходит LSP. В нашем слчае, алгоритм CSPF запускается 3 раза. При инициализации сигнализации LSP на R1, при пересечении границы между первой и нулевой зоной (на ABR1), при пересечении границы между нулевой и второй зоной (на ABR3).

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

Fast Reroute (ABR Protection)

В случае, когда мы сигнализируем LSP с опцией FRR Node protection, каждый маршрутизатор по пути должен прикинуть, что он будет делать в случае отказа соседа. Я писал об этом в посте про RSVP-TE. Напирмер, маршрутизатор Rx1 прикидывает, что он будет делать, когда его сосед ABR1 "отъедет". Опуская лишние подробности, Rx1 должен построить обходной туннель до маршрутизатора ABR3, минуя отказавшую ноду. Картинка ниже.

Во-первых, Rx1 нужно знать loopback маршрутизатора ABR3 для того, чтобы отправить ему PATH сообщение. А он как бы в другой зоне... Для того, чтобы обойти эту проблему, ABR3 должен быть сконфигурирован так, чтобы он отправлял свой node-id (loopback) в сообщениях RESV. Тогда Rx1 будет знать куда строить туннель. Как мы знаем, сначала от R1 в сторону R2 пройдет сообщение PATH со всеми нужными параметрами, в обратную сторону начнет распространятся сообщение RESV. Маршрутизатор за маршрутизатором. Каждая нода будет изменять это сообщение. ABR3, например, добавит свой ID. Когда Rx1 получит такое сообщение, он узнает к какому маршрутизатору нужно строить резервный LSP.

Во-вторых, для того чтобы построить такой обходной туннель нужно пройти через границу зон, а значит ABR2 (в нашему случае) должен выполнить операцию, которая описывалась выше, а именно ERO Expansion. Чтобы однозначно определить тот факт, что строящийся обходной туннель не должен проходить через ABR1 (было бы глупо) в PATH сообщении передается информация о том, что ABR1 должен быть исклчен при построении маршрута. Такая информация хранится в объекте XRO.

Что касается других RSVP-TE фишек, таких как SRLG и Admin Groups, работа их несильно отличается от intra-area TE.

В RFC4105 ясно сказано, что устройство должно поддерживать два подхода к определению пути LSP.

1. Static configuration of ABRs as loose hops at the head-end LSR. В таком случае, следуя нашему примеру, путь мы бы описали примерно как {ABR1 loose, ABR3 loose}. Т.е. мы должны явно указать, через какие ABRы должен пройти наш путь. Для того чтобы как-то зарезервировать ABR нам предлагается сконфигурировать ещё пару путей через другие ABRы. Такой подход я нашел у Cisco, описано в этом документе.
2. Dynamic ABR selection. Тут все проще и удобнее. LSP Path может быть вообще пустой. В таком случае, будет выбран ABR, который анонсирует префикс с лучшей ценой. Ну не ценой, конечно, а cost. Ну да простят мне такой корявый перевод немногочисленные читатели. Такой подход можно реализовать на Alcatel-Lucent и Juniper.

Ну что же, раз мы в двух словах пробежались по тому как это работает, можно пробежаться по тому как это настроить. Меня в первую очередь интересует Cisco IOS XR, Juniper и Alcetel-Lucent. Начнем, пожалуй, с последнего.

ALU configuration

Ясное дело, что сам MPLS, OSPF(IS-IS), RSVP-TE и прочее и прочее уже должно быть настроено.

Сначала создадим LSP путь. ALU позволяет осуществлять выбор ABR в автоматическом режиме, поэтому путь можно создать пустой.

*A:R1>config>router>mpls# path "loose-path-R2" no shutdown 

Далее создаем LSP. Указываем IP роутера R2. Далее, явно указываем, что хотим строить путь с помощью CSPF и построить обходные туннели по технологии FRR. Конечно же, указываем уже созданный путь и включаем LSP.

*A:R1>config>router>mpls# lsp "LSP-R1-R2" to 2.2.2.2
*A:R1>config>router>mpls# lsp "LSP-R1-R2" cspf         
*A:R1>config>router>mpls# lsp "LSP-R1-R2" fast-reroute facility         
*A:R1>config>router>mpls# lsp "LSP-R1-R2" primary "loose-path-R2" no shutdown
*A:R1>config>router>mpls# lsp "LSP-R1-R2" no shutdown

После всех телодвижений выше ничего не произойдет, потому что на всех ABR в сети нам надо явно включить механизм ERO Expansion. Делается это одной командой, что ниже. Производитель рекоммендует на всех устройствах в домене прописать эту настройку, чтобы потом было проще.

*A:ABR1# configure router mpls cspf-on-loose-hop

*A:ABR2# configure router mpls cspf-on-loose-hop

*A:ABR3# configure router mpls cspf-on-loose-hop

*A:ABR4# configure router mpls cspf-on-loose-hop

Как я говорил, при построении обходных туннелей, наш роутер Rx1 должен будет построить туннель до ABR3. Чтобы узнать его адрес, нам понадобится попросить его добавлять свой ID в сообщения PATH.

*A:ABR3# configure router rsvp node-id-in-rro include

Ну как-то так... в теории... надо будет ещё на лабе все это проверить по хорошему.

IOS XR Configuration

Cisco не умеет автовыбор ABR, поэтому для начала нужно создать LSP Path в котором все ABR ноды будут указаны как loose хопы. В своем примере я не указывал IP нод, но давайте представим, что у ABR1 и ABR3 адреса из примера наже. Таких LSP путей нужно бы создать несколько, чтобы подстраховаться от отказа одного из ABR.

explicit-path name path-to-R2
 index 10 next-address loose ipv4 unicast 10.10.10.1
 index 20 next-address loose ipv4 unicast 10.10.10.3

Далее, создаем туннельный интерфейс

interface Tunnel-te1
 ipv4 unnumbered Loopback0
 destination 2.2.2.2
 signalled-bandwidth 300
  path-option 1 explicit name path-to-R2

Я не нашел в Cisco никаких команд, которые явно включают ERO Expansion. Нужно просто включить IGP на несколько зон, например так.

router ospf 110
 router-id 10.10.10.1
 mpls traffic-eng area 0
 mpls traffic-eng area 1

Надо тоже проверять на лабе.

Juniper Configuration

Junos, как и Lacatel-Lucent, тоже умеет выбирать ABR автоматически. Так что созданный LSP Path будет пустым. К слову, в Junos пустой путь можно вообще не создавать. Если в конфигурации LSP не указыват никакой путь, то маршрут будет построен автоматически. Но мы, для консистентности, создадим-таки пустой путь. Далее добавим путь к LSP в сторону R2.

mpls {
    path to-R2 {
    }
    label-switched-path To-R2 {
    to 2.2.2.2;
    hop-limit 32;
    bandwidth 10m;
    primary to-R2;
    }
}

Ну и включим inter-area TE

mpls {
    expand-loose-hop;
} 
 

На этом, пожалуй, все о Inter-area TE. Конечно, хотелось бы проверить все это в лабе, но сначала нужно занятся просто RSVP-TE туннелями. 

Stay tuned!