1
00:00:07,980 --> 00:00:12,560
 В прошлом видео мы довольно подробно
 рассмотрели, что это за процесс.

2
00:00:12,560 --> 00:00:16,460
 используется, когда мы создаем общее
 дерево, как членство в IGMPM

3
00:00:16,460 --> 00:00:21,780
 отчет, полученный шлюзом по умолчанию, запускает
 PIM, то, что мы называем звездой,

4
00:00:21,780 --> 00:00:27,420
 G-join, который шаг за шагом
 продвигается к точке встречи.

5
00:00:27,420 --> 00:00:31,940
 И мы увидели, как это происходит, каждый маршрутизатор
 от маршрутизатора, по умолчанию

6
00:00:31,940 --> 00:00:35,260
 шлюз, получивший отчет о членстве,
 а затем каждый маршрутизатор вдоль

7
00:00:35,260 --> 00:00:39,740
 путь, который принимает звезду,
 G-соединение до точки встречи,

8
00:00:39,740 --> 00:00:44,440
 это создало то, что мы назвали звездой, состоянием
 маршрута G-em в нашей многоадресной маршрутизации.

9
00:00:44,440 --> 00:00:55,380
 стол. Итак, как только у нас будет эта звезда,
 состояние маршрута G-em, то есть я не

10
00:00:55,380 --> 00:00:59,080
 неважно, что это за источник, как только
 он начнет достигать точки встречи,

11
00:00:59,080 --> 00:01:03,420
 у нас есть открытое соединение, открытый
 путь вплоть до получателя.

12
00:01:03,420 --> 00:01:06,820
 И это основано на том, что было показано
 в списке исходящих интерфейсов.

13
00:01:06,820 --> 00:01:13,180
 Хорошо, теперь давайте собственно запустим многоадресную
 рассылку и посмотрим, что там происходит.

14
00:01:13,180 --> 00:01:19,800
 Таким образом, зеленая пунктирная линия в данном
 конкретном случае указывает на общее дерево.

15
00:01:19,800 --> 00:01:21,140
 это уже открыто.

16
00:01:21,140 --> 00:01:26,180
 Я не показываю здесь R8, но мы знаем,
 что R8 находится между этими двумя.

17
00:01:26,180 --> 00:01:30,160
 Теперь источник запустится.

18
00:01:30,160 --> 00:01:34,700
 И что мы увидим, так это когда R4 получит
 эту собственную многоадресную рассылку.

19
00:01:34,700 --> 00:01:39,840
 пакеты от источника, он скажет:
 да, у меня здесь проблема.

20
00:01:39,840 --> 00:01:46,820
 Потому что мне разрешено пересылать эти собственные
 многоадресные пакеты только в том случае, если

21
00:01:46,820 --> 00:01:51,820
 У меня есть запись в таблице маршрутов
 M, которая имеет интерфейс в исходящей

22
00:01:51,820 --> 00:01:56,960
 список интерфейсов. Но он скажет, что
 никто никогда меня об этом не просил.

23
00:01:56,960 --> 00:02:00,140
 Я никогда не получал никаких
 отчетов о членстве в IGMP.

24
00:02:00,140 --> 00:02:03,060
 Я никогда ни от кого не получал
 никаких присоединений к PIM.

25
00:02:03,060 --> 00:02:05,820
 Так что мне некуда это отправить.

26
00:02:05,820 --> 00:02:08,140
 И все же там могут быть приемники.

27
00:02:08,140 --> 00:02:09,600
 Так что мне делать?

28
00:02:09,600 --> 00:02:12,940
 Что ж, в разреженном режиме
 PIM он собирается взять

29
00:02:12,940 --> 00:02:19,280
 этот многоадресный пакет, и он собирается
 инкапсулировать его в одноадресный пакет.

30
00:02:19,280 --> 00:02:22,520
 И это будет внутри пакета PIM.

31
00:02:22,520 --> 00:02:27,300
 Итак, будет другой тип пакета
 PIM, называемый регистром PIM.

32
00:02:27,300 --> 00:02:29,120
 И это то, что мы собираемся
 рассмотреть дальше.

33
00:02:29,120 --> 00:02:31,640
 Так что регистр PIM на самом деле несет.

34
00:02:31,640 --> 00:02:36,600
 Это одноадресный пакет, одноадресная передача
 его от R4 непосредственно к RP.

35
00:02:36,600 --> 00:02:39,200
 Итак, мы увидим исходные адреса R4.

36
00:02:39,200 --> 00:02:42,240
 Адрес назначения – это место встречи.

37
00:02:42,240 --> 00:02:45,920
 Тип PIM будет новым типом,
 называемым регистром.

38
00:02:45,920 --> 00:02:51,240
 И в теле этого фактически будут
 наши многоадресные данные.

39
00:02:51,240 --> 00:02:55,840
 И когда точка встречи получит это,
 он деинкапсулирует ее, обнажая

40
00:02:55,840 --> 00:02:57,780
 многоадресный пакет.

41
00:02:57,780 --> 00:03:01,840
 И тогда РП скажет: окей,
 у меня есть на это штат?

42
00:03:01,840 --> 00:03:04,020
 Кто-нибудь когда-нибудь
 просил меня об этом?

43
00:03:04,020 --> 00:03:07,200
 Что ж, в этом случае вы ответите «да»,
 потому что наше общее дерево уже

44
00:03:07,200 --> 00:03:08,740
 готов и жду.

45
00:03:08,740 --> 00:03:11,460
 Поэтому он перешлет это по общему дереву.

46
00:03:11,460 --> 00:03:15,220
 Вот как наша многоадресная рассылка изначально
 начнется с регистрации этого

47
00:03:15,220 --> 00:03:26,920
 способ. Так что теперь это может продолжаться
 потенциально бесконечно.

48
00:03:26,920 --> 00:03:28,600
 Верно? Я имею в виду, это работает.

49
00:03:28,600 --> 00:03:31,640
 Он передает многоадресную рассылку
 от источника к получателю.

50
00:03:31,640 --> 00:03:38,240
 Но он просит, чтобы маршрутизатор подключен
 к источнику и RP работал.

51
00:03:38,240 --> 00:03:42,940
 немного сложнее обернуть эту штуку в
 одноадресную рассылку и развернуть ее

52
00:03:42,940 --> 00:03:45,360
 из одноадресной передачи на другом конце.

53
00:03:45,360 --> 00:03:50,440
 Поэтому, хотя это и работает, оно потребляет
 немного больше ресурсов процессора.

54
00:03:50,440 --> 00:03:54,040
 И конечно, если бы у нас были десятки
 или сотни многоадресных потоков,

55
00:03:54,040 --> 00:04:05,320
 это потенциально может быть плохо для RP, который
 осуществляет многоадресную рассылку внутри.

56
00:04:05,320 --> 00:04:08,500
 Так что же произойдет?

57
00:04:08,500 --> 00:04:13,940
 И мы увидим это более подробно в следующем
 сегменте, когда произойдет рандеву.

58
00:04:13,940 --> 00:04:18,400
 точка получает этот пакет пин-регистра,
 он на самом деле собирается сделать пару

59
00:04:18,400 --> 00:04:20,260
 вещей одновременно.

60
00:04:20,260 --> 00:04:23,640
 Во-первых, он собирается развернуть
 его и отправить по общему дереву.

61
00:04:23,640 --> 00:04:25,320
 Мы уже говорили об этом.

62
00:04:25,320 --> 00:04:36,140
 Следующая точка встречи — это многоадресная
 рассылка в ее чистом виде.

63
00:04:36,140 --> 00:04:38,600
 Так что я могу просто переслать
 его по моему м-маршруту.

64
00:04:38,600 --> 00:04:41,700
 Так что мне не придется постоянно
 приставать к своему процессору.

65
00:04:41,700 --> 00:04:43,000
 Видите, как мне это сделать?

66
00:04:43,000 --> 00:04:46,540
 Ну, я знаю, что мой сосед выше по течению
 собирается переслать это только

67
00:04:46,540 --> 00:04:48,980
 меня, если я попрошу его об этом.

68
00:04:48,980 --> 00:04:53,160
 Таким образом, RP фактически отправит сообщение
 о присоединении своему соседу.

69
00:04:53,160 --> 00:04:57,560
 Но это не звездная комедия, потому что
 он действительно знает источник.

70
00:04:57,560 --> 00:05:01,040
 Когда приходит этот первый мультикаст,
 он говорит: о, я знаю, кто источник.

71
00:05:01,040 --> 00:05:07,240
 есть, 4.5.4.5. Итак, он собирается отправить
 так называемое соединение S, G.

72
00:05:07,240 --> 00:05:11,280
 Когда мы видим в трассировке снайпера,
 это тот же формат, что и звезда.

73
00:05:11,280 --> 00:05:15,600
 -comedy join, за исключением того, что
 там указан исходный адрес и пара

74
00:05:15,600 --> 00:05:17,800
 Флаги тоже разные.

75
00:05:17,800 --> 00:05:24,440
 И это открывает дерево кратчайшего
 пути от точки встречи до

76
00:05:24,440 --> 00:05:29,120
 источник. Помните, мы говорили
 о том, что потенциально

77
00:05:29,120 --> 00:05:32,080
 несколько общих деревьев, верно?

78
00:05:32,080 --> 00:05:35,240
 Если я являюсь местом встречи и там
 разбросано 50 разных приемников

79
00:05:35,240 --> 00:05:38,940
 в сети может быть 50 различных
 общих деревьев.

80
00:05:38,940 --> 00:05:44,020
 Ну аналогично понятие дерева кратчайших
 путей от отдельного человека

81
00:05:44,020 --> 00:05:45,880
 точка зрения маршрутизатора.

82
00:05:45,880 --> 00:05:49,700
 Мой кратчайший путь к этому источнику –
 маршрутизатор может быть другим.

83
00:05:49,700 --> 00:05:54,700
 чем ваш кратчайший путь, чтобы добраться
 до того самого источника.

84
00:05:54,700 --> 00:05:57,360
 Итак, точка встречи, когда он получит
 этот регистровый пакет, он собирается

85
00:05:57,360 --> 00:06:02,820
 сказать, что я хочу открыть себе кратчайший
 путь, чтобы добраться до этого источника.

86
00:06:02,820 --> 00:06:06,140
 Потому что как только он откроется,
 эти регистры остановятся.

87
00:06:06,140 --> 00:06:09,900
 Начну получать чистый мультикаст
 в его родном виде.

88
00:06:09,900 --> 00:06:15,180
 Итак, как только регистр поступит,
 помимо пересылки его вниз

89
00:06:15,180 --> 00:06:23,900
 таким образом, этот RP будет отправлен,
 позвольте мне немного расширить это, он

90
00:06:23,900 --> 00:06:34,200
 собираюсь отправить s, G присоединиться
 к восходящему потоку.

91
00:06:34,200 --> 00:06:39,960
 И это в R4 добавит быстрый электронный
 знак на нуле-ноле в его

92
00:06:39,960 --> 00:06:42,320
 список исходящих интерфейсов.

93
00:06:42,320 --> 00:06:45,600
 Теперь наша четверка
 скажет: «О, отлично».

94
00:06:45,600 --> 00:06:50,200
 Хорошо, теперь я могу начать пересылку
 многоадресной рассылки в чистом виде.

95
00:06:50,200 --> 00:06:55,180
 Родная форма. Но знаете что, он будет
 продолжать регистрироваться.

96
00:06:55,180 --> 00:06:59,540
 Итак, теперь мы собираемся получить две
 копии этих многоадресных пакетов на

97
00:06:59,540 --> 00:07:03,400
 РП. Мы собираемся отключить встроенную
 многоадресную рассылку.

98
00:07:03,400 --> 00:07:08,560
 И мы собираемся получить еще одну копию внутри
 этого пакета контактного регистра.

99
00:07:08,560 --> 00:07:14,380
 Теперь вы можете спросить:
 почему это произошло?

100
00:07:14,380 --> 00:07:18,360
 Почему R4 просто останавливается
 в этот момент?

101
00:07:18,360 --> 00:07:20,600
 Ну, вот почему.

102
00:07:20,600 --> 00:07:24,600
 В этой конкретной топологии это
 не совсем хорошо ее описывает.

103
00:07:24,600 --> 00:07:40,480
 Но представьте, если бы у меня было это.

104
00:07:40,480 --> 00:07:44,140
 Хорошо, представьте,
 что вот мой источник.

105
00:07:44,140 --> 00:08:00,640
 Хорошо, у нас есть маршрутизатор
 X и PIM RP.

106
00:08:00,640 --> 00:08:02,740
 А это роутер номер пять.

107
00:08:02,740 --> 00:08:08,800
 Итак, мой источник отправляет многоадресную
 рассылку на пятый маршрутизатор.

108
00:08:08,800 --> 00:08:13,700
 Затем маршрутизатор номер пять принимает эту
 многоадресную рассылку и регистрирует ее.

109
00:08:13,700 --> 00:08:20,020
 Посмотрим, смогу ли я нарисовать здесь
 что-нибудь, чтобы обозначить это.

110
00:08:20,020 --> 00:08:23,060
 Итак, это регистрация.

111
00:08:23,060 --> 00:08:34,020
 И теперь пятый маршрутизатор
 получает соединение s, g.

112
00:08:34,020 --> 00:08:38,940
 Итак, давайте посмотрим, какой
 источник у этого парня?

113
00:08:38,940 --> 00:08:41,740
 4.5.4.5 в моем конкретном примере.

114
00:08:41,740 --> 00:08:45,280
 Итак, он говорит: хорошо,
 вот соединение PIM.

115
00:08:45,280 --> 00:08:51,320
 И на самом деле там будут
 указаны источник и группа.

116
00:08:51,320 --> 00:09:06,140
 Хорошо, когда это произойдет, если оно
 было, как мне это сформулировать?

117
00:09:06,140 --> 00:09:08,960
 На самом деле, вот лучший пример.

118
00:09:08,960 --> 00:09:16,180
 Поместите маршрутизатор
 прямо здесь, посередине.

119
00:09:16,180 --> 00:09:21,680
 Итак, все эти PIM-сообщения
 имеют одно время жизни.

120
00:09:21,680 --> 00:09:26,020
 Верно, мы видели, как соединение со звездой PIM
 вышло на один и тот же многоадресный адрес.

121
00:09:26,020 --> 00:09:30,200
 адрес в качестве приветствия, 2240013.

122
00:09:30,200 --> 00:09:33,360
 На самом деле я не указывал на это в трассировке
 сниффера, но точно так же, как и

123
00:09:33,360 --> 00:09:44,720
 Пим здравствуйте пора жить одному, Пим
 присоединяется и назовем его адрес

124
00:09:44,720 --> 00:09:55,220
 равен 55555. Когда соединение PIM происходит
 прямо здесь, в фактическом заголовке IP,

125
00:09:55,220 --> 00:10:01,160
 источник будет исходить от этого парня.

126
00:10:01,160 --> 00:10:06,060
 И пункт назначения будет таким.

127
00:10:06,060 --> 00:10:09,120
 Ну, на самом деле это будет роутер.

128
00:10:09,120 --> 00:10:11,820
 Вот этот парень, 4.5.4.4.

129
00:10:11,820 --> 00:10:18,040
 Скажем так, скажем так, он
 роутер 4, чтобы было проще.

130
00:10:18,040 --> 00:10:24,100
 Таким образом, маршрутизатор 4 не обязательно
 сможет узнать, что это соединение

131
00:10:24,100 --> 00:10:28,800
 на самом деле зародился на RP,
 потому что это шаг за шагом.

132
00:10:28,800 --> 00:10:43,360
 Когда RP впервые отправил его, RP отправил его маршрутизатору
 Z, потому что у него есть запятая.

133
00:10:43,360 --> 00:10:48,720
 g join содержал ту же информацию.

134
00:10:48,720 --> 00:10:51,700
 Источник был 4.5.4.5.

135
00:10:51,700 --> 00:10:56,500
 Группа была 239.999.

136
00:10:56,500 --> 00:11:04,380
 И у пакета здесь был IP-источник
 RP и пункт назначения.

137
00:11:04,380 --> 00:11:12,800
 маршрутизатор 4. Давайте
 поместим это прямо здесь.

138
00:11:12,800 --> 00:11:18,440
 На самом деле нет, пунктом назначения был маршрутизатор
 Z, потому что он выполняется шаг за шагом.

139
00:11:18,440 --> 00:11:22,540
 Это только один прыжок.

140
00:11:22,540 --> 00:11:27,040
 Источник IP — RP.

141
00:11:27,040 --> 00:11:32,480
 Пункт назначения равен маршрутизатору Z.

142
00:11:32,480 --> 00:11:36,820
 Итак, он отправил это сообщение с запятой, потому
 что ведущий сказал: «Хорошо, я знаю, кто этот».

143
00:11:36,820 --> 00:11:44,580
 источник есть. Мой следующий верхний
 сосед — маршрутизатор Z.

144
00:11:44,580 --> 00:11:49,440
 Итак, я собираюсь отправить запятую
 PIM этому соседу и сказать: эй!

145
00:11:49,440 --> 00:11:52,140
 сосед, ты можешь открыть мне этот путь?

146
00:11:52,140 --> 00:11:55,660
 Затем, когда маршрутизатор Z получает
 это, он делает то же самое.

147
00:11:55,660 --> 00:11:59,660
 Он говорит: я уверен, что путь
 к источнику — маршрутизатор 4.

148
00:11:59,660 --> 00:12:04,360
 Итак, я собираюсь создать соединение запятых
 PIM и отправить его на маршрутизатор 4.

149
00:12:04,360 --> 00:12:07,520
 Итак, он открывается по мере
 продвижения по пути сюда.

150
00:12:07,520 --> 00:12:11,120
 Этот интерфейс открывается в
 списке исходящих интерфейсов.

151
00:12:11,120 --> 00:12:14,460
 Этот интерфейс открывается в
 списке исходящих интерфейсов.

152
00:12:14,460 --> 00:12:19,600
 Но когда маршрутизатор 4 получает это,
 он понятия не имеет, почему он получает

153
00:12:19,600 --> 00:12:23,600
 это потому, что RP запустила процесс.

154
00:12:23,600 --> 00:12:27,120
 Все, что он знает, это то, что он получил
 соединение с запятой для маршрутизатора Z.

155
00:12:27,120 --> 00:12:32,080
 Он понятия не имеет, почему маршрутизатор
 Z отправил ему это.

156
00:12:32,080 --> 00:12:36,360
 Только этот маршрутизатор Z получил это,
 а тот маршрутизатор Z инициировал это.

157
00:12:36,360 --> 00:12:41,400
 Итак, он говорит: ну, маршрутизатор Z прислал
 мне это соединение с запятой, но я в

158
00:12:41,400 --> 00:12:43,120
 процесс регистрации.

159
00:12:43,120 --> 00:12:44,780
 Эти двое совершенно разные.

160
00:12:44,780 --> 00:12:48,700
 То, что один парень прислал мне регистрацию, не
 означает, что я должен прекратить регистрацию.

161
00:12:48,700 --> 00:12:51,300
 процесс с другим парнем.

162
00:12:51,300 --> 00:12:54,380
 Я все еще собираюсь продолжать регистрацию,
 потому что я не получил вестей от

163
00:12:54,380 --> 00:13:05,700
 РП еще. Все, что я слышал, это маршрутизатор
 Z, RP получит две копии

164
00:13:05,700 --> 00:13:06,900
 тот же пакет.

165
00:13:06,900 --> 00:13:09,880
 Когда многоадресный пакет начинает передаваться вниз,
 он будет передаваться естественным образом.

166
00:13:09,880 --> 00:13:15,240
 от 4 до Z до RP, потому что
 этот путь теперь открыт.

167
00:13:15,240 --> 00:13:19,240
 И в то же время, когда маршрутизатор 4 получил
 этот многоадресный пакет, он создал

168
00:13:19,240 --> 00:13:25,240
 его копию, и он инкапсулировал ее в одноадресную
 рассылку и отправил ее напрямую

169
00:13:25,240 --> 00:13:31,700
 в РП. Итак, теперь RP говорит:
 да, ладно, отличные новости.

170
00:13:31,700 --> 00:13:37,400
 Я только что получил настоящий многоадресный
 пакет в его чистом виде на свой

171
00:13:37,400 --> 00:13:38,840
 Дерево кратчайших путей.

172
00:13:38,840 --> 00:13:42,160
 Теперь я знаю, что мой кратчайший
 путь к источнику открыт.

173
00:13:42,160 --> 00:13:44,340
 Оно течет. Работает.

174
00:13:44,340 --> 00:13:47,240
 Он говорит, мне больше не нужны
 эти сообщения о регистрации.

175
00:13:47,240 --> 00:13:50,380
 Это заставляет меня работать
 больше, чем нужно.

176
00:13:50,380 --> 00:14:00,520
 Таким образом, RP фактически отправит так называемое
 сообщение об остановке регистра PIM.

177
00:14:00,520 --> 00:14:05,060
 к маршрутизатору 4. Это то,
 что ищет маршрутизатор 4.

178
00:14:05,060 --> 00:14:09,820
 Это заставит его фактически остановить
 процесс регистрации.

179
00:14:09,820 --> 00:14:14,320
 Итак, я знаю, что на этой диаграмме
 это было не совсем ясно.

180
00:14:14,320 --> 00:14:22,400
 Вы могли бы сказать: «Ну ладно, когда
 приложение остановит регистрацию,

181
00:14:22,400 --> 00:14:23,860
 Я хочу показать тебе нет.

182
00:14:23,860 --> 00:14:28,920
 Это не. Регистрация будет продолжаться
 до тех пор, пока RP прямо не скажет:

183
00:14:28,920 --> 00:14:32,900
 пожалуйста остановись. Я больше
 не хочу видеть эти регистры.

184
00:14:32,900 --> 00:14:40,100
 Поэтому он использует сообщение об остановке
 регистрации для переключения.

185
00:14:40,100 --> 00:14:44,780
 На самом деле он не использует его для переключения
 на дерево кратчайшего пути.

186
00:14:44,780 --> 00:14:50,500
 Он делает это после того, как его дерево
 кратчайшего пути уже открыто.

187
00:14:50,500 --> 00:15:05,720
 Так что на самом деле
 я готов это изменить.

188
00:15:05,720 --> 00:15:10,380
 Там RP использует сообщения об остановке регистра
 после своего дерева кратчайшего пути.

189
00:15:10,380 --> 00:15:17,480
 подтвержден и открыт.

190
00:15:17,480 --> 00:15:20,320
 Итак, это процесс регистрации PIM.

191
00:15:20,320 --> 00:15:26,420
 Итак, давайте продолжим, посмотрим на
 это и посмотрим, как это работает.

192
00:15:26,420 --> 00:15:32,340
 Я думаю, что сейчас наше
 общее дерево открыто.

193
00:15:32,340 --> 00:15:35,280
 Давайте просто подтвердим, зайдем на роутер
 3 в RP и убедимся, что он все еще

194
00:15:35,280 --> 00:15:46,720
 имеет звездочку, запись.

195
00:15:46,720 --> 00:15:48,680
 О, ладно, он этого не делает.

196
00:15:48,680 --> 00:15:53,640
 Давайте вернемся к нашему источнику,
 нашему приемнику.

197
00:15:53,640 --> 00:16:11,540
 Хорошо, вот почему, потому что
 он не присоединился к группе.

198
00:16:11,540 --> 00:16:14,500
 Хорошо, теперь оно у нас должно быть.

199
00:16:14,500 --> 00:16:23,440
 Итак, вот наша звезда, запись.

200
00:16:23,440 --> 00:16:27,680
 А еще, что касается этих таймеров,
 вот этот таймер такой:

201
00:16:27,680 --> 00:16:28,900
 время жизни этого.

202
00:16:28,900 --> 00:16:30,620
 Это будет продолжать обратный отсчет.

203
00:16:30,620 --> 00:16:35,240
 И если это когда-нибудь достигнет
 нуля, это значит, что я удалю это.

204
00:16:35,240 --> 00:16:38,580
 интерфейс из списка исходящих
 интерфейсов.

205
00:16:38,580 --> 00:16:43,640
 Но мы знаем, что пока этот приемник
 все еще активен, пока

206
00:16:43,640 --> 00:16:48,120
 запросы по-прежнему отправляются, а отчеты
 возвращаются, маршрутизатор 2 каждый раз

207
00:16:48,120 --> 00:16:54,420
 60 секунд, мы отправим еще одну звезду, присоединяйтесь
 сюда, чтобы обновить это состояние.

208
00:16:54,420 --> 00:16:59,720
 И роутер 8 тоже сядет, когда получит,
 пришлем ему свою звезду,

209
00:16:59,720 --> 00:17:02,780
 присоединиться, чтобы обновить
 это состояние.

210
00:17:02,780 --> 00:17:12,280
 Так, например, сейчас у нас осталось 233.

211
00:17:12,280 --> 00:17:14,080
 И он вернулся.

212
00:17:14,080 --> 00:17:19,580
 Видите, мы начали с трёх
 минут и 23 секунд.

213
00:17:19,580 --> 00:17:24,520
 И мы спустились примерно на минуту.

214
00:17:24,520 --> 00:17:27,980
 И тогда мы этого не видели, но на
 заднем плане он получил звезду,

215
00:17:27,980 --> 00:17:31,500
 сколько он присоединился к обновлению,
 и дело дошло до этого.

216
00:17:31,500 --> 00:17:38,740
 Вот этот таймер, показывает, как долго
 этот интерфейс находится в работе.

217
00:17:38,740 --> 00:17:40,220
 список исходящих интерфейсов.

218
00:17:40,220 --> 00:17:44,100
 Итак, прошла минута и четыре секунды с
 тех пор, как мы впервые получили наше

219
00:17:44,100 --> 00:17:51,160
 первая звезда, присоединение к которой привело к
 первоначальному созданию этой записи m-маршрута.

220
00:17:51,160 --> 00:17:53,940
 Так что на этот раз мы просто
 продолжим увеличивать.