1
00:00:08,860 --> 00:00:12,380
 Итак, многоадресный Mac, помните, что
 мы говорим о пункте назначения.

2
00:00:12,380 --> 00:00:18,460
 Mac-адрес частично получен из фактического
 IP-адреса многоадресной рассылки.

3
00:00:18,460 --> 00:00:20,840
 который находится над
 ним на сетевом уровне.

4
00:00:20,840 --> 00:00:26,520
 Итак, это два зарезервированных OUI, которые вам
 следует искать для многоадресной рассылки.

5
00:00:26,520 --> 00:00:30,160
 Если вы когда-нибудь увидите кадр Ethernet, направляющийся
 в пункт назначения, начинающийся

6
00:00:30,160 --> 00:00:36,780
 выходит с 01005E, это должно заставить
 вас сказать: ага, эта рама несет

7
00:00:36,780 --> 00:00:40,520
 многоадресный пакет IP версии 4.

8
00:00:40,520 --> 00:00:46,280
 Итак, это OUI, зарезервированный
 для многоадресных данных IPv4.

9
00:00:46,280 --> 00:00:52,220
 И потом, если вы когда-нибудь увидите что-нибудь,
 идущее к номеру 33333, это зарезервировано для

10
00:00:52,220 --> 00:00:55,260
 Многоадресная рассылка IPv6.

11
00:00:55,260 --> 00:00:59,180
 Хорошо, давайте немного поговорим о том,
 как мы на самом деле получаем данные.

12
00:00:59,180 --> 00:01:00,880
 Прежде всего, начнем с IPv6.

13
00:01:00,880 --> 00:01:04,360
 IPv6 — это очень просто,
 а потом я вернусь к IPv4.

14
00:01:04,360 --> 00:01:09,640
 Допустим, у меня многоадресный IPv6-адрес,
 я просто что-нибудь придумаю.

15
00:01:09,640 --> 00:01:19,340
 здесь. Допустим, он шел на FF0E, значит,
 это глобальная многоадресная рассылка, и

16
00:01:19,340 --> 00:01:36,300
 скажем так 11111, а потом АААА, ББББ,
 ССС, посмотрим, 1, 2, 3, 4,

17
00:01:36,300 --> 00:01:39,060
 5, мне нужно еще три.

18
00:01:39,060 --> 00:01:47,780
 А затем 2222, 777, 1, 2, 3, 4, 5, 6, 7,
 затем мы просто сделаем последний октет,

19
00:01:47,780 --> 00:01:53,700
 вроде запуска DDD.

20
00:01:53,700 --> 00:02:00,760
 Хорошо, все, что нам нужно сделать, это когда источник
 многоадресной рассылки сгенерирует это

21
00:02:00,760 --> 00:02:06,380
 адрес в качестве адреса назначения на
 третьем уровне, после этого, когда он

22
00:02:06,380 --> 00:02:11,080
 создавая свой кадр Ethernet, все, что он собирается
 сделать, это взять последние 32

23
00:02:11,080 --> 00:02:19,100
 бит, в данном случае это 777 и DDDD,
 и он собирается это исправить.

24
00:02:19,100 --> 00:02:21,180
 вот, где эти иксы.

25
00:02:21,180 --> 00:02:26,380
 Таким образом, на втором уровне кадр Ethernet
 будет предназначен для 333, двоеточие 777.

26
00:02:26,380 --> 00:02:32,020
 двоеточие ДДДД. Так что
 это довольно легко.

27
00:02:32,020 --> 00:02:36,400
 Просто помните, что последние 32 бита
 многоадресного адреса IPv6 напрямую

28
00:02:36,400 --> 00:02:42,420
 отображается в последние 32 бита MAC-адреса
 назначения кадра Ethernet.

29
00:02:42,420 --> 00:02:47,400
 Сейчас, в мире IPv4, это своего рода
 кошмар, чтобы отобразить это.

30
00:02:47,400 --> 00:02:50,580
 Так что просто потерпите, если вы еще не
 выпили кофе, возможно, вам захочется

31
00:02:50,580 --> 00:02:54,660
 на этом этапе стоит побольше выпить, потому
 что это обычно заставляет людей

32
00:02:54,660 --> 00:02:55,620
 глаза тускнеют.

33
00:02:55,620 --> 00:02:58,960
 Но мы собираемся пойти дальше и пройти через
 это, потому что я думаю, что вам следует

34
00:02:58,960 --> 00:03:08,780
 знать это. Итак, прежде всего, мой MAC-адрес многоадресной
 рассылки, который мы знаем на уровне

35
00:03:08,780 --> 00:03:21,920
 два — 01005E. И теперь вы можете подумать:
 окей, ну это половина дела.

36
00:03:21,920 --> 00:03:25,200
 адрес, да? MAC-адрес имеет длину 48 бит.

37
00:03:25,200 --> 00:03:30,380
 Это половина. Итак, вы можете подумать:
 ладно, мне осталось отобразить 24 бита.

38
00:03:30,380 --> 00:03:32,720
 Ну, не совсем.

39
00:03:32,720 --> 00:03:37,640
 Если я преобразую это в двоичный
 код до конца, только часть,

40
00:03:37,640 --> 00:03:42,380
 следующий бит должен быть нулем.

41
00:03:42,380 --> 00:03:52,620
 И тогда у вас есть 12345678,
 двоеточие 12345678.

42
00:03:52,620 --> 00:03:54,380
 Я просто сделаю это.

43
00:03:54,380 --> 00:04:00,580
 Двоеточие 12345678. У меня заканчивается
 место, но вы поняли.

44
00:04:00,580 --> 00:04:05,580
 Итак, из оставшихся 24 бит у меня
 действительно есть только 23 бита.

45
00:04:05,580 --> 00:04:09,520
 Вот это надо обнулить.

46
00:04:09,520 --> 00:04:12,320
 И если вы когда-нибудь посмотрите
 на это и задаетесь вопросом, что?

47
00:04:12,320 --> 00:04:14,180
 Ну, это не имеет смысла.

48
00:04:14,180 --> 00:04:16,000
 Вот что я вам скажу, есть
 интересная история.

49
00:04:16,000 --> 00:04:18,640
 Я не буду вдаваться в историю, но
 это то, что вам следует погуглить.

50
00:04:18,640 --> 00:04:21,980
 чтобы узнать, почему они в конечном
 итоге сделали это именно так?

51
00:04:21,980 --> 00:04:24,800
 Гуглите это. Загуглите имя Стив.

52
00:04:24,800 --> 00:04:34,380
 Фамилия, Диринг.

53
00:04:34,380 --> 00:04:36,880
 Многоадресная рассылка
 Mac. Погуглите это.

54
00:04:36,880 --> 00:04:39,780
 Стив Диринг Multicast Mac.

55
00:04:39,780 --> 00:04:42,480
 И вы сможете найти интересную
 историю о Стиве Диринге.

56
00:04:42,480 --> 00:04:45,040
 один из пионеров многоадресной передачи.

57
00:04:45,040 --> 00:04:47,160
 Он проделал большую первоначальную
 работу над этим.

58
00:04:47,160 --> 00:04:49,880
 И вы найдете интересную историю
 о том, как он был аспирантом,

59
00:04:49,880 --> 00:04:54,720
 небольшой разговор с профессором,
 связанный с деньгами,

60
00:04:54,720 --> 00:04:59,100
 и в итоге получилась вот эта
 странная штука: всего 23 бита

61
00:04:59,100 --> 00:05:04,440
 доступный. Хорошо, а как нам сопоставить
 IP-адрес многоадресной рассылки?

62
00:05:04,440 --> 00:05:09,700
 Что ж, если вы помните об этом, теперь
 это должно быть довольно легко.

63
00:05:09,700 --> 00:05:14,420
 Просто возьмите последние 23 бита многоадресного
 IP-адреса и отобразите их здесь.

64
00:05:14,420 --> 00:05:20,180
 Допустим, мой IP-адрес многоадресной
 рассылки — 239.

65
00:05:20,180 --> 00:05:29,420
 Ну, неважно, какой первый октет,
 от 224 до 239, он всегда

66
00:05:29,420 --> 00:05:31,660
 собираемся отобразить до 5e, верно?

67
00:05:31,660 --> 00:05:34,400
 Поскольку этот октет как бы аннулируется,
 он всегда будет становиться

68
00:05:34,400 --> 00:05:39,600
 5е. А теперь предположим, что у меня был
 многоадресный поток с номером 239.

69
00:05:39,600 --> 00:05:43,300
 давайте просто сделаем это проще.

70
00:05:43,300 --> 00:05:48,360
 1.1.1. Это мой IP-адрес
 многоадресной рассылки.

71
00:05:48,360 --> 00:05:54,480
 Ну, результирующий MAC-адрес многоадресной
 рассылки будет 01005e, и эти биты

72
00:05:54,480 --> 00:05:56,040
 будет нанесено на карту прямо здесь.

73
00:05:56,040 --> 00:06:01,620
 Итак, это будет 01005e, 1111.

74
00:06:01,620 --> 00:06:06,860
 А что если бы у меня был 225.1.1?

75
00:06:06,860 --> 00:06:11,320
 Это было бы то же самое.

76
00:06:11,320 --> 00:06:14,400
 0111, все они будут соответствовать одному и
 тому же MAC-адресу многоадресной рассылки.

77
00:06:14,400 --> 00:06:15,700
 Итак, давайте добавим это на секунду.

78
00:06:15,700 --> 00:06:21,860
 Если вы просто быстро посчитаете, если
 мы начнем с 224 и дойдем до 239,

79
00:06:21,860 --> 00:06:25,440
 сколько это уникальных чисел?

80
00:06:25,440 --> 00:06:30,440
 Я вам сразу скажу, это всего
 16 уникальных номеров.

81
00:06:30,440 --> 00:06:35,100
 От 224 до 239 — это 16 комбинаций байтов.

82
00:06:35,100 --> 00:06:42,440
 Итак, сразу же у нас есть 16 адресов многоадресной
 рассылки IPV4, которые будут

83
00:06:42,440 --> 00:06:47,120
 все сопоставляются с одним и тем же
 MAC-адресом многоадресной рассылки.

84
00:06:47,120 --> 00:06:50,220
 Но бывает даже лучше.

85
00:06:50,220 --> 00:06:59,520
 Потому что этому будет соответствовать
 не только 239.111, но и 239.129.11.

86
00:06:59,520 --> 00:07:04,520
 Потому что помните, этот 8 бит, этот бит,
 который обычно отображается в 128

87
00:07:04,520 --> 00:07:07,720
 бит всегда должен быть нулем.

88
00:07:07,720 --> 00:07:12,240
 Поэтому даже если в адресе IPV4 этот
 бит включен, нам придется включить

89
00:07:12,240 --> 00:07:14,920
 это прямо здесь.

90
00:07:14,920 --> 00:07:22,380
 Таким образом, 239.111 и 239.111 также
 будут соответствовать одному и тому же.

91
00:07:22,380 --> 00:07:27,560
 Каждый раз, когда в этом третьем октете
 включается 128-битный бит, он снижается.

92
00:07:27,560 --> 00:07:30,600
 out, потому что здесь должен быть ноль.

93
00:07:30,600 --> 00:07:35,260
 Это означает, что для каждой из этих
 16 комбинаций есть две комбинации.

94
00:07:35,260 --> 00:07:45,080
 это тоже карта. Например, 224.111
 и 224.129.11, оба сопоставлены

95
00:07:45,080 --> 00:07:46,540
 то же самое.

96
00:07:46,540 --> 00:07:56,460
 227.1.5.5, 227.129.5 сопоставлены
 с одним и тем же.

97
00:07:56,460 --> 00:08:03,620
 Итак, на самом деле у нас есть 16
 чисел в первом октете и два числа.

98
00:08:03,620 --> 00:08:05,760
 во втором октете.

99
00:08:05,760 --> 00:08:09,060
 Итак, у нас действительно 32.

100
00:08:09,060 --> 00:08:14,440
 Итак, для каждого отдельного MAC-адреса многоадресной
 рассылки, если я покажу вам, например,

101
00:08:14,440 --> 00:08:17,700
 вот здесь, давайте избавимся
 от имени Стива Диринга.

102
00:08:17,700 --> 00:08:21,360
 Я уверен, что ему бы хотелось увидеть
 это на презентации, но извини, Стив,

103
00:08:21,360 --> 00:08:23,600
 мы собираемся временно
 избавиться от этого.

104
00:08:23,600 --> 00:08:41,740
 Итак, если бы я дал вам этот MAC-адрес многоадресной
 рассылки, 01005E, упс, не 5.2, 5E.

105
00:08:41,740 --> 00:08:52,480
 А потом я сказал, скажем так, 7.1.1, позвольте
 мне сделать одно, давайте поставим двоеточия.

106
00:08:52,480 --> 00:08:58,500
 Вот и все, что нужно для обеспечения единообразия,
 давайте посмотрим здесь.

107
00:08:58,500 --> 00:09:01,380
 Давайте и здесь поставим двоеточия.

108
00:09:01,380 --> 00:09:11,140
 Хорошо, если бы я спросил вас, какой IPv4-адрес
 многоадресной рассылки закончился?

109
00:09:11,140 --> 00:09:15,820
 в результате чего появился этот
 многоадресный MAC-адрес?

110
00:09:15,820 --> 00:09:19,960
 Ваш ответ должен состоять
 из 32 уникальных чисел.

111
00:09:19,960 --> 00:09:25,080
 Потому что ты бы сказал: ну, Кит,
 первый октет мог быть чем угодно.

112
00:09:25,080 --> 00:09:30,840
 с 224 до 239.

113
00:09:30,840 --> 00:09:37,940
 И тогда второй октет мог
 бы быть числом 7 или

114
00:09:37,940 --> 00:09:50,920
 128 плюс 7, что будет 135.1.1.

115
00:09:50,920 --> 00:10:01,020
 Итак 224.7.135, 225.7.135,
 226.7.135, 111.1.

116
00:10:01,020 --> 00:10:02,780
 Все ли соответствует этому?

117
00:10:02,780 --> 00:10:09,200
 Это дает нам 32 IP-адреса многоадресной рассылки, которые
 соответствуют одной и той же многоадресной рассылке.

118
00:10:09,200 --> 00:10:16,680
 MAC-адрес. В этот момент вам может быть
 интересно: вау, ладно, интересно.

119
00:10:16,680 --> 00:10:21,500
 математическое упражнение, но какое отношение
 это имеет к реальному миру?

120
00:10:21,500 --> 00:10:23,460
 Где актуальность?

121
00:10:23,460 --> 00:10:26,180
 Что ж, позвольте мне нарисовать
 для вас картину.

122
00:10:26,180 --> 00:10:28,480
 Допустим, возьмем это.

123
00:10:28,480 --> 00:10:38,600
 Допустим, у меня есть 4 ноутбука.

124
00:10:38,600 --> 00:10:41,800
 Скажем так, 3-3 ноутбука, так как
 мне здесь не хватает места.

125
00:10:41,800 --> 00:10:45,900
 Хорошо, и мы сделаем это очень просто.

126
00:10:45,900 --> 00:10:55,180
 Они подключены к хабу, который, в свою очередь,
 подключен к многоадресной рассылке.

127
00:10:55,180 --> 00:10:59,960
 сервер. Конечно, вы никогда не увидите
 этого в реальной жизни, но вы получите

128
00:10:59,960 --> 00:11:02,560
 идея, лежащая в основе этого,
 как только я начну здесь.

129
00:11:02,560 --> 00:11:08,360
 Итак, мы просто скажем PCA, B и C.

130
00:11:08,360 --> 00:11:13,940
 Допустим, этот многоадресный сервер
 будет отправлять 3 уникальных

131
00:11:13,940 --> 00:11:15,440
 потоки трафика.

132
00:11:15,440 --> 00:11:23,820
 У нас есть 225.2.1.1.

133
00:11:23,820 --> 00:11:31,020
 У нас есть 239.130.1.1.

134
00:11:31,020 --> 00:11:35,540
 А у нас 232.

135
00:11:35,540 --> 00:11:45,220
 Ну, нам не следует использовать,
 ну вы поняли, 232.2.1.1.

136
00:11:45,220 --> 00:11:50,020
 И допустим, что все это
 потоки высокой четкости.

137
00:11:50,020 --> 00:11:54,940
 Каждый из них имеет скорость
 5 мегабит в секунду.

138
00:11:54,940 --> 00:11:58,700
 Если вы действительно его получите, вы
 будете получать 5 мегабит в секунду.

139
00:11:58,700 --> 00:12:03,580
 Итак, эти потоки идут сейчас.

140
00:12:03,580 --> 00:12:08,440
 Все три потока покидают этот
 сервер одновременно.

141
00:12:08,440 --> 00:12:12,000
 Если ПК, давайте начнем с PCC.

142
00:12:12,000 --> 00:12:20,140
 Если PCC говорит: «Посмотрите», меня
 интересует только 225.2.1.1.

143
00:12:20,140 --> 00:12:21,320
 Так что же он делает?

144
00:12:21,320 --> 00:12:22,860
 Он обращается к своей сетевой карте Nik.

145
00:12:22,860 --> 00:12:25,460
 Он говорит: «Хорошо, карта Ethernet Nik,
 это то, что я хочу, чтобы вы искали».

146
00:12:25,460 --> 00:12:32,200
 Если вы когда-нибудь видели кадр Ethernet,
 который начинается с 0.01, 0.05e, 0

147
00:12:32,200 --> 00:12:41,500
 .2, 0.1, 0.1, я хочу, чтобы вы забрали
 это и отправили на мой процессор для

148
00:12:41,500 --> 00:12:46,960
 обработка. В тот момент, когда он это делает, он программирует
 свою карту Nik так, чтобы она выглядела

149
00:12:46,960 --> 00:12:51,480
 при этом внезапно его ноутбук просто
 начинает выходить из строя.

150
00:12:51,480 --> 00:12:57,020
 Его видеоэкран просто пиксельный,
 ничего не видно, нет.

151
00:12:57,020 --> 00:13:00,700
 иметь смысл. Мало того, он пытается
 загрузить свою электронную почту и

152
00:13:00,700 --> 00:13:03,700
 загрузка его писем занимает целую вечность,
 возможно, он даже подключается

153
00:13:03,700 --> 00:13:06,640
 и отключение, подключение и отключение
 от его почтового сервера.

154
00:13:06,640 --> 00:13:09,440
 Как будто его ноутбук просто хлопнули.

155
00:13:09,440 --> 00:13:10,700
 Что происходит?

156
00:13:10,700 --> 00:13:15,700
 На данный момент, поскольку все три потока
 соответствуют одному и тому же

157
00:13:15,700 --> 00:13:22,240
 MAC-адрес второго уровня, теперь
 у нас есть три потока, и его Ник

158
00:13:22,240 --> 00:13:26,900
 карта собирает их все, потому что
 на втором уровне они все выглядят

159
00:13:26,900 --> 00:13:30,920
 такой же. Его сетевая карта не может распознать
 адреса третьего уровня, потому что

160
00:13:30,920 --> 00:13:31,920
 оно этого не делает.

161
00:13:31,920 --> 00:13:33,840
 Это просто сетевая карта второго уровня.

162
00:13:33,840 --> 00:13:39,280
 Итак все три этих потока, суммарно
 идет 15 мегабайт трафика

163
00:13:39,280 --> 00:13:44,700
 направлено на центральный процессор этого
 парня, и его процессор теперь должен

164
00:13:44,700 --> 00:13:50,820
 выбросить или выбросить 10 мегабайт из этого, чтобы
 он мог видеть только те пять мегабайт, которые

165
00:13:50,820 --> 00:13:55,060
 оно хочет. Что ж, его процессору, вероятно,
 будет очень трудно принимать

166
00:13:55,060 --> 00:14:00,240
 стабильные 15 мегабайт входящего трафика
 и попытка отбросить две трети

167
00:14:00,240 --> 00:14:02,220
 из них 10 мегабайт.

168
00:14:02,220 --> 00:14:05,000
 И в этом проблема перекрытия 32 к одному.

169
00:14:05,000 --> 00:14:07,900
 Теперь это не вина получателя.

170
00:14:07,900 --> 00:14:10,760
 Это вина человека, который настроил
 этот мультикаст-сервер в

171
00:14:10,760 --> 00:14:15,160
 первое место. Когда вы, если вы когда-нибудь
 окажетесь в ситуации, когда вы находитесь

172
00:14:15,160 --> 00:14:20,760
 администратор многоадресной рассылки,
 и вам предстоит придумать

173
00:14:20,760 --> 00:14:25,100
 IP-адреса многоадресной рассылки для каждого
 из потоков многоадресной рассылки, это

174
00:14:25,100 --> 00:14:29,080
 ваша задача – знать об этом и следить
 за тем, чтобы эти видеопотоки не

175
00:14:29,080 --> 00:14:33,060
 перекрывать. И он мог бы сказать: ну,
 Кит, есть ли простой способ понять,

176
00:14:33,060 --> 00:14:34,580
 это вышло? Конечно, есть.

177
00:14:34,580 --> 00:14:39,140
 Просто убедитесь, что из каждого многоадресного
 потока последние два

178
00:14:39,140 --> 00:14:41,920
 октеты никогда не бывают одинаковыми.

179
00:14:41,920 --> 00:14:44,780
 Технически мы могли бы перейти и к
 третьему октету, но если вы знаете

180
00:14:44,780 --> 00:14:49,960
 что эти последние 16 бит всегда уникальны,
 ваши MAC-адреса многоадресной рассылки

181
00:14:49,960 --> 00:14:55,580
 всегда будет уникальным, потому что последние
 16 бит преобразуются один в один

182
00:14:55,580 --> 00:14:58,520
 вплоть до многоадресного MAC-адреса
 на втором уровне.

183
00:14:58,520 --> 00:15:02,740
 Так что просто сделайте их уникальными, и у
 вас никогда не будет совпадений 32 к одному.

184
00:15:02,740 --> 00:15:05,120
 проблема когда-нибудь снова.

185
00:15:05,120 --> 00:15:14,220
 Вот как вы распознаете IP-адреса многоадресной
 рассылки и MAC-адреса многоадресной рассылки.

186
00:15:14,220 --> 00:15:22,280
 Теперь я немного рассказал о том, что делают
 маршрутизаторы с многоадресными кадрами.

187
00:15:22,280 --> 00:15:25,980
 Я сказал, что когда маршрутизатор получает
 многоадресный кадр, первое, что он говорит

188
00:15:25,980 --> 00:15:28,180
 это то, что мне нужно обработать?

189
00:15:28,180 --> 00:15:32,120
 Потому что это может быть приветствие EIGRP,
 приветствие OSPF или что-то в этом роде.

190
00:15:32,120 --> 00:15:35,180
 что в этом случае я скажу: ах,
 я запрограммирован искать это.

191
00:15:35,180 --> 00:15:37,980
 Позвольте мне отправить его на
 мой процессор для обработки.

192
00:15:37,980 --> 00:15:40,060
 Которые останавливаются и
 делают паузу на мгновение.

193
00:15:40,060 --> 00:15:41,020
 Думать об этом.

194
00:15:41,020 --> 00:15:47,680
 Представьте, что вы маршрутизатор, и вы
 запрограммированы на работу с EIGRP.

195
00:15:47,680 --> 00:15:51,760
 хорошо? Итак, вы специально прослушиваете
 поступающие кадры Ethernet.

196
00:15:51,760 --> 00:15:58,820
 переходя к 01005E, 0000A, верно?

197
00:15:58,820 --> 00:16:05,700
 Поскольку это соответствует 10, 2240010
 отображается до 00A на втором уровне.

198
00:16:05,700 --> 00:16:08,440
 Итак, время от времени вы ожидаете,
 что маршрутизатор скажет вам: «ОК,

199
00:16:08,440 --> 00:16:11,660
 ну, вы знаете, EIGRP не должен
 быть таким болтливым, верно?

200
00:16:11,660 --> 00:16:15,280
 В хорошей стабильной среде примерно каждые
 пять или десять секунд вам следует

201
00:16:15,280 --> 00:16:19,720
 получать пакет приветствия EIGRP, направляясь
 на этот многоадресный Mac, а затем

202
00:16:19,720 --> 00:16:24,400
 вы обрабатываете это. А что, если
 кто-то, ничего не знающий о EIGRP,

203
00:16:24,400 --> 00:16:29,060
 но они знают, что многоадресная рассылка настраивает
 их многоадресную передачу видео высокой четкости

204
00:16:29,060 --> 00:16:34,360
 поток, который идет со скоростью семь
 мегабит в секунду, и они выбирают,

205
00:16:34,360 --> 00:16:41,920
 Не знаю, 239.0010 как платье назначения.

206
00:16:41,920 --> 00:16:46,740
 Угадай, что? На втором уровне этот видеопоток
 высокой четкости будет отображаться на

207
00:16:46,740 --> 00:16:50,620
 тот же Mac-адрес, который
 использует EIGRP.

208
00:16:50,620 --> 00:16:53,200
 И теперь внезапно ваш маршрутизатор вместо
 того, чтобы получить только один пакет

209
00:16:53,200 --> 00:16:57,420
 каждые пять или десять секунд получают
 тысячи пакетов каждый раз

210
00:16:57,420 --> 00:17:00,300
 второй переход к этому слою для решения.

211
00:17:00,300 --> 00:17:03,400
 Можно поспорить, что роутер
 этому не очень обрадуется.

212
00:17:03,400 --> 00:17:07,220
 Он может даже выйти из строя, потому что ему
 придется принять весь трафик, направленный на

213
00:17:07,220 --> 00:17:13,640
 ЦП быть не EIGRP.

214
00:17:13,640 --> 00:17:18,200
 Мне нужно отказаться от этого, чтобы иметь возможность
 изолировать небольшое приветствие EIGRP, которое

215
00:17:18,200 --> 00:17:20,320
 все еще приходит каждые пять
 секунд или около того.

216
00:17:20,320 --> 00:17:23,200
 Так что имейте это в виду.

217
00:17:23,200 --> 00:17:25,640
 Что же делают коммутаторы при получении
 многоадресной рассылки?

218
00:17:25,640 --> 00:17:30,760
 Ну, если вы просто говорите о чистом втором уровне,
 коммутаторы рассылают многоадресную рассылку

219
00:17:30,760 --> 00:17:34,280
 потому что как коммутатор узнает,
 куда что-то пересылать?

220
00:17:34,280 --> 00:17:42,280
 Итак, когда приходит кадр Ethernet,
 что делает коммутатор?

221
00:17:42,280 --> 00:17:46,160
 Он узнает об этом в таблице MAC-адресов,
 иногда называемой таблицей CAM.

222
00:17:46,160 --> 00:17:49,520
 верно? Вот как коммутатор заполняет
 таблицу CAM, MAC-адрес

223
00:17:49,520 --> 00:17:52,120
 таблица на основе MAC-адресов источника.

224
00:17:52,120 --> 00:17:57,580
 Ну, видели ли когда-либо MAC-адреса многоадресной
 рассылки в источнике Ethernet?

225
00:17:57,580 --> 00:17:59,640
 рамка? Нет, они не.

226
00:17:59,640 --> 00:18:00,620
 По крайней мере, они не
 должны быть такими.

227
00:18:00,620 --> 00:18:02,080
 Это было бы незаконно.

228
00:18:02,080 --> 00:18:06,840
 Итак, поскольку MAC-адрес многоадресной рассылки
 отображается только в пункте назначения,

229
00:18:06,840 --> 00:18:11,140
 по умолчанию коммутатор не имеет возможности
 изучить его, поскольку его нет в источнике.

230
00:18:11,140 --> 00:18:14,320
 Так что же делают коммутаторы, когда
 они получают кадр Ethernet и выглядят

231
00:18:14,320 --> 00:18:16,880
 в пункте назначения, а в
 таблице нет совпадений?

232
00:18:16,880 --> 00:18:20,100
 Они затопляют его. Вот что они делают.

233
00:18:20,100 --> 00:18:24,180
 Таким образом, поведением многих коммутаторов
 по умолчанию является многоадресная рассылка.

234
00:18:24,180 --> 00:18:27,920
 Теперь посмотрим, когда мы перейдем к
 теме отслеживания IGMP, что изменится.