# Data Plane

В общих чертах передача пользовательского трафика выглядит, как и для случая VPWS, но добавляется шаг **изучения MAC**'ов и проверки MAC-таблицы при передаче трафика.

1. На AC-порт PE-маршрутизатора пришёл пользовательский кадр.
2. PE-маршрутизатор смотрит в заголовок Ethernet и проверяет MAC-адрес отправителя.

   А) Если он уже есть в таблице MAC-ов данного VSI, PE сразу переходит к шагу 3.

   Б) Если этого адреса ещё нет — он записывает соответствие MAC-порт в таблицу и тоже переходит к шагу 3.
3. PE-маршрутизатор смотрит в заголовок Ethernet и проверяет MAC-адрес получателя.

   А) если таковой присутствует в таблице MAC-адресов данного VSI:\
   1\. PE ищет выходной интерфейс для кадра с данным MAC'ом. Это может быть физический интерфейс или PW. 2. Если порт назначения — физический интерфейс — просто отправляет в этот порт.\
   Если это PW, то добавляет соответствующую метку — сервисную. Эта метка будет неизменна до конца пути. 3. PW — это всегда канал между двумя IP-узлами, поэтому зная IP-адрес удалённого PE, локальный PE из таблицы меток извлекает транспортную и ставит её сверху стека — она будет меняться на каждом P-маршрутизаторе. Б) Если же MAC-адрес неизвестен, то как порядочный коммутатор наш PE должен выполнить широковещательную рассылку кадра по всем PE данного VSI. И он делает, подлец.
4. Локальный PE составляет список всех удалённых PE этого VSI, и, создав копии этого кадра, вставляет в них сервисные метки — каждому своя.
5. Далее на каждую копию кадра навешивается ещё и транспортная метка (тоже своя для каждого PE).
6. Весь этот ворох кадров рассылается по сети провайдера.
7. Также копии широковещательного кадра отправляются в AC-интерфейсы, если такие есть, без заголовков MPLS.
8. Удалённый PE после получения кадра и снятия меток (то есть когда уже определил VSI) тоже действует как обычный коммутатор: А) Если MAC-адрес **источника** пока не известен, вносит его в таблицу. В качестве входного интерфейса будет указан PW к Ingress PE. Б) Если MAC-адрес **назначения** ему известен, отсылает кадр в тот порт, за которым он изучен. Отсылается уже чистый Ethernet-кадр, без каких-либо заголовков MPLS. В) Если этот MAC не удалось найти в таблице? Широковещательная рассылка по всем AC-портам этого VSI. Заметьте, **PE не будет рассылать этот кадр в PW данного VSI**, потому что все другие PE уже получили копию этого кадра от входного PE. Это всё то же правило расщепления горизонта (Split Horizon), и так достигается отсутствие петель коммутации и широковещательных штормов. (Ах, если бы всё было так просто...)

> Есть просто [гиф](https://habrastorage.org/files/954/959/af4/954959af411c4535adbed1cf6d269ca6.gif), которая показывает, что происходит.\
> А есть та же гиф, только с голосом.

Как и в обычном коммутаторе записи в MAC-таблице VSI периодически протухают и удаляются.

В вопросе изучения MAC-адресов в VPLS есть один нюанс, который резко отличает его от L3VPN.\
PE должен не просто знать физический порт, откуда пришёл кадр — важно определить соседа или, точнее PW как виртуальный интерфейс. Дело в том, что клиентский кадр нужно отправить не просто в какой-то физический порт, а именно в правильный PW, иными словами, правильному соседу.\
Для этой цели каждому соседу выдаётся личная метка, с которой тот будет отправлять кадр этому PE в данном VPLS-домене.\
И в дальнейшем по VPN-метке, заглянув в LFIB, PE узнает, от какого соседа пришёл кадр.\
Напомню, что L3VPN без разницы, откуда пришёл IP-пакет, поэтому для префикса в VRF всем соседям сообщается одна и та же метка.

Схема доставки пользовательского трафика незамысловата. Но что же с пресловутым Control Plane'ом? Опять придётся поломать мозги или малыми жертвами?\
Извините, но дальше начинается трэш и содомия. Не сразу — попозже, но будет. Вы действуете на свой страх и риск.