Теоретические основы и архитектура

Rosen mVPN (RFC 6037, draft-rosen) - первое решение для multicast внутри L3VPN, основанное на понятии MDT. Каждый PE создаёт для клиентской VRF multicast-VRF и туннельный интерфейс MTI, а все PE одной mVPN подписываются на групповой адрес default MDT в глобальной таблице. Клиентские пакеты и PIM-сообщения упаковываются в GRE с внешним адресом назначения - группой MDT, поэтому ядру достаточно обычного PIM, а PE одной VPN видят друг друга как соседей на LAN-подобном интерфейсе. Для мощных потоков вводят data MDT: PE сообщает группу через MDT Data TLV, и только PE с получателями присоединяются к ней. Для обнаружения PE применяют ASM или MDT SAFI в BGP. Урок объясняет механику и показывает, почему Rosen плохо масштабируется: состояние в ядре, рассылка default MDT на все PE, нагрузка клиентского PIM, GRE-накладные расходы и сложность Inter-AS. Эти ограничения подводят к NG-MVPN в следующем уроке.

Идея Rosen: мультикаст-VRF и туннель через ядро

Решение Cisco, описанное в RFC 6037 (draft-rosen), строится на простой мысли: ядро провайдера не знает про VRF, поэтому клиентский multicast инкапсулируется в multicast самого провайдера. На каждом PE для VRF создаётся mVRF - таблица multicast-маршрутизации этой VRF (отдельные PIM-соседи, mroute, RPF). Все PE одной mVPN соединяются мультикаст-туннелем MDT (Multicast Distribution Tree): клиентский пакет оборачивается в GRE, внешний IP-заголовок имеет источником loopback PE (адрес BGP-пиринга), а получателем - групповой адрес MDT из глобального пространства провайдера. Ядро размножает такой пакет обычным PIM, не зная, что внутри. MPLS-метки здесь не участвуют: пересылка в ядре идёт по IP multicast, а MPLS остаётся для юникастного VPN-трафика.

Default MDT и интерфейс MTI

Default MDT - группа, которую настроили в VRF командой mdt default; к ней присоединяются все PE этой mVPN, и каждый PE является корнем собственного дерева (PE,G) и листом деревьев остальных. В ядре для одной mVPN из N PE появляется до N записей (S,G) на каждый P-маршрутизатор по пути. PE создаёт для default MDT виртуальный интерфейс MTI (Multicast Tunnel Interface): для VRF это обычный multi-access интерфейс, куда уходят и откуда приходят клиентские PIM-сообщения и данные. Для проверки RPF интерфейс MTI считается допустимым входным интерфейсом, если юникастный маршрут к клиентскому источнику (VPNv4) ведёт к удалённому PE, а этот PE является PIM-соседом на MTI. Поэтому адрес next hop маршрута VPNv4 должен совпадать с адресом, из которого сформирован туннель.

Клиентский PIM поверх MDT

Клиентский PIM работает в VRF так же, как в обычной сети: Hello раз в 30 секунд, Join/Prune раз в 60 секунд, выборы DR на MTI. Для PIM клиента MTI выглядит как LAN, в которой находятся все PE. Поэтому Join отправляется на MTI и принимается всеми PE, при этом действует правило Join suppression/override и выбор Assert-победителя, если поток пришёл с нескольких PE. Служебные сообщения клиентского PIM тоже идут через default MDT и достигают всех PE, включая те, где получателей нет.

Data MDT

Default MDT рассылает все клиентские multicast-пакеты всем PE этой mVPN, даже если получатель есть лишь за одним из них. Чтобы не тратить полосу, для мощных потоков вводится data MDT. Команда mdt data задаёт пул групп и порог в kbps. Когда клиентский поток (C-S,C-G) превышает порог, исходный PE выбирает свободную группу из пула и сообщает её сообщением MDT Data TLV в UDP-пакете (порт 3232 на адрес 224.0.0.13) по default MDT. PE с получателями этого (C-S,C-G) присоединяются к data MDT группе, остальные - нет. Затем поток переносится на data MDT, а при падении трафика возвращается на default. Пул нужно размерить: число одновременных data MDT ограничено размером пула, оставшиеся потоки остаются на default MDT.

Обнаружение PE: ASM или MDT SAFI

PE должен знать адреса других PE той же mVPN, чтобы присоединиться к (PE,G). При ASM в ядре (PIM-SM с RP) источники находят друг друга через общее дерево: все PE отправляют в группу, а RP связывает источники с получателями. Для PIM-SSM в ядре адреса источников нужно знать заранее, и RFC 6037 вводит MDT SAFI (AFI 1, SAFI 66): PE отправляет BGP-обновление с RD, адресом PE и групповым адресом MDT, а получатель с тем же RT присоединяется к (PE,G) через ip pim ssm default. Адреса из MDT-SAFI позволяют использовать SSM (проще, без RP) и ограничить область распространения RT. RR должен передавать семейство mdt.

Ограничения Rosen

Во-первых, в ядре обязателен PIM (и RP при ASM); у P-маршрутизаторов растёт состояние: для каждой mVPN как минимум N записей default MDT плюс data MDT. Во-вторых, default MDT рассылает данные всем PE, пока поток не перешёл на data MDT. В-третьих, клиентский PIM обменивается периодическими сообщениями между всеми парами PE, что даёт нагрузку на control plane. В-четвёртых, GRE добавляет 24 байта (20 байт внешнего IP и 4 байта GRE), и клиентский пакет с MTU 1500 может не поместиться. В-пятых, Inter-AS требует дополнительных механизмов (BGP connector, RPF vector). Наконец, ядро использует IP multicast, а не метки, поэтому нет единого плана с LDP/RSVP-TE и FRR. Эти ограничения привели к NG-MVPN: BGP вместо PIM для клиентской сигнализации и P2MP-туннели вместо mGRE (следующий урок).