Глава 3. Routing protocols (DVMRP, PIM-DM, PIM-SM)

Материал из Juniper Exam Wiki
Перейти к навигации Перейти к поиску

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

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

Messges

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

Neighborship

Соседство устанавливается и поддерживается с помощью 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

Dense: целесообразно использовать только в том случае, если используем IGMPv1, т.к. он не имеет встречного механизма выбора query роутера.

Flooding

Для доставки multicast использует SPT.

  • Все роутеры получат одну копию исходного потока.
  • Каждый роутер проводит RPF check. Пакеты, которые не прошли RPF check - отбрасываются.
  • Пакеты прошедшие RPF check копируются и флудятся во все порты (OIL), за исключением порта, откуда трафик пришел (IIF).
  • (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.

При этом на 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

По дефлту при добавлении интерфейса в 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
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.

Messages

  • 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

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 operations, 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 знало, что источник все еще жив.

Tunnel requeriments

Для 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.

Выборы:

  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.

Чтобы исключить роутер из выборов (чтобы он перестал отправлять 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
[edit protocols pim]    
rp {
   local {
       address 172.30.5.254;
interface ge-0/0/0.208;
interface ge-0/0/2.200;
interface ge-0/0/3.204;
interface lo0.0;
  • строим MSDP-соседство между PE, которые буду выполнять роль RP. Соседство на lo-primary адресах.
[edit protocols]
+   msdp {
+       peer 172.30.5.2 {
+           local-address 172.30.5.1;
*если не хотим использовать MSDP, то можно и без него. Используем все предыдущие шаги и потом:
[edit protocols pim]
+    rp {
+        local {
+            family inet {
+                address 172.30.5.254;
+                anycast-pim {
+                    rp-set {
+                        address 172.30.5.2;
+                    local-address 172.30.5.1;

Specific config

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 load balancing

Если до источника есть несколько равнозначных путей, использоваться будет только 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 сообщением.

Troubleshoting

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 - может наблюдаться неоптимальный мультикаст роутинг.