В начале двухтысячных индустрия усиленно занялась поисками решений для L2VPN в масштабах оператора.
Критерии были следующими:
- Простота внедрения (очевидное требование)
- На существующем железе (протоколы не должны требовать аппаратной доработки)
- Поддержка уже функционирующих протоколов на сетях операторов.
- Принцип работы нового механизма не должна кардинально отличаться от существующих моделей.
Люка Мартини — бывший сотрудник Cisco — на этот необъявленный конкурс предоставил решение на основе LDP.
Работать оно будет поверх MPLS-сети.
Для сигнализации меток будет использоваться LDP, который уже является частью MPLS.
VPLS Martini Mode описан в стандарте RFC4762.
Именно это лаконичное решение и стало стандартом де факто в большинстве сетей по всему миру.
С тем, как работает Martini-mode мы уже познакомились в части про VPWS. Ровно то же самое и здесь, только удалённые LDP сессии создаются для каждого VSI не с одним соседом, а с несколькими.
LDP используется для распределения сервисных меток.
Удалённые сессии с каждым соседом в VPLS-домене настраиваются вручную.
Поскольку заранее известны все участники этого VPLS, каждому из них LDP выделяет индивидуальную метку в сообщении LDP Label Mapping Message.
Если добавляется новый PE в VPLS-домен, необходимо настроить LDP-соседство со всеми существующими PE этого VPLS. После чего с каждым из них новый PE обменятся метками.
В течение всего времени, LDP проверяет доступность своих соседей. Если какой-то из соседей выходит из группы или становится недоступным, сессия разрывается и все изученные MAC'и в PW к этому соседу очищаются.
Если состояние какого-либо из AC-портов VPLS-домена переходит в состояние Down, либо происходит другое событие, заставляющее очистить MAC-адреса с AC-порта, то PE сообщает об этом всем своим соседям, настаивая на удалении MAC-адресов в сообщении LDP MAC Withdraw (К сожалению CSR1000V на тестовом стенде этого не делает).
Известны случаи, когда в случае изменения состояния AC-порта, PE отправляет сообщение LDP MAC withdraw без уточнения, какие именно MAC'и. Это означает, что каждый сосед должен очистить всю таблицу MAC-адресов данного VPLS-домена.
Теперь представьте, что счёт идёт на сотни, возможно, тысячи записей. И по всей сети все PE начинают изучать MAC-адреса. А что они делают с кадром, когда не находят MAC получателя? Рассылают всем. Возникает кратковременный широковещательный шторм без петли коммутации.
Пока без петли. Ирония в том, что такой взрыв броадкаста можно забить каналы передач данных, особенно узкие, например, РРЛ. И тогда начнут теряться пользовательские данные. А если забьются очереди приоритетного трафика CS6-CS7, в котором передаются пакеты протоколов, то и STP может поломаться и ERPS сомкнуть кольцо — и образуется вполне себе реальная петля коммутации с нарастающим эффектом.
Если VPLS-домен не ограничен небольшим участком сети (а обычно это не так) прилечь может всё.
Нет повести печальнее на свете, чем шторм в VPLS-сЕти.
Пожалуйста, не делайте так.
В конце я расскажу о других неприятных ситуациях, которые могут возникнуть в VPLS сети.