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 Cloud CCNA Collaboration CCNA Cyber Ops CCNA Data Center CCDA CCNA Industrial CCNA Routing and Switching CCNA Security CCNA Service Provider CCNA 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

大家好！我是洪李吉。大家應該已經知道，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學習資訊分享」網站，也將會持續不停的改良和改變。希望這個網站的內容，能夠不停的帶給大家有用的資訊！ 我在沙燕橋上，往沙田公園、瀝源橋方向拍攝。畫面中的橋，就是瀝源橋。

我從網路新聞得知，台灣的台積電公司，受到病毒的攻擊。我花了一些時間研究這個事件。以下是我目前的心得。 我目前的理解 我從已經公告的內容理解，這個病毒爆發事件，在台灣時間八月三日星期五晚上開始爆發。台灣時間八月五日星期日公告發布的當天，已經控制(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天。如果被發現有疑似攻擊的行為，我們就可以先採取各種預防的步驟了。 我是洪李吉。希望我的心得整理，對於各位都有幫助。歡迎大家留言，聊一聊您對於這個事件的看法喔！

這幾天我在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架構還是一個同時能夠降低成本，和提升部署彈性的，企業內部智慧型廣域網路的方案。

我在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/24 205.251.193.0/24 205.251.195.0/24 205.251.197.0/24 205.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服務送過去。

一般家用型的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         :不切換到其他網路         MAC 隨機化         : 已停用 連線設定 ---------------------     SSID 數目              : 1     SSID 名稱              : "SSID"     網路類型               : 基礎結構     無線電波類型           : [ 任何無線電波類型 ]     廠商擴充                  : 不存在 安全性設定 -----------------     驗證                   : WPA2-Personal     加密方式               : CCMP     驗證                   : WPA2-Personal     加密方式               : 未知     安全性金鑰             : 現在     金鑰內容               : Wi-Fi密碼在這裡 成本設定 -------------     成本                   : 不受限制     壅塞                   : 否     接近資料限制           : 否     超過資料限制           : 否     漫遊                   : 否     成本來源               : 預設值 One more thing… 在我引用的來源文章裡面，其實也包含在 Linux，或者是 Mac OS上面，找之前儲存過的Wi-Fi密碼的方法或是命令。因為我手邊沒有環境驗證，大家測試出來的結果，是否可以在下面的留言區，跟我分享呢？ 我這篇文章，其實還有一個目的。 我知道有一些企業客戶的Wi-Fi密碼，是由員工手工設定固定的密碼，到來賓的PC上面，同時不讓來賓看到密碼。事實上，這個方法一點都不安全。來賓只需要讀過這篇文章，一樣可以將您以為看不到的密碼，給顯示出來的。 企業客戶，別再使用這種只求心安的密碼保護方式了！ 吉野櫻、綠柳樹、藍天、好多遊客 玉淵潭公園西門，中國北京市

在搭乘飛機的時候，每個人都會被告知手機(移動電話)必須要切換成飛航模式、或者是關機。大家也許看過了下面的這個趣味影片。我相信，每個人一定都很好奇：為什麼？ 影片中，這幾個質疑，我相信大家也很想要知道為什麼： 造價九千萬的飛機，會被我的美金四十元的iPod Shuffle所干擾？ 難道我可以用我的任天堂3DS來綁架這架飛機？ 為什麼飛機不會干擾到我的手機？ 其他手機也不會干擾到我的手機？ 我上次忘了關機，最後也沒事啊！ 國語字幕的影片，請參考這一個。 一切的恐懼，我相信都是來自於這個熟悉的聲音 (這個原本的聲音影片已經被移除，我替換成下面這個。大家可以搜尋 "GSM noise"找到類似的聲音素材) 只要當我們的手機靠近喇叭、麥克風，如果剛好又接到電話、或是簡訊的時候，一定都會聽到這個急速的、”達達達”的干擾聲音。 我在觀賞Air Crash Investigation這一系列的電視影集後，我才發現，駕駛員和塔台之間的通訊，都還是類比式系統。也就是說，只要有乘客的手機正在通訊，這樣子的 “達達達” 聲音，的確會造成駕駛員聽不到塔臺說話的內容。 造價九千萬的飛機，會被我的美金四十元的iPod Shuffle所干擾？ 只有駕駛員、塔臺之間的通話會被干擾。其他例如GPS、羅盤、飛行數據傳輸等等，因為頻率段都和手機沒有重疊，其實都不會被干擾。 只有導航用的聲音通話會被干擾，跟數位化的導航系統，是完全無關的。 從工作原理來看，只需要將手機切換到飛航模式，不要發射電磁波，其實是完全不會有干擾問題的。大部分的國家，規定都已經修正成只需要切換到飛航模式。不過，一切請依照當地的法律，聽從空服員的指示，一定不會出問題。 難道我可以用我的任天堂3DS來綁架這架飛機？ 當然不行。 為什麼飛機不會干擾到我的手機？ 其他手機也不會干擾到我的手機？ 移動電話目前使用的技術，自從第二代(Second Generation, 2G, GSM)之後，全部是使用”數位式”的通訊技術。數位式的通訊技術的特性，因為聲波已經預先被轉換成0或是1的數字，只要干擾的信號，不會造成0或是1的數字的辨識錯誤，或是數字可修復，完全不會有聲音內容錯誤(干擾)的問題。 我上次忘了關機，最後也沒事啊！ 這些”達達達”的干擾聲音，一般駕駛員，的確可以透過重複、或是覆誦的方式，來確認塔臺的指令已經正確收到，因此，我們的確幾乎沒有聽過，真的因為通訊干擾，而直接造成飛安危害的事故。但是，駕駛員在飛機起降過程，其實都是非常忙碌的，少部分人為了自己的方便，造成駕駛員的分心，真的不是聰明的做法。 另外，飛機即使已經降落到地面了，塔臺還是有可能要透過類比系統，來告知駕駛員，必需改換滑行道、停機閘門，等等。請務必等到飛機已經停到停機閘門，完全靜止不動了以後，再將手機從飛航模式，切換回正常模式。 One more thing… 通常飛機距離最接近的移動電話基地台，都還有非常遠的距離。如果在飛機上面，直接連接通訊，一來需要浪費大量的手機電力來發射信號，同時，因為好幾百人的手機同時登入基地台，即使信號強度不是問題，登入所要花的時間，一定也都是平常的好幾倍。 我自己的習慣是，進到航站大樓內，剛從飛機下來的乘客比較稀少的區域，我才切換到正常模式，來減少手機電力的浪費，和等待的時間。給大家參考！ 吉野櫻。 玉淵潭公園，中國北京市

當我們觀察到，一個網路交換器的物理埠上面，學習到多重的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:69 00:0C:29 00:1C:14 00:50:56 Microsoft 00:03:FF 00:0D:3A 00:12:5A 00:15:5D 00:17:FA 00:1D:D8 00:50:F2 XenSource 00:16:3E 有了這個對照表之後，我們很容易就可以用命令，找出包含虛擬機器的物理埠。使用的命令很簡單，其實就是 “show mac-address-table interface”。 我們看第一個例子。 Switch# show mac-address-table interface f0/1 Vlan Mac Address Type Ports ---- ----------- -------- ----- 100 0015.5dXX.YYYY DYNAMIC Fa0/1 100 0015.5dXX.ZZZZ DYNAMIC Fa0/1 Total Mac Addresses for this criterion: 2 Switch# 根據以上的截圖，我們幾乎可以確定，FastEthernet0/1其實所連結的，是一套Microsoft Hyper-V的伺服器。 我們還可以將命令做一點點的修改。例如，”show mac-address-table | include 0015.5d”。我們現在可以列出這個交換器，上面所有的Hyper-V伺服器裡面，虛擬機器的清單。例如下面第二個例子。 Switch# show mac-address-table interface | include 0015.5d 100 0015.5dXX.YYYY DYNAMIC Fa0/1 100 0015.5dXX.ZZZZ DYNAMIC Fa0/1 200 0015.5dWW.YYYY DYNAMIC Fa0/3 200 0015.5dWW.ZZZZ DYNAMIC Fa0/4 Switch# One more thing… 我另外找到，一般在KVM上面，預設的MAC地址範圍是： QEMU's registered OUI (52:54:00) 合併到前面的表格。新的表格如下： Reserved For Prefixes VMware 00:05:69 00:0C:29 00:1C:14 00:50:56 Microsoft 00:03:FF 00:0D:3A 00:12:5A 00:15:5D 00:17:FA 00:1D:D8 00:50:F2 XenSource 00:16:3E KVM (QEMU) 52:54:00 前面這些列表，所假設的，都是虛擬機器只使用各廠牌方案預設的、保留的MAC地址範圍。事實上，虛擬機器的管理者，很容易就可以透過各種設定，將MAC地址改換到其他的OUI範圍內。因此，這個方法，只能算是一個簡單的輔助的工具。使用時，需要注意它的限制。 Welcome to virtualized world! 吉野櫻下，仰望著天空 玉淵潭公園，中國北京市

我剛才在讀網路文章的時候，我才發現，原來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學習資訊分享」的內容！

有關海底光纜，如何安裝和施工，我找到了這個動畫影片。同樣是由專門做海纜安裝和施工的美國公司(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… 海底光纜的安裝和施工，是一個龐大的工程。除了需要準備登陸點的機房，好長好長的海纜本體、中繼器、還有各種施工的船、機器、設備，和複雜的施工步驟，才能完成安裝。 中繼器其實是和海纜一起埋到海底的。因此，中繼器本身的電力，一定是來自於海底光纜本身。我看到一些資訊，海纜本身，同時包含提供電力的銅纜。另外，因為電力要穿越這麼長的距離，肯定電壓一定是很高很高。我們一般人，最好遠離海纜，除了保護海纜，也保護我們自己的安全。 盛開中的吉野櫻 玉淵潭公園，中國北京市