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
|
|
Показаны примеры вывода в случаях, когда в сети есть клиенты соответствующей группы. О том, как настроить маршрутизатор в роли клиента, ниже. |
[править] Маршрутизатор как клиент мультикаст
R7(config)# int f0/0 R7(config-if)# ip igmp join-group 239.1.1.1
[править] Пример работы PIM-DM на Cisco
Пример работы 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 устанавливает отношения соседства, которые, в принципе, работают как и в протоколах динамической маршрутизации.
В роли источников и клиентов будут маршрутизаторы.
|
|
Для демонстрации работы 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
|
|
Группа 224.0.1.40 используется в режиме PIM-SM и всегда присутствует в таблице мультикаст в Cisco. |
В дальнейших выводах команды sh ip mroute, шапка с расшифровкой флагов будет опускаться.
[править] Флудинг трафика по сети
В сети появляется источник трафика, но пока что нет клиентов.
Источником будет маршрутизатор 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
[править] Таблица маршрутизации мультикаст на маршрутизаторах, когда в группе есть клиенты
Маршрутизатор 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
На маршрутизаторе 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
Если на маршрутизаторе не включена отправка сообщений 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
На примере сегмента между 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
Добавляем интерфейс 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
На примере сегмента между R8, R9 и R10 можно рассмотреть выбор Forwarder.
Если в один сегмент сети несколько маршрутизаторов передают мультикаст трафик, то, для того чтобы, исключить копирование трафика, выбирается маршрутизатор, который будет отвечать за отправку трафика в сегмент. Этот маршрутизатор называется Forwarder.
Forwarder определяется на основании сообщений Assert.
|
|
Интерфейс 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)
[править] Итоговая топология
[править] Дополнительная информация
- State Refresh в PIM-DM (англ.)
