Xgu.ru теперь в Контакте  — приходите и подключайтесь.
Пока мы работаем над следующими видео, вы можете подключиться в Контакте. Познакомимся и обсудим новые страницы и ролики.

Vk-big.pngYoutube-big.jpeg

PIM-DM в Cisco

Материал из Xgu.ru

Перейти к: навигация, поиск
Автор: Наташа Самойленко

PIM Dense Mode (PIM-DM) — это один из протоколов из семейства PIM. PIM-DM распространяет информацию об источниках и группах, выполняя флудинг по всему домену PIM.

Хотя в реальной жизни, на сегодняшний день, PIM-DM редко используется, информация о том, как он работает, может помочь понять как работают другие варианты PIM.

В разделе пример работы PIM-DM на Cisco пошагово описаны принципы работы PIM-DM, с выводами команд debug и show. Для лучшего понимания желательно также прочитать страницу PIM-DM, так как в этом разделе основной упор на то, чтобы показать эту работу на Cisco.

Принципы работы PIM Dense Mode описаны на странице PIM-DM.


Содержание

[править] Настройка PIM-DM в Cisco

PIM-DM настраивается довольно просто. Достаточно чтобы была включена маршрутизация мультикаст и включен PIM-DM на интерфейсах:

dyn3(config-if)# ip pim dense-mode

Если домены юникаст маршрутизации и мультикаст маршрутизации совпадают, то с PIM-DM не должно быть никаких проблем.

[править] Маршрутизатор как клиент мультикаст

Если на маршрутизаторе выполнить команду ip igmp join-group, то для указанной группы в таблице маршрутизации создается родительская запись (parent entry). Например, для группы 224.1.1.1 (*, 224.1.1.1).

В режиме PIM-DM эта запись не используется для передачи трафика multicast. Однако в Cisco IOS для каждой пары (S, G), создается соответствующая родительская запись. В этой записи в списке исходящих интерфейсов будут указаны интерфейсы:

  • с соседями PIM-DM,
  • непосредственно присоединенные соседи,
  • статически настроенные участники группы (ip igmp static-group или ip igmp join-group).


[править] Маршрутизатор как источник мультикаст

Маршрутизатор R1 будет источником трафика. Генерировать мультикаст пакеты можно обычным ping:

R1#ping 239.1.1.1 repeat 1000

Type escape sequence to abort.
Sending 1000, 100-byte ICMP Echos to 239.1.1.1, timeout is 2 seconds:

Reply to request 0 from 10.1.79.7, 1132 ms
Reply to request 1 from 10.1.79.7, 932 ms
Reply to request 2 from 10.1.79.7, 1032 ms
Reply to request 3 from 10.1.79.7, 1132 ms.

Или расширенным:

Repeat count [1]: 1000
Datagram size [100]: 
Timeout in seconds [2]: 
Extended commands [n]: yes
Interface [All]: FastEthernet2/0
Time to live [255]: 
Source address: 10.1.12.1
Type of service [0]: 
Set DF bit in IP header? [no]: 
Validate reply data? [no]: 
Data pattern [0xABCD]: 
Loose, Strict, Record, Timestamp, Verbose[none]: 
Sweep range of sizes [n]: 
Type escape sequence to abort.
Sending 1000, 100-byte ICMP Echos to 239.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 10.1.12.1 

Reply to request 0 from 10.1.79.7, 1196 ms
Reply to request 1 from 10.1.79.7, 908 ms
Reply to request 2 from 10.1.79.7, 1008 ms
Reply to request 3 from 10.1.79.7, 1108 ms
Reply to request 4 from 10.1.79.7, 908 ms
Reply to request 5 from 10.1.79.7, 1008 ms
Reply to request 6 from 10.1.79.7, 688 ms
Reply to request 7 from 10.1.79.7, 1088 ms

Note-icon.gif

Показаны примеры вывода в случаях, когда в сети есть клиенты соответствующей группы. О том, как настроить маршрутизатор в роли клиента, ниже.

[править] Маршрутизатор как клиент мультикаст

R7(config)# int f0/0                    
R7(config-if)# ip igmp join-group 239.1.1.1

[править] Пример работы PIM-DM на Cisco

PIM-DM cisco.png

Пример работы PIM-DM будет пошагово показан на основе схемы, которая изображена на рисунке. На схеме все IP-адреса соответствуют такому шаблону: 10.1.x.y/24. Где x — номера соседних маршрутизаторов, между которыми проходит сеть, а y — номер маршрутизатора.

На всех маршрутизаторах настроен OSPF, включена маршрутизация мультикаст и настроен режим dense на всех интерфейсах:

router ospf 1
 network 10.1.0.0 0.0.255.255 area 0
!
ip multicast-routing
!
int f0/0
 ip pim dense-mode

После включения PIM-DM на интерфейсах, PIM устанавливает отношения соседства, которые, в принципе, работают как и в протоколах динамической маршрутизации.

В роли источников и клиентов будут маршрутизаторы.

Icon-caution.gif

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

Кроме этого, используется вывод команд debug ip pim и debug ip mpacket.

[править] Сеть до появления источника мультикаст пакетов

До появления источника трафика, таблица маршрутизации мультикаст на всех маршрутизаторах в сети выглядит так:

dyn5#show ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report,
       Z - Multicast Tunnel, z - MDT-data group sender,
       Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 224.0.1.40), 00:32:04/00:02:10, RP 0.0.0.0, flags: DCL
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    FastEthernet2/0, Forward/Dense, 00:31:56/00:00:00
    FastEthernet1/0, Forward/Dense, 00:32:03/00:00:00
    FastEthernet0/0, Forward/Dense, 00:32:04/00:00:00

Note-icon.gif

Группа 224.0.1.40 используется в режиме PIM-SM и всегда присутствует в таблице мультикаст в Cisco.

В дальнейших выводах команды sh ip mroute, шапка с расшифровкой флагов будет опускаться.

[править] Флудинг трафика по сети

PIM-DM cisco 1.png

В сети появляется источник трафика, но пока что нет клиентов.

Источником будет маршрутизатор R1:

R1#ping 239.1.1.1 repeat 1000

Type escape sequence to abort.
Sending 1000, 100-byte ICMP Echos to 239.1.1.1, timeout is 2 seconds:
.............................


На маршрутизаторе R6:

IP(0): s=10.1.12.1 (Fa0/0) d=239.1.1.1 (Fa2/0) id=69, ttl=253, prot=1, len=100(100), mforward
IP(0): s=10.1.12.1 (Fa0/0) d=239.1.1.1 (Fa2/0) id=70, ttl=253, prot=1, len=100(100), mforward
IP(0): s=10.1.12.1 (Fa0/0) d=239.1.1.1 (Fa2/0) id=71, ttl=253, prot=1, len=100(100), mforward

На маршрутизаторе R7:

IP(0): s=10.1.12.1 (Fa1/0) d=239.100.1.1 id=744, ttl=251, prot=1, len=114(100), not RPF interface
IP(0): s=10.1.12.1 (Fa2/0) d=239.100.1.1 (Fa1/0) id=744, ttl=251, prot=1, len=100(100), mforward

R7 выбрал интерфейс fa2/0 как RPF по направлению к источнику 10.1.12.1. Поэтому, когда трафик приходит на fa1/0, то R7 его отбрасывает (выделено в выводе).

Проверить какой интерфейс прошел проверку RPF:

R7#sh ip rpf 10.1.12.1
RPF information for ? (10.1.12.1)
  RPF interface: FastEthernet2/0
  RPF neighbor: ? (10.1.79.9)
  RPF route/mask: 10.1.12.0/24
  RPF type: unicast (ospf 1)
  RPF recursion count: 0
  Doing distance-preferred lookups across tables

Как только появился источник и был выполнен флудинг пакетов по сети, на каждом маршрутизаторе, в таблице маршрутизации мультикаст, появилась запись (S, G). В данном случае это запись (10.1.12.1, 239.1.1.1):

R4# sh ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report,
       Z - Multicast Tunnel, z - MDT-data group sender,
       Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode 

(10.1.12.1, 239.1.1.1), 00:00:05/00:02:54, flags: PT
  Incoming interface: FastEthernet1/0, RPF nbr 10.1.35.3
  Outgoing interface list: Null
[править] Таблица маршрутизации мультикаст на маршрутизаторах, когда в группе есть клиенты
PIM-DM cisco 1a.png

Маршрутизатор R4 будет клиентом, который хочет получать рассылку группы 239.1.1.1:

R4(config)# int f1/0
R4(config-if)# ip igmp join-group 239.1.1.1

Теперь на R4 в таблице маршрутизации мультикаст один интерфейс в состоянии forward:

R3#sh ip mroute 239.1.1.1 

(10.1.12.1, 239.1.1.1), 00:37:09/00:02:55, flags: T
  Incoming interface: FastEthernet1/0, RPF nbr 10.1.23.2
  Outgoing interface list:
    FastEthernet2/0, Forward/Dense, 00:00:41/00:00:00

Так как клиент непосредственно подключен к R3, можно посмотреть участников группы в информации IGMP:

R3#sh ip igmp groups 239.1.1.1
IGMP Connected Group Membership
Group Address    Interface                Uptime    Expires   Last Reporter
239.1.1.1        FastEthernet2/0          00:01:51  00:02:54  10.1.35.4

На R2 в таблице маршрутизации мультикаст интерфейс, который веде к подключенному клиенту R4, в состоянии forward, а fa2/0 в состоянии Prune:

R2#sh ip mroute 239.1.1.1

(10.1.12.1, 239.1.1.1), 00:36:47/00:02:53, flags: T
  Incoming interface: FastEthernet0/0, RPF nbr 0.0.0.0
  Outgoing interface list:
    FastEthernet1/0, Forward/Dense, 00:03:20/00:00:00
    FastEthernet2/0, Prune/Dense, 00:33:37/00:02:43

[править] Удаление ветвей без получателей. Prune

PIM-DM cisco 2.png

На маршрутизаторе R6:

# Пришли мультикаст пакеты:
IP(0): s=10.1.12.1 (Fa0/0) d=239.1.1.1 (Fa1/0) id=69, ttl=253, prot=1, len=100(100), mforward
IP(0): s=10.1.12.1 (Fa0/0) d=239.1.1.1 (Fa2/0) id=69, ttl=253, prot=1, len=100(100), mforward

# R6 получил сообщение Prune от R8 и, соответственно, отметил, что интерфейс f1/0 в состоянии Prune:
PIM(0): Received v2 Join/Prune on FastEthernet1/0 from 10.1.68.8, to us
PIM(0): Prune-list: (10.1.12.1/32, 239.1.1.1) 
PIM(0): Prune FastEthernet1/0/239.1.1.1 from (10.1.12.1/32, 239.1.1.1)

# R6 получил сообщение Prune от R9 и, соответственно, отметил, что интерфейс f2/0 в состоянии Prune:
PIM(0): Received v2 Join/Prune on FastEthernet2/0 from 10.1.69.9, to us
PIM(0): Prune-list: (10.1.12.1/32, 239.1.1.1) 
PIM(0): Prune FastEthernet2/0/239.1.1.1 from (10.1.12.1/32, 239.1.1.1)

# Так как у R6 нет непосредственно подключенных клиентов и нет нижестоящих соседей PIM,
которые хотят получать рассылку 239.1.1.1, то R6 отправляет Prune своему вышестоящему соседу R2:
PIM(0): Insert (10.1.12.1,239.1.1.1) prune in nbr 10.1.26.2's queue
PIM(0): Building Join/Prune packet for nbr 10.1.26.2
PIM(0): Adding v2 (10.1.12.1/32, 239.1.1.1) Prune
PIM(0): Send v2 join/prune to 10.1.26.2 (FastEthernet0/0)

На остальных маршрутизаторах в сети ситуация будет аналогичной: так как нет клиентов желающих получать пакеты группы 239.1.1.1, то все интерфейсы будут в состоянии Prune.

Пока источник генерирует трафик, группа будет в таблице маршрутизации. Но когда пакеты перестанут приходить, то группа будет удалена через время, которое указано в таймере для группы:

R6#sh ip mroute 239.1.1.1
...
Outgoing interface flags: H - Hardware switched, A - Assert winner
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(10.1.12.1, 239.1.1.1), 00:00:14/00:02:52, flags: PT
  Incoming interface: FastEthernet0/0, RPF nbr 10.1.26.2
  Outgoing interface list:
    FastEthernet1/0, Prune/Dense, 00:00:13/00:02:46
    FastEthernet2/0, Prune/Dense, 00:00:09/00:02:50

[править] State-Refresh

PIM-DM cisco 3.png

Если на маршрутизаторе не включена отправка сообщений State-Refresh, то каждые 3 минуты будет повторяться флудинг трафика и исключение ветвей с помощью Prune.

Так как сообщения State Refresh генерирует маршрутизатор, который непосредственно присоединен к источнику, то в рассматриваемой схеме, это будет маршрутизатор R2. Он будет генерировать сообщения State-Refresh, а далее они будут идти вниз по дереву, обновляя таймеры на маршрутизаторах.

Проверить включен ли функционал State-Refresh (на данном интерфейсе выключен):

R6#sh ip pim interface f0/0 detail 
FastEthernet0/0 is up, line protocol is up
  Internet address is 10.1.26.6/24
  Multicast switching: process
  Multicast packets in/out: 73/0
  Multicast TTL threshold: 0
  PIM: enabled
    PIM version: 2, mode: dense
    PIM DR: 10.1.26.6 (this system)
    PIM neighbor count: 1
    PIM Hello/Query interval: 30 seconds
    PIM State-Refresh processing: enabled
    PIM State-Refresh origination: disabled
    PIM NBMA mode: disabled
    PIM ATM multipoint signalling: disabled
    PIM domain border: disabled
  Multicast Tagswitching: disabled

Включить на интерфейсе отправку State-Refresh:

R6(config)# int f0/0
R6(config-if)# ip pim state-refresh origination-interval    

По умолчанию интервал будет 60 секунд:

R6#sh ip pim interface f0/0 detail 
FastEthernet0/0 is up, line protocol is up
...
    PIM State-Refresh processing: enabled
    PIM State-Refresh origination: enabled, interval: 60 seconds
...

Вывод debug ip pim после включения отправки State-Refresh:

# R6 получил State-Refresh (SR) через интерфейс f0/0 от R2:
PIM(0): Received v2 State-Refresh on FastEthernet0/0 from 10.1.26.2
PIM(0): SR on iif from 10.1.26.2 orig 10.1.12.2 for (10.1.12.1,239.1.1.1)
PIM(0): flags: prune-indicator 
PIM(0): Cached metric is [0/0]
PIM(0): Keep RPF nbr 10.1.26.2
#R6 отправляет SR через интерфейсы f1/0 и f2/0:
PIM(0): Send SR on FastEthernet1/0 for (10.1.12.1,239.1.1.1) TTL=253
PIM(0): flags: prune-indicator 
PIM(0): Send SR on FastEthernet2/0 for (10.1.12.1,239.1.1.1) TTL=253
PIM(0): flags: prune-indicator

[править] Prune Override

PIM-DM cisco 3a.png

На примере сегмента между R3, R4 и R5 можно рассмотреть процедуру Prune Override.

Все три маршрутизатора находятся в одном сегменте, а к R4 подключен клиент, который хочет получать рассылку. Так как у R5 нет клиентов или нижестоящих соседей, которые хотят получать трафик, он будет отправлять через свой RPF-интерфейс, вышестоящему соседу R3, сообщение Prune для пары (10.1.12.1, 239.1.1.1).

После получения сообщения Prune, R3 ждет 3 секунды, прежде чем удалить интерфейс fa2/0 из дерева. За это время R4 должен отправить сообщение Prune Override (которое представляет из себя сообщение Join), для того чтобы сообщить R3, что в сегменте есть желающие получать трафик.


Маршрутизатор R5 генерирует Prune своему RPF-соседу 10.1.35.3, так как у него нет клиентов или нижестоящих соседей, которые хотят получать трафик:

# Генерация Prune на R5:
*19:57:53.801: PIM(0): Insert (10.1.12.1,239.1.1.1) prune in nbr 10.1.35.3's queue
*19:57:53.805: PIM(0): Building Join/Prune packet for nbr 10.1.35.3
*19:57:53.805: PIM(0): Adding v2 (10.1.12.1/32, 239.1.1.1) Prune
*19:57:53.805: PIM(0): Send v2 join/prune to 10.1.35.3 (FastEthernet1/0)

Вывод debug ip pim на маршрутизаторе R3:

# На R3 приходит сообщение Prune от R5
*19:57:53.205: PIM(0): Received v2 Join/Prune on FastEthernet2/0 from 10.1.35.5, to us
*19:57:53.205: PIM(0): Prune-list: (10.1.12.1/32, 239.1.1.1)
*19:57:53.209: PIM(0): Schedule to prune FastEthernet2/0 for (10.1.12.1/32, 239.1.1.1)

Вывод debug ip pim на маршрутизаторе R4:

# R4 видит сообщение Prune, которое маршрутизатор R5 отправляет маршрутизатору R3:
*19:57:53.345: PIM(0): Received v2 Join/Prune on FastEthernet1/0 from 10.1.35.5, not to us
*19:57:53.345: PIM(0): Prune-list: (10.1.12.1/32, 239.1.1.1)
# В ответ на это сообщение, R4 запускает таймер и отправляет сообщение Join (Prune Override):
*19:57:53.349: PIM(0): Set join delay timer to 1000 msec for (10.1.12.1/32, 239.1.1.1) on FastEthernet1/0
*19:57:54.337: PIM(0): Insert (10.1.12.1,239.1.1.1) join in nbr 10.1.35.3's queue
*19:57:54.337: PIM(0): Building Join/Prune packet for nbr 10.1.35.3
*19:57:54.337: PIM(0): Adding v2 (10.1.12.1/32, 239.1.1.1) Join
*19:57:54.341: PIM(0): Send v2 join/prune to 10.1.35.3 (FastEthernet1/0)


R3 получает Join от R4. Это и есть сообщение Prune Override:

*19:57:54.405: PIM(0): Received v2 Join/Prune on FastEthernet2/0 from 10.1.35.4, to us
*19:57:54.405: PIM(0): Join-list: (10.1.12.1/32, 239.1.1.1)
# После получения Prune Override, R3 обновляет состояние интерфейса:
*19:57:54.409: PIM(0): Update Fa2/0/10.1.35.4 to (10.1.12.1, 239.1.1.1), Forward state, by PIM SG Join


В это время R5 тоже видит Prune Override:

*19:57:54.993: PIM(0): Received v2 Join/Prune on FastEthernet1/0 from 10.1.35.4, not to us
*19:57:54.993: PIM(0): Join-list: (10.1.12.1/32, 239.1.1.1)

[править] Подключение ранее удаленной ветви. Graft

PIM-DM cisco 4.png

Добавляем интерфейс f0/0 маршрутизатора R7 как клиента группы 239.1.1.1:

R7(config)#int f0/0                                      
R7(config-if)#ip igmp join-group 239.1.1.1

R7, как маршрутизатор PIM, отправляет через свой RPF-интерфейс сообщение Graft (обратите внимание, что хотя интерфейсы f0/0 и f1/0 фигурируют в выводе, отправлено сообщение Graft только через f2/0):

PIM(0): Building Graft message for 239.1.1.1, FastEthernet0/0: no entries
PIM(0): Building Graft message for 239.1.1.1, FastEthernet2/0:
     10.1.12.1/32
PIM(0): Send v2 Graft to 10.1.79.9 (FastEthernet2/0)
PIM(0): Building Graft message for 239.1.1.1, FastEthernet1/0: no entries
PIM(0): Received v2 Graft-Ack on FastEthernet2/0 from 10.1.79.9
     Group 239.1.1.1:
     10.1.12.1/32

Как только приходит Graft-Ack от вышестоящего соседа, на R7 приходят мультикаст пакеты:

R7#
IP(0): s=10.1.12.1 (FastEthernet2/0) d=239.1.1.1 (FastEthernet0/0) id=2304, ttl=251, prot=1, len=100(100), mforward
IP(0): s=10.1.12.1 (FastEthernet2/0) d=239.1.1.1 (FastEthernet0/0) id=2305, ttl=251, prot=1, len=100(100), mforward
IP(0): s=10.1.12.1 (FastEthernet2/0) d=239.1.1.1 (FastEthernet0/0) id=2306, ttl=251, prot=1, len=100(100), mforward

Выше по дереву SPT можно увидеть сообщения Graft на R9:

PIM(0): Join-list: (10.1.12.1/32, 239.1.1.1)
PIM(0): Add FastEthernet2/0/0.0.0.0 to (10.1.12.1, 239.1.1.1), Forward state, by PIM Graft
PIM(0): Send v2 Graft-Ack on FastEthernet2/0 to 10.1.79.7
PIM(0): Building Graft message for 239.1.1.1, FastEthernet1/0:
    10.1.12.1/32
PIM(0): Send v2 Graft to 10.1.69.6 (FastEthernet1/0)
PIM(0): Received v2 Graft-Ack on FastEthernet1/0 from 10.1.69.6
     Group 239.1.1.1:
     10.1.12.1/32

И на на R9:

PIM(0): Join-list: (10.1.12.1/32, 239.1.1.1)
PIM(0): Add FastEthernet2/0/0.0.0.0 to (10.1.12.1, 239.1.1.1), Forward state, by PIM Graft
PIM(0): Send v2 Graft-Ack on FastEthernet2/0 to 10.1.69.9
PIM(0): Building Graft message for 239.1.1.1, FastEthernet0/0:
    10.1.12.1/32
PIM(0): Send v2 Graft to 10.1.26.2 (FastEthernet0/0)
PIM(0): Received v2 Graft-Ack on FastEthernet0/0 from 10.1.26.2
     Group 239.1.1.1:
     10.1.12.1/32

В итоге на R2 оба интерфейса в OIL в состоянии forward:

dyn2#sh ip mroute 239.1.1.1
...
(10.1.12.1, 239.1.1.1), 00:56:50/00:02:50, flags: T
  Incoming interface: FastEthernet0/0, RPF nbr 0.0.0.0
  Outgoing interface list:
    FastEthernet1/0, Forward/Dense, 00:23:23/00:00:00
    FastEthernet2/0, Forward/Dense, 00:10:43/00:00:00

[править] Выбор Forwarder. Сообщения Assert

PIM-DM cisco 3b.png

На примере сегмента между R8, R9 и R10 можно рассмотреть выбор Forwarder.

Если в один сегмент сети несколько маршрутизаторов передают мультикаст трафик, то, для того чтобы, исключить копирование трафика, выбирается маршрутизатор, который будет отвечать за отправку трафика в сегмент. Этот маршрутизатор называется Forwarder.

Forwarder определяется на основании сообщений Assert.

Note-icon.gif

Интерфейс f0/0 маршрутизатора R10 добавлен как клиент в группу 239.1.1.1.


Маршрутизатор R8:

PIM(0): Send v2 Assert on FastEthernet0/0 for 239.1.1.1, source 10.1.12.1, metric [110/3]
PIM(0): Assert metric to source 10.1.12.1 is [110/3]
PIM(0): We win, our metric [110/3]
PIM(0): Schedule to prune FastEthernet0/0
PIM(0): (10.1.12.1/32, 239.1.1.1) oif FastEthernet0/0 in Forward state
PIM(0): Received v2 Assert on FastEthernet0/0 from 10.1.89.9
PIM(0): Assert metric to source 10.1.12.1 is [110/3]
PIM(0): We lose, our metric [110/3]

Маршрутизатор R9 выиграл (так как у него значение IP-адреса больше, а AD и метрика у R8 и R9 одинаковые) и стал Forwarder:

PIM(0): Received v2 Assert on FastEthernet0/0 from 10.1.89.8
PIM(0): Assert metric to source 10.1.12.1 is [110/3]
PIM(0): We win, our metric [110/3]
PIM(0): (10.1.12.1/32, 239.1.1.1) oif FastEthernet0/0 in Forward state
PIM(0): Send v2 Assert on FastEthernet0/0 for 239.1.1.1, source 10.1.12.1, metric [110/3]
PIM(0): Assert metric to source 10.1.12.1 is [110/3]
PIM(0): We win, our metric [110/3]
PIM(0): (10.1.12.1/32, 239.1.1.1) oif FastEthernet0/0 in Forward state


Маршрутизатор R10:

PIM(0): Received v2 Assert on FastEthernet1/0 from 10.1.89.8
PIM(0): Assert metric to source 10.1.12.1 is [110/3]
PIM(0): Cached metric is [Inf/-1]
MRT(0): New RPF nbr 10.1.89.8 from Assert for (10.1.12.1/32, 239.1.1.1)
PIM(0): Set join delay timer to 3000 msec for (10.1.12.1/32, 239.1.1.1) on FastEthernet1/0
PIM(0): Received v2 Assert on FastEthernet1/0 from 10.1.89.9
PIM(0): Assert metric to source 10.1.12.1 is [110/3]
PIM(0): Cached metric is [110/3]
MRT(0): New RPF nbr 10.1.89.9 from Assert for (10.1.12.1/32, 239.1.1.1)

[править] Итоговая топология

PIM-DM cisco 5.png

[править] Дополнительная информация