Эта статья появилась из-за недостатка комплексных материалов по теме. Конечно, в интернете можно найти качественные статьи, описывающие работу мультикаста, например в знаменитом цикле "Сети для самых маленьких", однако взаимодействие с BGP и MSDP рассматривается в единичных источниках.

Краткий обзор используемых технологий

PIM (Protocol Independent Multicast) – это протокол групповой маршрутизации в современных сетях связи. Работает поверх обычных протоколов маршрутизации (OSPF, EIGRP и даже статической), автоматически создавая свою собственную таблицу мультикаст-маршрутизации (такая таблица, в терминологии CLI сетевого оборудования, обычно называется mroute).

Ранее было несколько вариантов протокола PIM, однако сегодня используется только PIM-SM (описанный в стандарте RFC 7761).

PIM-SM использует точку встречи (RP) – определенный интерфейс на определенном роутере, к которому будут приходить трафик от источника и запросы от отправителей, которые этот трафик хотят получить. После получения информации от источника и отправителя (и занесения данной информации в таблицу мультикаст-маршрутизации mroute) маршрутизация трафика может быть осуществлена по кратчайшему пути (минуя RP).

Т.е. еще раз для закрепления - сначала трафик идет к точке встречи (маршрут трафика к точке встречи называют RPT - Rendezvous Point Tree), а затем уже используется кратчайший маршрут, по которому передается поток данных (это называется SPT - Shortest Path Tree). Этот факт необходимо учитывать, так как не обязательно то что передача информации о потоках и сами потоки будут идти по одному и тому-же каналу, вполне возможно организовать передачу данных по одному пути, а потом за счет SPT Switchover (переключения RPT-SPT). Это наглядно показано на рисунке ниже.

MSDP (стандарт RFC 3618) – протокол который работает вместе с PIM и позволяет отправлять mrout’ы через BGP (вообще – между доменами PIM-SM, но пересылка через BGP является частным, однако одним из самых распространенных случаев). Как правило через BGP ни информацию о BSR, ни информацию о группах не передают, чтобы избежать коллизий и лишнего обмена трафика. На интерфейсах в сторону BGP ставится bsr-border. Однако, иногда всё-таки требуется получить определенные каналы от другого оператора или из другой автономной системы. Тогда на помощь приходит MSDP.

MSDP сначала устанавливает связность с другим MSDP-пиром, а затем пересылает ему специальные sa-сообщения в которых содержится информация о вещателях из других автономных систем (фактически, принцип его работы крайне похож на BGP). При этом точек встречи (RP) становится две – одна в «клиентской» автономке, другая в «серверной». «Серверная» отправляет mrout’ы на «клиентскую», в свою очередь «клиентская» должна знать маршруты к серверной части.

Суммируя все вышеизложенное (а также изложенное в стандарте RFC), имеем 3 тезиса:

1. MSDP-пиринг должен быть настроен на те-же интерфейсы, на которых работает BGP (т.к. MSDP работает поверх BGP)

2. MSDP должен быть настроен на RP как с «клиентской» так и с «серверной» стороны. Более того, RP «серверов» должна быть настоящей, знать те маршруты, которые она будет отправлять. Недостаточно сделать вынесенную из общей сети C-RP.

3. «Сервреной» автономной системе не обязательно знать о маршрутах к ее клиентской части. RP серверов и так получит информацию о пути к другой RP, т.к. они подключены друг к другу напрямую по MSDP, а RP клиентов достаточно знать маршруты, куда направлять пакеты и не обязательно делиться информацией о внутреннем состоянии своей сети.

Все эти тезисы далее мы увидим на практике.

Настройка тестового стенда в GNS3

Рассмотрим простую лабораторную работу в GNS3:

У нас есть две автономных системы (далее они будут называться скоращенно AS) – это AS 64521 и AS 64522. Это могут быть два разных провайдера или две разные городские сети. В AS 64521 есть сервер (Debian1-1), который вещает некий видеофайл в группу IGMP 224.3.10.1. Debian используется с графической средой LXQT, хотя в принципе это не имеет особого значения.

Настройка сервера вещания мультикастового трафика на примере Debian

Прописываем сервер статический IP (DHCP для сервера – не лучшая идея) в /etc/network/interfaces:

allow-hotplug enp0s3
iface enp0s3 inet static
address 172.16.1.10
gateway 172.16.1.1

Затем перезапускаем сетевую службу через

sudo systemctl restart networking.service

Ниже представлен скриншот того что получилось.

На скриншоте выше можно заметить адрес 169.254.225.111 - адрес выделенный из диапазона APIPA, потому что параллельно службе networking настройкой сети в моем стенде занимается графическая утилита из пакета LXQT. В проде необходимо выбрать только одну утилиту настройки чтобы избежать подобных коллизий.

Затем необходимо запустить VLC и выполнить следующую команду в терминале (ну или сделать скрипт для ее автоматического запуска по загрузке ОС):

vlc gif.mp4 --sout udp://224.3.10.1:1234 --ttl 20 -L

Тут указываем vlc какой файл открывать (gif.mp4), поток в какую группу отправлять и какой установить ttl (чтобы пройти все маршрутизаторы по пути к клиенту). Особенность VLC в том что если ему явно не указать TTL - TTL по-умолчанию будет 1 и мультикаст-пакеты не будет проходить через роутер.

Во время вещания у нас ничего не отображается на экране, но вещание идет:

Настройка сетевого оборудования

Настройка AS сервера

Теперь приступаем к настройке маршрутизатора сервера. Все маршрутизаторы, через которые предполагается прохождение мультикаст-трафика должны быть с возможностью маршрутизации мультикаста (ip multicast-routing включен глобально).

Порт в сторону сервера и аплинка должен работать в PIM. Ниже настройка в сторону сервера, в сторону роутера R1 – аналогично. Вообще аналогично для всей автономки кроме портов в сторону BGP.

interface FastEthernet1/1
description to_ServerTV
ip address 172.16.1.1 255.255.255.0
ip pim sparse-mode
duplex auto
speed auto

Включаем OSPF:

router ospf 1
redistribute connected subnets
network 10.1.0.0 0.0.255.255 area 0

Как видно на изображении для AS «сервера», чтобы упростить понимание и настройку OSPF у нас выбрана внутренняя сеть 10.1.0.0/16, а «клиента» 10.2.0.0/16, поэтому мы можем просто сказать OSPF’у чтобы он слал свои LSA в данные адреса и за одно распространять подключенные подсети, там будет немного другая адресация.

Остальные роутеры в цепочке настраиваем аналогичным образом, чтобы они передавали известные им маршруты по OSPF. Сервер должен иметь свзяность с RP (BGP-стыком, в нашем случае).

Нужно не забыть на одном из роутеров указать чтобы он передавался в OSPF как шлюз последней надежды (default gateway) - default-information originate. В примере это сделано на R1, но в принципе можно и на BGP-роутере.

Пока другие роутеры не настроены – можем посмотреть на mroute – на Cisco это show ip mroute:

(172.16.1.10, 224.3.10.1), 00:00:09/00:02:50, flags: PFT
Incoming interface: FastEthernet1/1, RPF nbr 0.0.0.0
Outgoing interface list: Null

Это означает что роутер обнаружил источник вещания, но пока нет никаких запросов: Флаг P - Pruned указывает что интерфейс временно отсечен, т.к. трафик не нужен нижестоящим узлам, но у нас его ни кто никогда пока что и не запрашивал. Остальные флаги говорят о том что группа зарегистрирована роутером (F - Register Flag) и находится на оптимальном пути (флаг T - SPT Bit) (см. SPT Switchover. Тут с первого взгляда может быть не очень понятно почему стоит этот флаг, но т.к. это единственный роутером перед сервером, то стоять он там будет всегда.

Исправим досадный пробел отсутствия запросов. Настроим остальные 2 роутера по тому-же принципу (IP и pim-sm на интерфейсах и OSPF). Теперь перейдем к настройке нашей RP:

Сначала нужно настроить access-лист, чтобы РП работало только с определенными группами. В сети может быть много источников мультикаста и если не вешать access-листы роутер может сдуреть от этой прикормки и перезагрузиться, даже при минимальной загрузке процессора.

ip access-list standard RP_IPTV
permit 224.3.10.0 0.0.0.255
deny any

Теперь назначим BSR и PR кандидатов. Стоит обратить внимание что для нашей топологии RP должна быть одна, даже если у нас будет другой кандидат – то MSDP будет работать только на BGP-роутере.

ip pim bsr-candidate Loopback10 0
ip pim rp-candidate Loopback10 group-list RP_IPTV

На этом настройка для одного PIM-домена окончена. Сейчас рутер ClientR1 на порту Fa1/1 раздает IP по DHCP (как это сделать - многократно рассмотренно в других источниках) и клиент может спокойно запросить группу через VLC.

К сожалению, скорость при виртуализации в GNS оставляет желать лучшего поэтому для подобных экспериментов стоит делать самые простые видео из гифок.

Настройка BGP и MSDP стыка

Переходим к настройке BGP. Как уже ранее упоминалось – нам нужно передать маршруты источника в AS2 и не принимать лишние маршруты от нее. Со стороны AS1 все точно также – принимаем нужное и не передаем ненужное.

Рассмотрим настройку роутера со стороны AS сервера.
Сначала – пишем префикс-листы на объявление маршрутов в BGP:

ip prefix-list BGPIN seq 5 deny 0.0.0.0/0 le 32
ip prefix-list BGPOUT seq 5 permit 172.16.1.0/24

Т.е. будем передавать в другую AS только информацию о той сети, с которой ведется вещание.

Настраиваем BGP-пиринг (указываем в какой AS мы находимся, AS соседа и префикс листы на вход и на выход):

router bgp 64521
bgp log-neighbor-changes
redistribute static
redistribute ospf 1 match internal external 2
neighbor 192.168.250.2 remote-as 64522
neighbor 192.168.250.2 prefix-list BGPIN in
neighbor 192.168.250.2 prefix-list BGPOUT out

Тут важно учесть redistribute ospf 1 match internal external 2 т.к. в таблице маршрутизации к нам на сервер она приходит как E2:

BGP1#show ip route
<...>
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
O 10.1.101.0/24 [110/2] via 10.1.103.10, 01:59:59, FastEthernet0/0
O 10.1.102.0/24 [110/2] via 10.1.103.10, 01:59:59, FastEthernet0/0
C 10.1.103.0/24 is directly connected, FastEthernet0/0
L 10.1.103.1/32 is directly connected, FastEthernet0/0
O 10.1.202.0/24 [110/3] via 10.1.103.10, 01:59:59, FastEthernet0/0
172.16.0.0/16 is variably subnetted, 3 subnets, 3 masks
S 172.16.0.0/20 is directly connected, Null0
O E2 172.16.1.0/24 [110/20] via 10.1.103.10, 01:59:59, FastEthernet0/0
C 172.16.3.1/32 is directly connected, Loopback10
192.168.250.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.250.0/24 is directly connected, FastEthernet1/1
L 192.168.250.1/32 is directly connected, FastEthernet1/1

Как вариант 2 – делать маршрутизацию путем задания статического маршрута в Null 0, но это не тема данной статьи и по BGP сейчас достаточно много информации.

Если нужно объединить несколько префикс листов (а в реальной жизни это часто и требуется сделать) на Cisco используется route-map, например:

route-map RM-IN
match ip address prefix-list BGPIN1
match ip address prefix-list BGPIN2

И, самое главное – включаем MSDP-пиринг на тот-же интерфейс, что и BGP:

ip msdp peer 192.168.250.2 connect-source FastEthernet1/1

С другой стороны - все тоже самое, только зеркально:

ip prefix-list BGPIN seq 5 permit 172.16.1.0/24
ip prefix-list BGPOUT seq 5 deny 0.0.0.0/0 le 32
router bgp 64522
bgp log-neighbor-changes
redistribute static
neighbor 192.168.250.1 remote-as 64521
neighbor 192.168.250.1 prefix-list BGPIN in
neighbor 192.168.250.1 prefix-list BGPOUT out
ip msdp peer 192.168.250.1 connect-source FastEthernet1/1

Стоит обратить внимание что mrout'ы которые передаются или принимаются роутером можно (и даже нужно) также ограничивать при помощи ACL, но в этой статье я не рассматриваю это вопрос.

Напоминаю, что на BGP роутере со стороны AS2 нужно также создавать RP и BSR!

Все, теперь можно проверять, проходят ли пакеты MSDP:

BGP2#show ip msdp sa-cache
MSDP Source-Active Cache - 1 entries
(172.16.1.10, 224.3.10.1), RP 172.16.3.1, BGP/AS 0, 00:00:15/00:05:44, Peer 192.168.250.1

Также посмотрим какие маршруты приходят к нам в BGP:

BGP2#show ip bgp neighbors 192.168.250.1 routes
BGP table version is 14, local router ID is 10.172.16.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 172.16.1.0/24 192.168.250.1 20 0 64521 ?
Total number of prefixes 1

Отлично. Теперь RP из автономной системы 2 знает откуда будет приходить поток. Можно переключить виртуальную машину к роутеру Client2 и это проверить.

Флаги mroute демонстрирующие корректную работу MSDP

Посмотрим что выдает роутер к которому подключен клиент и RP сети клиента.

Роутер "клиента":

(172.16.1.10, 224.3.10.1), 00:00:31/00:02:28, flags: J
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    FastEthernet1/1, Forward/Sparse, 00:00:31/00:02:34

RP "клиента":

(172.16.1.10, 224.3.10.1), 00:01:08/00:01:51, flags: MT
  Incoming interface: FastEthernet1/1, RPF nbr 192.168.250.1
  Outgoing interface list:
    FastEthernet1/0, Forward/Sparse, 00:01:08/00:03:09

Тут видно, что на RP появились новый для нас флаг - M. Он означает что используемый маршрут получен через MSDP. Также виден флаг T - трафик перешел на оптимальный маршрут (ну опять-же это единственный маршрут в данной сети).

Также необычен единичный флаг J на роутере клиента. Это означает что устройство присоединилось к уже созданному SPT (создано оно было ранее через BGP-роутер). По этой-же причине не указывается и входящий интерфейс. Однако трафик в таком состоянии у нас будет проходить - чудеса мультикаста да и только.

Рассмотрим, в каком состоянии у нас работает роутер "сервера" и RP автономки сервера.

Рутер "сервера":

(172.16.1.10, 224.3.10.1), 00:03:13/00:02:22, flags: FT
  Incoming interface: FastEthernet1/1, RPF nbr 0.0.0.0
  Outgoing interface list:
    FastEthernet0/0, Forward/Sparse, 00:02:27/00:02:26

RP AS "сервера":

(172.16.1.10, 224.3.10.1), 00:02:30/00:02:28, flags: TA
  Incoming interface: FastEthernet0/0, RPF nbr 10.1.103.10
  Outgoing interface list:
    FastEthernet1/1, Forward/Sparse, 00:02:02/00:03:10

Флаг TA в таблице mroute сервера означает факт того что SPT был активирован и был найден оптимальный интерфейс до источника трафика.

Также стоит обратить внимание что с mroute на роутере сервера исчез флаг P - теперь трафик с сервера был запрошен каким-либо клиентом.

PS.

Спасибо за то, что прочитали мою статью до конца. Прошу строго не судить, так как это моя первая статья на Habr. Готов выслушать критику и внести дополнения, если это потребуется.