Глава 3. Routing protocols (DVMRP, PIM-DM, PIM-SM)
DVMRP
Distance vector multicast routing protocol
- Первый, нах! протокол маршрутизации для мультикаст.
- Danse-mode implementation
- Distance-vector
- Don't use unicast route information for RPF.
PIM
Protocol Independent Multicast
- Использует unicast routing table для RPF check. Использует любой IGP, BGP или оба.
- Sparse (ASM / SSM) / Dense mode
- Version 1 (encapsulate messages into IGMP, sent to 224.0.0.2)/ 2 (encapsulate messages into protocol 103, sent to 224.0.0.13).
Dense mode
Messges
- Hello: для нахождения и поддержания соседства.
- Join/prune: имеют одинаковый формат сообщения. В основном в dense mode используются prune сообщения - сообщить upstream роутеру об отказе о группе.
- Graft/graft-ack: graft используется для запроса трафика у upstream роутера, куда был уже отправлен prune запрос.
- Assert: выбирает gesignated forwarder (DF) для сегмента, где > 1 роутера.
Nieghbourship
Соседство устанавливаетя и поддерживается с помощью hello сообщений. В зависимости от весрии шлем на нужный адрес. Version 1 (encapsulate messages into IGMP, sent to 224.0.0.2) Version 2 (encapsulate messages into protocol 103, sent to 224.0.0.13).
hello сообщения могут содержать hold-time - как долго сосед будет в состоянии up без посылки hello. В Junos если holdtimer = 0, то роутер будет использовать локальный таймер. По умолчанию = 105 сек.
Designated router election
Выбор строится, основываясь на DR priority field в hello сообщениях. По умолчанию = 1. Можно задавать самому. Чем больше приоритет, тем выигрышнее.
Если приоритеты равны, то выигрывает с наибольшим ip.
В выборах может учавствовать интерфейс p2p и multi-access.
Flooding
- Все роутеры получат одну копию исходного потока.
- Каждый роутер проводит RPF check. Пакеты, которые не прошли RPF check - отбрасываются.
- Пакеты прошедшие RPF check копируются и флудятся во все порты.
- (S,G) создается на каждом роутере (даже на котором вообще нет получителей).
- Роутеры, не имеющие напрямую включенных получателей должны периодически посылать prune, чтобы быть исключенными из SPT дерева.
Prunning unwanted traffic
Prune отправляется в случае:
1. Если нет получателей, подключенных к роутеру.
2. Если на роутер пришло prune сообщение от downstream роутера.
Информация (S,G) хранится на роутере 3 минуты. Если появляется новый получатель или отваливается старый, я роутер не мгновенно среагирует на изменения, а будет ждать таймаут 3 минуты и после этого обновит инфо.
Prune нужно отправлять периодически, так как есть определенный таймаут, после которого возобновляется вещание multicast трафика во все порты.
Source-based tree
В итоге после отправки всех prune, на сети вырисовывается shortest-path tree, по которому и ходит в дальнейшем трафик.
Prunning on milti-access network
При отправке роутером (R2) prune к upstrem роутеру, может пострадать другой роутер из этого же multi-access сегмента (R1).
У роутера из этого же сегмента (R1) есть 2 сек, чтобы отправить join к upstream роутеру и тем самым убить prune от первого роутера.
При этом на R2 будет литься трафик, но сам роутер не будет его передавать другим роутрам, так как нет получателей.
Grafting back
SPT уже установлено, но в сети появился новый получатель.
Роутер, получивший IGMP report от получателя, генерирует Graft-message и шлет его по SPT к источнику на upstream-router. Истоник известен, т.к. на всех роутерах хранятся (S,G) записи.
Роутер, ближайший к источнику в ответ на graft сообщение генерирует graft-ack сообщение и посылает его к конечному свитчу. На этом же роутере сохранена запись (S,G), но без OIL interfaces. После получения report, список OIL интерфейсов обновляется, в сторону источника отправляется Join сообщение.
После этого получатель получает свой заветный трафик, не ожидая никаких таймаутов.
Assert mechanism in Multiaccess networks
В multi-access сегменте несколько роутеров могут начать посылать трафик вниз к получателям. Чтобы этого избежать, проводятся выборы DF.
Assert сообщение содержит информацию: source, group, metric preference, metric. Наименьшее значение metric pref / metric - выигрывает. если значения равны, то выигрывает наибольший ip роутера.
При этом downstream роутер как-то хитро переподписывается на группу, что получает в итоге трафик от одного роутера.
Configuration
set protocols pim assert-timeout 180 set protocols pim interface ge-0/0/0.0 mode dense priority 1 hello-interval 30
show pim interfaces show pim neighbors show pim neighbors detail show pim join extensive show pim source detail show multicast rpf <src addr> show multicast route extensive show route table inet.1 show route table inet.1 extensive show multicast next-hops show pim statistics show multicast usage
можно использовать traceoptions
mtrace from-source group 224.7.7.7 ttl 20 source <src ip> || запускается от роутера, ближнего к получателю
Пинг source:
ping 224.7.7.7 ttl 10 interface ge-0/0/0.900 bypass-routing || запускается от роутера, ближнего к получателю.
Пинг получателя: тоже как-то можно продиагностировать, но придется заморочиться.
Sparse mode
Messages
- Hello: соседство.
- Join/Prune: подписка/отписка.
- Assert messages: выборы designated router (DR).
- Register / register-stop: сообщения между source и RP.
- Bootstrap and candidate-RP: для работы bootstrap.
Join operations, Receiver -> RP
От подписчика на роутер поступает (*,G) report. Роутер не знает какой именно источник будет использоваться, пожтому он направляет пакет к upstream роутеру не в сторону источника, а в сторону RP. Строится randevous-point tree (RPT).
Source DR -> RP
Источник начинает вещание группы. Далее source DR роутер инкапсулирует мультикаст трафик в PIM register сообщение и посылает его к RP.
RP получает register сообщение, деинкапсулирует его и начинает слать чистый мультикаст в интерфейс к которого пришел report на подписку к этой группе.
Если на RP приходят register от источника, но у нее нет подписчиков на эту группу, то RP отправит Register-stop в сторону источника. Если между RP и источником есть роутер, то он примет register-stop, начнет отбрасывать мультикаст трафик, но сервер как слал его так и будет слать дальше. Также на RP будет сохранена запись (S,G), т.е. если появятся получатели, то RP пошлет запрос сразу к источнику. Также роутер между источником и RP каждые 3 минуты будет отправлять register на RP, чтобы RP знало, что источник все еще жив.
Tunnel requeriments
Для RP и DR требуется туннелирование. (Не требуется только если RP=DR).
Возможности туннелирования зависят от платформы. Иногда требуется даже докупать доп оборудование (платы).
На MX сериях туннелирование включается так:
set chassis fpc X pic X tunnel-services bandwidth 1g
Проверка:
show interfaces terse | match "pe|pd"
SPT switchover
В ситуациях, когда есть роутеры (R6), для которых путь до источника через RP является не оптимальным, происходит перестроение дерева.
На R6 есть получатель. R6 отправляет (*,G) к RP. От RP приходит пакет (S,G). В таком случае R6 узнает об источнике. Если R6 видит более оптимальный путь до источника, то он шлет (S,G) к источнику по этому пути (до R1 - ближайший к источнику).
Когда между R1 и R6 установлено source-based tree, мультикаст трафик может идти напрямую от R1 к R6. Есть небольшой промежуток времени, когда R6 будет получать 2 копии мультикаст трафика.
R6 отправляет prune сообщение uptream роутеру в сторону RP. RP проверит, что больше не получателей конкретной группы и отправит Prune сообщение (S,G).
В итоге трафик польется оптимальным путем.
Но на R6 (ближний к получателю) останется 2 записи о группе:
- (S,G) - где в качестве upstream state будет указан: Join to source, Prune from RP. И в incoming interface: интерфейс в сторону R1 (ближний к источнику).
- (*,G) - в качестве upstream state указан: Join to RP. Incoming interface: интерфейс в сторону RP.
(S,G) - более специфичный.
RP в общем
В sparse обязательно должна использоваться RP.
- RP должна быть расположена оптимально, желательно поближе к источникам, чтобы не гонять большие объемы трафика от источников.
- Инкапсуляция и деинкапсуляция трафика от источника делается посредством использования tunnel-servoces.
- Для надежности, есть 3 механизма нахождения rp: static, auto-RP, bootstrap. Можно использовать все сразу, тогда по предпочтительности: BSR -> auto-RP -> static.
- Anycast-RP может быть использована с любым из механизмов нахождения RP (можно потом почитать здесь: http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/ip-multicast/whitepaper_c11-508498.html).
Static RP
Прописывается вручную. Минус - никакого резервирования. В случае отвала RP, требуется ручное вмешательство в конфигурацию.
Конфигурация:
RP:
set protocols pim rp local address x.x.x.x
Не RP:
set protocols pim rp static address x.x.x.x
Auto-RP
Используется с PIMv1 и v2.
- Нестандартное проприетарное решение (вроде от Cisco).
- Позволяет резервировать RP, но не делает балансировку между RP.
- Использует мультикаст для распространения инфо, связанной с RP (обычно dense-mode).
Компоненты:
- Candidate-RP (C-RP). Периодически отсылают инфо о себе на 224.0.1.39 (вроде слушает только mapping agent) (announce messages).
- Mapping agent слушает C-RP, выбирает RP для каждой группы (наибольший ip), анонсирует победителя RP на 224.0.1.40 (слушают все auto-rp роутеры).
RP выбирается для групп.
Если RP сдохнет, то mapping agent выбирает новую RP. В общем время падения составляет несколько минут.
Конфигурация
RP + mapping agent:
set protocols pim rp local address x.x.x.x set protocols pim rp auto rp mapping set protocols pim dense-groups 224.0.1.39 set protocols pim dense-groups 224.0.1.40
Non-RP:
set protocols pim rp auto rp discovery set protocols pim dense-groups 224.0.1.39 set protocols pim dense-groups 224.0.1.40
Bootstrap
Работает только с PIMv2.
- Для распространения информации используют сообщения PIMv2.
- Использует backup RP и обеспечивает некую балансировку для одних и тех же групп между RP. Но по прежнему для 1 группы - используется 1 RP.
Компоненты:
- Candidate-RP: заявляет о себе BSR через unicast.
- Bootstrap router: выбирается на основании наивысшего приоритета (далее наивысшего ip), получает оповещения от C-RP, определяет RP/group соответствие - это RP-set, включает RP-set в bootstrap сообщения и распространяет по сети.
Выборы: 1.Выбор BSR: каждый роутер предполагает, что он BSR. Генерирует BSR-сообщения другим BSR (ip+приоритет+пустой RP-set). Когда роутер получает BSR-сообщение с бОльшим приоритетом (или бОльшим ip), он перестает генерировать сообщения. Выбранный BSR-роутер продолжает генерировать сообщения, остальные лузеры-BSR просто передают эти сообщения своим соседям. Т.о. все роутеры знают об активном BSR. BSR генерирует BSR сообщение, в котором содержится ip BSR, пустой RP-set. DA = 224.0.0.13.
2.C-RP передают инфо о себе BSR: свой ip, перечисляют group range.
3.BSR собирает C-RP оповещения, складывает их в RP-set (RP+group range). Отправляет RP-set всем PIM роутерам.
4.Каждый PIM роутер выбирает для группы действующую RP: делает hash из C-RP ip, group range, mask. Наименьший hash для группы определяет выбранную RP.
Конфигурация
RP + BSR:
set protocols pim rp local address 10.1.1.1 set protocols pim rp bootstrap priority 200
Non-RP:
особого конфига не нужно, просто должен быть включен PIM на интерфейсах.
Нельзя, чтобы одновременно на сети были включены Auto-RP и Bootstrap.
Specific config
- Shortest-path tree cutover (не переключаться на shotest-path tree)
set protocols pim spt-threshhold infinity rpt-always-policy set policy-options policy-statement rpt-always-policy term 1 from route-filter 224.7.7.7/32 exact set policy-options policy-statement rpt-always-policy term 1 from cource-address-filter 10.1.1.1/32 exact set policy-options policy-statement rpt-always-policy term 1 then accept set policy-options policy-statement rpt-always-policy term 2 then reject
Делается для того, чтобы ограничить дополнительный статус (S,G), который создается при переключении на source-based tree.
- PIM join load balancing:
set protocols pim join-load-balance
Если до источника есть несколько равнозначных путей, использоваться будет только 1 (т.к. пройдет RFP-check только 1). Используя команду выше, может использоваться несколько интерфейсов к источнику.
- Таймеры
set protocols pim join-prune-timeout 230 || by default 210 set protocols pim reset-tracking bit || в multi-access сетях для настройки подавления join от нескольких роутеров. set protocols pim propagation-delay 500 || время, кот определяет как долго ждать выполнения prune на upstream роутере. В теч этого времени роутер ждет любых prune override join message от других роутеров. set protocols pim override-interval 2000 || макс время для задержки отправки join сообщений. Если в multi-access появился prune, то таймер гарантирует, что не все downstream роутеры среагируют одновременно join сообщением.
Диагностика
show pim interfaces show pim neighbors extensive || можно посмотреть RX Join groups!! show pim statictics show multicast usage show multicast route extensive show route table inet.1 show multicast next-hops show pim join extensive || помимо прочего, полезно: "Upstream state: Join to Source, Prune to RP" pim traceoptions show pim source detail show multicast rpf x.x.x.x show pim rps || какие rp известны, через какой механизм, какой набор групп приходит show pim rps extensive || помимо того, что выше - видны конкретные группы, статус, time active и много всяких подробностей show pim bootsrap || активный BSR роутер
© Наталия Бобкова 2014—2022