Просмотр кода страницы Глава 3. Routing protocols (DVMRP, PIM-DM, PIM-SM)

{{#description2: PIM Dense mode. PIM Sparse mode. SPT switchover. Static RP. Auto-RP. Bootstrap. Anycast RP. Конфигурация PIM. PIM BFD. Траблшутинг PIM. Информация для подготовки к экзаменам Juniper.}}

=DVMRP=

''Distance vector multicast routing protocol''
*Первый, нах! протокол маршрутизации для мультикаст.
*Dense-mode implementation
*Distance-vector
*Для RPF не использует Unicast таблицу.
*Можно использовать туннелирование между островками Unicast.
*Для передачи routing info использует отдельный протокол.

=PIM=

''Protocol Independent Multicast''
*Использует unicast routing table для RPF check. Использует любой IGP, BGP или оба.
*'''ASM [any-source multicast]: Sparse / Dense / Sparse-Dense/ Bidirectional''' modes.
*Version 1 (encapsulate messages into IGMP, sent to 224.0.0.2)/ 2 (encapsulate messages into protocol 103, sent to 224.0.0.13). Могут использоваться совместно даже на одном интерфейсе.
*Отдельно есть SSM [source-specific multicast]

==Dense mode==
Пригоден для использования с большим количеством получателей в сети. 

===Сообщения PIM DM===
*'''Hello''': для нахождения и поддержания соседства.
*'''Join/prune''': имеют одинаковый формат сообщения. В dense mode используются prune сообщения - сообщить upstream роутеру об отказе от группы.
*'''Graft/graft-ack''': graft используется для запроса трафика у upstream роутера, которому уже пришел prune запрос.
*'''Assert''':  для выбора gesignated forwarder (DF) для сегмента, где > 1 роутера.

===Соседство PIM DM===

Соседство устанавливается и поддерживается с помощью 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 PIM DM===
'''Dense''': целесообразно использовать только в том случае, если используем IGMPv1, т.к. он не имеет встречного механизма выбора query роутера.

===Flooding===
Для доставки multicast использует SPT. 
*Все роутеры получат одну копию исходного потока.
*Каждый роутер проводит RPF check. Пакеты, которые не прошли RPF check - отбрасываются.
*Пакеты прошедшие RPF check копируются и флудятся во все порты (OIL), за исключением порта, откуда трафик пришел (IIF).
*(S,G) создается на каждом роутере (даже на котором вообще нет получителей).
*Роутеры, не имеющие напрямую включенных получателей должны периодически посылать prune, чтобы быть исключенными из SPT дерева.

===Отбрасывание нежелательного трафика (Prunning)===
Prune отправляется в случае: 
#Если нет получателей, подключенных к роутеру.
#Если на роутер пришел 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.

При этом на 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 роутер как-то хитро переподписывается на группу, что получает в итоге трафик от одного роутера.

===Конфигурация PIM DM===
По дефлту при добавлении интерфейса в protocols pim, включается version 2, sparse mode.
 set protocols pim assert-timeout 180
 set protocols pim interface ge-0/0/0.0 mode dense priority 1 hello-interval 30

===Траблшутинг PIM DM===
 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.

Пинг source:
 mtrace from-source group 224.7.7.7 ttl 20 source <src ip> || запускается от роутера, ближнего к получателю
Пинг получателя: тоже как-то можно продиагностировать, но придется заморочиться.
 ping 224.7.7.7 ttl 10 interface ge-0/0/0.900 bypass-routing || запускается от роутера, ближнего к получателю.

==Sparse mode==
Shared tree (rendezvous point tree) = (*,G) 

Source-based tree (shortest path tree (SPT)) = (S,G)

Более приспособлена к реальности: поток получают только роутеры, заинтересованные в потоке. Работа в 2х режимах: ASM/SSM. При работе ASM, требуется RP.

*'''DR''' (designated router) - занимается только отправкой register-message, join message в multi-access сети.
*'''DF''' (designated forwarder) - занимается передачей трафика в multi-access netw.

===Сообщение PIM SM===
*'''Hello''': поиск соседей, поддержание соседства, выбор DR в multi-access netw. (отправляется на dst-address 224.0.0.13, src-adderss - p2p интерфейса)
*'''Join/Prune''': подписка/отписка. (отправляется на dst-address 224.0.0.13, src-address - p2p интерфейса)
*'''Assert messages''': выборы designated router (DR).
*'''Register / register-stop''': сообщения между source и RP.
*'''Bootstrap and candidate-RP''': для работы bootstrap.

===Выбор Designated router в PIM SM===
'''Sparse''': выбор роутера проводится со стороны как получателей и так и источников.

*receiver DR: отправляет PIM join и PIM prune сообщения от получателей к RP.
*source DR: отправляет PIM register сообщения от источника к RP.

Выбор основан на DR priority field в hello сообщениях. По умолчанию = 1. Можно задавать вручную. Больший приоритет - выигрышней. Если приоритеты равны, то выигрывает с наибольшим ip.
 set protocols pim interfaces xe-0/0/0.50 priority 50

Можно активировать выбор DR и на p2p линке.
 set protocols pim dr-election-on-p2p

===Описание Join процесса===
'''Receiver -> RP'''

От подписчика на роутер поступает (*,G) report. Роутер не знает какой именно источник будет использоваться, поэтому он направляет пакет к upstream роутеру не в сторону источника, а в сторону RP. 

Строится ''rendevous-point tree (RPT)'' или ''shared tree''.

'''Source DR -> RP'''

Источник начинает вещание группы. Далее source DR роутер инкапсулирует мультикаст трафик в PIM register сообщение и посылает его к RP.

RP получает register сообщение, деинкапсулирует его и начинает слать чистый мультикаст в интерфейс к которого пришел report на подписку к этой группе.

Если у RP есть подписчики на нужную группу, то RP шлет join (S,G) к источнику. После этого строится source-based tree. И роутер, подключенный к источнику сможет слать чистый мультикаст в направлении RP. В короткий промежуток времени RP получит 2 копии одного и того же трафика, чтобы отписаться от инкапсулированного мультикаста, RP шлет register-stop к source DR.

Если на RP приходят register от источника, но у него нет подписчиков на эту группу, то RP отправит register-stop в сторону источника.

Если между RP и источником есть роутер, то промежуточный роутер примет register-stop, начнет отбрасывать мультикаст трафик, но источник как слал его так и будет слать дальше.

Если появится новый источник, то заново повторится весь сценарий: register -> RP, (S,G) -> source, multicast -> RP, register-stop -> source.

Также на RP будет сохранена запись (S,G), т.е. если появятся получатели, то RP пошлет запрос сразу к источнику.

Также роутер между источником и RP каждые 3 минуты будет отправлять register на RP, чтобы  RP знало, что источник все еще жив.

====Требования к туннелированию====

Для RP и source 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 - ближайший к источнику). 

Upstream роутер, получив (S,G) также ищет более короткий путь и шлет (S,G) join вверх по топологии.

Когда между R1 и R6 установлено source-based tree, мультикаст трафик может идти напрямую от R1 к R6.
Есть небольшой промежуток времени, когда R6 будет получать 2 копии мультикаст.

R6 отправляет prune сообщение (S,G) uptream роутеру в сторону RP. RP проверит, что больше нет получателей конкретной группы и отправит prune (S,G) к source DR.

В итоге трафик польется оптимальным путем.

Но на 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 при этом будет храниться информация следующего вида:
'''(S,G) Sate''': Group x.x.x.x, Source: y.y.y.y, Upstream State: '''Prune to Source'''

===RP===

В sparse обязательно должна использоваться RP.
* RP должна быть расположена оптимально, желательно поближе к источникам, чтобы не гонять большие объемы трафика от источников и максимально исключить перестроение на spt.
*Инкапсуляция и деинкапсуляция трафика от источника делается посредством использования tunnel-services. Tunnel-services не требуется, если DR = RP.
*Для одной группы - 1 RP.
*Для надежности, есть 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 среди других.

Дефолтное значение приоритета = 1.

'''Override''': при использовании нескольких механизмов поиска RP, static - менее приоритетный. Override - сделает его приоритетной остальных.

'''PE = RP:'''
 set protocols pim rp local address x.x.x.x
 set protocols pim rp local group-ranges 227.0.0.0/24     - RP только для этих групп (без range: все IPv4, IPv6 группы)
 set protocols pim rp local override        
'''PE =/=  RP:'''
 set protocols pim rp static address x.x.x.x

====Auto-RP====
*Используется с PIMv1 и v2.
*Нестандартное проприетарное решение (вроде от Cisco, нет RFC).
*Позволяет резервировать RP, но не делает балансировку между RP.
*Использует мультикаст для распространения инфо, связанной с RP - dense-mode.
*По PIM домену распространяет набор соответствий group-RP.
Компоненты:
*''Candidate-RP (C-RP)'': периодически отсылают инфо о себе на 224.0.1.39 (слушает только mapping agent) (announce messages).

'''Announce message''':
 C-RP IP | 224.0.1.39 | group 224/4
*''Mapping agent'': слушает C-RP, выбирает RP для каждой группы (наибольший ip), анонсирует победителя RP для группы на 224.0.1.40 (Discovery message - слушают все auto-rp роутеры). 

'''Discovery message/mapping message''':
 Mapping agent IP | 224.0.1.40 | RP 1 - group 224/4

RP выбирается для групп.

Если RP сдохнет, то mapping agent выбирает новую RP. В общем, время падения составляет несколько минут.

'''Конфигурация'''

Обязательно на всех роутерах включить ''sparse-dense mode'' и включить 2 группы, по которым передается служебная инфо. Dense - для передачи служебной информации, Sparse - трафик.
 set protocols pim interface all mode sparse-dense
 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
''discovery'' - только получение mapping (group-RP) сообщений.

'''C-RP:'''
 set protocols pim rp local address 10.200.86.3
 set protocols pim rp auto-rp announce  
''announce'' - '''без local address''': только слушает announce сообщения, '''с local address''': слушает и отправляет announce.

'''RP + mapping agent:'''
 set protocols pim rp local address 10.200.86.3
 set protocols pim rp auto-rp mapping 
''mapping'' - позволяет отправку (и получение) как announce (C-RP), так и mapping (group-RP) сообщений. Если на роутере не будет настроен local address, то роутер сможет ''отправлять'' только announce.

Несколько '''Mapping Agent''', настраиваем только на них:
 set protocols pim auto-rp mapping mapping-agent-election
Mapping agent с наименьшим IP (проиграл) перестает слать mapping messages в сеть, при получении mapping message от агента с бОльшим IP.
 set protocols pim auto-rp mapping no-mapping-agent-election

====Bootstrap====
*Работает только с PIMv2. Для распространения информации используют сообщения PIMv2.
*backup RP обеспечивает средство защиты от падения RP и некую балансировку для одних и тех же групп между RP. Но по прежнему для 1 активной группы - используется 1 RP.
*сообщения между роутерами происходит с source Lo interface роутера. Поэтому Lo обязательно должны быть routable. Можно проверить: ''show pim bootstrap''

'''Компоненты:'''
*Candidate-RP: заявляет о себе BSR через unicast (advertisement message).
*Bootstrap router: выбирается на основании наивысшего приоритета (далее наивысшего ip), получает оповещения от C-RP. Определяет RP/group соответствие - это RP-set. Включает RP-set в bootstrap сообщения и распространяет по сети.

BSR - всего лишь роутер, который будет передавать информацию: RP-set: RP <-> группы. То есть в выводе: ''sh pim rps'' мы увидим все RP.

'''Выборы:'''
#Выбор BSR: каждый роутер предполагает, что он BSR. Генерирует BSR-сообщения другим BSR (ip+приоритет+пустой RP-set). Когда роутер получает BSR-сообщение с бОльшим приоритетом (или бОльшим ip), он перестает генерировать сообщения. Выбранный BSR-роутер продолжает генерировать сообщения, остальные лузеры-BSR просто передают эти сообщения своим соседям. Т.о. все роутеры знают об активном BSR. BSR генерирует BSR сообщение, в котором содержится ip BSR, пустой RP-set. DA = 224.0.0.13. 
#C-RP передают инфо о себе BSR: свой ip, перечисляют group range.
#BSR собирает C-RP оповещения, складывает их в RP-set (RP+group range). Отправляет RP-set всем PIM роутерам.
#Каждый PIM роутер выбирает для группы действующую RP: делает hash из C-RP ip, group range, mask. Наименьший hash для группы определяет выбранную RP.
Чтобы исключить роутер из выборов (чтобы он перестал отправлять BSR сообщения), можно ему поставить приоритет = 0.

'''Конфигурация'''

BSR [C-RP]:
 set protocols pim rp local 10.200.86.3
 set protocols pim rp bootstrap priority 200

Non-RP: особого конфига не нужно, просто должен быть включен PIM на интерфейсах.

 blair> show pim bootstrap 
 Instance: PIM.master 
 BSR                     Pri Local address           Pri State      Timeout 
 10.200.86.3             200 10.200.86.1             100 Candidate      110

 oban> show pim rps    
 Instance: PIM.master 
 Address family INET
 RP address      Type        Mode   Holdtime Timeout Groups Group prefixes
 10.200.86.1     bootstrap   sparse      150     145      0 224.0.0.0/24
 10.200.86.3     bootstrap   sparse      150    None      1 235.0.0.0/8
 10.200.86.9     bootstrap   sparse      150     145      0 232.1.1.0/24
 10.200.86.3     static      sparse      150    None      1 235.0.0.0/8

====Anycast RP====
Для load-balancing между RP и для обеспечения резерва (redundancy) - лучший способ: использовать Anycast RP.

Может использоваться как с MSDP, так и без него. С использованием MSDP у ваших. Anycast RP будет полное и одинаковое представление об источниках. При выходе одной RP из строя - второй RP не придется изучать инфу о новых source. Лучше использовать MSDP между RP.

С MSDP:
* на lo добавляем еще один адрес [anycast - общий для нескольких PE роутеров]. Изначальный адрес lo лучше сделать primary, anycast адрес - оставить как есть.
 [edit interfaces lo0 unit 0 family inet address 172.30.5.1/32]
 +       primary;
 +       preferred;
 [edit interfaces lo0 unit 0 family inet]
         address 172.30.5.1/32 { ... }
 +       address '''172.30.5.254/32;'''
*nni линки и lo добавляем в protocols pim. Указываем новый адрес lo как адрес RP
 set protocols pim rp local address 172.30.5.254
 set protocols pim interface ge-0/0/0.208
 set protocols pim interface ge-0/0/2.200
 set protocols pim interface ge-0/0/3.204
 set protocols pim interface lo0.0

*строим MSDP-соседство между PE, которые буду выполнять роль RP. Соседство на lo-primary адресах.
 set protocols msdp peer 172.30.5.2 local-address 172.30.5.1
 *'''если не хотим использовать MSDP, то можно и без него.''' Используем все предыдущие шаги и потом:

 set protocols pim rp local family inet address 172.30.5.254 anycast-pim rp-set address 172.30.5.2
 set protocols pim rp local family inet address 172.30.5.254 anycast-pim local-address 172.30.5.1

===Конфигурация дополнительных фич протокола PIM===
====Shortest-path tree cutover (не переключаться на shotest-path tree) ====

 set protocols pim spt-threshold infinity no-spt
 set policy-options policy-statement no-spt term 1 from route-filter 235.4.5.6/32 exact
 set policy-options policy-statement no-spt term 1 from source-address-filter 10.66.66.2/32 exact
 set policy-options policy-statement no-spt term 1 then accept
 set policy-options policy-statement no-spt term 2 then reject

Делается для того, чтобы ограничить дополнительный статус (S,G), который создается при переключении на source-based tree.

Или если из-за других причин не выгодно, чтобы последний роутер перестраивался на SPT.

====Балансировка PIM join====
Если до источника есть несколько равнозначных путей, использоваться будет только 1 (т.к. пройдет RFP-check только 1, альтернативные пути будут простаивать).  Имеется ввиду, что будут балансироваться как join к upstream роутеру, так и трафик в сторону downstream. 

С помощью join-load-balance можно использоваться несколько интерфейсов к источнику.

Включается на не RP-роутерах.
 set protocols pim join-load-balance

====BFD====
Bidirectional Forwarding Detection работает можно настроить также и для PIM.

set protocols pim interface ge-1/0/0.900 family inet bfd-liveness-detection

====Таймеры====
 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" 
 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 роутер
 traceoptions         || для диагностики не забываем включать
 
 show pim neighbors 
 Instance: PIM.master
 Interface           IP V Mode        Option       Uptime Neighbor addr 
 xe-1/1/0.910         4 2             HPLGT       13w2d5h 212.1.253.189  
 xe-1/2/0.822         4 2             HPLG       03:08:00 192.168.152.49 

 B = Bidirectional Capable = bidirectional mode supported
 G = Generation Identifier = gracefull restart turned on for pim
 H = Hello Option Holdtime, 
 L = Hello Option LAN Prune Delay,
 P = Hello Option DR Priority, 
 T = Tracking Bit      = Join Suppression supported, если нет T - то у соседа настроен: ''reset-tracking-bit''

 show pim neighbors detail
 Interface: xe-1/2/0.822
    Address: 192.168.152.49,	IPv4, PIM v2, ''sg Join Count: 2'', tsg Join Count: 0
        BFD: Disabled
        Hello Option Holdtime: 105 seconds 102 remaining
        Hello Option DR Priority: 1
        Hello Option Generation ID: 1593016797
        Hello Option LAN Prune Delay: delay 1000 ms override 3000 ms
   Address: 192.168.152.50,	IPv4, PIM v2, Mode: Sparse, sg Join Count: 0, tsg Join Count: 0
        Hello Option Holdtime: 65535 seconds
        Hello Option DR Priority: 1
        Hello Option Generation ID: 1898464853
        Hello Option LAN Prune Delay: delay 500 ms override 2000 ms
                                      Join Suppression supported

 pim {
    traceoptions {
        file pim.log size 10m;
        flag all;

PIM Join и PIM Prune можно посмотреть в '''pim statistics''' (как принятые так и отправленные).

 > show pim statistics interface xe-1/2/0.822 
 Instance: PIM.master Family: INET
 PIM Interface statistics for xe-1/2/0.822
 PIM Message type        Received       Sent  Rx errors
 '''V2 Hello                     389        413          0'''
 V2 Register                    0          0          0
 V2 Register Stop               0          0          0
 '''V2 Join Prune                  0        195          0'''

В monitor traffic interface не будут отображаться PIM Join, PIM Prune. Если требуется помониторить входящие и исходящие пакеты, то можно только замиррорить трафик.

При включенном traceoptions, join также отчетливо видны (исходящие):
 traceoptions {
    file pim.log size 10m;
    flag all;
    flag join detail;
    flag prune detail;

 > show log pim.log | match 235.69.101.
 Oct 13 13:21:50.354863 group 235.69.101.1 joins 1 prunes 0
 Oct 13 13:21:50.354881 group 235.69.101.2 joins 1 prunes 0
 Oct 13 13:21:50.354897 group 235.69.101.4 joins 1 prunes 0
 Oct 13 13:21:50.354913 group 235.69.101.11 joins 1 prunes 0
 Oct 13 13:21:50.354929 group 235.69.101.19 joins 1 prunes 0
 Oct 13 13:21:50.354944 group 235.69.101.20 joins 1 prunes 0

==Bidirectional mode==
То же самое что и Sparse, только в bidirectional PIM роутеры строят shared bidirectional trees (*,G) и не производят переключение на SPT. За счет этого в процессе работы используются только (*,G).

Считается, что этот режим более масштабируемый для сети.

В отличие от PIM-SM, в данном режиме не требуется PIM Register tunneling.

т.к не происходит перестроение на SPT - может наблюдаться неоптимальный мультикаст роутинг.

=Дополнительная информация=
*[[Глава 5. PIM-SSM]]
*[[Политики в мультикасте | Глава 6. Политики в мультикасте]]
*[[MSDP | Глава 4. MSDP]]