MPLS L2VPN отказоустойчивость

Тема отказоустойчвости в MPLS вообще, и в L2VPN в частности, возведена просто во главу угла.  Когда читаешь какой-нибудь best practice просто удивляешься, как это вообще может сломаться. Насколько должно не повезти или на сколько руки не из того места должны расти. Тему High Availability (HA) я немного затрагивали в посте про MPLS вообще и в посте про FRR. Так в чем же проблема того же FRR или Secondary LSP? Да не в чем... просто мало...

Все посты про MPLS VPN можно посмотреть по тегу MPLS или в обобщающем посте.

Тема HA в MPLS полна подводных граблей и тонкостей. Лезть в них мы не будем, поэтому просто возьмем простую схемку сети для примера и попробуем навернуть в ней максимально всего для защиты VLL и VPLS сервисов. Даже в сигнализацию лезть не будем. Цепляться к вендорам по возможности тоже не будем.

CORE

Для начала разберемся с ядром сети, потом представим, что это облачко, и будем держать в голове все, что придумали. Итак, в ядре провайдера у нас четыре Provider (P) роутера. Задача каждого их них - молотить трафик полагаясь на метки и участвовать в сигнализации транспортных туннелей (PSN), по которым пойдет потом pseudowire туннели с клиентским трафиком. Кроме P роутеров в ядре есть ещё Provider Edge (PE) роутеры, которые стоят на границе сети. Их задача отличается от P роутеров. Они ответсвтенны за сервисы в сети. К ним подключаются клиенты, после чего они передают их трафик в точку назначения через сигнализированные ими pseudowire туннели.

Вспомним, что MPLS строится поверх IP сети, соответственно, для того чтобы MPLS работал, нам нужен стабильный и быстро восстанавливающийся протокол динамической маршрутизации. Это нужно как для IP связности всех нод в сети, так и для того, чтобы информация о сети передавалась MPLS устройствам для корректной работы CSPF алгоритма. Сходимость OSPF TE и IS-IS TE быстрая, но не для наших задач. Полагаться на hello протокол просто неприлично. Конечно, hello таймер можно уменьшить до малых значений, но тогда возрастет нагрузка на сеть, что не желательно.

Для того чтобы ускорить время реакции OSPF или IS-IS можно исплользовать:

• Bidirectional Forwarding Detection (BFD). Это протокол, который поверх IP шлет hello-сообщения своим соседям. После установления сессии, BFD может быстро понять, что тот или иной линк пропал и сказать об этом вышестоящему протоколу (OSPF, IS-IS, RSVP). Вышестоящий протокол сразу же начнет принимать какие-либо действия не дожидаясь пока его медленные dead таймеры сработают.

• Ethernet in the First Mile (EFM). Протокол который работает ещё жестче. Известно, что самый плохой случай для сетевых протоколов это обнаружение "не локальной" аварии. EFM делает аварию наиболее очевидной. ) EFM довольно сложен, но работает как топор. Если кратко, на L2 происходит обнаружение соседей средствами рассылки multicast кадров. Как только EFM понимает, что на линке случилась авария, он просто кладет линк. Причем сделать это он может на subsecond уровне. Работает он таким образом быстрее BFD, потому как ему не нужно сообщать информацию об аварии вышестоящим протоколам. В качесвте плюса так же можно отметить тот факт, что вышестоящим протоколам не нужно поддерживать интероперабильность с EFM. Для них авария выглядит просто как падение линка, на которую они реагируют незамедлительно. 

Ок, протокол маршрутизации теперь сходиться как молния. На картинке ниже на всех линках запущен OSPF+EFM. Конечно же, схема упрощена и не все линки на деле будут просто проводами. Например, оба PE могут быть поключены через радио-релейный пролет. Даже в таком случае, EFM должен отработать очень быстро.

PE маршрутизаторы должны быть соединены по схеме каждый с каждым (full-mesh). Что мы можем добавить здесь? Будем использовать RSVP-TE, который позволит нам пользоваться всеми фишками, такими как уже известные FRR и Secondary LSP. Более того, это позволит нам сигнадизировать LSP с резервированием пропускной способности. На каждом PE маршутизаторе настраивается PSN туннель до каждого PE. На каждом таком PSN сигнализируется доволнительный Secondary LSP, который должен проходить по как можно более отличающемуся пути. Так же включаем FRR. Теперь каждый маршрутизатор по пути попытается заранее простроить допольнительные пути. Можно ещё линки покрасить, группы риска расставить и прочее. Почитать про все это можно в посте про FRR.

На картинке левый PE сигнализирует PSN туннель до правого. В качестве опции, левый PE так же сигнализирует второй LSP через нижнюю часть топологии. Ну и при сигнализицации так же задается FRR. На схеме видно как левый-верхний P роутер просчитать обходной путь до своего соседа через нижний роутер.

Наверняка можно ещё что-нибудь придумать, но пришло время обратить взоры на Edge сеть в организации VLL сервиса. Теперь PE девайсы мы обозначим облачком.

VLL

Теперь к сети можно поключить Customer Edge (CE) устройство. Это железка преналдежащая абоненту. Конечно же глупо подключить CE одним линком в PE. Давно известна технология Link Aggregation Group (LAG). Поключаем CE к PE двумя линками в LAGe.

Ясно, что PE1 может отказать, а нам надо его зарезервировать. Подключаем ещё одним LAGом CE1 к PE2. Выглядит красиво, но работать не будет. Надо каким-либо образом управлять состоянием четырех линков и не заколцевать трафик. Решений несколько, но самые красивые из них относятся к группе Multi Chassis LAG. В таком случае, все четыре линка для CE1 выглядят как один LAG на 4 порта, а PE1 и PE2 согласовывают состояния этих линков и избавляют сеть от петли. У Extreme Networks все четыре линка могут передавать трафик, у Алкателя, например, только одно устройство (PE1 или PE2) терменирует активные линки, второе на подхвате. Такое же подключение производим с CE2.

При использовании MC-LAG от Alcatel, только два порта из четырех будут пропускать трафик. Остальные два линка будут заблокированы, потому как два PE роутера договорятся между собой об этом и передадут через соответсвующие линки определенные сообщения LACP.

После всех манипуляций по резервированию точки подключения и резервирования PE устройства можно сигнализировать pseudowire для VLL сервиса. Однако и её надо резервировать. Тут все просто, сигнализируем ещё один stanby туннель на каждом PE маршрутизаторе. В процессе сигнализации PE устройства передадут статусы своих pseudowire, в итоге из всех путей выберется один возможный - это pseudowire туннель, у которого обе стороны в состоянии active.

На схемке ниже, PE1 сигнализирует pseudowire до PE2. Таким же образом будет сигнализирован второй туннель до PE4, однако PE1 придержит его на будущее и переведет в состояние not-forwarding. PE3 поступает аналогичным образом.

Может быть ситуация, при которой pseudowire PE1-PE2 упадет, в таком случае поднимется standby туннель от PE1 до PE4. Вы уже поняли, я думаю. Что если и он тоже свалится? Если мы используем не Extreme'овский MLAG, то CE нет никакого смысла слать трафик в сторону PE2, потому что между CE и PE1 нет аварии. В таком случае, при обрыве двух линков PE1-PE2, PE1-PE4, трафик будет приходить на PE1 и оставаться там. Для того чтобы предусмотреть и эту ситуацию, нужна ещё пара pseudowire туннелей, которые соединяют точку подключения в сторону абонента с точкой подключения pseudowire в сторону ядра. Таким образом, у нас есть ещё два туннеля между:

Точкой подключения абонента на PE1 и точкой подключения pseudowire на PE2

Точкой подключения абонента на PE2 и точкой подключения pseudowire на PE1.

Довольно весело, я считаю.

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

Резюмируем с VLL. Мы имеем:

1. Быструю сходимость протокола маршрутизации в ядре с помощью (BFD или EFM)
2. Запасные пути прохождения транспортных туннелей (Secondary LSP, FRR)
3. Множественные точки подключения абонента.
4. Резервирование пограничных (PE) устройств.
5. Запасные pseudowire туннели до выходных PE устройств.
6. Тут уж точно PROFIT!

VPLS

В ядре все то же самое, тут ясно. Многое в VPLS пересекается с VLL, но есть и особенности. VLL имеет point-to-point природу, а значит в единицу времени существует только одни путь от точки А до точки B. VPLS же является развитой L2 сетью. К тому же, не стоит забывать, что VPLS бывает иерархичным.

Ясно, что линки и PE ноды надо резервировать, поэтому сразу перейдем к схеме с множественным подключением.

В таком случае мы можем запустить STP VPLS для того чтобы не допустить петли, либо использовать Multichassis LAG. STP я не люблю, так что считаю более красивым решением Multichassis LAG для подключения абонентов. Тут ничего нового.

 

Понятно, что вся "мякотка" организовать отказоустойчивость в H-VPLS. Поэтому изменим схему. Теперь четыре PE агрегируют pseudowire туннели и выступают как hub-PE. А PE, r которым подключен абонент, будут spoke-PE. Spoke-PE подключены с помощью специальной spoke pseudowire к hub-PE, Об этом я писал в посте про VPLS. 

Понятно же, что вообще не вариант подключать одним spoke-pseudowire туннелем к одному hub-PE девайсу. Надо двумя туннелями и к двум PEшкам)

Помним, что spoke pseudowire не подвержена split horizon правилу, а значит надо каким-то образом избежать петель. Самый простой вариант, это сигнализировать одну spoke pseudowire как active, а вторую как backup. По одной будет бегать трафик, а вторая будет ждать падения первой.
На картинке Spoke-PE1 сигнализировал два pseudowire туннеля. Первый туннель ведет к hub-PE1, он находится в активном состоянии. Второй туннель ведет к hub-PE3. Этот туннель будет использован в случае аварии.

Второй вариант - сигнализировать все spoke pseudowire и запускать среди них инстанс STP, который заблокирует дополнительные pseudowire и избавит от петель. Можно в каждом сервисе запустить по STP, а можно запустить один Management-VPLS инстанс, который будет считать топологию сразу для многих сервисов.

Используя любую схему резервирования в VPLS, каждый раз, когда какой-либо pseudowire туннель меняет состояние, по сети с помощью T-LDP расходиться сообщение о сбросе FDB на Visrtual Switching Instance (VSI). Примерно такое же поведение есть в STP при перестроении топологии. Нужно это для того чтобы трафик всегда шел верным путем, а не попадал в упавший pseudowire туннель из-за того, что запись в FDB ещё не очистилась по таймеру. 

В VLL когда PE терял все свои pseudowire туннели, использовались специальные ICB pseudowire. В VPLS используется немного другой подход. Когда hub-PE понимает, что он потерял все свои mesh pseudowire соединяющие его с другими hub'ами, он может отправить специальное сообщение в сторону spoke-PE, в котором заявляет о том, что pseudowire находится в состоянии "not forwarding". После чего spoke-PE сразу же переключается на stanby pseudowire, которая ведет к другому hub-PE. Это правда уже проприетарная алкателевская фишка, которая носит название Block-on-Mesh-Failure (BOMF).

На картинке ниже, hub-PE1 потерял два туннеля до hub-PE2 и hub-PE4. Трафик от CE1 все ещё приходит на него, но  hub-PE1 сбрасывает его. Трафик преодолевает путь CE1 -> spoke -> PE1 -> hub-PE1, потому что пока ещё нет никаких предполсылок для того чтобы оба spoke-PE со стороны абонентского устройства опустили линк spoke-PE1-CE1 и подняли spoke-PE2-CE2. Для того чтобы это произошло, hub-PE1 шлет специальное сообщение в сторону spoke-PE1 с просьбой не слать ему трафик. В итоге spoke-PE1 переводит pseudowire до hub-PE3 в активное состояние и трафик начинает проходить по запасному маршруту, минуя аварийные линки.

Пока все. Каждый из пунктов и каждая из картинок достойна отдельной статьи. Одно распространение MAC-Flush при перестроении топологии чего стоит. Но я ограничусь пока что вышеизложенным.

Пока что закончу, наверное, серию постов про MPLS. Пока что не знаю точно, о чем напишу дальше, но уже есть идеи...