MPLS VPN, OSPF PE-CE Protocol

Введение.

Рассмотрим несколько особенностей OSPFv2 как PE-CE протокола в MPLS VPN окружении. Для этого нам понадобится горсть различных роутеров да немного энтузиазма.

Итак, зачем же нам именно MPLS VPN? Почему просто не экспортировать маршруты в обычный BGP бэкбон? Это действительно можно сделать, но проблема в том, что BGP не сохранит значение route type, что в конечном итоге приведет к экспорту нашего маршрута в целевой OSPF с типом «внешний». Казалось бы, что в этом плохого? А вот целый список минусов такого подхода:

• Внешние маршруты не могут быть суммаризированы
• Внешние маршруты будут распространены по всем областям 
• Специфика метрики внешних маршрутов тоже может дать себе знать
• Внешние маршруты не будут переданы в stubby и NSSA области
• Внутренние маршруты будут обладать приоритетом над ними.

Для борьбы с указанными проблемами и было создано следующее решение – супербэкбон (superbackbone). Данная область добавляет новую иерархическую ступень в традиционные взаимоотношения областей OSPF.  Собственно, это и изображено на рисунке:

При этом роли распределятся следующим образом:

• PE роутеры будут являться ABR и ASBR.
• CE роутеры будут ABR.

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

При таком исполнении мы увидим некоторой упрощение общей топологии:

• PE роутеры будут являться ABR и ASBR.
• CE будут простыми роутерами.

В обоих случаях маршруты данного VPN будут переданы от PE к PE посредством расширенных BGP-комьюнити, а потом реэкспортированы обратно в OSPF в виде LSA 3. Теперь рассмотрим всё это более детально. Вот наша тестовая топология:

 

Для облегчения понимания, внесу некоторые пояснения:

P1, P2 – MPLS-ядро сети, BGP-free.

RR – Route Reflector.

PE1, PE2 – собственно граничные провайдерские маршрутизаторы, клиенты route reflector'a.

CE1, CE2 – клиентские маршрутизаторы.

Подобный дизайн типичен для SP-сети. MP-BGP здесь служит для распространения VRF меток для каждого PE устройства. Рассмотрим поэтапно, что именно нам нужно для полноценной работы данной схемы:

 

1.    Настроенные и поднятые интерфейсы. Прописываем сети /30 или /31 сети на физических линках, проверяем доступность пингом. Поднимаем лупбэк с /32 адресом.

2.   Полноценная L3 связность между всеми провайдерскими устройствами. Обеспечивается запуском IGP протокола. Т.к. у нас всё подготовлено это займет немного времени.

3.      Запуск MPLS на всех внутренних интерфейсах операторского оборудования.

4.     Настройка RR. Очень важный шаг, без функционирующего RR мы столкнемся с проблемой масштабирования MP-iBGP соединений. Т.к. для полноценной работы ему требуется связность со всеми своими соседями.

5.      Настройка BGP на PE-оборудовании. 

Итак, после всего этого нам останется только настроить VRF на всех причастных к этому устройствах. Для этого на PE1, PE2, RR потребуется прописать собственно сам VRF и новую address-family для него:

ip vrf cust_a

 rd 65535:1

router bgp 65535

 address-family ipv4 vrf cust_a

 redistribute connected

 no synchronization

 exit-address-family

Теперь останется только настроить OSPF для каждого из клиентских включений. Делается это следующим образом:

int fa0/1

desc TO_CE1

ip vrf forw cust_a

ip add 192.168.1.254 255.255.255.0

ip ospf 2 area 1

router ospf 2 vrf cust_a

 router-id 192.168.1.254

redis bgp 65535 sub

 log-adjacency-changes

router bgp 65535

 address-family ipv4 vrf cust_a

 redis ospf 2 vrf cust_a

После этого обычным образом настраиваем OSPF на CE1 и CE2. Радуемся получившийся связности.

Частности.

После такого чрезмерно общего введения, стоит уделить внимание определенным частностям, или вернее сказать особенностям применения OSPF в MPLS окружении. Например, начнем со следующего сценария:

Заказчик нашего VPN организовал между своими точками резервный канал, объединив таким образом устройства CE1 и CE2. Заказчик хочет использовать OSPF, какую область ему стоить задать на этом линке? Какие особенности работы проявятся при том или ином решении?

 

Представим, что он решил выбрать Area 0. Тогда мы получим классический случай разделенной нулевой области. Ведь у нас будет и супербэкбон, и нулевая область м/у CE1 и CE2. Согласно известному правилу, ABR дропает все LSA3 пакеты полученные не через бэкбон (в случае есть у него есть интерфейс в состоянии FULL Adjacency в этой области). Т.е. CE1 будет получать обновления со стороны CE2, но дропать все, что придет со стороны провайдера MPLS. Такое же поведение будет и у PE1/PE2 в отношении LSA3 приходящих от CE1/CE2. Решение данного кейса столь же классическое – требуется поднять виртуал-линки PE1-CE1 и PE2-CE2, объединив таки образом нулевую область. Тогда мы подойдем к следующему шагу.

Представим, что клиент стал не заморачиваться и решил на всю получившуюся сеть растянуть одну область, например Area 0. Что он заметит спустя некоторое время? Банальный факт, что трафик м/у CE1 и CE2 стал ходить по резервному линку. Даже если он загрубит на нем OPSF Cost командой ip ospf cost 1000 – это не поможет. OSPF всегда предпочитает маршрут полученный изнутри области, маршруту полученному снаружи. Дальше – больше. В случае если у клиента будет еще одно включение на PE1 то и его трафик к CE2 станет ходить через резернвый канал. Да и вообще, провайдерский BGP в силу своего алгоритма best path selection станет выбирать маршрут анонсированный через IGP.

Решение? Требуется поднять sham-link м/у нашими PE1 и PE2 поверх нашего MPLS. Sham-link представляет собой control plane туннель, позволяющий передавать LSA1 и LSA2. Для его работы нам потребуется пара лупбэков в VRF’е заказчика, по одному на PE. Адреса лупбэков должны анонсироваться только в BGP, после этого в настройках ospf мы просто поднимем sham-link. Подобный сценарий нам понадобится и в том случае, если клиент решит использовать Area 1 или любую другую на всей своей сети, т.к. маршруты приходящие со стороны провайдера будут inter area.

В итоге, наша схема станет выглядеть так:

 

Занятности.

В получившейся топологии, есть один несколько тонких мест. Как известно, ABR должен игнорировать приходящие со стороны простых областей LSA3 пакеты. Это одно из правил позволяющих создать loop-free структуру с несколькими задействованными областями. В MPLS VPN добавляется ещё пара элементов для достижения этого результата. Первый из них – это DN-бит, который согласно RFC 4576, должен устанавливаться на все исходящие от PE LSA обновления. Т.е. на типы 3, 5 и 7 (When a type 3, 5, or 7 LSA is sent from a PE to a CE, the DN bit MUST be set.  The DN bit MUST be clear in all other LSA types). И в случае если другой PE переполучит от CE LSA с установленным DN-битом, он просто отбросит его. Однако реализация этого у Cisco несколько отличается от рекомендаций. Роутеры Cisco помечают таким образом только LSA 3 пакеты, для 5 и 7 используется схожий механизм – route tag. При отправке LSA 5 или LSA 7 в сторону CE, они будут помечены тэгом с номером используемой AS. Это детально описано в RFC 4577.