1
00:00:08,400 --> 00:00:11,420
 Итак, к этому моменту процесса,
 если вы смотрели эти видео

2
00:00:11,420 --> 00:00:15,800
 с самого начала и до сих пор мы охватили
 практически подавляющее большинство

3
00:00:15,800 --> 00:00:21,340
 деталей процесса PIM и того, как
 он работает в 90% случаев.

4
00:00:21,340 --> 00:00:24,640
 Но есть еще пара деталей, которые,
 возможно, от вас ускользнули.

5
00:00:24,640 --> 00:00:27,020
 это важно знать, и именно
 об этом мы и поговорим

6
00:00:27,020 --> 00:00:30,820
 теперь существует концепция назначенных маршрутизаторов
 и назначенных серверов пересылки.

7
00:00:30,820 --> 00:00:35,040
 На самом деле нет необходимости знать, работают
 ли PIM идеально, но в этом случае

8
00:00:35,040 --> 00:00:37,900
 если что-то работает не так, как вы ожидаете,
 вам, возможно, придется устранить неполадки

9
00:00:37,900 --> 00:00:42,960
 вещи, вам обязательно нужно знать, что
 это за роутеры, какого назначения

10
00:00:42,960 --> 00:00:48,260
 они служат, и почему они были избраны
 на именно эти должности.

11
00:00:48,260 --> 00:00:50,300
 Так вот в чем дело.

12
00:00:50,300 --> 00:00:53,820
 У меня есть к вам пара вопросов.

13
00:00:53,820 --> 00:00:57,240
 Так что, если вы смотрите это как запись,
 просто подумайте об этом, размойте это.

14
00:00:57,240 --> 00:01:00,200
 ответьте устно, не бойтесь, что
 рядом будут люди в кубиках

15
00:01:00,200 --> 00:01:03,580
 вам может показаться, что вы сумасшедший, но посмотрите,
 сможете ли вы ответить на эти вопросы

16
00:01:03,580 --> 00:01:06,740
 вопросы. По сути, это вопросы
 «да» или «нет».

17
00:01:06,740 --> 00:01:10,180
 Итак, глядя на эту диаграмму, мы видим,
 что наш источник находится в верхнем

18
00:01:10,180 --> 00:01:15,280
 левый угол, и у нас есть два приемника,
 приемник X и приемник Y.

19
00:01:15,280 --> 00:01:20,780
 Итак, мой первый вопрос: давайте предположим, что
 получатель Y первым присоединяется к потоку.

20
00:01:20,780 --> 00:01:23,760
 отправив отчет о членстве в IGMP.

21
00:01:23,760 --> 00:01:28,040
 Ну, потому что третий и четвертый маршрутизаторы
 подключены к одной и той же локальной сети.

22
00:01:28,040 --> 00:01:30,800
 сегмент, вот мой вопрос.

23
00:01:30,800 --> 00:01:33,420
 Будет ли это иметь логический смысл?

24
00:01:33,420 --> 00:01:37,540
 Была ли какая-то цель у обоих этих маршрутизаторов,
 маршрутизаторов номер три и

25
00:01:37,540 --> 00:01:41,720
 четыре, когда они оба получают отчет
 о членстве, оба отправляют

26
00:01:41,720 --> 00:01:45,980
 звезда, IG присоединяется
 к месту встречи?

27
00:01:45,980 --> 00:01:51,780
 Что ж, надеюсь, ответили: нет,
 за этим не было никакой цели.

28
00:01:51,780 --> 00:01:55,880
 На самом деле, это было бы плохо,
 потому что, если бы оба эти

29
00:01:55,880 --> 00:02:01,740
 маршрутизаторы делали это, они отправляли
 объединения туда и сюда, ну

30
00:02:01,740 --> 00:02:06,720
 Угадай, что? Теперь, когда многоадресный трафик
 действительно начинает происходить,

31
00:02:06,720 --> 00:02:11,420
 используйте другой цвет прямо здесь, и он
 начнет отключаться, ну, маршрутизатор

32
00:02:11,420 --> 00:02:14,660
 Five имеет два интерфейса и не
 входит в список интерфейсов.

33
00:02:14,660 --> 00:02:18,400
 Итак, он скопирует этот многоадресный трафик,
 и в итоге у нас будет две копии.

34
00:02:18,400 --> 00:02:22,600
 того же пакета в LAN C.

35
00:02:22,600 --> 00:02:23,580
 Мы этого не хотим.

36
00:02:23,580 --> 00:02:27,280
 Нам не нужны дубликаты копий, потому что кто
 знает, как маршрутизатор, как получатель

37
00:02:27,280 --> 00:02:28,720
 Y собирается на это ответить.

38
00:02:28,720 --> 00:02:32,960
 Видео может быть очень прерывистым,
 может иметь зеркальный эффект.

39
00:02:32,960 --> 00:02:34,100
 Мы этого не хотим.

40
00:02:34,100 --> 00:02:37,780
 Так нет, хоть два часа в одном
 локалке мы увидим членство

41
00:02:37,780 --> 00:02:42,840
 отчет, мы не хотим, чтобы они оба отправляли
 соединение вверх по течению к месту встречи

42
00:02:42,840 --> 00:02:47,360
 точка. Следующий вопрос.

43
00:02:47,360 --> 00:02:54,620
 Источник запускается, отправляет
 свой первый пакет в LAN A.

44
00:02:54,620 --> 00:02:58,740
 Оба маршрутизатора — первый
 и второй — видят этот пакет.

45
00:02:58,740 --> 00:03:03,740
 Аналогичный вопрос возникает раньше: имеет ли
 это смысл как для маршрутизаторов, так и для

46
00:03:03,740 --> 00:03:09,780
 два, чтобы зарегистрировать один и тот же пакет
 и отправить эти два регистра на место встречи

47
00:03:09,780 --> 00:03:16,560
 точка? Еще раз, надеюсь, вы сказали
 «нет», это не имеет особого смысла.

48
00:03:16,560 --> 00:03:20,840
 потому что нам не нужны они
 оба, чтобы сделать это.

49
00:03:20,840 --> 00:03:23,480
 Номер один собирается добавить дополнительную
 работу к месту встречи.

50
00:03:23,480 --> 00:03:28,220
 Теперь вам в два раза труднее
 найти точку встречи и

51
00:03:28,220 --> 00:03:38,480
 деинкапсулировать, необходимо отправить
 только один пакет в LAN A.

52
00:03:38,480 --> 00:03:40,720
 Двоих отправлять не обязательно.

53
00:03:40,720 --> 00:03:44,320
 Итак, еще раз, как будто не было необходимости
 обоим маршрутизаторам отправлять звезду,

54
00:03:44,320 --> 00:03:49,600
 присоединяйтесь, нет причин, по которым оба маршрутизатора
 и маршрутизаторы 2 должны отправлять

55
00:03:49,600 --> 00:03:52,940
 зарегистрировать пакеты на
 шестом маршрутизаторе.

56
00:03:52,940 --> 00:03:57,400
 Только один из них должен это сделать.

57
00:03:57,400 --> 00:04:00,140
 И последний вопрос.

58
00:04:00,140 --> 00:04:02,880
 Допустим, идет многоадресная рассылка.

59
00:04:02,880 --> 00:04:07,500
 Итак, все идет вниз по общему дереву.

60
00:04:07,500 --> 00:04:11,240
 Теперь к этому потоку присоединился
 и получатель X.

61
00:04:11,240 --> 00:04:14,900
 Таким образом, он также проходит через
 второй маршрутизатор в LAN B.

62
00:04:14,900 --> 00:04:19,040
 И помните, маршрутизаторы третий и четвертый,
 они оба видели отчет о членстве.

63
00:04:19,040 --> 00:04:21,080
 от приемника Ю.

64
00:04:21,080 --> 00:04:24,640
 Итак, третий маршрутизатор поместил этот интерфейс
 в свой список исходящих интерфейсов.

65
00:04:24,640 --> 00:04:28,220
 Маршрутизатор номер четыре поместил этот интерфейс
 в свой список исходящих интерфейсов.

66
00:04:28,220 --> 00:04:32,440
 Итак, четвертый маршрутизатор, когда он получает
 пакеты, пересылает их в локальную сеть.

67
00:04:32,440 --> 00:04:38,780
 C. Когда третий маршрутизатор увидит, что эти
 пакеты поступают в LAN B, он перешлет их

68
00:04:38,780 --> 00:04:42,340
 тот же пакет также передается в LAN C.

69
00:04:42,340 --> 00:04:43,960
 Хотим ли мы этого?

70
00:04:43,960 --> 00:04:49,340
 Нет, мы этого не делаем. И снова мы получили
 повторяющиеся многоадресные пакеты.

71
00:04:49,340 --> 00:04:53,080
 LAN C. Это, вероятно, не
 обрадует получателя.

72
00:04:53,080 --> 00:04:58,700
 что. Итак, как нам уйти от этих проблем,
 связанных с несколькими маршрутизаторами?

73
00:04:58,700 --> 00:05:02,020
 отправка соединения для того же
 потока и той же локальной сети?

74
00:05:02,020 --> 00:05:06,620
 Несколько маршрутизаторов отправляют регистр одного
 и того же потока в одной локальной сети.

75
00:05:06,620 --> 00:05:10,280
 Несколько маршрутизаторов пересылают дубликаты
 пакетов в одну и ту же локальную сеть.

76
00:05:10,280 --> 00:05:12,900
 Этот сегмент именно об этом.

77
00:05:12,900 --> 00:05:13,840
 Как нам этого избежать?

78
00:05:13,840 --> 00:05:17,220
 Что ж, PIM, к счастью, люди, которые разработали
 PIM, были намного умнее, чем

79
00:05:17,220 --> 00:05:20,800
 мне. Они заранее обдумали эти
 проблемы и придумали некоторые

80
00:05:20,800 --> 00:05:26,580
 решения. Итак, как это работает?

81
00:05:26,580 --> 00:05:30,200
 Ну PIM назначил роутер.

82
00:05:30,200 --> 00:05:33,920
 Когда два маршрутизатора используют одну и ту же локальную
 сеть, один из них будет выбран в качестве

83
00:05:33,920 --> 00:05:35,820
 Маршрутизатор, назначенный PIM.

84
00:05:35,820 --> 00:05:39,220
 Это просто делается путем
 обмена приветствиями PIM.

85
00:05:39,220 --> 00:05:42,880
 Это похоже на связующее дерево, если
 вы знакомы с связующим деревом.

86
00:05:42,880 --> 00:05:47,720
 дерево. Существуют ли специальные сообщения
 о выборах для выбора корневого моста?

87
00:05:47,720 --> 00:05:52,140
 Без прав? В связующем дереве используется
 только один формат BPDU.

88
00:05:52,140 --> 00:05:54,860
 Этот один формат пакета
 используется для всего.

89
00:05:54,860 --> 00:05:59,040
 Таким образом, когда два коммутатора пересылают
 друг другу BPDU, они видят друг друга.

90
00:05:59,040 --> 00:06:03,220
 имена, и один парень говорит: ладно,
 я знаю, что ты корневой мост.

91
00:06:03,220 --> 00:06:05,560
 На самом деле он этого не говорит,
 он думает об этом в уме.

92
00:06:05,560 --> 00:06:07,540
 Ладно, я проиграл, он лучше меня.

93
00:06:07,540 --> 00:06:10,000
 Так что я буду думать о нем
 как о корневом мосте.

94
00:06:10,000 --> 00:06:12,800
 Другой парень скажет: «О,
 я видел его пакет».

95
00:06:12,800 --> 00:06:14,340
 Он не так хорош, как я.

96
00:06:14,340 --> 00:06:18,560
 Так что я буду просто корневым мостом
 и предполагаю, что он знает о корне

97
00:06:18,560 --> 00:06:20,800
 мост. То же самое и с PIM.

98
00:06:20,800 --> 00:06:23,160
 Эти маршрутизаторы обмениваются
 приветствиями.

99
00:06:23,160 --> 00:06:30,380
 Когда они видят приветствия друг друга в одной
 локальной сети, они смотрят на свои,

100
00:06:30,380 --> 00:06:32,360
 ну, на самом деле это две вещи.

101
00:06:32,360 --> 00:06:34,380
 Во-первых, это приоритет PIM.

102
00:06:34,380 --> 00:06:38,300
 Таким образом, существует приоритет интерфейса, точно
 так же, как OSPF имеет приоритет интерфейса.

103
00:06:38,300 --> 00:06:42,020
 В пакет приветствия включен
 приоритет PIM.

104
00:06:42,020 --> 00:06:46,400
 Таким образом, тот, у кого самый высокий
 приоритет интерфейса, автоматически

105
00:06:46,400 --> 00:06:48,920
 быть выбранным в качестве назначенного
 маршрутизатора.

106
00:06:48,920 --> 00:06:53,860
 Если их приоритеты одинаковы, а они так
 и будут по умолчанию, то кто бы ни был

107
00:06:53,860 --> 00:06:58,400
 имеет самый высокий IP-адрес, будет
 выбран назначенным маршрутизатором.

108
00:06:58,400 --> 00:07:03,780
 Хорошо? Итак, как только назначенный маршрутизатор
 будет выбран, если мы вернемся к нашему рисунку

109
00:07:03,780 --> 00:07:11,920
 вот, это решает пару проблем,
 которые мы рассматриваем.

110
00:07:11,920 --> 00:07:15,080
 Номера маршрутизаторов представляют
 их IP-адреса.

111
00:07:15,080 --> 00:07:19,020
 Таким образом, четвертый маршрутизатор в LANC имеет
 более высокий IP-адрес, чем третий маршрутизатор.

112
00:07:19,020 --> 00:07:24,840
 Итак, в данном конкретном случае у меня
 есть слайд, который анимирует все

113
00:07:24,840 --> 00:07:36,340
 этого. Итак, в данном конкретном случае
 давайте на секунду посмотрим на LAN A.

114
00:07:36,340 --> 00:07:40,740
 Когда пакет многоадресной рассылки, когда попадает
 самый первый пакет многоадресной рассылки

115
00:07:40,740 --> 00:07:45,200
 LAN A, за регистрацию будет отвечать
 только назначенный маршрутизатор.

116
00:07:45,200 --> 00:07:47,560
 этот пакет с RP.

117
00:07:47,560 --> 00:07:51,420
 Итак, в данном конкретном случае, какой маршрутизатор,
 по вашему мнению, сможет это сделать?

118
00:07:51,420 --> 00:07:55,120
 Кто будет назначенным маршрутизатором
 в локальной сети A?

119
00:07:55,120 --> 00:08:03,280
 Что ж, надеюсь, вы сказали «маршрутизатор
 один», потому что у него самый высокий

120
00:08:03,280 --> 00:08:07,560
 Айпи адрес. Итак, он будет назначенным маршрутизатором,
 он будет нести ответственность

121
00:08:07,560 --> 00:08:12,040
 для регистрации этих пакетов.

122
00:08:12,040 --> 00:08:20,520
 А в LANC, когда получатель Y отправляет
 отчет о своем членстве в IGMP, оба

123
00:08:20,520 --> 00:08:25,320
 Маршрутизаторы три и маршрутизаторы четыре увидят
 его, но маршрутизатор номер четыре назначен

124
00:08:25,320 --> 00:08:27,200
 маршрутизатор в силу его
 наивысшего IP-адреса.

125
00:08:27,200 --> 00:08:33,840
 Таким образом, именно он отправит звезду
 PIM, запятую G, вверх по течению к

126
00:08:33,840 --> 00:08:35,140
 место встречи.

127
00:08:35,140 --> 00:08:40,040
 Теперь это отвечает на два из трех
 вопросов, которые у нас были.

128
00:08:40,040 --> 00:08:41,860
 Итак, у нас было три вопроса.

129
00:08:41,860 --> 00:08:44,980
 Помните, номер один был в том, что два маршрутизатора
 видят отчет о членстве, который

130
00:08:44,980 --> 00:08:46,900
 кто-то отправляет соединение на RP?

131
00:08:46,900 --> 00:08:49,080
 Ну, это назначенный маршрутизатор.

132
00:08:49,080 --> 00:08:51,600
 Значит, что-то идет в РП.

133
00:08:51,600 --> 00:08:55,600
 Второй вопрос заключался в том, получат ли два маршрутизатора
 пакет многоадресной рассылки, кто отправит

134
00:08:55,600 --> 00:08:57,920
 реестр в РП?

135
00:08:57,920 --> 00:09:00,000
 Это назначенный маршрутизатор.

136
00:09:00,000 --> 00:09:05,000
 Итак, помните, назначенный маршрутизатор,
 возможно, вы можете думать о R в DR как о

137
00:09:05,000 --> 00:09:08,900
 это что-то ответственное за выход
 к месту встречи, кто-то

138
00:09:08,900 --> 00:09:11,840
 кто что-то отправляет к месту встречи.

139
00:09:11,840 --> 00:09:17,660
 Я сказал, что в этом сценарии
 у нас есть еще одна проблема:

140
00:09:17,660 --> 00:09:24,160
 у нас было несколько дубликатов пакетов, отправленных
 в одну и ту же локальную сеть из нескольких

141
00:09:24,160 --> 00:09:28,960
 маршрутизаторы. И я сказал, что
 это не работа ДР - выяснять это.

142
00:09:28,960 --> 00:09:33,860
 Это работа назначенного экспедитора.

143
00:09:33,860 --> 00:09:39,060
 Итак, если несколько пакетов, если у меня есть два
 или три маршрутизатора, которые все обслуживают

144
00:09:39,060 --> 00:09:44,960
 одна и та же локальная сеть, и двое или более
 из них используют один и тот же мульти

145
00:09:44,960 --> 00:09:50,740
 -направить пакеты в эту локальную сеть, тогда
 один из них будет выбран назначенным

146
00:09:50,740 --> 00:09:56,380
 экспедитор. На самом деле это
 немного более сложный процесс.

147
00:09:56,380 --> 00:10:00,300
 чем просто просматривать
 пакеты приветствия.

148
00:10:00,300 --> 00:10:06,480
 Чтобы это выяснить, на самом деле существует
 специальное PIM-сообщение под названием

149
00:10:06,480 --> 00:10:10,140
 ПИМ утверждает. Итак, это новое послание,
 о котором мы еще не говорили.

150
00:10:10,140 --> 00:10:14,860
 Итак, до сих пор мы говорили о черносливе,
 который состоит из одного пакета.

151
00:10:14,860 --> 00:10:18,240
 зависит от тела пакета, будь то соединение
 или сокращение, но это

152
00:10:18,240 --> 00:10:19,980
 тот же код типа в PIM.

153
00:10:19,980 --> 00:10:23,860
 У нас был еще один код типа —
 «привет», и был третий тип.

154
00:10:23,860 --> 00:10:26,160
 код, который был в реестре.

155
00:10:26,160 --> 00:10:29,860
 И у нас была остановка регистра,
 а теперь это другой вид.

156
00:10:29,860 --> 00:10:32,840
 Это сообщение подтверждения PIM.

157
00:10:32,840 --> 00:10:37,940
 А вот анимация, показывающая,
 как это будет работать.

158
00:10:37,940 --> 00:10:46,960
 Итак, в данном конкретном случае
 источник начинает идти, и пакеты

159
00:10:46,960 --> 00:10:51,080
 оба идут вниз по общему дереву, поэтому маршрутизатор
 4 помещает их в локальную сеть

160
00:10:51,080 --> 00:10:57,320
 C, а маршрутизатор 3 получает их через
 LAN B, поэтому он также помещает их

161
00:10:57,320 --> 00:11:02,440
 в локальную сеть C. Таким образом, маршрутизаторы 3 и
 4 будут видеть эти повторяющиеся пакеты, поступающие

162
00:11:02,440 --> 00:11:03,740
 друг от друга.

163
00:11:03,740 --> 00:11:08,120
 Они поймут, эй, это плохо, нам
 нужен назначенный экспедитор.

164
00:11:08,120 --> 00:11:14,220
 Таким образом, они оба будут отправлять
 друг другу сообщения подтверждения PIM.

165
00:11:14,220 --> 00:11:19,500
 И в этом конкретном случае парень с
 наименьшим IP-адресом на самом деле

166
00:11:19,500 --> 00:11:22,360
 быть избранным в качестве
 назначенного экспедитора.

167
00:11:22,360 --> 00:11:27,380
 Итак, как только оба маршрутизатора узнают, что маршрутизатор
 3 является назначенным сервером пересылки, он

168
00:11:27,380 --> 00:11:32,360
 теперь задача маршрутизатора 3 — продолжить пересылку
 этой многоадресной рассылки в локальную сеть.

169
00:11:32,360 --> 00:11:36,900
 Маршрутизатор 4 говорит: «ОК, я больше не
 нужен в этой локальной сети, потому что

170
00:11:36,900 --> 00:11:38,660
 пересылка пакетов не моя работа.

171
00:11:38,660 --> 00:11:44,560
 Поэтому в ответ он отправит сообщение
 об обрезке вверх по течению, которое

172
00:11:44,560 --> 00:11:47,720
 в конечном итоге приведет к отрезанию
 этого общего дерева.

173
00:11:47,720 --> 00:11:51,660
 И теперь многоадресная рассылка будет
 пересылаться в LAN C только через

174
00:11:51,660 --> 00:11:58,340
 назначенный сервер пересылки, которым
 является маршрутизатор 3.

175
00:11:58,340 --> 00:12:03,340
 На этом мы завершаем эту конкретную тему
 о назначенном PIM маршрутизаторе и

176
00:12:03,340 --> 00:12:04,480
 назначенный экспедитор.

177
00:12:04,480 --> 00:12:07,980
 Вы также можете увидеть это, когда
 зайдете в маршрутизатор.

178
00:12:07,980 --> 00:12:11,480
 Я не знаю, есть ли у нас здесь какие-либо
 сегменты, которые заслуживают специального

179
00:12:11,480 --> 00:12:14,220
 экспедитор, но давайте посмотрим.

180
00:12:14,220 --> 00:12:19,580
 Показать IP соседа PIM.

181
00:12:19,580 --> 00:12:25,620
 Ну, здесь DR показывает, является ли кто-то
 назначенным маршрутизатором или нет, так что

182
00:12:25,620 --> 00:12:28,960
 как вы для конкретного сегмента, кем
 является назначенный маршрутизатор.

183
00:12:28,960 --> 00:12:40,680
 И я думаю, что мы также можем
 показать интерфейс IP PIM.

184
00:12:40,680 --> 00:12:45,680
 Это просто еще раз показывает вам, кто
 является назначенным маршрутизатором.

185
00:12:45,680 --> 00:12:50,000
 Его приоритет по умолчанию равен единице, так
 что это уровень приоритета по умолчанию для

186
00:12:50,000 --> 00:12:52,620
 интерфейс, но вы можете это изменить.

187
00:12:52,620 --> 00:13:07,300
 Давайте посмотрим здесь. Здесь показаны конкретные
 группы, к которым мы присоединились.

188
00:13:07,300 --> 00:13:14,440
 на интерфейсе команда show IP Interface.

189
00:13:14,440 --> 00:13:19,840
 Я не знаю, какую команду
 мы будем использовать.

190
00:13:19,840 --> 00:13:25,120
 Или, может быть, подробно.

191
00:13:25,120 --> 00:13:34,040
 Вот и все. Это должно быть здесь.

192
00:13:34,040 --> 00:13:39,720
 Давайте посмотрим здесь. PIM включает
 версию, которой является DR.

193
00:13:39,720 --> 00:13:45,640
 Обновление состояния. Да, я думаю, причина, по которой
 мы этого не видим, заключается в том, что

194
00:13:45,640 --> 00:13:51,760
 это будет означать, что назначенный переадресатор будет
 выбран только тогда, когда оба маршрутизатора

195
00:13:51,760 --> 00:13:57,420
 увидеть один и тот же многоадресный пакет,
 исходящий из приходящих дубликатов пакетов.

196
00:13:57,420 --> 00:14:00,720
 Но если никогда не возникает ситуации,
 когда повторяются пакеты

197
00:14:00,720 --> 00:14:04,700
 локальной сети, нет необходимости
 выбирать назначенного экспедитора.

198
00:14:04,700 --> 00:14:08,200
 И в моей конкретной топологии, я не думаю,
 что у нас была такая ситуация.

199
00:14:08,200 --> 00:14:10,940
 где необходимо выбрать назначенного
 экспедитора.

200
00:14:10,940 --> 00:14:15,420
 Я ожидаю, что если он и существует, то
 он должен быть здесь, в IP-адресе шоу.

201
00:14:15,420 --> 00:14:17,580
 Подробный вывод интерфейса PIM.

202
00:14:17,580 --> 00:14:21,260
 Хорошо, Джош задает хороший вопрос.

203
00:14:21,260 --> 00:14:26,840
 Позвольте мне вернуться к концепции
 назначенного маршрутизатора.

204
00:14:26,840 --> 00:14:28,460
 У нас было вот это.

205
00:14:28,460 --> 00:14:30,820
 Упс. Прямо там.

206
00:14:30,820 --> 00:14:35,820
 Поэтому в данном конкретном случае он спрашивает,
 где четвертый маршрутизатор является назначенным

207
00:14:35,820 --> 00:14:38,140
 маршрутизатор и третий
 маршрутизатор - нет.

208
00:14:38,140 --> 00:14:41,680
 Он говорит, что если назначенный маршрутизатор выйдет
 из строя, то в случае сбоя четвертого маршрутизатора

209
00:14:41,680 --> 00:14:47,800
 и умирает или удаляется, как третий маршрутизатор создает
 или восстанавливает свою многоадресную рассылку

210
00:14:47,800 --> 00:14:49,980
 таблицу маршрутизации и сколько
 времени это занимает?

211
00:14:49,980 --> 00:14:57,300
 Хорошо, имейте в виду, что хотя четвертый маршрутизатор
 является назначенным маршрутизатором,

212
00:14:57,300 --> 00:15:03,620
 когда получатель Y отправил свой отчет о членстве
 в IGMP, оба маршрутизатора и третий

213
00:15:03,620 --> 00:15:05,580
 четвертый маршрутизатор это увидел.

214
00:15:05,580 --> 00:15:10,140
 Таким образом, хотя третий маршрутизатор
 понимает, что присоединяться к

215
00:15:10,140 --> 00:15:14,440
 общее дерево, он не собирается
 просто игнорировать этот отчет.

216
00:15:14,440 --> 00:15:21,500
 Он по-прежнему будет создавать звезду и состояние
 в своей таблице маршрутов M, как и маршрутизатор.

217
00:15:21,500 --> 00:15:26,360
 четыре делает. Просто когда он создаст
 это государство, он ничего не сделает

218
00:15:26,360 --> 00:15:42,320
 об этом. Теперь, если многоадресная рассылка в
 настоящее время передается таким образом, вниз

219
00:15:42,320 --> 00:15:50,240
 общее дерево, мы ожидаем, что когда
 самый первый многоадресный пакет

220
00:15:50,240 --> 00:15:55,780
 случается, четвертый маршрутизатор скажет, что
 я конечный маршрутизатор, так что моя работа -

221
00:15:55,780 --> 00:16:00,060
 переключиться на дерево кратчайшего пути
 всего лишь после получения одного пакета.

222
00:16:00,060 --> 00:16:05,600
 Итак, посмотрите на эту диаграмму, четвертый маршрутизатор,
 с моей точки зрения, хорошо бы сказал:

223
00:16:05,600 --> 00:16:10,760
 самый короткий путь на самом деле проходит
 через третий маршрутизатор.

224
00:16:10,760 --> 00:16:17,980
 Это мое дерево кратчайшего пути,
 идущее туда, туда и сюда.

225
00:16:17,980 --> 00:16:23,720
 Таким образом, четвертый маршрутизатор фактически
 создаст соединение S, G, а третий маршрутизатор

226
00:16:23,720 --> 00:16:29,860
 получить это, так что на самом
 деле здесь как-то странно.

227
00:16:29,860 --> 00:16:34,080
 Когда этот самый первый многоадресный
 пакет попадет сюда, я не уверен.

228
00:16:34,080 --> 00:16:35,200
 время вещей.

229
00:16:35,200 --> 00:16:38,300
 Мы знаем, что третий маршрутизатор
 собирается создать состояние S, G.

230
00:16:38,300 --> 00:16:40,760
 Я просто не знаю, что произойдет первым.

231
00:16:40,760 --> 00:16:44,700
 Увидит ли он этот самый первый многоадресный
 пакет и это создаст S, G

232
00:16:44,700 --> 00:16:50,880
 состояние? Или он увидит, что сначала
 соединяются PIM S, G, и это создаст S,

233
00:16:50,880 --> 00:17:05,120
 Состояние G? Затем он перенаправит свое собственное
 соединение S, G вверх по течению, поэтому после

234
00:17:05,120 --> 00:17:10,240
 мы ожидаем, что всего один пакет
 придет менее чем за секунду

235
00:17:10,240 --> 00:17:16,540
 многоадресный поток теперь будет идти
 сюда через третий маршрутизатор.

236
00:17:16,540 --> 00:17:21,260
 А затем, как только четвертый маршрутизатор увидит
 этот многоадресный пакет, он обрежет его.

237
00:17:21,260 --> 00:17:27,640
 выключенный. Таким образом, даже если четвертый маршрутизатор
 умрет, он действительно нужен нам только для одного

238
00:17:27,640 --> 00:17:32,100
 пакет, просто чтобы передать один пакет по проводу,
 а затем третий маршрутизатор сделал это

239
00:17:32,100 --> 00:17:35,480
 вся оставшаяся работа по открытию
 дерева кратчайших путей, и теперь

240
00:17:35,480 --> 00:17:39,220
 пакеты пересылались на землю C, и четвертый
 маршрутизатор не был нужен

241
00:17:39,220 --> 00:17:44,620
 больше. Знаете, здесь мы можем вникать
 во всякие острые случаи.

242
00:17:44,620 --> 00:17:50,460
 типа, окей, а что, если появится отчет
 о членстве, оба маршрутизатора

243
00:17:50,460 --> 00:17:58,740
 три и четвертый маршрутизатор получают это, но прежде
 чем четвертый маршрутизатор сможет создать

244
00:17:58,740 --> 00:18:02,220
 присоединение, он умирает.

245
00:18:02,220 --> 00:18:05,080
 Прямо сейчас это очень серьезно,
 потому что мы говорим о

246
00:18:05,080 --> 00:18:08,180
 здесь прошло меньше секунды с момента
 получения отчета о членстве

247
00:18:08,180 --> 00:18:12,120
 прежде чем у него появится возможность
 отправить соединение.