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
 如果您看到一個乙太網路幀，該幀將發送至目的地

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
 這就是為 IPv4 多播資料保留的 OUI。

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，然後是 AAAA、BBBB、CCC，讓我們看看
 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
 創建他的乙太網路幀，他要做的就是取得最後 32 個

23
00:02:11,080 --> 00:02:19,100
 位，在本例中是 777 和 DDDD，他將把它改正

24
00:02:19,100 --> 00:02:21,180
 在這裡，這些 X 所在的位置。

25
00:02:21,180 --> 00:02:26,380
 所以在第二層，乙太網路訊框將會被送到 333 colon 777

26
00:02:26,380 --> 00:02:32,020
 冒號 DDDD。所以這很容易。

27
00:02:32,020 --> 00:02:36,400
 只要記住 IPv6 多播位址的最後 32 位元直接

28
00:02:36,400 --> 00:02:42,420
 對應到乙太網路封包的目標 MAC 位址的最後 32 位元。

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
 Steve Deering 多播 Mac。

55
00:04:39,780 --> 00:04:42,480
 你會發現一個關於 Steve Deering 的有趣故事

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
 只需取出多播 IP 位址的最後 23 位元並將其對應到此處即可。

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
 5e.現在假設我的多播流為 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
 因為這裡必須為零。

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
 這個，讓我們在這裡去掉 Steve Deering 的名字。

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
 如果是PC，我們就從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
 他說好吧，乙太網路 Nik 卡，這就是我要你找的。

146
00:12:25,460 --> 00:12:32,200
 如果您看過以 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 位址，我們現在有三個流下來，他的 Nik

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
 指向這傢伙的中央處理器，他的 CPU 現在必須

164
00:13:44,700 --> 00:13:50,820
 丟掉或丟棄 10 兆，這樣它只能看到 5 兆

165
00:13:50,820 --> 00:13:55,060
 它想要。那麼他的 CPU 可能會很難接收

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 比 1 重疊的問題。

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 比 1 的重疊

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 hello 或 OSPF hello 或類似的內容

190
00:15:32,120 --> 00:15:35,180
 在這種情況下我會說，啊，我被編程來尋找這個。

191
00:15:35,180 --> 00:15:37,980
 讓我將其發送到我的 CPU 進行處理。

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
 好吧？所以你正在專門監聽即將到來的乙太網路幀

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 hello 封包，前往該多播 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
 EIGRP 使用的 Mac 位址完全相同。

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
 CPU 不是 EIGRP。

214
00:17:13,640 --> 00:17:18,200
 我需要丟棄它才能隔離小的 EIGRP hello

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
 那麼，當乙太網路幀進來時，交換機會做什麼？

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 位址？

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
 那麼當交換器收到乙太網路幀並查看時會做什麼

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 監聽主題時會發生變化