发现中文播客


Cisco學習資訊分享 - weicast.com

Cisco學習資訊分享

Li-Ji Hong (洪李吉)

科技
网站 Apple Podcast

網站"Cisco學習資訊分享"的有聲版本


2020-07-27

WEP並不安全

首先我要澄清,製作這個影片,我並不想要教大家,去破解別人的Wi-Fi網路。我只是要證明,WEP這個方法並不足以保護Wi-Fi網路。



第一步:準備動作,找到WEP目標

因為後續的WEP工具,需要告知它去破解哪一個以WEP 保護的Wi-Fi網路,因此,我們需要找到這個被攻擊網路的 頻道號碼、還有BSSID,也就是基站的MAC地址。

我使用 airodump-ng 來掃描,命令是:

sudo airodump-ng wlan0 –encrypt wep

這裡我們找到了,所要被攻擊的目標,它的BSSID,頻道,還有SSID名稱。確定這是我原本準備好的標靶。


第二步:使用主要破解工具 besside-ng


我使用 besside-ng,命令是:

sudo besside-ng wlan0 -c -b

開源工具besside-ng的工作原理,大致上來說,是自動注入一些數據楨,強迫目標回應,然後擷取數據楨的內容,來找到足夠分析的IV值。

這個工具和步驟,所花的時間是最多的,時間長短的變動也最大,因此,需要耐心等待結果。

這次的錄影,我到了將近十萬個IV值,才完成WEP破解,花了將近半小時的時間;我印象中曾經只要兩萬多個IV,不到十分鐘,就破解了。

第二步完成的時候,WEP的金鑰已經被破解,也就是說,之後擷取到的Wi-Fi數據楨,都可以被軟體解密了。

假設我的終極目標,是要找出 WEP登入密碼,我還需要第三個步驟。


第三步:找到WEP登入密碼


這裡我使用 aircrack-ng 來反解。命令是:

sudo aircrack-ng wep.cap

其中的wep.cap檔案,是第二步驟 besside-ng所自動擷取存檔的WEP數據楨內容。因此,這個步驟,其實可以離線進行。


總結來說,假設您還在使用WEP來保護Wi-Fi網路,任何段數的駭客,花個幾十分鐘,就可以進到您的網路。WEP真的很不安全!


One more thing…


我發現,即使是家用型的Wi-Fi網路產品,幾乎預設都已經不再使用WEP來保護了。大家不需要看完我的影片,就開始感到恐慌。

就算是不小心連接到使用WEP保護的Wi-Fi網路,Windows 10也會自動警告,這個Wi-Fi網路並不安全。

Wi-Fi網路,也就是IEEE 802.11的網路,還是一種方便取得的無線通訊技術,讓企業能夠完全掌握,而且足夠安全。我們不一定非得要在企業內部架設或提供Wi-Fi網路服務,但是,我們一定要有足夠的能力,來監視企業場地內的Wi-Fi通訊活動。

白沙尾觀光港
台灣屏東縣、小琉球
我是洪李吉。我的網站是「Cisco學習資訊分享」。我們下次見!


2020-05-02

Cisco MDS Zoning 基礎模式、CFS、和加強模式

【Cisco MDS Zoning 基礎模式、CFS、和加強模式】
Cisco MDS 9000 Family (截圖自Cisco.com官網)
Fibre-Channel是存儲網路(Storage Area Network, SAN)領域中最常被使用的協定。Cisco也有存儲網路的交換器產品:Cisco MDS系列。Fibre-Channel 協定(後面我用FC來代替) 的安全管制機制稱為分區(Zoning, 將Zone變成動詞)。我們來討論,在Cisco MDS產品上,幫助FC Zoning設定的三種工具:基礎模式(Basic Zoning)、Cisco Fabric Service (CFS)、加強模式(Enhanced Zoning)。
為了方便理解,我這裡另外錄製了一段展示影片,可以跟這篇文章一起研讀。

我們先將三套MDS乾淨的VSAN建立好。展示的畫面中我使用VSAN 4。

Basic Zoning,基礎模式


Cisco MDS當VSAN剛建立完成的時候所預設的Zoning, 稱為 Basic Zoning。Basic Zoning是Fibre Channel的標準協定,可以跨廠牌支援。我們來觀察,在Cisco MDS上面的Zoning資訊傳遞行為。
我們先創建Zone Set“set4A”和“set4B”。
當我們創建Zone Set,但是尚未啟用(Activate)之前,所有的MDS都不會收到任何的Zoning資訊。
接下來我們執行“zoneset activate name set4A vsan 4”。這個命令,除了將會在本地的MDS,將Zoning的設定以set4A啟用之外,還會透過Fibre Channel底層的協定,將啟用過的Zoning設定,複製同時啟用,到所有的MDS上面。
我們透過“show zoneset active vsan 4”命令來檢查所有的MDS,啟用中的Zone Set。
我們可以觀察到,所有的MDS,都是“set4A”被啟用。
任何時間,我們只能有一份的Zone Set是啟用中。通常,我們在MDS上面,不只是保存啟用中的Zone Set,我們經常會面對不同場景的,保留好幾份的Zone Set,輪流按照需要啟用。這些定義過,無論是否被啟用的Zone Set,全部合起來稱為 Full Zone Set。
我們可以透過 “show zoneset vsan 4”命令來檢查,所有MDS上面的Full Zone Set。然而,因為Basic Zoning所傳遞的資訊,並不包含Full Zone Set,因此除了我們有設定過的這套MDS之外,其他的MDS完全看不到Full Zone Set。

Cisco Fabric Service, CFS


在Basic Zoning工作模式之下,我們無法透過標準的Fibre Channel協定來傳遞 Full Zone Set。我們只能透過,Cisco私有的協定Cisco Fabric Service(後面簡稱為CFS),來傳遞 Full Zone Set。
CFS協定預設已經開啟。但是,我們必須手動要求CFS傳送Full Zone Set。我們利用 “zoneset distribute vsan 4” 來立刻傳遞 Full Zone Set。
CFS的限制是,除非我們手動下達“zoneset distribute vsan 4”,否則,CFS不會自動將更動過的Full Zone Set的內容,同步複製到所有的MDS。
我們可以編輯加入一組新的Zone Set “set4C”,然後再次透過 “show zone


2019-11-27

如何知道,我正在使用IPv6?

最近不少人在討論「全球 43 億個 IPv4 地址今日正式耗盡」,例如這一篇。我相信起因,是因為RIPE的Nikolas Pediaditis幾天前的一封公開Email,宣布RIPE NCC的IPv4地址,已經全部發放完畢。

https://www.ripe.net/ripe/mail/archives/ncc-announce/2019-November/001380.htmlDear colleagues, Today, at 15:35 UTC+1 on 25 November 2019, we made our final /22 IPv4 allocation from the last remaining addresses in our available pool. We have now run out of IPv4 addresses. .....

五個「區域網際網路註冊中心」


原本IPv4地址的發放,由IANA統一控管,再下發給全球五個「區域網際網路註冊中心」 (Regional Internet Registry, RIR)。各區域內的電信、服務業者、企業、組織等等,如果需要IP地址,就自行跟「區域網際網路註冊中心」申請。

Wikipedia: Regional Internet Registries world map.
Rir.gif: Dork BlankMap-World6,_compact.svg: Canuckguy et al. derivative work: Sémhur (talk) - Rir.gif BlankMap-World6,_compact.svg


目前全球一共分成五個「區域網際網路註冊中心」:

(區域Regional所指的是全球來看,好幾個國家的區域。)


AfriNIC:大致上是非洲APNIC:大致上是亞洲、太平洋區域ARIN:大致上是北美洲,其實只有美國和加拿大。LACNIC:剩下的美洲,大致上是拉丁美洲、中、南美洲。RIPE NCC:大致上是歐洲、中東、俄羅斯
所以,RIPE NCC用完IPv4地址,並不代表”全球”的所有區域全部都用完。事實上,我剛才查到,AfriNIC,今天 (Nov 27, 2019) 的確還沒有用完。

http://www.potaroo.net/tools/ipv4/網站的 Nov. 27, 2019 快照

為什麼我現在跟電信業者申請新的網路,我還是可以取得IPv4地址可以使用呢?


電信業者都會有庫存的IPv4地址。電信業者跟「區域網際網路註冊中心」申請地址的時候,一定會考慮到預留未來可能增加的客戶數,批次申請。因此,一定還有庫存可以使用。

電信業者依然可以分配客...


2019-11-13

什麼是「網際網路交換中心」Internet Exchange (IX)?

我們普通的網際網路使用者,只需要將網路連接到網際網路服務業者(Internet Service Provider,ISP),剩下的網際網路的連通工作,業者會在幕後幫我們完成。

但是站在網際網路服務業者的角度,業者不只是必須跟國際的ISP連接,在國內,也必須同時跟國內的其他業者ISP相連接。於是,我們需要一個額外的腳色,專門服務業者和業者之間的網路封包的連通和交換。這個額外的腳色,就是 Internet Exchange (IX),我稱為「網際網路交換中心」。

我藉著下面假想的、台灣的例子,我們就可以理解網際網路交換中心,扮演什麼重要的功能。


假想情境:五家業者


首先,我先假設台灣國內有五家網際網路服務業者。這五家業者,各自租用連接到外國的國際線路,來讓各自的租用客戶,可以跟國際的Internet 相接通。

這樣已經可以讓網際網路開始工作了。但是,並不是很有效率。

我假設台灣國內某個熱門的購物網站,伺服器架設在業者一(ISP 1)。熱門購物網站的用戶端,肯定不只是業者一自己內部的租用客戶,一定也有不少的用戶,是來自於業者三、或者是業者五。

這時候問題來了。業者三租用客戶的封包,必須先跑到國外,才能再連回到業者一。反方向的流量,或者是業者五的用戶,也有完全相同的困擾。

在這個情境下,網路依然可以接通,只不過,所走的路徑並不是最短路徑,網路延遲時間會非常高。同時,出國的國際線路,單價很高,頻寬很貴,這並不是最經濟的網路連接方式。

可能方案一 業者之間直拉國內線路


在這個假想的情境中,我假設業者一和業者三、業者五之間,願意投資直拉的線路。這時候,封包就可以改成走台灣國內的線路。國內的線路,跟國際的線路比較,相對的單價比較便宜,同時網路延遲時間也比較短。因此,流量最佳化的問題解決了。

下一個新的問題是,假設每一家業者,都有熱門的網站,都需要服務來自不同業者內的租用客戶,而且每一家業者之間,都願意投資直拉的線路。如果真的這樣拉線路,最後這個業者和業者之間的線路網,本身就會變得非常複雜。


我知道,很多讀者可能覺得,畫面中的拓樸只有10條線路,感覺起來不算很複雜。但是,當業者數目越來越多的時候,例如台灣國內有20家業者,這時候線路的數字,就來到了190條 (20X19/2) 了!

永久方案:網際網路交換中心


我們需要一個獨立的腳色,也就是本文的主角「網際網路交換中心」(Internet Exchange, IX)。

只要「網際網路交換中心」存在,業者和業者兩兩之間,不再需要拉直通的台灣國內線路了。每家業者,只需要分別拉通往「網際網路交換中心」的直拉線路,就可以同時達成,封包在比較近比較便宜的國內線路交換,而且線路網本身,又不會太複雜。

可能會有朋友擔心,單點故障全體故障 (Single Point of Failure, SPOF)的疑慮。事實上,網際網路交換中心的腳色,可以同時存在超過一個,對於網際網路業者來說,只要同時連接到超過一個的網際網路交換中心,問題就得到解決。

因為「網際網路交換中心」所連接的對象,都是網際網路服務業者,因此也有文件稱呼,網際網路交換中心就是ISP之間的Service Provider。


One more thing…


「網際網路交換中心」(Internet Exchange, IX),從前面的討論來看,的確扮演著「國內流量」的交換匯聚腳色,假設「網際網路交換中心」的管理上出現問題,被駭客植入監視系統,肯定所有業者下面的租用戶流量,都可能被駭客監看。

我個人的看法是,封包只要在網際網路上流動,內容被第三者監看,是很自然的結果。只要我們的封包,在送出我們自己的電腦之前,都已經得到加密、電子簽章的保護,例如IPSec、VPN、SSH、SSL/TLS等,一般的用戶,其實不需要特別擔心。

還有,網際網路交換中心,在國內也不會只有一個。只要別同時被駭客控制,就沒有完全斷網的可能。即便在最差的狀況下,失去了所有的網際網路交換中心,業者依然可以透過昂貴的國際Internet來接通。

我想說的是,保護好「網際網路交換中心」的確很重要,但是,也別恐慌於即將失去其中的一個。

我是洪李吉。我的網站是「Cisco學習資訊分享」。我們下次見!

「林蔭大道」
香港中文大學


2019-11-06

全球的BGP IPv4路由表突破800K

這一週,全球的BGP IPv4路由表,已經來到八十萬筆。不需要擔心,這只是一個時間上的里程碑。

我依然記得,在2001年,我幫客戶安裝了一套BGP路由器。這套路由器的型號是Cisco 3660,其實只有256 Megabytes的DRAM記憶體。當年的美好時光,全球的BGP路由表只有不到十五萬筆而已。雖然今天看起來256 Megabytes很小,當年依然跑得動。

隨著DRAM記憶體的價格下降,路由器硬體支援的DRAM記憶體容量越來越大。即使只安裝出廠預設的DRAM,不需要特別增加DRAM,BGP管理者也不容易買錯DRAM不足的路由器硬體。

我之前曾經寫過另外一篇文章,每十萬筆的單一鄰接的BGP資訊庫,大約需要80 Megabytes大小的DRAM記憶體。

Cisco學習資訊分享:BGP 記憶體需求估計
換句話說,如果要存放今天全球BGP八十萬筆的資訊庫,我們大約也只需要保留每個鄰接800 Megabytes,也就是0.8 Gigabytes的DRAM,給BGP協定來使用就夠了。對於今天的路由器硬體來說,小事一件。

我舉一個例子,Cisco ASR 1000 RP1加4G DRAM,今天來看已經不是太新潮的路由器硬體了。但是,它依然可以承載一百萬筆的BGP路由表。所以八十萬筆,裝得下沒問題。

CIDR REPORT 網站的畫面快照,November 6, 2019

「空盛桑運河」、和「昭披耶河」的交匯處。泰國曼谷市。

One more thing…


我只有一點提醒。如果您在規劃BGP的路由反射角色(Route Reflector),您也許需要稍微注意。因為您的容量規劃,必須將上面的估計,乘以鄰接的數字。

延續前面的Cisco ASR 1000 RP1加4G DRAM的例子,在BGP的路由反射角色下,可以支援到五百萬筆IPv4路由表。假設您需要連接超過五個鄰接,您很可能會超過五百萬筆的上限。也許需要考慮再增加DRAM,或者升級硬體型號,來支援更多的DRAM,例如將路由處理器(Route Processor,RP)升級成 RP2。

對了,您也想知道全球的IPv6路由表數目嗎?目前全球IPv6路由表大約不到八萬筆。IPv6短時間內還不會是問題,全球路由表比IPv4小得太多。

我是洪李吉。我的網站是「Cisco學習資訊分享」。我們下次見!


2019-11-01

免安裝軟體的簡易IPv4地址掃描工具

我們經常需要做網段內的IPv4地址掃描。例如要確定IP地址有沒有被重複使用,或者是純粹做安全掃描,確保沒有隱藏的網路使用者。
為了掃描IP地址,我們也許需要從網路搜尋下載安裝免費的掃描工具,或者是昂貴的工具例如Cisco Prime Infrastructure。沒有工具,我們只能透過PING,來作手動掃描。不論是哪一個方式,都不是那麼簡單。
我這裡提供一個簡易工具,不需要下載安裝,不需要昂貴的軟體。您只需要一套Windows 10的PC。我們一起來看。

第一步:打開PowerShell視窗


在Windows上按下“Windows Logo Key ❖ + R”,輸入”powershell”。然後按下Enter開始執行。Windows 10會產生一個PowerShell視窗,這個視窗並不需要系統管理者的特權。
這點應該不難才對!

第二步:將下列單行腳本剪貼到PowerShell執行


$ipv4prefix=$(ipconfig | where {$_ -match 'IPv4.+\s(\d{1,3}\.\d{1,3}\.\d{1,3}\.)' } | out-null; $Matches[1]); 0..255 | %{"$ipv4prefix$_"}| % {"$($_): $(Test-Connection -count 1 -quiet -ComputerName $($_))"}
這個一行的PowerShell腳本,是我在我的電腦上面測試過可以使用的。
萬一剖析本地的IP地址有問題,或者是,您只是要掃描其他網段,您可以手工將$ipv4prefix變數修改成您所要的目的地網段開頭,例如,您想要掃描的網段是”192.168.1.X”,您可以將$ipv4prefix變數指定成”192.168.1.”。請注意,最後的那個句點,別漏掉了。修改完成的單行腳本,如下:
$ipv4prefix="192.168.1."; 0..255 | %{"$ipv4prefix$_"}| % {"$($_): $(Test-Connection -count 1 -quiet -ComputerName $($_))"} 

第三步:大約五分鐘左右完成掃描,結果在視窗中


下面是一個可能的掃描結果畫面:
192.168.1.0: False192.168.1.1: True192.168.1.2: False192.168.1.3: False192.168.1.4: False192.168.1.5: True…
如果印出”True”,代表這個IP地址有回應,正在使用中。剩下的、印出”False”,代表那些IP地址沒有回應,那些IP地址應該不在使用中的。
假設您認為輸出行數太多,您還可以過濾掉”False”的那幾行,只留下”True”的內容。過濾器就是 “| Select-String True”。例如:
$ipv4prefix=$(ipconfig | where {$_ -match 'IPv4.+\s(\d{1,3}\.\d{1,3}\.\d{1,3}\.)' } | out-null; $Matches[1]); 0..255 | %{"$ipv4prefix$_"}| % {"$($_): $(Test-Connection -count 1 -quiet -ComputerName $($_))"} | Select-String True
加上過濾器後,輸出將會變成類似下面的外觀:
192.168.1.1: True192.168.1.5: True…
是樂園(倫披尼公園, Lumpini Park) 西南方四號門外的King Rama VI Monument

One more thing…


我剛才所作的展示,就是要告訴大家,任何人只要有Windows 10的電腦,隨時都可以開始做IP地址掃描。我們可以想像,假設今天我們使用的是Liunx的電腦,我們甚至可以作出更複雜的掃描工具。
我這裡簡單舉一個Linux上面等價的例子。這個單行腳本所使用的是內建的BASH和AWK。
ipv4prefix="192.168.1."; for i in `seq 1 255`; do ping -c 1 ${ipv4prefix}$i | tr \\n ' ' | awk '/1 received/ {print $2}'; done
我要強調的是「任何人」都可以快速地開始掃描。
我相信大家現在感覺到了,駭客其實很容易就可以找到、列出您全部的公開IP地址。因此,只要您暴露在公開的Internet上面的軟硬體,依然存在著弱點,很快就會被駭客找到,而且攻進去。就像是,我之前提到過的安全事件一樣。
Cisco學習資訊分享:停止支援的路由器,讓銀行損失近百萬美金
我是洪李吉。我的網站是「Cisco學習資訊分享」。我們下次見!


2019-10-18

ATM大當機只因為誤觸一條線路所導致嗎?

這是昨天(2019-10-17)的台灣媒體報導:

針對今天晚間各地銀行發生ATM(自動櫃員機)出現大當機,財金公司回應是一位IBM工程師進行維修時,「誤觸」一條線路導致 …
金管會表示,根據銀行及財金公司回報情況,跨行交易系統是在今晚17點42分出現壅塞,速度變非常慢,但並不是全部當機無法使用;後來狀況是晚間18點18分排除。
我從外部觀察者的角度,來聊一聊這個事件。


有沒有可能只因為碰掉一條網路線,就造成系統停止服務?


這是非常可能的,純粹看運氣。

我這裡假設一個情境,您碰掉的網路線,正好是伺服器的網路掛接存儲系統的唯一通道,偏偏伺服器的關鍵資料檔案就放在上面。

我這裡所提到的「網路掛接存儲系統」,就是Network Attached Storage, NAS。

這算不算是「單點故障全體故障」


當然算,這是一個典型的「單點故障全體故障」案例,Single Point of Failure, SPOF。

我也觀察到,整個事故從發現停止服務開始,在不到40分鐘之內,就恢復正常服務,我判斷系統只有暫停服務,並沒有造成緊急停機或是系統當機。非常可能,真的只因為瞬間失去網路連通性而已。我的經驗告訴我,很多系統,光是執行伺服器停機,或是開機程序,所花費的時間,都遠遠超過40分鐘。

如果無法避開「單點故障全體故障」,應該如何與它共存?


避開「單點故障全體故障」,當然是我們在規劃任何系統的首要目標。但是,在實務上不一定都是那麼容易。例如,這是一個工作中、又不太能停機的單點故障全體故障的系統,光是加入備用系統,就必須安排停止服務的時間,很可能這將是好幾個月後才能發生的事;又或者是,備援系統太貴、目前沒有場地可以安裝、等等。

我們現在能夠做的就是,將這些已知的單點故障全體故障的問題,全部正確的記錄下來,在最終可以負責任的人同意下,列入追蹤,未來找時間、預算,儘快地修正這些問題。


One more thing…


從Phra Pin-klao橋回頭看Rama VIII Bridge
泰國、曼谷市
我們可以趁著這次的事故,順便檢視,我們的工作系統,是否還有單點故障全體故障的問題存在。我這裡另外提醒兩點,跟網路有關的注意事項。

作業風險區,請清楚標示


只要有可能造成單點故障全體故障的關鍵地點、空間,無論是硬體、軟體、線路,都應該清楚的標示。必須要讓任何操作維護的工作人員,都很容易察覺到,在附近作業必須特別小心注意。

例如,我們可以透過掛牌、顏色、三角錐、等等,來提醒所有的工作人員。

機櫃線路作業區,請保留足夠的空間


機櫃緊密並排,並不是問題,但是,網路機櫃的前、後門,我建議至少保留60公分以上的工作空間。這是因為,我們在整理線路、電源線的時候,如果沒有足夠的空間,工作人員會看不到所要維護的連接口,或者是,拔插連接口的時候,去碰觸到其他關鍵的連接口。


我是洪李吉。這是我的網站「Cisco學習資訊分享」,我們下次見!


2019-08-13

擺了乖乖,機房就會自己「乖乖」嗎?

在台灣我經常觀察到,好多公司的資訊機房內,會在機櫃頂端放著好幾包「乖乖」餅乾。難道這麼做,機房就真的會變得「乖乖」嗎?我今天來聊聊這個輕鬆的話題。

「乖乖」風潮


到底是誰先發起了這股「乖乖」風潮,今天應該已經是不可考證了。

大致上的起因,是因為資訊系統維護的日常工作當中,經常發生一些過於巧合的意外。一直都很穩定的系統,偏偏在放假前一天停止服務;有些從來都不曾故障過的硬體,半夜忽然故障發送告警;更新軟體每一次操作都成功,就只有我操作的這一次,軟體重啟後才察覺到服務帶不起來、等等等。

某些朋友也許在偶然間發現,如果在資訊機房、機櫃頂,放了幾包「乖乖」餅乾之後,這種巧合的意外,「感覺起來」,好像比較不會發生。似乎「放乖乖」和「更穩定」兩者之間,猶如真的存在某些關聯性。

這是迷信嗎?


「感覺起來」有關連性,不代表可以從客觀的統計過程當中,歸納出相同的關聯性。假設我們要永久的釐清,需要去蒐集數據,來證明「放乖乖」和「更穩定」兩者是否相關,或是不相關。

我還沒有找到研究報告,我個人目前也還沒有機會進行這種統計。我的確沒有足夠的證據,來指出這就是迷信。

我的看法


不過,我直觀認為,因為下面這幾個理由,「放乖乖」不只不會讓系統更穩定,反過來,還可能增加資訊機房的維護風險。

第一、可能散發香味

「乖乖」的包裝,經常會因為各種原因,釋放出餅乾的香味,甚至於我們人站在旁邊,都聞得到。機房內部擺了這種有機會洩漏香味的餅乾,反而會增加了吸引老鼠、蟑螂、螞蟻的風險。

老鼠會啃食任何物體,包括「光纖」、「網路線」。蟑螂、螞蟻有可能在溫暖的網路孔洞內結巢產卵。這些可能性將變成潛在的機房安全風險。

第二、地震時餅乾袋會掉落

雖然餅乾本體不重,但是當地震時,從機櫃頂落下的時候,高度落差的重力加速度的結果,撞斷一兩個光纖接頭的可能性是很大的。

或者,餅乾袋摔落後萬一破損,很可能造成餅乾散落一地,在資訊機房內,真的很不容易清理乾淨。

第三、彩色包裝袋干擾視線

沒有擺放餅乾的時候,很容易直接用肉眼察覺,機房、機櫃頂並沒有不該出現的異物。

當花花綠綠的彩色包裝袋,擋住視線的時候,要辨認到底是異物、或是單純的餅乾,變得非常困難。

---

簡單的結論就是,我建議大家,千萬別在機房、機櫃頂,繼續擺放「乖乖」餅乾了!


哲徑、和校訓碑文
香港中文大學

One more thing…


很多意外的發生,只要花點時間仔細分析,其實背後都有發生的原因。沒有解決背後的因素,意外將會一直重複發生。我這裡試著分析前面提到的三個例子。

「一直都很穩定的系統,偏偏在放假前一天停止服務」:很可能是系統設計的缺陷,例如一段時間之後,只要硬碟、記憶體滿了,隨時會停止服務。

「有些從來都不曾故障過的硬體,半夜忽然故障發送告警」:只要是旋轉的物體,都會磨損,最後就故障。這包括散熱風扇、硬碟。

以上兩者,平常、白天也可能會發生,只不過,沒有打擾到管理人員的休息時間,大部分的管理人員不會記得曾經發生過。

「更新軟體每一次操作都成功,就只有我操作的這一次,重啟後才察覺到服務帶不起來」:軟體的更新,有失敗的風險是正常的。如果要提早發現風險,更新的軟體最好預先在測試環境中,確認更新的操作過程和結果,再到生產系統操作。

這幾天,農曆的中元節快要到了,很多公司都會用餅乾來做拜拜,「乖乖」當然也是熱門選項之一。

我的提議是,「乖乖」餅乾是要發給「工程師」,在休息室吃的,不是讓您擺在機櫃上面的。吃完「乖乖」以後,「工程師」們才有充足的力氣,努力讓您的機房變「乖乖」。

我是洪李吉!我的網站是「Cisco學習資訊分享」。歡迎常回來逛逛!


2019-06-21

CCNA將於2020年改版重點整理

Cisco已經在官方網站上宣布,好多認證考試的更新,將於2020年2月24日發生。我這裡先整理CCNA的部分。

CCNA考試(200-301)內容改版


2020年新版的考試名稱,正式的名稱是CCNA 2.0認證考試。為了避免大家有誤解,我後面一律用考試代碼200-301稱呼它。

跟目前的考試版本200-125相比較,考試內容最大的差異,是考試範圍的廣度變大了,考試時間和題目數都加長了,增加了無線區域網路(Wireless LAN),增加了自動化和網路管理程式化(Automation and Programming)。簡單的說,就是考試變困難了。

好消息是,2020年2月24日距離現在,還有八個月左右的時間,200-125考試依然可以報考。



如果正要開始準備CCNA認證的朋友們,其實還有充足的時間準備,無論是打算報名密集訓練課程,或者是工作中、學校中自修,時間好好把握,應該是足夠的。

已經取得CCENT衝擊


如果原本計畫分兩階段考試,來取得CCNA的朋友們,這次的改版對您的衝擊是最大的。CCENT認證資格和考試,同樣的將於2020年2月24日一起消失。簡單的說,您必須將ICND1、ICND2兩次考試,一口氣在2020年2月24日之前完成,才能取得CCNA。

(根據我的觀察,台灣計畫分兩階段參加CCNA考試的朋友人數,應該不多。歡迎留言讓我知道!)

已經取得專長CCNA,例如CCNA Wireless的衝擊


這些認證名稱,將於2020年2月24日起,全部變成單一的CCNA認證,而已喔!Cisco網站提到,這些朋友除了會收到CCNA新的證書之外,還會獲得Cisco所承認的學分(Credits)。這些學分,對於CCNA的資格維持(Recertification),是有幫助的。

簡單的說,除非是您所任職的公司要求,一定要立刻通過考試,否則,我建議等到2020年2月24日之後,再考新的版本。

下面是專長CCNA的清單。

CCNA CloudCCNA CollaborationCCNA Cyber OpsCCNA Data CenterCCDACCNA IndustrialCCNA Routing and SwitchingCCNA SecurityCCNA Service ProviderCCNA Wireless

CCNA資格維持(Recertification)


這部分最大的改變,就是未來參加任何Cisco的課程,包含教室、線上、自修,只要是Cisco認可的,Cisco都提供對應承認學分(Credits)。因此,除了每三年重新考CCNA考試,也就是原本的方式之外,只要每三年內取得足夠的學分,也可以繼續CCNA資格。

目前的學分對應規則,網站只有提到CCNA資格維持需要30個學分。但是,課程和學分的對應表,我還沒有看到進一步資訊。

台北植物園裡面的荷花

One more thing…


這次的CCNA改版,我認為是正面的。增加了自動化和網路管理程式化,其實也反映出網路技術最近的趨勢發展。有關於Programming,未來我們再深入討論。

事實上,這次的考試和規則改版,不只有CCNA,就連CCNP、CCIE等等,都是2020年2月24日同時改變。如果大家遇到類似CCNA改版的困擾,請留言讓我知道!

官方網站連結:
Cisco Certified Network Associate (200-301)
New CCNA exam goes live on February 24, 2020


2019-02-15

為何在搭乘飛機的時候,我們的手機,都必須關機呢?

在搭乘飛機的時候,每個人都會被告知手機(移動電話)必須要切換成飛航模式、或者是關機。大家也許看過了下面的這個趣味影片。我相信,每個人一定都很好奇:為什麼?


影片中,這幾個質疑,我相信大家也很想要知道為什麼:
造價九千萬的飛機,會被我的美金四十元的iPod Shuffle所干擾?難道我可以用我的任天堂3DS來綁架這架飛機?為什麼飛機不會干擾到我的手機?其他手機也不會干擾到我的手機?我上次忘了關機,最後也沒事啊!國語字幕的影片,請參考這一個。

一切的恐懼,我相信都是來自於這個熟悉的聲音


(這個原本的聲音影片已經被移除,我替換成下面這個。大家可以搜尋 "GSM noise"找到類似的聲音素材)

只要當我們的手機靠近喇叭、麥克風,如果剛好又接到電話、或是簡訊的時候,一定都會聽到這個急速的、”達達達”的干擾聲音。

我在觀賞Air Crash Investigation這一系列的電視影集後,我才發現,駕駛員和塔台之間的通訊,都還是類比式系統。也就是說,只要有乘客的手機正在通訊,這樣子的 “達達達” 聲音,的確會造成駕駛員聽不到塔臺說話的內容。

造價九千萬的飛機,會被我的美金四十元的iPod Shuffle所干擾?

只有駕駛員、塔臺之間的通話會被干擾。其他例如GPS、羅盤、飛行數據傳輸等等,因為頻率段都和手機沒有重疊,其實都不會被干擾。

只有導航用的聲音通話會被干擾,跟數位化的導航系統,是完全無關的。

從工作原理來看,只需要將手機切換到飛航模式,不要發射電磁波,其實是完全不會有干擾問題的。大部分的國家,規定都已經修正成只需要切換到飛航模式。不過,一切請依照當地的法律,聽從空服員的指示,一定不會出問題。

難道我可以用我的任天堂3DS來綁架這架飛機?

當然不行。

為什麼飛機不會干擾到我的手機?
其他手機也不會干擾到我的手機?

移動電話目前使用的技術,自從第二代(Second Generation, 2G, GSM)之後,全部是使用”數位式”的通訊技術。數位式的通訊技術的特性,因為聲波已經預先被轉換成0或是1的數字,只要干擾的信號,不會造成0或是1的數字的辨識錯誤,或是數字可修復,完全不會有聲音內容錯誤(干擾)的問題。

我上次忘了關機,最後也沒事啊!

這些”達達達”的干擾聲音,一般駕駛員,的確可以透過重複、或是覆誦的方式,來確認塔臺的指令已經正確收到,因此,我們的確幾乎沒有聽過,真的因為通訊干擾,而直接造成飛安危害的事故。但是,駕駛員在飛機起降過程,其實都是非常忙碌的,少部分人為了自己的方便,造成駕駛員的分心,真的不是聰明的做法。

另外,飛機即使已經降落到地面了,塔臺還是有可能要透過類比系統,來告知駕駛員,必需改換滑行道、停機閘門,等等。請務必等到飛機已經停到停機閘門,完全靜止不動了以後,再將手機從飛航模式,切換回正常模式。


One more thing…

通常飛機距離最接近的移動電話基地台,都還有非常遠的距離。如果在飛機上面,直接連接通訊,一來需要浪費大量的手機電力來發射信號,同時,因為好幾百人的手機同時登入基地台,即使信號強度不是問題,登入所要花的時間,一定也都是平常的好幾倍。

我自己的習慣是,進到航站大樓內,剛從飛機下來的乘客比較稀少的區域,我才切換到正常模式,來減少手機電力的浪費,和等待的時間。給大家參考!

吉野櫻。
玉淵潭公園,中國北京市


2019-02-14

Google即將停止Google+的服務

大家好!我是洪李吉。大家應該已經知道,Google即將停止Google plus服務。如果您是來自於Google+找到我的「Cisco學習資訊分享」網站,或者是您透過Google+訂閱這個網站的話,我建議,將訂閱方式,儘快修改成我下面的建議:Twitter、Facebook、或是Email其中之一。


Twitter

Twitter服務是我認為最接近於Google+的服務。未來我會將原本打算張貼在Google+的內容,全部改在Twitter這裡發布。

如果您本身就使用Twitter,歡迎您直接跟隨(Follow)我的帳號:@hongliji
https://twitter.com/hongliji

即使您沒有使用Twitter,我也建議您將Twitter網址加成書籤,偶爾過來逛逛。大致上,「Cisco學習資訊分享」網站內,只會有我自己寫的內容。但是,如果我發現其他作者好的、有趣的內容作品,我會在Twitter這裡分享。

Facebook

接下來是Facebook。老實說,我目前還是不確定,我應該如何經營Facebook。如果您已經是Facebook重度使用者,我建議可以直接按讚、追蹤「Cisco學習資訊分享」專頁:
https://www.facebook.com/showipprotocols.tw

我目前的計畫是,這裡張貼的內容,將和Twitter同步。

Email訂閱

最後是Email訂閱。Email訂閱一直是我最推薦的方式。透過Email訂閱,您不會漏掉我發布的任何一篇文章內容。我知道現在不流行收看Email,但是Email服務我依然會持續提供。請點開下面連結,完成Email訂閱。提醒您,我的訂閱服務是寄存在FeedBurner。
http://feedburner.google.com/fb/a/mailverify?uri=GsCiscoClassroom&loc=en_US


One more thing…

Google即將停止Google+的服務,的確讓我感到很意外。網路界不變的定律,就是網路的技術和知識,將會持續的不停的改良和改變。未來「Cisco學習資訊分享」網站,也將會持續不停的改良和改變。希望這個網站的內容,能夠不停的帶給大家有用的資訊!

我在沙燕橋上,往沙田公園、瀝源橋方向拍攝。畫面中的橋,就是瀝源橋。


2018-08-06

病毒爆發時,網路團隊可以幫什麼忙?

我從網路新聞得知,台灣的台積電公司,受到病毒的攻擊。我花了一些時間研究這個事件。以下是我目前的心得。

我目前的理解


我從已經公告的內容理解,這個病毒爆發事件,在台灣時間八月三日星期五晚上開始爆發。台灣時間八月五日星期日公告發布的當天,已經控制(contained)病毒感染範圍,同時找到解決方案,同一天的下午兩點為止,受影響的機台80%已經恢復正常。預計八月六日完全恢復。目前(台灣時間八月六日晚上十點)為止,我還沒有看到完全恢復的公告。

病毒的感染來源是「新機台在安裝軟體的過程中操作失誤」,病毒在「新機台連接到公司內部電腦網路時發生病毒擴散」。破壞範圍並不包含公司核心資料,「公司資料的完整性和機密資訊皆未受到影響」。

從以上公開資訊,我判斷,並不是因為網路硬體的缺陷,讓病毒進入後爆發。病毒攻擊感染的對象,是用戶或是伺服器的主機作業系統。


網路團隊可以協助


回到我原本的主題。單純從網路系統出發,面對這種病毒攻擊事件,我認為網路團隊至少可以提供下面這幾種協助。同時,我也舉出一些可能的檢查點,也許其他的企業,可以同時作自我檢視。

攻擊偵測和分析(Detection and Analysis)


當網路系統觀察到不正常的流量和可疑的封包,可以提早告警。

透過網路擴散的病毒攻擊,一定會在正常的網路流量之外,產生不正常的流量或是封包。

如果我們平常就觀察記錄正常流量的基線(Baseline),要察覺出流量數值開始偏離正常值,應該不困難。

要取得這些流量數據,我們將會需要SNMP和NetFlow。我們企業的網路系統,是否已經具備這個功能了呢?是否可以自動抓取,自動保存至少最近三個月的數據呢?

病毒開始擴散的時候,很可能會丟出不少的探測封包,標定哪些主機是可以被攻擊的。因此不合理的探測封包來源的出現的時候,例如ARP封包、廣播封包、ICMP、TCP/UDP Port Scanning,我們可以合理的懷疑這些封包來源有問題。

我們自己企業網路裡面,是否可以判別這些異常封包的活動?可以抓出來源嗎?能夠紀錄不正常來源的網路埠、MAC地址、IP地址等資訊嗎?

遏制(Containment)


網路系統可以啟動包圍、遏制攻擊活動,控制受影響範圍。

當其他團隊確認中毒的主機是哪幾部之後,我們是否可以立刻知道,這些主機有可能和哪些其他主機相連通嗎?可以透過防火牆、路由表、存取控制清單(ACL),立刻隔離它們的網路連通嗎?

最少,我們應該要能夠知道,這些產生封包的來源,到底接在哪一個網路硬體的網路埠上,我們可以快速關閉這些網路埠,而且,關閉了這些網路埠之後,不應該斷開對於這個網路硬體的管理功能。

復原(Recovery)


網路系統可以提供頻寬和優先順序,縮短復原的時間。

當主機要進行修復的時候,應該會需要將備份的資料、作業系統映像檔案,也就是大量的數據封包,傳送到受損的主機。我們的企業網路,是否容量規劃上足夠承載這種大規模的復原流量嗎?在共用網路埠上,能夠區分封包的優先順序嗎?


以上是我個人的觀察和建議的檢查點。我相信,台積電這種規模的公司,肯定將迅速的從這個事件中復原。

日本東京,「お台場海浜公園」回頭看富士電視台

One more thing…


檢疫隔離(Quarantine)這個字的來源,其實就是義大利語的「40天」。也就是說,對於不知道是否帶有傳染病毒的來源,我們先將他們隔離至少40天,如果在這個時間內,沒有看到病毒的傳染,代表我們可以放心,這個來源應該是不帶傳染性的。

這個簡單的做法,面對未知的電腦病毒,我認為也有幫助。當不確定是否乾淨的未知系統,要接入生產網路之前,也許先接上一個虛擬的世界:裡面有Internet、各種電腦、網路硬體、等等。我們先觀察記錄它的行為,也許不需要到40天。如果被發現有疑似攻擊的行為,我們就可以先採取各種預防的步驟了。

我是洪李吉。希望我的心得整理,對於各位都有幫助。歡迎大家留言,聊一聊您對於這個事件的看法喔!


2018-07-23

停止支援的路由器,讓銀行損失近百萬美金

這幾天我在ITHOME看到這則新聞。因為這則新聞,和路由器有關,我自己花了一些時間去深入理解。

我目前的理解


受害的銀行,是俄羅斯的PIR Bank。有嫌疑的駭客集團是MoneyTaker。事件發生過後,PIR Bank 請Group-IB公司進行入侵事件後的修復和調查。目前Group-IB已公開的資訊指出,駭客是透過停止支援的路由器的漏洞進入。駭客的步驟細節尚未公開。

PIR Bank的路由器的型號是 Cisco 800系列路由器。這款路由器的軟硬體,已經在2016年停止支援。作業系統版本是Cisco IOS 12.4.

我的解讀


這些路由器,我判斷,應該是連接在Internet上面的VPN路由器。如果是封閉在內部網路的路由器,駭客必須穿過好多道防火牆才到的了路由器。假設駭客都能穿過防火牆了,當然也不需要透過路由器的缺陷。

VPN加密的保護協定,應該就是IPSec,在這個事件中,本身並沒有被發現缺陷。有缺陷的是路由器軟硬體。駭客應該是透過了Cisco IOS的缺陷,例如針對某個缺陷,作「零時差攻擊」(Zero-day Exploit),控制了路由器之後,將路由器當成攻擊跳板,或是開後門讓駭客從 Internet 進入到內部網路中。

這個事件的責任,主要也不在於Cisco,因為Cisco已經公告停止支援了。客戶如果硬要使用停止支援的路由器,客戶需要承擔大部分的風險。

好可惜!所損失的一百萬美金,足夠買好多好多全新的路由器了。

我給企業的建議

立刻盤點現有的路由器,尤其是連結到、暴露在Internet上面的。立刻跟硬體供應商確認,哪些路由器已經停止支援的,或者是即將停止支援的,應該立刻、儘快更換。仍然有支援的路由器,需要逐一確認,上面的作業系統已經是最新修補過的版本。銀杏大道(イチョウ並木),日本北海道大學

One More Thing…


我建議大家不需要對於Internet VPN架構,或是IPSec協定,有任何恐慌。事實上,好多的網路新架構,例如軟體定義廣域網(Software-defined Wide Area Network, SD WAN),也都是基於Internet VPN和IPSec這樣的技術。

只要能夠確保這些路由器隨時維持在最健康的狀態,軟體需要更新就隨時更新,硬體需要更換就隨時更換,Internet VPN架構還是一個同時能夠降低成本,和提升部署彈性的,企業內部智慧型廣域網路的方案。


2018-04-25

駭客竊取MyEtherWallet網站用戶乙太幣事件過程整理

我在ITHOME得知這個事件。綜合Doug Madory,還有Louis Poinsignon的這兩篇文章,我來整理發生了什麼事。

「中島公園」的秋意濃
日本札幌市
【駭客的目標】

駭客想要欺騙MyEtherWallet.com網站的用戶,改連接到駭客另外準備好的網站。我用瀏覽器作為例子,當不知情的用戶,瀏覽器網址列輸入「MyEtherWallet.com」打開的時候,會以為連接到官方的伺服器。實際上,連線到駭客自己準備好了的伺服器。

另外一個背景資訊是,MyEtherWallet.com網站的服務,是架設在Amazon AWS雲運算服務上面的。他們DNS的地址解析,也是直接租用Amazon AWS上面的 Route 53服務。


【什麼是Amazon Route 53?】

對於一般的用戶來說,Amazon Route 53就是DNS解析服務。但是對於網站業者來說,Route 53是一個智慧型的DNS解析服務。網站伺服器通常都分布在全世界各地。Route 53能夠動態地針對目前各網站伺服器的負載、是否在線的狀態,或是所指定好的規則,針對不同的用戶端DNS請求,回應不同的IP地址。簡單的說,就是Amazon所提供的,全世界都可連接的負載均衡(Global Server Load-balancing)服務。

補充一個背景資訊,提供Amazon Route 53服務的伺服器本身的主要公開IP地址,是包含在下面這五個公開地址段裡面。

205.251.192.0/24205.251.193.0/24205.251.195.0/24205.251.197.0/24205.251.199.0/24
換句話說,任何用戶的電腦,在解析MyEtherWallet.com的時候,都會向這五個地址段裡面的DNS伺服器,發出DNS解析請求封包。

【BGP協議快速回顧】

BGP協議所執行的工作,就是網路業者內部、或不同業者和業者之間的網路硬體,來交談和探知不同的IP地址段(IP Prefix),分別由那些網路業者所擁有。

這個IP地址段誰擁有的資訊,可以讓網路業者的網路硬體,知道不同目的地地址的封包,應該分別往哪個下一站送出。簡單地說,例如網路業者A宣稱擁有IP地址段X,所有參與BGP協議的網路硬體,都會將封包往趨近業者A的方向送出。

因此,如果這個資訊是錯誤的,封包就會被往錯誤的方向送出。

【駭客做了什麼】

駭客想辦法讓美國eNet這家網際網路業者,透過BGP協議,偽冒Amazon的身分,宣稱擁有前面提到的Amazon Route 53的五個IP地址段的路由資訊。換句話說,受害用戶的解析DNS請求,會改成往eNet這家業者的網路送出。

我的判斷,eNet業者網路裡面,一定也存在駭客準備好的DNS解析伺服器,IP地址剛好就設定成前面提到的五個地址段內的地址,因此,這些伺服器,可以攔截到受害用戶的DNS解析請求。當然,駭客伺服器回應的解析結果,就是駭客自己準備好了的網站伺服器IP地址。目前已知,這些駭客準備好的網站伺服器,都不在美國國內。

另外,只要相信了eNet所宣稱資訊的其他業者,他們的網路用戶,只要打開MyEtherWallet.com網址,受害的結果都是一樣的。

因此,駭客的確達到他們設計的目標。


One more thing…

雖然還沒有足夠證據明確指控,我幾乎可以確定,駭客已經差不多控制了 eNet這個網路業者。不只是能夠產生偽冒的BGP資訊,同時還在eNet網路內部植入了有問題的DNS名稱解析服務。因此,選擇足夠安全的網際網路業者,其實遠比想像中重要。

另外,MyEtherWallet.com雖然租用了Amazon.com的各種服務,整個駭客的過程,其實都跟Amazon無關。封包根本就還沒有進入Amazon,就被往駭客的DNS服務送過去。


2017-05-16

顯示Windows 10上面儲存的 Wireless LAN 密碼

一般家用型的Wireless LAN (我後面一律稱為 Wi-Fi),上面所設定的密碼,在設定完家用的Windows PC,可以正常連線之後,時間久了,我們經常會忘記這組密碼。如果我們不打算重置密碼,想要從設定好了的Windows上面,找回這組密碼,應該如何做呢?



我找到了這篇文章。

How to Find the Wi-Fi Password of your Current Network

結論就是,只要在Windows 10裡面打開一個CMD窗,輸入下面命令:


netsh wlan show profile name=SSID key=clear | findstr "金鑰內容"


其中,請將SSID更換成您的Wi-Fi網路名稱(Service Set Identifier, SSID)。

參考截圖:

C:\netsh wlan show profile name=SSID key=clear

介面 Wi-Fi 上的設定檔 SSID:
=======================================================================

已套用: 所有使用者設定檔

設定檔資訊
-------------------
    版本                   : 1
    類型                   : 無線區域網路
    名稱                   : SSID
    控制選項        :
        連線模式           : 自動連線
        網路廣播           : 只有此網路正在廣播時才連線
        AutoSwitch         :不切換到其他網路
 ...


2017-05-04

從交換器上,如何用命令找到虛擬機器接在哪裡?

當我們觀察到,一個網路交換器的物理埠上面,學習到多重的MAC地址的時候,這個物理埠,有可能是連接到了另一套網路交換器,或者是,連接到了一個包含多重虛擬機器(Virtual Machine)的物理伺服器(Hypervisor)。

如果我們能夠直接透過簡單的命令,找到哪些物理埠,跟虛擬機器有關,尤其是連接PC或是伺服器的埠,我們可以馬上指出來,哪些PC、伺服器上面,的確有虛擬機器的存在。這對我們數據中心的管理,將會是很有幫助的。
我之前找到了一個Microsoft TechNet網站上面的資訊,內容是將常用的、預設分配給虛擬機器的MAC地址範圍的組織識別碼(Organizationally Unique Identifier, OUI)號碼,整理成一個對應表。其中,包含VMware、Xen、還有Microsoft。

Microsoft Technet: How to Set the Static MAC Address Range for Virtual Network Devices

Reserved For Prefixes VMware 00:05:6900:0C:2900:1C:1400:50:56 Microsoft 00:03:FF00:0D:3A00:12:5A00:15:5D00:17:FA00:1D:D800:50:F2 XenSource 00:16:3E
有了這個對照表之後,我們很容易就可以用命令,找出包含虛擬機器的物理埠。使用的命令很簡單,其實就是 “show mac-address-table interface”。
我們看第一個例子。
Switch# show mac-address-table interface f0/1Vlan Mac Address Type Ports---- ----------- -------- -----100 0015.5dXX.YYYY DYNAMIC Fa0/1100 0015.5dXX.ZZZZ DYNAMIC Fa0/1Total Mac Addresses for this criterion: 2Switch#
根據以上的截圖,我們幾乎可以確定,FastEthernet0/1其實所連結的,是一套Microsoft Hyper-V的伺服器。
我們還可以將命令做一點點的修改。例如,”show mac-address-table | include 0015.5d”。我們現在可以列出這個交換器,上面所有的Hyper-V伺服器裡面,虛擬機器的清單。例如下面第二個例子。
Switch# show mac-address-table interface | include 0015.5d100 0015.5dXX.YYYY DYNAMIC Fa0/1100 0015.5dXX.ZZZZ DYNAMIC Fa0/1200 0015.5dWW.YYYY DYNAMIC Fa0/3200 0015.5dWW.ZZZZ DYNAMIC Fa0/4Switch#

One more thing…
我另外找到,一般在KVM上面,預設的MAC地址範圍是:
QEMU's registered OUI (52:54:00)
合併到前面的表格。新的表格如下:
Reserved For Prefixes VMware 00:05:6900:0C:2900:1C:1400:50:56 Microsoft 00:03:FF00:0D:3A00:


2017-04-27

Google的公開NTP網路校時伺服器


我剛才在讀網路文章的時候,我才發現,原來Google也有對外服務的NTP伺服器,網址分別有五個:

TIME.google.com
TIME1.google.com
TIME2.google.com
TIME3.google.com
TIME4.google.com

相較於我過去經常使用的,台灣政府的「國家時間與頻率標準實驗室」的公開服務網址:

TICK.stdtime.gov.tw
TOCK.stdtime.gov.tw

Google的網址稍微短一點點。

兩個都分享給大家,希望對於大家找NTP Server設定的時候有所幫助。


One more thing…

我們在Cisco路由器上面,如果要檢查NTP Server是否可以校時,我們通常直接使用命令:

ntp server time.google.com

之後,再使用 show ntp associations 來檢查。

如果是 Linux上面呢? 我找到一個簡單的命令。

sntp time.google.com

只要出現類似下面的輸出,就代表NTP Server有回應。

2016-12-01 15:03:12.433437 (+0000) -0.000011 +/- 0.001587 secs


【外部參考資料】
Configuring Clients  |  Public NTP  |  Google DevelopersGoogle Cloud Platform Blog: Making every (leap) second count with our new public NTP servers台灣國家時間與頻率標準實驗室,時間網站

中國北京市國貿LeCool溜冰場在這裡:



我是文章作者洪李吉。歡迎大家在下方留言,也歡迎大家分享本網站「Cisco學習資訊分享」的內容!


2017-04-26

海底光纜,如何安裝和施工?

有關海底光纜,如何安裝和施工,我找到了這個動畫影片。同樣是由專門做海纜安裝和施工的美國公司(TE SubCom),所製作的動畫影片。我將影片中所提到的關鍵步驟,翻譯成國語,加上我自己的註解,希望能夠解答大家的疑惑。


海纜登陸機房。(0:08)海纜安裝母船停到適合登陸的海岸邊,準備海纜直接登陸。(0:15)開始做海岸端的海纜登陸,利用接駁艇等工具,將海纜從安裝船拉到岸上。(0:21)海纜安裝船,開始放置主海纜。(0:33)海纜安裝船,放出海底挖溝器(Sea Plow),在海床上挖溝、埋海纜、回填、壓平。(0:45)必要時,熔接海纜中繼器,連接兩段海纜,和海纜一起投放。(1:09)如果遇到海纜交會點,海底挖溝器拉起,越過海纜交會點。(1:27)海纜埋設結束後的末端,收回海底挖溝器。(1:45)投入Remotely operated vehicle (ROV)到海床,做安裝後的海纜檢查和埋設。(2:00)ROV在海纜交會點,會做特殊的回填操作。(2:14)

影片中沒有解釋如何作,我只能確定,施工必須很小心,不能破壞既有的海纜,同時能將新的海纜保護好。
施工的同時,海纜安裝船,需要讓海纜鬆弛不會太緊,來確保海纜能沿著海床的形狀,服貼在海床上面。(2:34)

One more thing…
海底光纜的安裝和施工,是一個龐大的工程。除了需要準備登陸點的機房,好長好長的海纜本體、中繼器、還有各種施工的船、機器、設備,和複雜的施工步驟,才能完成安裝。

中繼器其實是和海纜一起埋到海底的。因此,中繼器本身的電力,一定是來自於海底光纜本身。我看到一些資訊,海纜本身,同時包含提供電力的銅纜。另外,因為電力要穿越這麼長的距離,肯定電壓一定是很高很高。我們一般人,最好遠離海纜,除了保護海纜,也保護我們自己的安全。

盛開中的吉野櫻
玉淵潭公園,中國北京市


2017-04-25

海底光纜障礙,是如何修復的?

最近(2017/4/22)服務台灣的APCN2海底光纜,發生了障礙,造成台灣往日本、歐洲、美國的網際網路,速度變得特別慢。新聞上提到,需要海纜修復船來修復,可能要花上一個月的時間才能完全修復。

我相信大家一定跟我一樣,很想要知道,海纜如果真的有障礙的話,修復船是如何修復海纜的。我找到這個影片,是由一家專門做海纜安裝和施工的美國公司(TE SubCom),所製作的動畫影片。我將影片中所提到的關鍵修復步驟,翻譯成國語,加上我自己的註解,希望能夠解答大家的疑惑。

海纜為何會障礙

大部分應該都是人為的,例如被拖曳中的漁網扯斷。少部分是海裡的動物啃咬,例如鯊魚。

如何找到障礙點

利用「光時域反射儀」(Optical Time-domain Reflectometer, 簡稱OTDR),可以找到障礙點距離已知地點的海纜長度,再從海纜路線圖標定近似位置。

影片中的修復步驟
放出剪斷海纜專用的抓鉤,將有障礙的海纜切成兩段。我分別稱為A端和B端。 (0:23)放出抓取海纜專用的抓鉤,將剪斷後的舊A端抓住。 (0:37)抓住舊A端後,拉到海纜修復船的船上。 (0:50)用浮標固定好這一端,放回海上 。(0:56)放出抓住海纜專用的抓鉤,將剪斷後的舊B端抓住。 (1:42)抓住舊B端後,拉到海纜修復船甲板上面的接合工作區。 (2:02)第一次熔接:替換用的備料光纜,一端跟B端接上。(2:11)

我判斷,這個步驟之前,應該需要做肉眼或工具檢查,將有問題的海纜切掉,變成新的B端後,再接上備料光纜。
熔接套件:MCJA。 (2:53)修復船開始往舊A端的浮標前進,同時將熔接完成的舊海纜B端加上備料替換海纜,放回到海床。(3:07)修復船找到浮標,還有舊海纜的A端。(3:16)修復船動態調整位置。我相信,這個步驟是要調整海纜長度,不會太鬆或太緊。(3:31)將舊A端熔接到替換用的備料光纜的另外一端。(4:32)一樣使用熔接套件:MCJA。(4:42)將熔接好的舊A端和替換用的備料光纜,重新放回海床。(4:53)釋放修復後的海纜。(5:07)

One more thing…

從影片裡面,我們可以發現,沒有海纜修復船,基本上無法做任何修復的操作。海纜修復船全球並沒有很多艘,光是將修復船開過來,肯定要花上好幾天的時間。因此,海纜修復時間一定是很長很長的。

也就是說,海底光纜的建置,一定要做多線路的同時備援。

另外,我們也知道,熔接過後的光纖,一定會增加能量的損耗。當修復熔接次數超過某個數字,整條的光纖就會不堪使用了。

這說明了,海纜是壽命有限的,需要定時安裝新的海纜來替換。

玉淵潭公園,盛開的櫻花,和背後的中國中央廣播電視塔。
中國北京市


2017-04-03

清除Cisco MDS上面的允許VSAN清單

有一位朋友問到一個好問題,Cisco MDS FibreChannel (FC)交換器,”switchport trunk allowed vsan all” 命令會有什麼效果呢?到底是目前的VSAN全部允許,還是包括未來的VSAN全部都允許呢? 盛開中的櫻花
櫻花園,玉淵潭公園。中國北京市
我試著去找文件,但是我發現,沒有任何Cisco官方文件明確描述這個命令的效果。因此,我在實驗區的Cisco MDS 9148做幾個測試。我發現,結論如下: 
如果要清除允許的VSAN清單,同時允許所有的VSAN,也包含未來定義的VSAN,只需要使用這個命令:在interface模式下“switchport trunk allowed vsan all”命令。
如果要清除允許的VSAN清單,同時不允許所有的VSAN,也包含未來定義的VSAN,只需要使用這個命令:在interface模式下“no switchport trunk allowed vsan all”。
如果不是以上兩者,請直接使用 “switchport trunk allowed vsan” 或者是“switchport trunk allowed vsan add” 命令來編輯允許的VSAN清單。

One more thing…
如果要編輯允許的VSAN清單,先使用“switchport trunk allowed vsan” 命令,然後再使用 “switchport trunk allowed vsan add” 命令。
在生產網路上,記得總是維護允許的VSAN清單,而不是使用預設的行為:允許全部的VSAN。因為,萬一不小心打錯字,錯誤地創建了不需要的VSAN,很有可能會衝擊到生產網路的效能。


2017-03-22

Cisco IOS/IOS XE弱點,需要立刻關閉TELNET

今天的內容很短,我只是要提醒大家,Cisco這幾天公告了一個存在Cisco IOS和IOS XE作業系統的弱點。簡單的解決方法,就是將往路由器方向的TELNET服務關閉。如果需要遠端管理,請改成沒有這個弱點的Secure Shell (SSH)。

櫻洲上面的櫻花。中國南京市的玄武湖


詳細技術細節,請參閱原始公告內容。

Cisco IOS and IOS XE Software Cluster Management Protocol Remote Code Execution Vulnerability

One more thing…

關閉TELNET服務的命令,同時打開SSH:

transport input ssh

如果要雙重確認,可以檢查作業系統等待的埠 (Listening Ports):

show control-plane host open-ports
show tcp brief


2016-12-14

AS-PATH就是BGP資訊(乘客)的簽到記錄

這一篇文章的內容,我們花一點時間仔細觀察,AS-PATH這個路徑屬性,在BGP協定裏面,扮演那一種腳色。



BGP的距離向量(Distance Vector)行為

BGP協定的設計,有一個很有趣的特色。每一家公司,無論公司內部的路由器包含幾套,公司內部的網路有多複雜,在BGP協定裏面,都只當成是一跳、一站(One hop)。

BGP協定,完全保留著距離向量(Distance Vector)門派的協定分類的特性。換句話說,我這家公司所有知道的可能的IP網路目的地網段(NLRI),他們在BGP資訊庫裡面的冠軍(最佳路由資訊),我全部都會分享給我的鄰接路由器。這種行為,正好就是距離向量門派的「武功心法」。


BGP防止路由資訊重複複製(Routing Loop)的內建機制

我一提到距離向量,我相信不少朋友,馬上就會聯想到,那個古老的Routing Information Protocol (RIP)協定。舊版CCNA教材花了好大的篇幅,來解釋RIP路由資訊重複複製(Routing Loop)的動態,這個問題,BGP會不會遇到呢?

當然會遇到,因為複製的路徑隨便繞著環狀拓樸繞個一圈,一定走會回來,「相遇會中」。但是需不需要擔心,不需要。因為,BGP的作者,想到了好辦法。

BGP作者的好辦法,其實很簡單。

每一次資訊(乘客)在離開我這一家公司,複製給鄰接路由器的時候,我就將我公司的統一編號(ASN),簽名簽在資訊上面。簽在哪裡,就是每一筆資訊(乘客)的AS-PATH這個路徑屬性上面。當然,這個簽到表的長度,肯定會越來越長。但是每一家公司,在檢查鄰居複製進來的BGP資訊(乘客),只要在簽到表上面,看到我自己的名字(ASN),我就知道,這個資訊(乘客),曾經經過我這裡複製出去。這當然代表,這一筆資訊就是被重複複製過的。我可以直接刪除掉。

因此,在跨公司的BGP協定(EBGP),有了這一個內建的機制,我們完全不需要擔心任何路由資訊重複複製的困擾。


AS-PATH只保護EBGP

等等,那如果鄰接的路由器,都是同一家公司的,也就是內部BGP鄰接關係(IBGP),還需不需要簽到?還需不需要檢查AS-PATH?

我先說結論:兩個問題的答案都是「不需要」。複製的規則,和避開路由資訊重複複製的機制,內部BGP協定(IBGP)的設計完全是不一樣的。我們下一篇再討論。


One more thing…

從以上的討論,我們發現,路由器必須要將鄰居送過來的Internet超過五十萬筆的BGP資訊,一筆一筆檢查,AS-PATH有沒有我們曾經簽到過的紀錄。感覺起來,肯定要花上不少時間來檢查。

沒錯,BGP協定,設計的目標,完全就不是為了讓交換速度加快的協定。我常常用這個類比,來說明BGP慢速度的感覺。

OSPF這一類的協定,就像是高速戰鬥機,反應速度很快,最高速度可以超音速,但是,一趟只能載送一個人(相對較少的數千筆資訊乘客)。

BGP這一類的行定,就像是噴射客機一樣,反應速度相對很慢、最高速度也遠低於音速,但是,一趟可以載送好幾百位乘客(超過五十萬筆的資訊乘客)。

至於我們前面提到的RIP這個失聯很久的協定,延續前面的類比,就像是練習用的飛行教練機。速度更慢,唯一的好處,是讓學員可以觀察得到,路由資訊重複複製的問題,和錯誤過程的重現。除了訓練用途之外,應該不會有航空公司,會用教練機來載乘客的。這也正是在生產網路上,我們不應該再使用RIP協定的主要原因。

A peaceful place for myself.
Botanic Gardens, Saint Vincent and the Grenadines





以上照片,都在下面這個地點附近拍攝的。

我是文章作者洪李吉。歡迎大家在下方留言,也歡迎大家分享本網站「Cisco學習資訊分享」的內容!


2016-10-31

BGP載送的資訊(乘客),包含哪些?

一樣的,我這篇文章的目的,不是來取代Cisco BGP官方教材。原則上教材找得到的,我這裡就不重複了。


我們先從IPv4 Unicast開始,最早最早,BGP也只支援IPv4 Unicast。

從IPv4 Unicast單播的世界開始討論

當BGP設定好以後,協定所載送的資訊(乘客),很容易找到。只要執行 “show ip bgp”命令,所顯示出來的,就是目前BGP協定所維護的BGP資訊庫,也就是所有的BGP資訊的集合。

BGP資訊(乘客)的集合,我故意用「BGP資訊庫」來稱呼,和其他人的習慣不同。我知道有些教材或文件,稱為BGP路由表。為了避免讓大家和IP網路層的路由表(show ip route的輸出),有所混淆,我這裡不採用這個名詞。

每一筆BGP資訊,就是一筆使用中的IPv4單播目的地網段的資訊描述。

大致上,BGP資訊庫中,每一筆的BGP資訊,包含兩個部分。


(NLRI, Path Attributes)


乘客欄位一,Network Layer Reachability Information (NLRI)

我先不翻譯,這是IETF的用詞,簡單地說,就是IPv4目的地網段。例如,168.95.0.0/16。我們經常會聽到,目前的IPv4全球網段數目,超過500,000筆,所指的就是,所有可能的IPv4目的地網段,也就是所有可能的NLRI使用中的組合,超過五十萬個。

IETF稱呼這個欄位為泛用的名詞NLRI,我認為很有道理。馬上我們就會討論到這點。


乘客欄位二,Path Attributes,路徑屬性集合

教材裡面都看得到的,例如NEXT_HOP、AS-PATH、Origin、Local Preference等等。有了路徑屬性集合,路由器軟體才能針對BGP資訊庫來做過濾、篩選、內容調整、和檢查等等。

我這裡只解釋NEXT_HOP,其他的我留給教材。

NEXT_HOP欄位,是一個IPv4地址,會直接出現在IP網路層路由表 (show ip route所印出)的 “via” 後面,意思是經由哪一個IPv4地址,可以到達這個NLRI。在BGP協定的世界裡,NEXT_HOP幾乎都”不是”本地路由器的直接相接的網段,因此,NEXT_HOP還要再做遞迴回頭查詢IP網路層路由表,才能知道,真正直接相接的相鄰地址,到底是哪一個。

給定任何一個單播的目的地(NLRI),如果有很多BGP資訊,都告訴我們如何到達,那麼,只有”最好”的那一筆,他的NEXT_HOP才會進到IP網路層的路由表,當然NLRI就是目的地網段。如何選擇 “最好”,是BGP複雜的另一個主題,教材裡面有,Cisco也在網站上整理成13大規則 “BGP Best Path Selection Algorithm”,我這裡先不重複。

為何我只介紹 NEXT_HOP?因為,NEXT_HOP就是冠軍 (“最好”) 的獎盃,只有冠軍的NEXT_HOP,才會變成 “show ip route” 真正的 Via。

等等,只有這樣嗎?教材通常都寫得很複雜,簡單分類之後,真的只有這樣。


One more thing…

IPv4單播的世界以外,BGP協定必須要被擴充,新的協定,稱為Multiprotocol BGP (MBGP)。這個擴充協定,從名稱看起來很複雜,但是,如果從乘客資訊來看,並沒有想像中複雜。

MBGP所修改的欄位,只有NLRI,和NEXT_HOP。例如IPv6單播的世界,如果也用BGP來載送資訊,IPv6的目的的網段,改編碼成新的NLRI,同時NEXT_HOP改編成IPv6地址。其他完全不變!

例如是MPLS VPN的世界,NLRI所編碼的,除了VPN內部的目的地IPv4/IPv6網段之外,再加上Route Distingusher(RD),和VPN標籤。NEXT_HOP變成VPN內部的IPv4/IPv6地址。其他也都完全不變!


我和太湖第一次的接觸。
中國,無錫市



這篇文章中出現的照片,都是在下方的地圖附近,所拍攝的。


2016-10-26

BGP鄰接關係


BGP協定,工作原理其實並不難理解。BGP複雜的是,有好多名詞需要解釋,需要定義清楚,還有過濾工具種類非常多等等。標準的Cisco BGP訓練課程,需要五天完整的解說和練習,才能夠走完一次。

我寫這些文章的目的,不是用來取代Cisco的標準課程。我只是想要減低大家的BGP學習進入障礙,讓大家都可以快速上手BGP協定。



ASN號碼和內、外分別

Autonomous System Number (ASN) 直接翻譯,是”自治系統識別號碼”。自治系統,其實只是IETF所採用的廣泛概括性名詞,一個自治系統,可以是一家公司、可以是一家電信業者、可以是一所學校、可以是一個非營利組織、可以是某個層級的政府。每一個這樣的組織、單位,都可以去申請一個唯一識別的號碼。因此,”自治系統” 這個詞彙,非常的中立。

這個號碼,功能非常接近於,在台灣有合法登記的公司,都會有的 “統一編號、統編”。

這個號碼,原則上都要跟IANA,或是IANA授權指定的各地理區域的註冊組織,例如,台灣屬於亞太區,ASN一律都跟APNIC申請。

如果只是做實驗練習BGP的設定,需要去申請一個這樣的號碼嗎? 其實不需要,ASN 64,512 到 65,534連續的1,023個號碼,稱為私人使用的ASN號碼(Private Use ASN),免申請,任何人都可以直接用。但是,不能用這群ASN來跟全球公共Internet網路相接。

私人使用的ASN,效果就跟RFC1918保留的IPv4地址,例如192.168.0.0/16、10.0.0.0/8、172.16.0.0/12等網段地址,完全是相同的目的。

(當然,完全封閉的網路,ASN就隨您選擇。)

確定完ASN,同一家公司的BGP路由器,ASN全部設定成完全相同的號碼。

每一部BGP路由器,只能屬於一家公司,只能指定一個ASN。因此,兩部路由器用BGP協定互相鄰接成鄰居,如果ASN相同,代表是內部的鄰接(Internal BGP,IBGP);如果ASN不相同,代表是外部的鄰接(External BGP,EBGP)。

因為BGP協定,對內部,和對外部,行為差異非常大,因此,我們必須先確定,我們BGP協定所連結的路由器之間的關係,到底是內部,還是外部。

唯一的鄰接方式,只有TCP,單播(Unicast)

是的,只有TCP。因此,完全是單播(Unicast)。

換句話說,我們沒有自動發現鄰居的機制,幫我們自動找到鄰居,例如OSPF、EIGRP這類協定的協助。全部的BGP鄰居,都必須手工一個一個定義。

這個TCP連線,不只是定義了路由器的鄰接關係,同時,也是BGP資訊唯一的運輸工具。
一個鄰接關係,就是一個運輸工具,就是一個TCP連線。

AS號碼、地址必須要配成對

當兩部BGP路由器的TCP接通的時候,軟體開始檢查這個TCP連線,下面的
四個參數配對,必須要完全一致:

本地ASN,本地TCP地址,遠端TCP地址,遠端ASN
這四個參數,只要有一個不相符,這個TCP連線就會被拒絕,鄰接的關係就不會形成。
因此,針對每一個有鄰接關係的BGP路由器,我建議用下面的設定來個別定義。

router bgp 65001
! 鄰居IPv4地址是1.2.3.4,ASN是65,002
! 本地的IPv4地址用Serial 1/0的IPv4地址,本地的ASN是65,001

  neighbor 1.2.3.4 remote-as 65002
  neighbor 1.2.3.4 update-source Serial1/0

! 鄰居 IPv6地址是 FD00::1234,ASN是65,002
! 本地的IPv6地址用Serial 1/0的IPv6地址,本地的ASN是65,001

  neighbor fd00::1234 remote-as 65002
  neighbor fd00::1234 update-source Serial1/0

只有一個注意事項,在外部BGP(EBGP)的情境下,Cisco IOS預設的BGP TCP (Time To Live, TTL)是1,也就是說,直接相接的物理埠兩端,EBGP才能接通。如果這個預設,跟您的需求不符合,應該要修改預設的TTL超過1,例如,下面的例子,將:TTL從預設的1改成255。

router bgp 65001
 neighbor 1.2.3.4 remote-as 65002
 neighbor 1.2.3.4 update-source Loopback0
 neighbor 1.2.3.4 ebgp-multihop 255

檢查BGP鄰接關係

BGP的運輸工具,必須要正常工作,BGP的資訊才有機會正常交換。因此BGP的設定和排錯,都從BGP的運輸工具開始檢查。我最喜歡用的命令是:

show ip bgp summary
show bgp ipv6 unicast summary

以上的命令顯示的是摘要。

如果要顯示鄰接關係的詳細資訊,可以用下面的命令:

show ip bgp neighbors
show bgp ipv6 unicast neighbors


One more thing…

BGP的鄰接關係是TCP當成運輸工具,因為是TCP,鄰接關係可以借道穿過很多完全沒有啟用BGP協定的路由器。這一點,跟OSPF、EIGRP等一般公司內部路由器協定(Interior Gateway Protocol, IGP)相比較,很不一樣。

這一篇我先從運輸工具開始討論。之後我再寫其他文章,討論BGP乘客資訊、資訊複製規則等等BGP特有的行為。


Cane Garden, Saint Vincent and the Grenadines.

Sunset at the Caribbean Sea
Overlooking Kingstown from Cane Garden, the south sid


2016-10-26

健康操和組播(IP Multicast)

數年前,我服務的公司忽然有了一個簡單的需求。需求背後的故事不重要,重點是,為何最後IP Multicast幫我解決了問題。


很簡單的需求

原始的需求只有這麼簡單。下午三點半,全公司七百多人,可以一起在座位的PC前面,同步收看健康操影片,每個人跟著影片中的動作,做做健康體操,增加員工的身體健康。

背景資訊:全公司七百多人,被路由器分隔在好多網段,甚至部分外部辦公室,頻寬只有E1 (2Mbps)的專線。

我一聽到以上需求的時候,我發現,我必須要解決兩個問題。


第一個問題是頻寬

七百多人,假設一個員工觀看影片,占用1Mbps,如果我還是採取單播(Unicast)的話,我在伺服器上面,就必須要提供至少700Mbps的頻寬,來播放這個影片。

當時的伺服器,雖然物理埠可以提供1,000Mbps的頻寬,我的確也可以將兩個埠做合併(Port Aggregation、EtherChannel)。但是,我沒有把握磁碟I/O是否跟得上這個速度。700Mbps遠比當時公司內部安裝在最高級硬體的Microsoft Exchange Server需求還要高。如果真的要這麼做,我需要好多部的伺服器,才能夠支撐全部的流量需求。

假設我真的要設計成多部伺服器,我的伺服器也需要增加額外的軟體,才能夠讓用戶端自動分散連結不同的伺服器,或是負載均衡的網路硬體。當時,這些額外增加的預算都不可行。

另外,外部辦公室的部分,如果使用單播,只有2Mbps頻寬的專線也不夠用。增加專線,預算上又不可行。


第二個問題是同步

不是全部的員工,都會同時打開播放軟體,假設有員工比較晚打開播放軟體,最好能夠同步地從現在的時間點開始看,而不是一律從頭開始觀看。

我們知道今天的技術,例如 YouTube Live,可以透過將影片分割成數秒鐘一段,即使只使用單播的技術,一樣可以達成類似同步的效果。可是,當年並沒有這樣的軟體。


IP Multicast解決我這兩個問題

最後,我在網路端的設計,只剩下一個選擇,那就是IP Multicast。

因為,我只要在伺服器端丟出一份的影片內容、一份的頻寬、一份的IP Multicast UDP/RTP封包,全公司的員工都可以收到。

延續前面的分析,伺服器端只需要丟出 1Mbps 左右的頻寬,全公司七百多人都可以同時收到。

路由器上面需要設定IP Multicast路由協定。所有UDP/RTP的封包,都是由中間的路由器來擔任往各網段複製封包的工作。到了VLAN裡面,就改由L2交換器擔任逐埠(per port)的封包複製。

我全部的路由器都是Cisco,因此,IP Multicast路由協定,很自然地就使用Cisco PIM (Protocol Independent Multicast)。

更好的是,封包收到的時間是完全同步的!PC端的軟體,不論何時打開軟體,都可以同步播出影片的內容。



One more thing…

因為沒有其他的預算,伺服器端我用既有的Windows Server (當時是Server 2003)的Windows Media Service,用戶端就只使用Windows Media Player。影片原始檔案是MPEG-1,我用Windows免費軟體轉換成 Windows Media的影片格式。

從網路的角度來看,UDP/RTP的封包,幾乎都是同時抵達用戶端的,可是我真正走到不同的座位觀察才發現,因為用戶端PC的硬體新舊、規格不一致,每一部PC真正開始緩存內容、播放,竟然有數秒鐘的時間差異,即使接在完全相同VLAN、交換器的PC。

我當時的同事,幫我想到一個辦法,讓全公司的人都有一致的音樂節奏可以做體操。方法是每個辦公室找一部PC一樣打開收聽IP Multicast,將影片中的聲音,接到各辦公室內的擴音(聲音廣播)系統,播放給整個辦公室聽。雖然PC上面的畫面有幾秒鐘的不一致,因為影片都是每天重複的,只要廣播的聲音是同步的,同事們覺得可以接受畫面的幾秒鐘的差異。

如果大家未來有類似的需求,IP Multicast將是您的好工具。我從這個故事也學習到,不是全部的問題,都可以用技術方法來解決,需要大家一起合作,一起發揮創意啊!

Fort Charlotte, Saint Vincent & the Grenadines



本文的照片,都是在這裡拍攝的。