1
00:00:08,600 --> 00:00:14,560
 Мы всегда видели, что когда вы показываете
 маршрут IPM, это вполне возможно.

2
00:00:14,560 --> 00:00:19,900
 что у тебя может быть просто запись
 звездного комика, верно?

3
00:00:19,900 --> 00:00:23,620
 Итак, если нет многоадресной рассылки,
 но вы получили звездное сообщение

4
00:00:23,620 --> 00:00:26,640
 присоединяйтесь, у вас
 будет звездный статус.

5
00:00:26,640 --> 00:00:28,180
 И это значит, что я готов.

6
00:00:28,180 --> 00:00:30,820
 Я жду возможности переслать
 этот многоадресный трафик.

7
00:00:30,820 --> 00:00:33,960
 Кто-то попросил меня об этом.

8
00:00:33,960 --> 00:00:38,600
 Запись s-comagee не может
 существовать отдельно.

9
00:00:38,600 --> 00:00:40,240
 Не может стоять в одиночестве.

10
00:00:40,240 --> 00:00:45,120
 Другими словами, когда маршрутизатор
 2 создает эту запись s-comagee, он

11
00:00:45,120 --> 00:00:50,820
 также должен создать запись
 о звездном комике.

12
00:00:50,820 --> 00:00:53,440
 Эти двое должны идти вместе.

13
00:00:53,440 --> 00:00:58,060
 Так что, хотя он так и не получил
 отчета о членстве в IGMP, хотя он

14
00:00:58,060 --> 00:01:03,540
 никогда не получал звездного комика PIM с этим
 набором символов подстановки, как только он

15
00:01:03,540 --> 00:01:08,120
 создает запись s-comagee, ему необходимо
 создать запись star-comagee как

16
00:01:08,120 --> 00:01:10,920
 хорошо. Они оба должны быть там.

17
00:01:10,920 --> 00:01:17,120
 Итак, комик, я иногда использую
 аналогию со звездным комиком.

18
00:01:17,120 --> 00:01:20,860
 как старший брат и комаги, как маленький

19
00:01:20,860 --> 00:01:24,660
 брат, да? Старший брат, которому
 15 лет, он может выйти из

20
00:01:24,660 --> 00:01:28,600
 дом, гулять по окрестностям и кататься
 на велосипеде в одиночку.

21
00:01:28,600 --> 00:01:34,540
 Младшему брату, который является комиком,
 которому всего 7 лет, ему не разрешено

22
00:01:34,540 --> 00:01:37,360
 сделать это, если с ним
 не пойдет старший брат.

23
00:01:37,360 --> 00:01:41,360
 Так что не знаю, помогут
 они вам или нет, но вот.

24
00:01:41,360 --> 00:01:49,140
 Кроме того, как только трафик начнет
 течь по кратчайшему пути, это

25
00:01:49,140 --> 00:01:53,040
 s-comagee, которая используется
 для пересылки этого трафика.

26
00:01:53,040 --> 00:01:56,440
 Я имею в виду, что вы увидите звездного комика,
 у которого есть общительный характер.

27
00:01:56,440 --> 00:02:00,300
 список интерфейсов, и вы увидите s-comagee,
 у которого есть исходящий интерфейс

28
00:02:00,300 --> 00:02:05,660
 список. Что бы ни было в списке исходящих
 интерфейсов s-comagee, это

29
00:02:05,660 --> 00:02:06,940
 важный.

30
00:02:06,940 --> 00:02:09,520
 Это то, что фактически используется для
 пересылки многоадресной рассылки.

31
00:02:09,520 --> 00:02:14,360
 Когда он идет по кратчайшему пути,
 если он идет по общему пути

32
00:02:14,360 --> 00:02:19,220
 путь, то запись star-comagee
 определяет пересылку

33
00:02:19,220 --> 00:02:36,580
 трафик. Здесь я хочу упомянуть
 еще несколько вещей.

34
00:02:36,580 --> 00:02:45,620
 В этой конкретной топологии у
 меня нет большой избыточности.

35
00:02:45,620 --> 00:02:56,900
 А что, если бы у меня
 было что-то подобное?

36
00:02:56,900 --> 00:03:00,680
 Давайте избавимся от этой
 линии прямо здесь.

37
00:03:00,680 --> 00:03:16,360
 Допустим, у нас есть коммутатор и два
 соседа, два соседа выше по течению.

38
00:03:16,360 --> 00:03:23,080
 Другими словами, на самом деле
 дело даже не в переключателе.

39
00:03:23,080 --> 00:03:27,320
 Давайте просто скажем так.

40
00:03:27,320 --> 00:03:40,900
 Первый маршрутизатор может использовать либо второй,
 либо четвертый маршрутизатор для доступа к источнику.

41
00:03:40,900 --> 00:03:46,080
 Итак, на этой конкретной диаграмме,
 надеюсь, очень ясно, что прохождение

42
00:03:46,080 --> 00:03:50,280
 точка встречи — не кратчайший путь, поскольку
 у нас четыре маршрутизатора

43
00:03:50,280 --> 00:03:53,440
 пройти, чтобы добраться до источника, где мы
 можем пройти только через два маршрутизатора

44
00:03:53,440 --> 00:03:56,220
 если мы пройдем через второй
 или четвертый маршрутизатор.

45
00:03:56,220 --> 00:03:59,480
 Итак, вопрос теперь в том, хорошо, когда маршрутизатору
 нужно открыть свой самый короткий путь.

46
00:03:59,480 --> 00:04:03,620
 путь, он скажет: хм, у меня
 есть лишние кратчайшие пути.

47
00:04:03,620 --> 00:04:07,600
 Я мог бы пройти через соседа
 два или соседа четыре.

48
00:04:07,600 --> 00:04:10,900
 Итак, вопрос в том, куда
 он собирается пойти?

49
00:04:10,900 --> 00:04:14,260
 Куда он собирается отправить
 свой s, g join?

50
00:04:14,260 --> 00:04:18,620
 Согласно спецификации,
 это то, что вы увидите.

51
00:04:18,620 --> 00:04:21,980
 Это сосед, у которого самый
 высокий IP-адрес.

52
00:04:21,980 --> 00:04:24,040
 В основном к этому и сводится.

53
00:04:24,040 --> 00:04:29,080
 Итак, если бы это было две точки, две точки, две
 точки, два, а это было две точки, две точки.

54
00:04:29,080 --> 00:04:36,360
 четыре, тогда в этом конкретном случае соединение
 s, g прошло бы через маршрутизатор

55
00:04:36,360 --> 00:04:42,360
 четыре. Сосед с самым высоким IP-адресом,
 если у вас есть резервный

56
00:04:42,360 --> 00:04:47,460
 пути. То же самое относится
 и к общему дереву, верно?

57
00:04:47,460 --> 00:04:51,000
 Если бы я был маршрутизатором и у меня было несколько
 способов добраться до точки встречи

58
00:04:51,000 --> 00:04:56,440
 и все они имели одинаковое расстояние
 EIGRP или одинаковую стоимость OSPF, я

59
00:04:56,440 --> 00:04:59,500
 выберет того соседа PIM, который
 имеет самый высокий IP-адрес.

60
00:04:59,500 --> 00:05:22,560
 Именно туда я отправлял своих участников,
 чтобы добраться до места встречи.

61
00:05:22,560 --> 00:05:26,440
 Итак, мы знаем, что s, g остаются созданными,
 но их также необходимо поддерживать.

62
00:05:26,440 --> 00:05:30,680
 Так что это ничем не отличается.

63
00:05:30,680 --> 00:05:35,180
 Точно так же, как мы говорили о том, что в
 общем дереве после его построения каждый

64
00:05:35,180 --> 00:05:38,800
 минуту, если я маршрутизатор, к которому
 подключен напрямую приемник, каждую

65
00:05:38,800 --> 00:05:43,980
 минутку, я пришлю еще одну звезду, присоединяюсь
 к восходящему течению, и они пойдут до конца

66
00:05:43,980 --> 00:05:47,740
 способ поддерживать это состояние
 в процессе обновления.

67
00:05:47,740 --> 00:05:51,020
 То же самое справедливо
 и для кратчайшего пути.

68
00:05:51,020 --> 00:05:55,740
 Каждую минуту, каждые 60 секунд маршрутизаторы,
 которым это нужно, показывают нам путь.

69
00:05:55,740 --> 00:06:06,060
 send s, g присоединяется к восходящему потоку,
 чтобы поддерживать его обновление.

70
00:06:06,060 --> 00:06:09,200
 Так когда же это состояние
 s, g будет удалено?

71
00:06:09,200 --> 00:06:14,140
 Что ж, если эти периодические соединения со стороны
 нижестоящего соседа прекратятся, давайте

72
00:06:14,140 --> 00:06:20,120
 скажи, что источник мультикаста
 был позади меня и я роутер, ты

73
00:06:20,120 --> 00:06:23,240
 маршрутизатор, и я твой кратчайший путь,
 чтобы добраться до этого парня.

74
00:06:23,240 --> 00:06:26,920
 Итак, прямо сейчас мой список исходящих
 интерфейсов указывает на вас.

75
00:06:26,920 --> 00:06:31,260
 Вы отправили мне сообщение «s, g
 join», указывая на свой интерес.

76
00:06:31,260 --> 00:06:33,620
 Я поместил вас в список
 исходящих интерфейсов.

77
00:06:33,620 --> 00:06:38,140
 Так что вы обязаны каждую минуту отправлять мне
 сообщения, g присоединяется, чтобы обновить

78
00:06:38,140 --> 00:06:46,580
 этот. Но что, если между нами и вашим компьютером
 есть коммутатор или концентратор?

79
00:06:46,580 --> 00:06:49,900
 соединение с этим коммутатором
 или хабом пропадает?

80
00:06:49,900 --> 00:06:52,000
 Я этого не знаю.

81
00:06:52,000 --> 00:06:57,720
 Насколько я понимаю, ты все еще жив.

82
00:06:57,720 --> 00:07:02,300
 Итак, в этом конкретном случае, если периодические
 соединения снова прекратятся,

83
00:07:02,300 --> 00:07:07,340
 этот таймер 210 секунд, это магическое
 число, если через 210 секунд,

84
00:07:07,340 --> 00:07:11,980
 Я больше не получаю от вас эти
 заявки, тогда я удалю их.

85
00:07:11,980 --> 00:07:13,140
 список исходящих интерфейсов.

86
00:07:13,140 --> 00:07:17,260
 Опять же, в этой конкретной ситуации,
 скорее всего, что бы

87
00:07:17,260 --> 00:07:21,160
 случается, я бы сказал: ну, подождите секундочку,
 я потерял своего соседа по PIM, верно?

88
00:07:21,160 --> 00:07:25,920
 Потому что в случае с PIM вы также отправляете
 мне привет от PIM каждые 30 минут.

89
00:07:25,920 --> 00:07:31,240
 секунды. И если я пропущу три из
 них, я объявлю соседа мертвым.

90
00:07:31,240 --> 00:07:36,680
 Таким образом, можно было бы предположить, что
 если связь между вами и коммутатором прервется,

91
00:07:36,680 --> 00:07:43,600
 вниз, PIM обнаружит потерянного соседа,
 мы видели 105 секунд, что

92
00:07:43,600 --> 00:07:50,120
 был этот таймер до истечения срока
 действия 210-секундного таймера.

93
00:07:50,120 --> 00:07:55,400
 Я не собираюсь это проверять
 прямо сейчас.

94
00:07:55,400 --> 00:07:58,360
 Но я просто хочу узнать, согласно
 спецификации, если

95
00:07:58,360 --> 00:08:03,880
 периодические соединения прекращаются через
 210 секунд, это один из критериев удаления

96
00:08:03,880 --> 00:08:08,960
 этот интерфейс из списка
 исходящих интерфейсов.

97
00:08:08,960 --> 00:08:15,540
 Если источник многоадресной рассылки снова
 прекратит передачу через 210 секунд,

98
00:08:15,540 --> 00:08:16,640
 Я подожду, да?

99
00:08:16,640 --> 00:08:20,000
 Если источник многоадресной рассылки
 перестанет бить меня по затылку, 210

100
00:08:20,000 --> 00:08:23,000
 секунд спустя я удалю свои
 исходящие интерфейсы.

101
00:08:23,000 --> 00:08:26,780
 И это происходит с каждым маршрутизатором
 на этом пути.

102
00:08:26,780 --> 00:08:32,240
 Итак, в этой конкретной топологии, если
 источник остановится, 210 секунд.

103
00:08:32,240 --> 00:08:41,820
 позже четвертый маршрутизатор удалит свой интерфейс,
 а маршрутизатор номер один удалит

104
00:08:41,820 --> 00:08:44,660
 его интерфейс из списка
 исходящих интерфейсов.

105
00:08:44,660 --> 00:08:50,300
 Или если вы получили сообщение
 об удалении PIM.

106
00:08:50,300 --> 00:08:54,980
 Таким образом, сообщение об обрезке — это способ
 сказать: «Эй, я больше этого не хочу».

107
00:08:54,980 --> 00:08:59,980
 Как и в этом конкретном случае, после
 успешного открытия маршрутизатора

108
00:08:59,980 --> 00:09:06,260
 Поднявшись по дереву кратчайшего пути, он отправит
 сообщение об обрезке до места встречи.

109
00:09:06,260 --> 00:09:12,000
 точка, говоря: мне больше
 не нужна эта ветка дерева.

110
00:09:12,000 --> 00:09:13,340
 Итак, мы действительно можем это увидеть.

111
00:09:13,340 --> 00:09:16,800
 Я не думаю, что мы еще сосредоточились
 на сообщении об обрезке.

112
00:09:16,800 --> 00:09:19,920
 Но давайте вернемся к нашей
 исходной топологии.

113
00:09:19,920 --> 00:09:26,920
 Теперь я думаю, что маршрутизатор номер пять на данный
 момент, вероятно, закончил отправку своих пингов.

114
00:09:26,920 --> 00:09:32,900
 Ага. Хорошо. И если прошло 210 секунд,
 что, вероятно, так и есть, нам следует

115
00:09:32,900 --> 00:09:37,840
 больше не вижу состояния s, g
 ни на каких маршрутизаторах.

116
00:09:37,840 --> 00:09:41,040
 Да, это ушло.

117
00:09:41,040 --> 00:09:46,400
 Срок действия истек. Итак, я собираюсь
 пойти дальше и снова запустить пинг.

118
00:09:46,400 --> 00:09:55,500
 И что мы сейчас конкретно будем искать,
 так это однажды маршрутизатор

119
00:09:55,500 --> 00:10:04,220
 два открывает этот путь, мы должны увидеть, как он
 отправляет PIM-сброс на восьмой маршрутизатор.

120
00:10:04,220 --> 00:10:06,880
 Итак, давайте продолжим и сфотографируем этот чернослив,
 просто чтобы посмотреть, как он выглядит.

121
00:10:06,880 --> 00:10:15,780
 нравиться. Итак, на восьмом маршрутизаторе я хочу, чтобы
 нулевая косая черта была его входящим интерфейсом.

122
00:10:15,780 --> 00:10:48,100
 И согласно этому, это будет ноль
 косой черты два на переключателе.

123
00:10:48,100 --> 00:10:51,540
 Хорошо. Итак, давайте готовиться.

124
00:10:51,540 --> 00:10:54,720
 Я перейду к пятому маршрутизатору.

125
00:10:54,720 --> 00:11:13,400
 И давайте запустим трассировку снайпера.

126
00:11:13,400 --> 00:11:16,800
 Хорошо. Наверное, это чернослив.

127
00:11:16,800 --> 00:11:22,320
 Давай выясним. Ага.

128
00:11:22,320 --> 00:11:25,660
 Количество чернослива одно.

129
00:11:25,660 --> 00:11:29,660
 Итак, еще раз, бит RP установлен, что означает,
 что происходит повышение общего уровня.

130
00:11:29,660 --> 00:11:32,040
 дерево до места встречи.

131
00:11:32,040 --> 00:11:38,280
 И мы говорим, что я отсекаю
 этот источник и эту группу.

132
00:11:38,280 --> 00:11:43,220
 Таким образом, это тот же формат сообщения, что и при
 соединении PIM, за исключением того, что вместо

133
00:11:43,220 --> 00:12:00,360
 присоединившись, мы сократили.

134
00:12:00,360 --> 00:12:04,760
 Итак, мы уже говорили о том, что чернослив
 PIM использует тот же формат, что и PIM.

135
00:12:04,760 --> 00:12:10,960
 объединения, используемые для того, чтобы побудить соседей
 выше по течению прекратить пересылку многоадресной рассылки

136
00:12:10,960 --> 00:12:17,440
 трафик к нам. Теперь, почему здесь сказано
 «поощрять», почему не заставлять

137
00:12:17,440 --> 00:12:20,560
 сосед по восходящему каналу прекратить
 пересылку нам многоадресного трафика?

138
00:12:20,560 --> 00:12:25,380
 Ну, вот почему.

139
00:12:25,380 --> 00:12:30,420
 Если бы у меня была такая ситуация,
 скажем, давайте просто сделаем

140
00:12:30,420 --> 00:12:48,400
 это просто, хаб. Хорошо.

141
00:12:48,400 --> 00:12:50,640
 Допустим, это мой РП.

142
00:12:50,640 --> 00:12:55,080
 У нас есть маршрутизатор номер один, маршрутизатор
 номер два и маршрутизатор номер три.

143
00:12:55,080 --> 00:13:02,840
 Подключусь к тому же хабу.

144
00:13:02,840 --> 00:13:15,540
 Хорошо. Допустим, сейчас оба этих ПК,
 PCA и PCB, являются многоадресными.

145
00:13:15,540 --> 00:13:18,900
 ресиверы. И они оба получают
 одну и ту же группу.

146
00:13:18,900 --> 00:13:23,300
 Знаете, они сейчас смотрят видеопрезентацию
 генерального директора.

147
00:13:23,300 --> 00:13:25,760
 Значит мультикаст стекает.

148
00:13:25,760 --> 00:13:32,200
 А в третьем маршрутизаторе у нас
 есть и звезда, и состояние.

149
00:13:32,200 --> 00:13:50,040
 И быстрый Ethernet ноль, ноль в
 списке исходящих интерфейсов.

150
00:13:50,040 --> 00:14:00,520
 Хорошо. Если вдруг получатель A отправит
 сообщение об выходе IGMP, потому что

151
00:14:00,520 --> 00:14:04,540
 его больше не интересует этот поток,
 это вызовет маршрутизатор

152
00:14:04,540 --> 00:14:10,720
 один. Он скажет: окей, я
 удалю этот интерфейс из

153
00:14:10,720 --> 00:14:12,400
 мой список исходящих интерфейсов.

154
00:14:12,400 --> 00:14:16,360
 Он скажет: «Ой, в моем исходящем интерфейсе
 больше нет интерфейсов».

155
00:14:16,360 --> 00:14:19,340
 список. Мой список исходящих
 интерфейсов равен нулю.

156
00:14:19,340 --> 00:14:22,380
 И это заставит его сказать: «Хорошо,
 мне это больше не нужно».

157
00:14:22,380 --> 00:14:27,180
 Итак, он собирается отправить сообщение PMPRUN,
 которое мы только что видели в сниффере.

158
00:14:27,180 --> 00:14:31,120
 след. Это пойдет в хаб.

159
00:14:31,120 --> 00:14:32,560
 Второй маршрутизатор это увидит.

160
00:14:32,560 --> 00:14:34,160
 Маршрутизатор три его увидит.

161
00:14:34,160 --> 00:14:38,980
 Теперь, если бы третий маршрутизатор немедленно
 удалил этот интерфейс, мы бы получили

162
00:14:38,980 --> 00:14:44,100
 проблема. Потому что PCB перестанет
 получать поток.

163
00:14:44,100 --> 00:14:45,260
 И ему все еще интересно.

164
00:14:45,260 --> 00:14:47,480
 Он спокойный и заинтересованный приемник.

165
00:14:47,480 --> 00:14:53,140
 Таким образом, принцип работы PEM заключается в том,
 что в данном конкретном случае, когда маршрутизатор

166
00:14:53,140 --> 00:14:57,800
 третий получает этот чернослив, он действительно
 подождет несколько секунд.

167
00:14:57,800 --> 00:15:00,980
 Я думаю, это около пяти секунд, хотя
 не цитируйте меня по этому поводу.

168
00:15:00,980 --> 00:15:01,560
 Но это несколько секунд.

169
00:15:01,560 --> 00:15:06,360
 Это не очень долго, потому что предполагается,
 что, эй, если второй маршрутизатор

170
00:15:06,360 --> 00:15:09,720
 тоже увидел этот чернослив,
 что он собирается делать?

171
00:15:09,720 --> 00:15:11,420
 Он скажет: подожди секунду.

172
00:15:11,420 --> 00:15:14,200
 У меня еще есть кое-кто,
 кому это интересно.

173
00:15:14,200 --> 00:15:19,060
 И это побудит его отправить еще
 одно присоединение к PEM.

174
00:15:19,060 --> 00:15:22,320
 В данном конкретном случае это, вероятно,
 будет объединение s-coma-g, потому что

175
00:15:22,320 --> 00:15:24,000
 он знает источник.

176
00:15:24,000 --> 00:15:27,200
 И это переопределит чернослив.

177
00:15:27,200 --> 00:15:32,180
 Таким образом, этот интерфейс останется
 в списке исходящих интерфейсов.

178
00:15:32,180 --> 00:15:35,520
 Вот почему мы говорим, что чернослив PEM поощряет
 соседа, расположенного выше по течению.

179
00:15:35,520 --> 00:15:39,860
 Потому что в данном конкретном случае роутер
 не скажет: «Ой, чувак, я посылаю чернослив»,

180
00:15:39,860 --> 00:15:41,700
 но я все еще получаю эту
 многоадресную рассылку.

181
00:15:41,700 --> 00:15:43,680
 Ну, он действительно ничего
 не может с этим поделать.

182
00:15:43,680 --> 00:15:47,800
 Каждую минуту он будет посылать чернослив
 и говорить: эй, пожалуйста, чернослив.

183
00:15:47,800 --> 00:15:52,160
 мне. И второй маршрутизатор отменит это, отправив
 заметку, продолжайте в том же духе,

184
00:15:52,160 --> 00:16:01,560
 Продолжай. Вот что их провоцирует.

185
00:16:01,560 --> 00:16:06,840
 Сокращение PEM срабатывает, когда
 вы получаете какой-то отпуск

186
00:16:06,840 --> 00:16:12,300
 сообщение от вашего получателя или если на нисходящем
 интерфейсе просто истекает время ожидания,

187
00:16:12,300 --> 00:16:16,640
 верно? Может быть, получатель уходит, так
 и не отправляя отпуск и, в конце концов,

188
00:16:16,640 --> 00:16:21,220
 вы, знаете, IgMP тайм-аут этого
 интерфейса, это вызовет обрезку

189
00:16:21,220 --> 00:16:27,280
 также. Или если вы получили чернослив
 от соседа ниже по течению.

190
00:16:27,280 --> 00:16:33,580
 Итак, в этом конкретном случае, когда маршрутизатор
 B или когда PCB наконец решает

191
00:16:33,580 --> 00:16:37,260
 что он закончил, он больше
 не хочет это смотреть.

192
00:16:37,260 --> 00:16:44,120
 Что ж, это заставит второй маршрутизатор
 отправить сообщение об обрезке.

193
00:16:44,120 --> 00:16:55,300
 Это удалит этот интерфейс из
 списка исходящих интерфейсов.

194
00:16:55,300 --> 00:16:58,520
 И теперь третий маршрутизатор понимает,
 что его список исходящих интерфейсов

195
00:16:58,520 --> 00:17:17,140
 null, это заставит его отправить свою собственную
 обрезку PEM вверх по течению.

196
00:17:17,140 --> 00:17:24,120
 На этом, по сути, завершается раздел,
 посвящённый вступлению в

197
00:17:24,120 --> 00:17:25,820
 Дерево кратчайших путей.

198
00:17:25,820 --> 00:17:28,580
 О, есть еще одна вещь, которую мы хотим
 проверить, прежде чем я закончу.

199
00:17:28,580 --> 00:17:32,400
 Позвольте мне вернуться.
 Мы хотим это проверить.

200
00:17:32,400 --> 00:17:39,080
 Мы хотим увидеть, когда многоадресная рассылка
 действительно начнет распространяться по общему

201
00:17:39,080 --> 00:17:45,860
 дерево, согласно RFC, самый первый человек,
 который переключится, должен

202
00:17:45,860 --> 00:17:47,140
 быть конечным маршрутизатором.

203
00:17:47,140 --> 00:17:50,480
 Что этот промежуточный маршрутизатор восьмого
 маршрутизатора здесь, потому что у него нет

204
00:17:50,480 --> 00:17:58,700
 подключенных приемников, не разрешено
 выполнять этот процесс переключения.

205
00:17:58,700 --> 00:18:01,200
 Итак, давайте посмотрим, действительно
 ли это правда.

206
00:18:01,200 --> 00:18:02,600
 Я уверен, что это возможно.

207
00:18:02,600 --> 00:18:04,260
 Но давайте посмотрим здесь.

208
00:18:04,260 --> 00:18:08,040
 Как мы собираемся это проверить?

209
00:18:08,040 --> 00:18:15,140
 Ну, вот что, я думаю, произойдет.

210
00:18:15,140 --> 00:18:21,080
 Если все пойдет так, как
 говорит RFC, то когда

211
00:18:21,080 --> 00:18:25,700
 второй маршрутизатор, конечный маршрутизатор получает
 первый многоадресный пакет, он должен

212
00:18:25,700 --> 00:18:27,500
 присоединиться к дереву кратчайшего пути.

213
00:18:27,500 --> 00:18:34,800
 Как только дерево кратчайшего пути откроется,
 ему следует обрезать восьмой маршрутизатор.

214
00:18:34,800 --> 00:18:39,340
 Маршрутизатор номер восемь должен затем отправить
 черновик или маршрутизатор номер три.

215
00:18:39,340 --> 00:18:46,900
 Таким образом, в каком-то смысле мы никогда не должны
 видеть соединение S, G, исходящее от маршрутизатора.

216
00:18:46,900 --> 00:18:51,860
 восемь. Мы должны видеть, что от него произошел
 чернослив, но мы не должны видеть

217
00:18:51,860 --> 00:18:57,540
 Присоединения S, G происходят
 с его IP-адреса.

218
00:18:57,540 --> 00:19:00,720
 Итак, вот как мы собираемся
 это проверить.

219
00:19:00,720 --> 00:19:06,560
 Давайте просто переключимся на каждый интерфейс,
 подключенный к маршрутизатору.

220
00:19:06,560 --> 00:19:12,880
 восемь, то есть ноль два
 и ноль тринадцать.

221
00:19:12,880 --> 00:19:18,780
 Мы зафиксируем весь входящий и исходящий трафик
 и посмотрим, будет ли он когда-нибудь

222
00:19:18,780 --> 00:19:24,760
 на самом деле отправляет соединение
 S, G, которого мы не должны видеть.

223
00:19:24,760 --> 00:19:29,200
 Хорошо, вот и сделано.

224
00:19:29,200 --> 00:19:35,300
 Выясним состояние MROUT,
 покажем IP, MROUT.

225
00:19:35,300 --> 00:19:38,680
 Итак, время ожидания состояния
 S, G уже истекло.

226
00:19:38,680 --> 00:19:42,780
 Перейдем к выключателю.

227
00:19:42,780 --> 00:19:46,140
 Итак, сейчас мы наблюдаем за ноль-два.

228
00:19:46,140 --> 00:20:07,200
 Мы хотим добавить к этому
 списку ноль тринадцать.

229
00:20:07,200 --> 00:20:14,020
 Хорошо, давайте вернемся
 к пятому маршрутизатору.

230
00:20:14,020 --> 00:20:34,360
 Запускаем трассировку снайпера.

231
00:20:34,360 --> 00:20:39,680
 Хорошо, на данный момент я не вижу, чтобы многоадресная
 рассылка проходила через маршрутизатор.

232
00:20:39,680 --> 00:20:45,460
 уже восемь, потому что сейчас
 я смотрю только на интерфейсы

233
00:20:45,460 --> 00:20:48,600
 подключен к восьмому маршрутизатору, и я
 не вижу никакой многоадресной рассылки

234
00:20:48,600 --> 00:20:52,280
 через там. Оно остановилось прямо здесь.

235
00:20:52,280 --> 00:20:55,280
 Итак, давайте посмотрим здесь
 восемь два восемь два.

236
00:20:55,280 --> 00:21:02,820
 Это маршрутизатор два восемь
 четыре восемь восемь.

237
00:21:02,820 --> 00:21:11,640
 Это роутер восемь восемь
 четыре восемь восемь.

238
00:21:11,640 --> 00:21:13,780
 Хорошо, так что же отправил
 сюда восьмой маршрутизатор?

239
00:21:13,780 --> 00:21:16,300
 Роутер восемь восемь
 четыре восемь восемь.

240
00:21:16,300 --> 00:21:18,500
 Он прислал чернослив.

241
00:21:18,500 --> 00:21:24,320
 Ладно, это он посылает чернослив
 на общее дерево, и он это сделал.

242
00:21:24,320 --> 00:21:27,240
 в ответ на полученный чернослив.

243
00:21:27,240 --> 00:21:31,100
 Так что это, скорее всего, тот
 чернослив, который он получил.

244
00:21:31,100 --> 00:21:35,200
 Итак, да, это чернослив со второго
 маршрутизатора, который подключен

245
00:21:35,200 --> 00:21:39,320
 нашему приемнику, который сказал: «Эй, смотри,
 сосед восемь два восемь восемь».

246
00:21:39,320 --> 00:21:40,980
 Ты мне больше не нужен.

247
00:21:40,980 --> 00:21:44,400
 Давай подрежем это общее дерево
 между тобой и мной.

248
00:21:44,400 --> 00:21:51,120
 И восьмой маршрутизатор перенаправил
 это соединение в точку встречи.

249
00:21:51,120 --> 00:22:01,720
 Итак, конечно же, мы не видим никаких сообщений
 о присоединении от восьмого маршрутизатора.

250
00:22:01,720 --> 00:22:07,480
 Вот он присоединяется к авто
 РП, так что это не в счет.

251
00:22:07,480 --> 00:22:14,360
 Таким образом, это подтверждает то, что говорит
 RFC, что только конечные маршрутизаторы

252
00:22:14,360 --> 00:22:18,320
 или маршрутизаторам последнего перехода разрешено
 присоединяться к дереву кратчайшего пути.