Разбираясь с современными методами организации multicast VPN я заметил, что в сети не так много материала, описывающего принципы и детали работы технологий. На сайте вендора представлена достаточная конфигурация для внедрения, но не описан смысл всех производимых деяний.
В этом цикле статей я постараюсь немного приоткрыть завесу тайны того как всё работает под капотом.
Прим. Автор подразумевает, что читатель хорошо знаком со следующими технологиями: OSPF, BGP, PIM, MPLS.
Заинтересовавшимся добро пожаловать под кат.
Основной задачей является туннелирование мультикаст-пакетов между РЕ маршрутизаторами (от Ingress PE к одному или более Egress PE). Для этого необходимо построить наложенную (overlay) сеть поверх опорной (underlay) инфраструктуры.
Если мы обратимся к RFC6513, то найдем там одно довольно пространственное пояснение по поводу, как необходимо передавать трафик между РЕ-маршрутизаторами: P-tunnels must be used a P-tunnel is a transport mechanism inside the network of the Service Provider that instantiates a Provider Multicast Service Interface (PMSI). A PMSI is a conceptual overlay on the P-network with the following property: a PE in a given MVPN can give a packet to the PMSI, and the packet will be delivered to some or all of the other PEs in the MVPN, such that any PE receiving the packet will be able to determine the MVPN to which the packet belongs.
Т.е. если просто следовать сказанному, то вся multicast VPN инфраструктура будет выглядеть приблизительно вот так:
Осталась самая малость разобраться с тем, как строить этот PMSI и как РЕ устройствам узнавать друг о друге.
На текущий момент мне известно четыре способа создания Р-туннелей:
- Protocol Independent Multicast (PIM, P-PIM, Provider-PIM; PIM работающий внутри опорной сети в рамках глобальной таблицы маршрутизации GRT)
- Multipoint Label Distribution Protocol (mLDP)
- Resource Reservation Protocol Traffic Engineering (RSVP-TE)
- Ingress Replication (IR)
Прим. В статьях основное внимание будет уделено созданию PMSI с помощью PIM и mLDP.
После поднятия Р-туннелей, РЕ должны произвести сигнализацию о наличии Источников и/или Получателей трафика в сети. Делается это одним из двух вариантов:
- PIM (C-PIM, Customer-PIM; PIM работающий внутри наложенной сети в рамках клиентской таблицы маршрутизации (VRF))
- BGP.
Ключевыми блоками mVPN являются следующие компоненты:
- тип корневого дерева. Корневое дерево определяет как будет передаваться пользовательский многоадресный трафик (C-Multicast) поверх опорной сети.
- протокол построения корневого дерева
- протокол сигнализации клиентского трафика
Мультикастные деревья
Как известно, путь следования многоадресных пакетов в сети часто называют мультикастным деревом.
В зависимости от того, как может передаваться многоадресный трафик, все деревья можно разделить по группам:
- точка-точка (Point-to-Point)
- это классическое дерево (должно быть знакомо всем тем, кто работал с MPLS сетями), которое представляет собой LSP для передачи одноадресного (unicast) трафика.
- точка-многоточка (Point-to-Multipoint)
- это дерево в котором только одно устройство (корень дерева, root) может передавать пакеты в сеть. По своей природе дерево является однонаправленным (unidirectional).
- многоточка-многоточка (Multipoint-to-Multipoint)
- это двунаправленное дерево (bidirectional), в котором трафик передается либо по направлению к корневому маршрутизатору, либо от него. Любой РЕ может передавать пакеты в сеть, равно как и принимать их.
- точка-точка-многоточка (Point-to-Point-to-Multipoint)
- дерево представляет собой микс P2P и P2MP деревьев. Любой РЕ
коммутатор может передавать пакеты внутрь P2P LSP в сторону
корневого РЕ, который в свою очередь передает пакеты дальше
посредством P2MP до всех остальных РЕ.
Необходимость в таком дереве будет рассмотрена в главе, посвященной тематике Partitioned MDT.
- дерево представляет собой микс P2P и P2MP деревьев. Любой РЕ
коммутатор может передавать пакеты внутрь P2P LSP в сторону
корневого РЕ, который в свою очередь передает пакеты дальше
посредством P2MP до всех остальных РЕ.
Функционально деревья делятся на три категории:
- Multi-Directional Inclusive PMSI (MI-PMSI, aka Default MDT)
- Selective PMSI (aka Data MDT)
- Multi-Directional Selective PMSI (aka Partitioned MDT)
О каждом из этих деревьев мы подробно поговорим в следующих разделах (в следующих выпусках). Сейчас же остановимся на дереве, которое является обязательным аттрибутом любой имплементации mVPN и носит название Default MDT.
Default MDT
Default MDT представляет собой древовидную структуру для соединения всех PE-маршрутизаторов в рамках одного VPN (VRF) с включенной многоадресной рассылкой. Преимущество наличия Default MDT заключается в том, что оно облегчает передачу сигнализации PIM в наложенной сети.
Default MDT всегда включено и из-за этого все маршрутизаторы PE становятся PIM соседями в рамках VRF, что позволяет передавать PIM сигнализацию (Join/Prune, RPT Switchover) поверх Default MDT также, как если бы все РЕ маршрутизаторы находились в одном LAN сегменте.
mVPN Profile 0
Одним из наиболее простых способов реализации mVPN является вариант настройки который известен под кодовым именем Profile 0, именуемый в народе как Draft Rosen.
Основные компоненты реализации профиля:
- использование Default MDT
- использование PIM для сигнализации внутри наложенной сети
- использование PIM внутри опорной сети
- инкапсуляция C-multicast трафика внутрь GRE (mGRE если быть точным)
Прежде чем переходить к описанию того, как передается и сигнализируется клиентский трафик в рамках рассматриваемого профиля, необходимо разобраться с построением опорной сети. Из минимального набора нам потребуется:
- BGP (в частности, адресное семейство VPNv4), с помощью которого будут передаваться unicast клиентские адреса для прохождения RPF проверок многоадресного трафика.
- OSPF или IS-IS (по вкусу) для обеспечения IP-связности между интерфейсами Loopback0 всех устройств, поверх которых будут строиться BGP сессии
- PIM ASM внутри опорной сети (в рамках Global Routing Table,
GRT)
- В качестве метода распространения информации о точке рандеву выберем протокол Bootstrap Router (BSR)
- LDP внутри опорной сети для распространения меток от/до РЕ.
Шаблон для настройки базовых ингридиентов:
router ospf 1 router-id X.X.X.X!ip mutlicast-routing!ip pim register-source Lo0!interface Loopback0 ip address X.X.X.X 255.255.255.255 ip ospf 1 area 0 ip pim sparse-mode!interface Gi2.Y encapsulation dot1q Y ip address 10.X.Y.Z 255.255.255.0 ip ospf 1 area 0 ip pim sparse-mode!router bgp 65001 bgp router-id X.X.X.X no bgp default ipv4 unicast neighbor Y.Y.Y.Y remote-as 65001 neighbor Y.Y.Y.Y update-source Loopback0 ! address-family vpnv4 neighbor Y.Y.Y.Y activate neighbor Y.Y.Y.Y send-community-both!####################################################### ТОЛЬКО НА ТОЧКЕ РАНДЕВУ #######################################################!ip pim rp-candidate Lo0ip pim bsr-candidate Lo0
После проведение указанных настроек, Вы можете увидеть, что на каждом из устройств появился как минимум один туннель (а на Provider RP (P-RP) целых два). При этом эти туннели не видны в конфигурации, но присутствуют в выводе show ip int brief. В чем же их назначение? Ответ: Tunnel необходим для передачи (encap) сообщений PIM-Register в сторону P-RP. На стороне P-RP дополнительный Tunnel необходим для обработки (decap) всех прибывающих Register сообщений.
Прим. Номера туннельных интерфейсов у меня и у Вас в лаборатории могут отличаться
PE1#show int tu2 | i Descr|destination|Tunnel2Tunnel2 is up, line protocol is up Description: **Pim Register Tunnel (Encap)** for RP 8.8.8.8 Tunnel source 1.1.1.1 (Loopback0), destination 8.8.8.8
>RR#show int tu0 | i Descr|destination|Tunnel0Tunnel0 is up, line protocol is up Description: **Pim Register Tunnel (Encap)** for RP 8.8.8.8 Tunnel source 8.8.8.8 (Loopback0), destination 8.8.8.8 Tunnel0 source tracking subblock associated with Loopback0RR#show int tu1 | i Descr|destination|Tunnel1Tunnel1 is up, line protocol is up Description: Pim Register Tunnel (**Decap**) for RP 8.8.8.8 Tunnel source 8.8.8.8 (Loopback0), destination 8.8.8.8 Tunnel1 source tracking subblock associated with Loopback0
В Profile 0 подразумевается передача C-multicast трафика с помощью mGRE инкапсуляции. В новом (внешнем) IP заголовке выставляется адрес многоадресной рассылки. Данный адрес должен быть маршрутизируем в рамках опорной сети (внутри GRT). Именно для этого нам необходим PIM внутри GRT. Задается данная группа с помощью следующей конструкции:
ip vrf C-ONE mdt default 239.1.1.1
Таким образом, если ingress PE получает мультикаст-пакет в рамках клиентского VRF, то этот ingress РЕ инкапсулирует его внутрь mGRE, в качестве destination IP выставляет адрес 239.1.1.1 и пакет отправляется в опорную сеть.
Очевидно, что все egress PE должны быть подписаны на ту же самую многоадресную группу. В противном случае трафик до них не дойдет. Дополнительной настройки для подписки на группу не требуется.
PE2#show ip igmp membership Flags: A - aggregate, T - tracked L - Local, S - static, V - virtual, R - Reported through v3 I - v3lite, U - Urd, M - SSM (S,G) channel 1,2,3 - The version of IGMP, the group is inChannel/Group-Flags: / - Filtering entry (Exclude mode (S,G), Include mode (G))Reporter: <mac-or-ip-address> - last reporter if group is not explicitly tracked <n>/<m> - <n> reporter in include mode, <m> reporter in exclude Channel/Group Reporter Uptime Exp. Flags Interface *,239.1.1.1 2.2.2.2 1d20h stop 2VA Lo0
Из вывода видно, что РЕ2 подписался на группу (*, 239.1.1.1) со своего интерфейса Loopback0. Это, в свою очередь, ведет к генерации PIM Join в сторону RP и формированию многоадресного дерева в опорной сети.
В выводе ниже видно, что на Р2 появляется запись в mRIB. Наличие двух маршрутов обусловлено работой PIM ASM (shared tree и source-based tree):
P2#show ip mroute 239.1.1.1IP Multicast Routing Table(*, 239.1.1.1), 2d00h/00:03:09, RP 8.8.8.8, flags: S Incoming interface: GigabitEthernet2.68, RPF nbr 10.6.8.8 Outgoing interface list: GigabitEthernet2.67, Forward/Sparse, 2d00h/00:03:09 GigabitEthernet2.26, Forward/Sparse, 2d00h/00:03:05 (2.2.2.2, 239.1.1.1), 05:22:26/00:01:55, flags: T Incoming interface: GigabitEthernet2.26, RPF nbr 10.2.6.2 Outgoing interface list: GigabitEthernet2.56, Forward/Sparse, 05:22:26/00:02:46 GigabitEthernet2.67, Forward/Sparse, 05:22:26/00:03:09
После того, как настройка MDT для vrf C-ONE растиражирована на все РЕ, на Р устройствах появляются соответствующие маршруты:
P2#show ip mroute 239.1.1.1IP Multicast Routing Table(*, 239.1.1.1), 2d00h/00:03:09, RP 8.8.8.8, flags: S Incoming interface: GigabitEthernet2.68, RPF nbr 10.6.8.8 Outgoing interface list: GigabitEthernet2.67, Forward/Sparse, 2d00h/00:03:09 GigabitEthernet2.26, Forward/Sparse, 2d00h/00:03:05(4.4.4.4, 239.1.1.1), 05:21:57/00:02:16, flags: T Incoming interface: GigabitEthernet2.56, RPF nbr 10.5.6.5 Outgoing interface list: GigabitEthernet2.26, Forward/Sparse, 05:21:57/00:03:15(3.3.3.3, 239.1.1.1), 05:22:22/00:01:46, flags: T Incoming interface: GigabitEthernet2.67, RPF nbr 10.6.7.7 Outgoing interface list: GigabitEthernet2.26, Forward/Sparse, 05:22:22/00:03:05(2.2.2.2, 239.1.1.1), 05:22:26/00:01:55, flags: T Incoming interface: GigabitEthernet2.26, RPF nbr 10.2.6.2 Outgoing interface list: GigabitEthernet2.56, Forward/Sparse, 05:22:26/00:02:46 GigabitEthernet2.67, Forward/Sparse, 05:22:26/00:03:09(1.1.1.1, 239.1.1.1), 2d00h/00:03:15, flags: T Incoming interface: GigabitEthernet2.56, RPF nbr 10.5.6.5 Outgoing interface list: GigabitEthernet2.26, Forward/Sparse, 2d00h/00:03:05
На данном этапе опорная сеть готова к передаче многоадресного трафика в рамках GRT. Но зачем нам это? ведь пользовательский трафик живет внутри C-VRF! Постараемся ответить на данный вопрос ниже.
Следующим шагом необходимо поднять интерфейс PMSI. На Cisco IOS (в рамках Profile 0) за это отвечает адресное семейство MDT процесса BGP. Как только на РЕ появляется сконфигурированный MDT сосед, операционная система автоматически создает PMSI интерфейс.
Все MDT сессии будем строить также через Route Reflector (R8).
PE1#sh run | s bgprouter bgp 65001 ! address-family ipv4 mdt neighbor 8.8.8.8 activate exit-address-family
На РЕ сразу же появляется дополнительный интерфейс Tunnel:
*Nov 12 11:27:45.131: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up
PE1#show int Tu0 | i transport|source|Tunnel0Tunnel0 is up, line protocol is up Tunnel source 1.1.1.1 (Loopback0) Tunnel0 source tracking subblock associated with Loopback0 Set of tunnels with source Loopback0, 2 members (includes iterators), on interface <OK> Tunnel protocol/transport multi-GRE/IP Tunnel transport MTU 1476 bytes
Интерфейс Tunnel0 ничто иное, как PMSI относящийся к C-VRF.
PE1#show ip pim vrf C-ONE interface Address Interface Ver/ Nbr Query DR DR Mode Count Intvl Prior172.1.11.1 GigabitEthernet2.111 v2/S 1 30 1 172.1.11.11172.1.15.1 GigabitEthernet2.115 v2/S 1 30 1 172.1.15.151.1.1.1 Tunnel0 v2/S 3 30 1 4.4.4.4
Через данный интерфейс РЕ начинает рассылку сообщений PIM Hello (на адрес 224.0.0.13) и устанавливает отношения соседства со всеми другими РЕ, на которых настроена VRF с таким же адресом для Default MDT.
PE1#show ip pim vrf C-ONE interface Address Interface Ver/ Nbr Query DR DR Mode Count Intvl Prior172.1.11.1 GigabitEthernet2.111 v2/S 1 30 1 172.1.11.11172.1.15.1 GigabitEthernet2.115 v2/S 1 30 1 172.1.15.151.1.1.1 Tunnel0 v2/S 3 30 1 4.4.4.4
PE1#show ip pim vrf C-ONE neighbor PIM Neighbor TableMode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority, P - Proxy Capable, S - State Refresh Capable, G - GenID Capable, L - DR Load-balancing CapableNeighbor Interface Uptime/Expires Ver DRAddress Prio/Mode172.1.11.11 GigabitEthernet2.111 4d20h/00:01:25 v2 1 / DR S P G172.1.15.15 GigabitEthernet2.115 4d21h/00:01:25 v2 1 / DR S P G3.3.3.3 Tunnel0 00:07:25/00:01:41 v2 1 / S P G2.2.2.2 Tunnel0 00:07:25/00:01:41 v2 1 / S P G4.4.4.4 Tunnel0 00:08:24/00:01:41 v2 1 / DR S P G
На рисунке ниже представлен дамп одного из PIM Hello, отправленного со стороны РЕ1. Как видно, доставка клиентского (в рамках VRF) пакета до всех заинтересованных РЕ достигается за счет инкапсуляции внутрь многоадресного IP-пакета, который может маршрутизироваться в рамках опорной сети.
Из всего вышесказанного следует, что дерево Default MDT имеет тип Multipoint-to-Multipoint т.к. любой РЕ имеет право передавать данные в рамках дерева (напр. сообщения PIM Hello) и пакеты будут доставлены до любого другого РЕ, являющегося частью указанного дерева.
Внимательный читатель мог справедливо задаться вопросом: а в чем тайный смысл адресного семейства MDT? Ведь маршрутизация осуществляется благодарю наличию PIM ASM в опорной сети.
Все дело в том, что реализация Cisco IOS подразумевает, что PMSI поднимется только после настройки хотя бы одного BGP соседа в рамках указанного адресного семейства. Технически, соседство может быть даже не установлено (Tunnel0 переходит в состояние UP как только Вы введете команду neighbor activate).
Соседство в рамках MDT строго требуется, если внутри опорной сети работает PIM SSM. Дело в том, что если в сети отсутствует RP, то РЕ маршрутизаторам как-то необходимо узнать друг о друге. В рамках MDT они обмениваются маршрутами следующего вида:
PE1#show bgp ipv4 mdt all Network Next Hop Metric LocPrf Weight PathRoute Distinguisher: 1.1.1.1:1 (default for vrf C-ONE) *> 1.1.1.1/32 0.0.0.0 0 ?Route Distinguisher: 2.2.2.2:1 *>i 2.2.2.2/32 2.2.2.2 0 100 0 ?Route Distinguisher: 3.3.3.3:1 *>i 3.3.3.3/32 3.3.3.3 0 100 0 ?Route Distinguisher: 4.4.4.4:1 *>i 4.4.4.4/32 4.4.4.4 0 100 0 ?
PE1#show bgp ipv4 mdt all 2.2.2.2/32BGP routing table entry for 2.2.2.2:1:2.2.2.2/32 version 3Paths: (1 available, best #1, table IPv4-MDT-BGP-Table) Not advertised to any peer Refresh Epoch 1 Local 2.2.2.2 from 8.8.8.8 (8.8.8.8) Origin incomplete, metric 0, localpref 100, valid, internal, best Originator: 2.2.2.2, Cluster list: 8.8.8.8, MDT group address: 239.1.1.1 rx pathid: 0, tx pathid: 0x0
Из указанных апдейтов РЕ выбирает поля Originator и MDT group address, что позволяет просигнализировать (S,G) дерево.
Прим. Согласно документации от вендора: The Address Family
(AF) IPv4 Multicast Distribution Tree (MDT) must be used for all
types of PIM signaling in the core (not only for PIM Source
Specific Multicast (SSM)).
Т.е. без sAFI MDT всё будет работать, но официально такая
конструкция не поддерживается.
Осталось проверить прохождение клиентского трафика.
Для этого, на CE3 и CE4 пропишем конструкцию:
interface Loopback0 ip igmp join-group 230.0.0.1
Убедимся, что на РЕ3 и РЕ4 появились маршруты:
PE3#show ip mroute vrf C-ONE (*, 230.0.0.1), 05:58:36/00:03:19, RP 15.15.15.15, flags: S Incoming interface: Tunnel1, RPF nbr 1.1.1.1 Outgoing interface list: GigabitEthernet2.313, Forward/Sparse, 00:00:10/00:03:19
PE4#show ip mroute vrf C-ONE(*, 230.0.0.1), 00:00:29/00:03:00, RP 15.15.15.15, flags: S Incoming interface: Tunnel0, RPF nbr 1.1.1.1 Outgoing interface list: GigabitEthernet2.414, Forward/Sparse, 00:00:29/00:03:00
На РЕ2 OIL пустой (поскольку нет активных получателей). Однако, IIL состоит из интерфейса Tunnel (default MDT). Т.е. РЕ2 будет получать пакеты на группу 230.0.0.1 и отбрасывать их.
PE2#show ip mroute 239.1.1.1(*, 239.1.1.1), 05:06:26/stopped, RP 8.8.8.8, flags: SJCFZ Incoming interface: GigabitEthernet2.26, RPF nbr 10.2.6.6 Outgoing interface list: MVRF C-ONE, Forward/Sparse, 05:06:26/stopped
PE2#show ip mroute vrf C-ONE(*, 230.0.0.1), 05:59:17/00:01:08, RP 15.15.15.15, flags: SP Incoming interface: Tunnel1, RPF nbr 1.1.1.1 Outgoing interface list: Null
И запустим трафик:
CE1#ping 230.0.0.1 source 11.11.11.11Type escape sequence to abort.Sending 1, 100-byte ICMP Echos to 230.0.0.1, timeout is 2 seconds:Packet sent with a source address of 11.11.11.11 Reply to request 0 from 14.14.14.14, 11 msReply to request 0 from 13.13.13.13, 13 ms
Из дампа наглядно видно, что передача трафика осуществляется абсолютно также, как и передача сигнальных сообщений PIM (посредством инкапсуляции в mGRE):
Таким образом: даже при наличии MPLS внутри опорной сети, метки для передачи многоадресного трафика (в рамках Profile 0) не используются.
При этом ответный трафик (ICMP reply) подчиняется законам одноадресной маршрутизации и его передача осуществляется по классическим правилам MPLS L3 VPN:
К сожалению, Default MDT не всегда эффективно. Все дело в том, что оно доставляет весь многоадресный трафик на все PE-маршрутизаторы, независимо от того, есть ли C-Receiver или же нет. Это означает, что ядро сети может передавать многоадресный трафик к тем маршрутизаторам PE, которые затем отбрасывают трафик. Это видно из дампа трафика (обратите внимание на поле VLAN ID = 26, которое символизирует линк между R2 (PE2) и R6 (P2)).
Чтобы обойти ограничения Default MDT вводится понятие Data MDT, которое позволяет переключить пользовательский трафик C-(S,G) из Default MDT в Data MDT, в котором участвуют только те РЕ, где есть активные источники или получатели трафика. Об этом мы поговорим с Вами в следующем выпуске.
Продолжение следует...
