Cisco學習資訊分享: Recent Episodes
Li-Ji Hong (洪李吉)
【 BGP百萬大富翁】
我從幾個指標觀察到，大致上是2025年2~4月這幾個月以來，全球的IPv4 BGP 路由表總數，已經穩定的突破100萬筆。
| | | 我使用這個工具製圖。資料區間：2025/2/1 ~ 2025/4/30 |
首先我先釐清100萬這個數字。因為是數數量，我這裡所指的100萬筆，就是剛剛好1,000,000這個數字。我知道很多人習慣的1,024*1,024=1,048,576這個數字，目前尚未突破。我相信也很快，也許數週之後就會達到了。到時候，我可以再發出一篇新的更新訊息。目前我的觀察，還沒有太多人在網路上慶祝這個里程碑，我相信是因為，今天的路由器硬體，已經不存在2014年左右，所發生的硬體筆數不足的事故。
因為沒有造成困擾，所以討論的人也不多，我的猜想。
我做了一些調查，最近這幾年的硬體路由表筆數支援，尤其是電信業者線上的路由器硬體，都已經遠超過100萬這個數字。因此100萬筆這個里程碑，純粹是一個值得紀念的數字，並不會產生任何可能的服務中斷的事故。大家都不需要感到恐慌。
現在起，我們都是BGP百萬大富翁。
One more thing…今天的主角是IPv4。那麼，IPv6的BGP路由表大小，是多少呢？
今天2025年五月初，大約是22萬筆。
| | | 我是用這個工具製圖。資料區間：2025/2/1 ~ 2025/5/4。 |
我相信大家一定跟我一樣很想要知道，海纜如果真的被破壞的話，修復船是如何修復海纜的。綜合網路上所找得到的資訊，我製作今天這個影片，希望能夠解答大家的疑惑。
海底光纖纜線，我後面用海纜來稱呼。修復的進程，大致上可以分解成以下的階段。
1.正常工作海纜
最初的正常狀態是，海纜正常工作，海纜沉降服貼在海床上。
2.海纜故障出現
海纜可能因為天然因素的損壞，例如纜線老化、地震、落石、生物咬食；也可能是人為因素的損壞，例如，漁網拖曳、下錨撞擊、惡意破壞。故障發生的時候，有可能只是纜線的保護皮破損、光纖折斷、或甚至被整個切斷。
3.OTDR確認故障範圍後，派出維修船到A
「光時域反射儀」(OTDR, Optical Time-domain Reflectometer)利用雷射光反射的時間差，可以用來量測故障斷點距離所接上的OTDR儀器的光纖路徑長度，由這個資訊可以推斷出光纖故障的距離範圍區間，以及在光纖海圖上的位置。
確定位置之後，就可以派出維修船，抵達計畫中的海纜A地點，找到海纜A端。
4.截斷A端
因為接下來要將A端整個用浮標繫留漂浮在海面上，因此必須找A端適合的位置截斷海纜。找到與截斷海纜的方式，可能透過維修船上特製的海底拖曳勾爪，或者是放出水下海底機器人等。
換句話說，我們並不是在舊的海纜上進行修修補補，而是將整段有問題的切掉換成新的。
5.抓起後，浮標固定A端
將A端海纜抓到海面後，以浮標繫留在海面，維修船就可以離開A地點前往計畫中的B地點。
6.維修船移動，抓起B端
維修船到了B地點的海域後，同樣可以透過海底拖曳勾爪，或是放出水下海底機器人等方式，找到B端海纜。同樣的，將B端海纜抓到維修船上。
7.熔接B端到新海纜
在維修船上，進行光纖熔接，將B端熔接到新的替換海纜線捲上。通常在熔接的時候，會透過特製的套件，方便維修船上的熔接施工。
8.新海纜佈放回到A端浮標
熔接完成之後，維修船可以將B端海纜與新的替換海纜逐漸的沉降佈放到海底。接下來，一路進行佈放回到A地點的A端浮標。
9.新海纜熔接到A端
維修船回到A地點的A端浮標，將A端的海纜，和新的替換海纜，抓在維修船上進行熔接。一樣的，通常也透過特製的熔接套件完成熔接。
10.海纜歸位
A端熔接完成後，海纜已經回到可工作連通狀態。因此整段的海纜就可以沉降拉伸回到海底。
到這裡，完成了海纜故障修復的全部施工。
One more thing…根據修復施工的進程，我們立刻發現，沒有海纜維修船，基本上無法進行任何的海纜修復。同時海纜修復船全世界並沒有很多艘，光是將修復船開過來地點A，即使以30節的高航速，每小時時速依然不到60公里，以這樣的航行速度，肯定要花上好幾天的時間，才能到達現場。因此，海纜修復時間一定是以週數來計算的。
站在網路業者的角度，海底光纜的使用，一定要做到多線路、多路經的同時備援。
另外，我們也知道，熔接過後的光纖，一定會增加穿透能量的損耗。當修復熔接次數超過某個數字，整條的光纖就會不堪使用了。海纜是壽命有限的，需要定時安裝全新的海纜來替換。
最後，萬一海纜的破壞，是屬於人為故意的，我建議至少可以採取這兩個措施：
- 增加海纜維修船的分布密度。如此一來，我們可以減少等待維修船的排程，和移動航行的時間。
- 加派巡邏隊守護海纜路徑。正常的船隻航行，不會任意在海面上下錨或靜止。如果有這種跡象，而且徘徊在海纜路徑上，很大的機會一定是故意的行為。
使用哪一種設備量測光纖斷點距離？
滑鼠點開來看答案。
使用「光時域反射儀」(OTDR, Optical Time-domain Reflectometer)
這個影片的重點，在於使用正則表達式(Regular Expression)來過濾命令的輸出內容。
【好酷的，沉浸式冷卻法】
我頭一次看到這種冷卻技術。
每次想到液體冷卻、水冷式冷卻，我腦中浮現的畫面是，不漏水的散熱水管分布在主機板上。我沒有想到過這種可能性，將整個主機板，包含散熱風扇，全部泡在液體中散熱。
Cisco Service Provider Tweet我第一次看到Cisco Live的展示影片的時候，我看到透明清澈的液體，我以為那就只是普通的水。問題是，水會導電，別說泡在水裡，就連碰到一滴水，主機板肯定立刻短路燒毀。難道說，現在發明了什麼新的保護鍍膜技術，可以讓主機板防水，還可以泡在水裡？
我搜尋網路，找到這個影片。看完之後，我才知道，原來所有的魔術，都在這個透明的液體。這種液體由「Engineered Fluids」所生產，名稱是「ElectroCool Dielectric Coolant」 。
https://youtu.be/PvmMs6mU0NU?si=-NgiEM5AbHxdu_kE
這個特殊液體材料，本身在數十仟伏特、仟安培的電力下不會導電。因此，將它倒入運行中的主機板、散熱風扇、光纖收發器，如同倒入一種更稠密的空氣，將原本的自然空氣排出，因此主機板等元件，依然可以持續工作。同時這個特殊液體材料，本身比自然空氣，有著更強大的吸熱散熱能力，對於高速運轉、產生高熱的元件和電路，能夠提供更好的散熱功能。
我的確還沒有看到Cisco的確認，Cisco的展示影片所用到的就是「ElectroCool Dielectric Coolant」。即使不是，肯定也是其他公司所生產的類似的液體材料。
這種冷卻方式，我學習到至少有下列的幾個優點：
- 這種液體完全透明，不導電，散熱效果比純氣冷式散熱更好。
- 這種液體減少了風扇的噪音，讓機房更安靜。
- 這種液體沒有毒性，至少影片中看到人體可以直接安全碰觸。
- 比在主機板上安裝不漏水水管還要更簡單，直接整個泡在液體桶裝裡面就好了。
- 光纖收發器也可以正常工作，沒有光學折射的問題。
One more thing…目前我也想到幾個可能的問題，我還沒有得到答案：
- 這種液體會不會腐蝕金屬，長時間後最終破壞主機板？會不會傷到旋轉的風扇？
- 這種液體會不會容易揮發，如果是，我們需要準備很多，一直補充。
- 這種液體萬一遇到真的水，例如，消防水、凝結水、雨水，會發生什麼事？會不會開始導電短路？
無論如何，這是一個有趣的數據中心伺服器、網路設備的散熱新技術，值得我持續觀察。
我剛才在Faceoobk看到這張圖片。如果是我的網站讀者，應該很快就會發現問題所在。
案例和圖片來源(Thanks!)：
這個現象，稱為乙太網無窮迴圈(Looping)。發生的時候，一個數據楨會在這一條網路線，兩個埠中間，無限循環複製。結果會造成整部交換器的轉發送數據楨硬體資源，全部消耗完畢。看得到的現象，就是這兩個埠燈號比正常還更快速閃爍，加上所有穿越這套交換器的網路數據楨，全部穿不過去，等同於網路全部斷線。
非Cisco廠牌的網路交換器，我碰到過的幾乎都是如此，預設都沒有打開STP(Spanning Tree Protocol，生成樹協定、擴張樹協定)。因此，只要跟圖片一樣的接法，埠的燈號一亮起，穿越這個交換器的網路馬上就斷了。
反過來看，如果交換器品牌是Cisco的，只要你沒有故意關閉STP功能，即使跟圖片完全一樣的接法，網路依然完全不會斷線。
(我又幫Cisco在賣產品了，哈哈哈)
這個問題現象在家用型的Wi-Fi路由器、分享器上，很容易重現。驗證完成後，記得還原拔斷這條網路線。
One More Thing ....."Spanning Tree Protocol"協定裡面的"Spanning Tree"，其實就是是離散數學、資料結構裡面都會討論到的一個最小的樹狀結構子集合，同時連結圖(Graph)上的所有的節點。一般在離散數學、資料結構的教科書，將Spanning Tree翻譯成「擴張樹」。我知道網路相關的中文書籍，幾乎都翻譯成「生成樹」。因此，「生成樹協定」「擴張樹協定」我都認為是正確的翻譯。同時我也注意到：
如果你會將Spanning Tree翻譯成「擴張樹」的，很有可能你曾經讀過、修過離散數學，或是資料結構等學科。
2021年十月四日，Facebook跟所屬的服務，例如Instagram等，意外發生長時間停止服務。查詢 Wikipedia，我確認這一次的Facebook斷線，持續了七個小時。目前看得到的報導，都是說因為網路設定出錯，所導致。不過，根據我觀察過的案例，我認為，「網路設定出錯」，只是一個藉口。如果這一次的事件發生，只跟「網路設定」有關，網路硬體其實只需要回朔到前一個版本的設定，即使在最差的狀況下，頂多硬體也必須重開機。花不了一個小時的時間，一定可以回到前一個可以用的狀態。
因此，斷線時間如果只有一兩個小時，有可能真的只是純網路設定問題。但是持續時間如此的長，我真的不太相信。
當發現BGP協定的設定出錯，只要斷線持續超過20分鐘，回朔到前一個版本的設定，一定是必然的決策。如果好多路由器一起回朔設定、重新啟動，那也只是頂多再加上一個小時左右的時間而已。
更何況，我不認為Facebook的網路工程師，會是如此的差勁。因為錯誤的設定，讓整個Facebook 完全跟世界斷開來。我認為設定上的錯誤，頂多只會弄壞部分的服務狀態，而不是讓整個Facebook都離線。
Cloudflare的描述我認為是可以相信，而且是客觀的準確描述。Cloudflare只是服務Facebook的外部廠商。同時，BGP的活動紀錄，是我們外部世界、相鄰網路業者，所能夠唯一觀察到的Facebook表面活動。
綜合我目前觀察到的，Cloudflare加上Facebook官方的公告，我個人提出的假想理論是：
- Facebook 遇上了未公開的、不得已的緊急狀態。
- Facebook「故意」刪除掉全部DNS伺服器所在網段的BGP路由表，讓全世界用戶端軟硬體，都無法解析到 Facebook.com。等到DNS解析紀錄完全過期之後，沒有任何用戶可以解析到Facebook.com的IP地址，等於拒絕全世界用戶端的請求。
- 接下來，Facebook 「故意」刪除掉所有的BGP路由表，讓整個Facebook對外服務的網路，徹底跟全世界斷開來。
- 經過數個小時的處理後，Facebook慢慢送出正確的BGP路由表。恢復正常服務狀態。
One more thing…除非Facebook未來願意公開資訊，我這個「陰謀論」很難驗證。我只是要強調我的重點：如果只是單純網路設定的錯誤，斷線時間如果遠遠超過兩個小時，是很不符合經驗上所能觀察到的案例通則的。
歡迎大家留言告訴我，您的看法！
| | | 巴克禮紀念公園台南市 |
我們藉由一個連接三個辦公室，三個網段的簡單拓樸，來說明連接辦公室網路，維護正確的路由表內容的時候，到底應該使用靜態路由，還是多多運用動態路由協定。
網路拓樸中，三部路由器，分別代表一個獨立辦公室，背後各只有一個區域網路、LAN網段。圖中每一個區域網路，我只列出一部電腦，來代表網段內的使用者，或者是伺服器。
為了聚焦在路由表本身，IP地址已經全部配發完成。電腦上面只有基本網路連接功能。
我們的目標是，完全接通三個辦公室中，不同的區域網路，區域網路內的任何電腦、電腦之間，都必須完全連通。
路由表的基本知識回顧我們先回顧路由表的基本知識。
路由器在轉送每一個封包的時候，一律查詢路由表。封包的目的地地址，如果在路由表中存在定義，那就按照路由表的定義轉送。反過來看，封包的目的地地址，如果在路由表中找不到定義，這個封包就會被直接丟棄。
回到三個辦公室的情況。任何從電腦出發的封包，要到達其他辦公室的電腦的話，看完網路拓樸，我們馬上知道，都必須穿越兩次不同的路由器。
因此，第一站的路由器裡面的路由表，必須包含兩個遠端辦公室網段的資訊，封包才有機會，被往下一部路由器轉送。
事實上，拓樸中的三部路由器，上面的路由表，都必須包含對面遠端兩個辦公室的網段資訊，否則，完全的接通，肯定無法實現。
路由表的初始內容接下來，我們觀察路由器上面，路由表的初始內容。
初始的路由表的內容，有一些資訊是自動產生的。例如，直接相連的網段。除此之外，全部都必須透過我們的設定，來將缺少的路由表加進來。
這樣的初始內容，肯定是不夠的，因此網路連通性，還不存在。所以，我們開始加入缺少的路由表內容。
要加入路由表，我們有兩個選擇。
- 靜態路由
- 動態路由協定
我們兩者都試試看，先別急著下結論。最後我們再來比較，哪一個工具比較好。
加入路由表方法一：使用靜態路由依照剛才分析的結果，我們需要在三部路由器上面，分別透過靜態路由工具，來加入各兩筆的靜態路由資訊。
以R1為例子，需要在IP、IPv4分別加入這兩筆：
[R1]
ip route 10.2.1.0 255.255.255.0 10.0.12.2
ip route 10.3.1.0 255.255.255.0 10.0.13.3
ipv6 route fd10:2:1::/64 Ethernet1/0 FE80::200:FF:FE12:2
ipv6 route fd10:3:1::/64 Ethernet1/1 FE80::200:FF:FE13:3
完成之後，「完全接通」這個目標，我們達到了。我們可以透過任意兩部電腦、電腦之間的PING工具，來驗收這個目標。
以上的例子，分析過程應該不難理解。只不過，如果只能使用靜態路由，真的很不方便。
首先，輸入的時候，靜態路由命令很長，而且隔壁路由器的地址資訊，需要反覆檢查確認。非常容易出錯。
我們再觀察下面的兩個狀況，我們會發現，採用靜態路由，來維護路由表，真的很不方便。
案例一
假設第三號辦公室，需要增加一個網段。請參考網路拓樸。
分析的過程差不多，但是，每一部的路由器上面，就必須分別增加一筆第三號辦公室的新網段。我這裡用路由器一來說明。我們必須先檢查目前有的路由表，得知缺少的新網段，然後透過靜態路由命令，來加入這一筆。
事實上，路由器二，也必須完成相同的檢查，和確認。
如果這樣還不夠讓人感到苦惱，我再加入一個狀況：
案例二
二號辦公室，要改換網段地址。
相同的分析之後，我們發現，我們必須修改，所有路由器上面，跟二號網段相關的所有路由表的內容。我同樣用路由器一來說明。我們必須先檢查目前有的路由表，得知變更了的網段路由表內容，然後透過靜態路由命令，來移除舊的，加入新的這一筆路由表。
當然，路由器三也必須完成相同的路由表檢查跟編輯。
因此，如果我們只能使用靜態路由這個工具，將會很不方便，沒有彈性，糟糕的是，路由表並不會自動隨著網段地址改變而自動調整。
有沒有更好的解決方案？當然是有的。
加入路由表方法二：使用動態路由協定我們就挑選OSPF協定，來展示動態路由協定的優勢。
我們會發現，OSPF協定的啟動、設定命令，每一部路由器都完全一樣，我們不需要來回檢查確認其他路由器的地址。我們甚至可以用剪貼(copy paste)的方式，一口氣設定完全部的路由器。
```
router ospf 1
network 0.0.0.0 255.255.255.255 area 7
ipv6 router ospf 1
int e1/0
ipv6 ospf 1 area 7
int e1/1
ipv6 ospf 1 area 7
int e2/0
ipv6 ospf 1 area 7
int lo0
ipv6 ospf 1 area 7
``` 我們輸入完成之後，接下來，只需要等待協定的交談結果，讓路由器自動幫我們將正確的路由表內容準備好。
數秒鐘後，目前的路由表內容，已經是完全正確的。
透過動態路由協定，是不是簡單很多呢？
同時，前面所提到的兩個案例，動態路由協定，甚至於會幫助我們，自動更新路由表的內容。
案例一我們的確必須透過命令，告知路由器三R3，新增加這個網段。除此之外，其他設定，全部不需要改變。路由表自動更新完成。
案例二我們甚至於不需要修改任何原有的設定。
因此，前面的兩個場景，我們同樣使用OSPF的時候，我們幾乎不需要更動增加設定，路由表就會自動調整過來。
結論動態路由協定，可以幫助我們自動找到正確的路由表內容，更棒的是，當網路拓樸改變，路由表的內容，也會自動更新。同時，動態路由協定的命令，通常行數、字數也會比較少。
所以，我們必須花時間去學習，類似於OSPF這類型的、自動化的動態路由協定，來幫助我們，用最少的命令，讓路由器自動去探索拓樸，調整路由表的內容。
One more thing…只需要透過少數幾行的命令，就可以讓路由器自動維護，完全正確的路由表內容，確保辦公室網路的連通性。是不是既省力，效果也很讓人滿意呢？
如果喜歡以上的內容，請訂閱「Cisco學習資訊分享」YouTube頻道。事實上，我們還可以從其他的觀察角度出發，來增加我們網路服務的品質。例如「斷線自動修復」，和「網路遠端管理」，我還沒有討論到。我將放在未來的影片中。
歡迎大家開啟畫面、左方的影片連結，裡面有更多「Cisco學習資訊分享」的影片喔！
不安裝額外軟體，在Windows 10上面我們要如何快速找到，我現在工作中的Wi-Fi無線網路連線速度呢？我是洪李吉。
在Windows 10上面我們很容易知道，我們目前作業系統，是不是連上Wi-Fi網路。但是速度是多少呢？好像沒有比較簡單的方法，可以快速知道我們當前 Wi-Fi無線網路接入速度到底是多少。我這篇文章的內容就是來分享我常用的幾個方法。
影片版
方法一、使用滑鼠操作圖形介面這個方法在Windows 10上面，肯定是沒問題的。主要是因為Windows 10的圖形介面設計很不錯，甚至不需要看任何文件，稍微摸索一定找得出來。
但是，這個方法有缺點。經常發生，一段時間後，Windows可能會調整它的操作介面、路徑。換句話說，我們現在熟悉的流程，或者是我現在錄製下來的軌跡參考，非常可能日後還需要做調整更新。甚至於在未來的Windows版本裡面，流程完全都不一樣了。
我們需要有心理準備，經過一段時間之後，現在所錄製的畫面，很可能是不正確的。因此，接下來我介紹方法二。
方法二、使用netsh (Net Shell)Windows命令列工具netsh已經存在Windows作業系統家族裡面非常久了。預設內建，不需要另外安裝。
顯示Wi-Fi無線網路速度的命令，其實不長。
netsh wlan show interfaces
執行使用netsh，我們可以從命令列 CMD視窗，或者從PowerShell視窗來執行都可以。
方法三、使用PowerShellPowerShell也是Windows 10內建的命令列的介面。預設內建，不需要另外安裝。
他的命令稍微複雜一點，解釋起來的確需要花一段時間，整個命令的細節我先不解釋。
``
Get-WmiObject -Class Win32_NetworkAdapter |
Where-Object { $.Speed -ne $null -and $.MACAddress -ne $null } | Format-Table Name,
@{Label='Connected'; Expression={-not $_.OperationalStatusDownMediaDisconnected}}, @{Label='Speed(MB)'; Expression = {$_.Speed/1000000}},
FullDuplex,InterfaceDescription
```
相同的，命令執行之後，馬上就知道，我們的Wi-Fi無線網路接入速度是多少。結論以上我所分享的幾種方法，可以在Windows 10上面不需要安裝額外的任何軟體，就可以快速知道，我現在工作中的Wi-Fi網路接入速度是多少。希望對大家有幫助。
One more thing…Wi-Fi的接入的速度，我這裡的意思是，從Windows出發，到達第一站的接入點(Access Point)的這一段鏈接的速度。因此，真實的端到端(End to End)網路有效連線速度，不一定會這麼好。這是因為，端到端網路連線，並不是只有Wi-Fi這一段的路徑，還要再經過有線網路，中間也許還會經過其他的網路設備，例如，路由器、交換器、防火牆。最後的速度，可能不太一樣。
另外，在Wi-Fi無線網路的領域，所謂接入的速度是指，輪到你用的時候，你在無線信號上的瞬間傳輸速度。實際上，Wi-Fi無線網路，一定是共用的。我們會跟好多用戶，共用分享少數的接入點。這個速度的數字，還需要往下再打個折扣。
在Windows 10上面 PowerShell是預設內建，不需要另外安裝，而且快速方的命令列管理工具，同時也是可程式化的，就跟Python、BASH相當。假設大家想要更深入了解，歡迎在下方的留言區告訴我！
我是洪李吉。我的網站是「Cisco學習資訊分享」。我們下次見！
就在三天前，2021年3月23日，當地時間大約7:40 (5:40 UTC)，台灣的長榮海運公司的貨櫃輪「長賜輪」(EVER GIVEN)，在「蘇伊士運河」的航道上意外擱淺，正好將整個通道阻塞。因此，「蘇伊士運河」完全停止服務，任何輪船都無法穿越，一直到影片製作的現在。我從「維基百科」、「Google地圖」的觀察，我發現，「蘇伊士運河」本身存在著「單點故障、全體故障」的問題，也就是Single Point of Failure, SPOF。因為開鑿運河本身，就是一個極為昂貴的工程，我的重點不是在指出「蘇伊士運河」的設計規劃有問題。我只是藉由這個例子，來說明任何網路系統的設計，如果存在著「單點故障、全體故障」的服務停止缺陷，雖然發生的機會很小，只要機會不是零，我們就必須預先規劃好，如何降低發生的機率；或是當這個狀況發生的時候，所產生的代價，我們是否可以承受；還有，我們必須花費多久時間，才能修復回正常服務的狀態。
「蘇伊士運河」事件的摘要我先將視野，站在「蘇伊士運河」業主本身。
我從報導得知，「蘇伊士運河」在2020年一整年的過路費收入，大約是56 億美元 (5.6 Billion USD)。我假設運河本身365日每天都營運，平均每一天的收入，大約是一千五百萬美元 (15 Million USD)，這個數字大約是超過新台幣四億元。因此每停止服務一天，過路費收入的損失就是一千五百萬美元。到目前為止我的觀察，「蘇伊士運河」業主本身能夠做的手段，還沒有看到明顯的效果，包括使用拖船、挖開擱淺岸邊的砂土。目前已經尋求外部救援公司的協助。如果最後真的需要外部救援公司才能解決，我的估計，光是移動外部救援公司的機具到現場，可能就要好幾個星期，因此，這個阻塞問題需要更多的日子，才能夠解決。
光是過路費的收入，就是一筆好大好大的數字。我將視野，拉回到網路系統。萬一我們的網路規劃，還存在著類似的「單點故障、全體故障」的SPOF問題，我提出下面幾個思考的切入點，來避免我的工作網路遇到，跟進行中的「蘇伊士運河」事故一樣糟糕的結果。
停止服務事件，發生的機率有多大？雖然我沒有具體的統計數字，但是，經驗上告訴我，纜線、路由器、交換器、防火牆，任何可單獨安裝的硬體單位，一年內完全沒有任何故障的機率，幾乎是零。就算完全沒有故障，也只能算是運氣好。
我必須預期，一條纜線，一個路由器，一個交換器，一個防火牆，就在未來的一年內，一定會產生故障的事件。在這個情境下，來進行我的網路規劃。
因此即使發生單一硬體故障，也不會造成服務停止的冗餘設計(Redundancy)，非常重要。例如，多重冗餘路徑、多重冗餘硬體的加入，都能夠減少停止服務的機率。
即使最後因為不敷成本不採用冗餘設計，這些冗餘設計的選項，我也必須列入考慮清單中。未來如果條件改變，我可以快速知道，我還有哪一些備案可以選擇。
停止服務事件，發生後的代價有多大？地點不同，代價也不相同。如果某個網路連線，只服務一個時間要求不高的使用者，例如，單一普通員工的座位電腦、小群組印表機，代價也許不明顯。
但是如果是主幹道上面的網路，停止服務後，損失一定很可觀。如果可能，將預期的損失用金錢來估算，這樣會比較有感覺，同時，這個數字也能夠幫助我評估，我能夠投入的合理預算，有多少。
停止服務事件，發生的時候，要花多久時間修復？在網路系統距離不遠處，準備一些多餘的可能故障的備用品，例如網路線、光纖收發器(Transceiver)，甚至是交換器，都可以減少停止服務的時間。
尋求外部公司的協助，也是可行的選項。例如資訊系統另外付費的「保證四小時內到場維護」等級的硬體服務。
結論前面三個切入點的問題，每個企業內的系統的情境、取捨，可能都不一樣。重點是，我都必須隨時準備好，我要如何去回答。
One more thing…雖然我的視角只是網路系統，事實上，前面全部的檢視，也適用於任何的資訊系統。
回到「蘇伊士運河」。誰能事先想得到，竟然會這麼剛好，擱淺意外，發生在「蘇伊士運河」單向、單通道的航道段，而且主角是總重量超過二十萬噸的、世界最大型的貨櫃船。
如果能回到過去，改成發生在雙通道航道段，或者是主角不是如此笨重的輪船，一切就不會演變成整個「蘇伊士運河」完全阻塞。
只要機率不是零，我都必須假設，這種事故真的會發生。我不能只靠運氣好。
我是洪李吉。我的網站是「Cisco學習資訊分享」。我們下次見！
我這幾天在「網路攻防戰」Facebook頁面看到文章「標題：台灣 IPv6 使用率已經超過 50%」，我順著找到了好多關於台灣IPv6發展現況的資訊。我這時候才驚覺到，原來在台灣，IPv6協定用戶端連線數，目前已經超越IPv4協定。APNIC從「用戶端」完成的成功工作連線數，來做為量測依據。因此，並不是IP地址空間中的可能地址數，而是有真實意義的使用人數、人次。
台灣目前Internet上面的IPv6的使用連線數，已經超過台灣全部的IPv4連線數了。或者這樣看，假設您的用戶端只能支援IPv4，那麼您已經是屬於不到一半的少數了。
我整理出我的三個觀察，跟大家分享。
| | | 資料來源：https://stats.labs.apnic.net/ipv6/TW | |
行動電話上面的網路活動，IPv6遠高於IPv4光從APNIC的圖表，我馬上注意到中華電信的數字。
| | | 資料來源：https://stats.labs.apnic.net/ipv6/TW | |
「IPv6 Capable」所指的是透過IPv6執行完畢完整的連線。
「IPv6 Preferred」所指的是，雙協定用戶端，最後選擇IPv6執行完畢完整的連線。
其中，EMOME代表的是中華電信來自於行動電話的樣本，HINET上面流量是來自於中華電信其他技術的使用者。APNIC量測到的數值來看，HINET上面的「IPv6 Capable」大約佔全部連線數的30%，但是EMOME行動電話IPv6 Capable竟然已經達到大約90%。因此可以看得出來，行動電話上面的IPv6普及性非常高。
行動電話應該是台灣IPv6使用者的主要成分同樣依照中華電信的數字來計算，我將APNIC所取得的樣本數字乘以IPv6 Capable百分比，EMOME大致上的IPv6 Capable樣本數目，是HINET的兩倍(23,864 vs 11,885)。因此我推斷，行動電話是台灣IPv6使用者的主要成分。
| | | 資料來源：https://stats.labs.apnic.net/ipv6/TW | |
台灣屬於高度IPv6使用率的領先群APNIC的量測數值，是浮動的，台灣目前的世界排名，大致上是第七名、第六名之間跳動。即使如此，台灣IPv6使用率，目前依然大幅領先全世界的很多國家。
| | | 資料來源：https://stats.labs.apnic.net/ipv6 | |
結論整體來看我相信，並不是IPv4使用人數大幅減少，而是因為IPv6使用人數大增。同時最近這幾年，行動電話的數量大幅增加，增加的速度遠超過PC、Notebook。因此我推測，新增加的行動電話用戶，幾乎都是IPv6 Capable，使用IPv6來連網。
我完全同意「網路攻防戰」Facebook頁面的建議：「還不熟悉 IPv6 的資訊/資安從業人員，要盡早補充相關知識了。」
One more thing…
| | | 資料來源：https://stats.labs.apnic.net/ipv6 | |
簡單的來說，APNIC的量測方式，是透過HTTP/HTTPS連線數，也就是瀏覽器、App等所完成的樣本連線數來量測。我認為這是接近於真實的Internet行為。因為從一般的實務統計來看，HTTP/HTTPS已經超越90%以上的Internet流量。
另外，不只是APNIC在研究量測這個主題，好多商業公司、非營利組織，都同時使用不同的量測工具來估計IPv6的使用率。因此，我這裡所分享的APNIC來源，只是其中之一。
我稍作觀察，不論是來自哪一個發布的來源，台灣其實都屬於領先群。
| | | 資料來源：https://labs.ripe.net/Members/wilhelm/ipv6-adoption-statistics-a-comparison-of-different-metrics | |
| | | 台灣春天的山櫻花台灣、桃園市、Feb. 5, 2021 |
我是洪李吉。我的網站是「Cisco學習資訊分享」。我們下次見！
今年2020年初，我用Windows 10筆記型電腦，接在別人的某電信業者的寬頻網路上網。網路盒上面其實同時開通著Wi-Fi，因為我人就坐在網路盒子旁邊，我依然使用有線網路連網。我的電腦裡面，所安裝的軟體很單純，基本上只有瀏覽器，和Microsoft的Office軟體而已。我將乙太網路線，一插入網路盒的埠上面，甚至連PPPoE撥接、密碼等等，全部都不需要設定或輸入，Windows 10馬上就顯示，「網際網路存取」已經接通。接下來，不論是瀏覽器連接Google、YouTube、Facebook、Twitter等，收郵件、甚至是Windows Update，完全都沒有問題。於是，我沒有多想，就繼續將網路線接在這個網路盒，開開心心的上網去了。
直到，有同事請我幫他測試一個網站。
我覺得好奇怪，打開這個網站，瀏覽器居然發生逾時的錯誤，就連首頁畫面，都無法開啟。我跟同事都覺得好奇怪，剛才從其他的網路測試，明明都可以連接上去，為何現在會連首頁都打不開？
因為我連接其他的網路服務，全部都沒有問題，只有這個「待測網站」，就連首頁都打不開。我第一個先懷疑的，應該是這個網站伺服器自己的問題。
靈異事件，即將開始我乾脆將網路線拔掉，改用同一個網路盒的Wi-Fi 服務連網，反正我也知道密碼。輸入完成密碼之後，Wi-Fi接通，所有的網際網路服務，當然都還是可以正常工作。
於是我再重新測試一次，這個「待測網站」。
「待測網站」的首頁，這次，竟然可以打開！
這怎麼可能？？！！
我都是通過完全相同的網路盒連接，只不過，透過有線網路，「待測網站」首頁打不開，透過無線網路，竟然可以打開！
難道是，有防火牆安插在網路盒上嗎？我仔細想想，這個網路盒應該是超級低成本的，不太可能。
難道是，被電信業者封鎖住我的IP地址了嗎？我能夠完全正常使用其他的網站，這點也不成立。
難道是，我的Windows 10電腦，錯誤的將這個網站當成惡意網站，給封鎖住了嗎？我明明使用完全相同的Windows 10電腦連接，怎麼可能有線網路就封鎖，Wi-Fi反而接通？
完全沒有任何科學理論，可以合理解釋，正發生在我眼前的這個，十分詭異的靈異現象！
我被這個靈異現象，嚇出了一身冷汗，就這樣持續了五百個毫秒。
我只剩下最後一招了，於是，我只能打開Windows 10命令列視窗。準備執行 「ipconfig /all」 命令。
當閃動的游標停在「all」的「L」字母後面，我開始遲疑了，我到底應不應該，接著按下Enter按鍵？？
再經過五百個毫秒的遲疑之後，我總算下定決心，將Enter鍵按下去。
於是，我得到了這個類似的畫面(事後模擬)。
乙太網路卡 乙太網路:
連線特定 DNS 尾碼 . . . . . . . . :
描述 …
IPv6 位址. . . . . . . . . . . . .: 2001:b011:0000:0000:0000:0000:0000:0000(偏好選項)
臨時 IPv6 位址. . . . . . . . . . : 2001:b011:0000:0000:0000:0000:0000:0000(偏好選項)
連結-本機 IPv6 位址 . . . . . . . : fe80::0000:0000:0000:0000%2(偏好選項)
IPv4 位址 . . . . . . . . . . . . : 169.254.1.2
子網路遮罩 . . . . . . . . . . . .: 255.255.0.0
…
原來如此，我之前一直能夠成功連網，是因為，網路盒所提供的IP地址，其實一直都只有IPv6地址。Google、YouTube、Facebook、Twitter，全部都是 IPv6 Ready的網路服務。
「待測網站」因為還在開發，伺服器上面只有IPv4地址。
電信業者的網路盒上的Wi-Fi功能，因為提供了標準的IPv4 NAT 地址轉譯(用Cisco的術語，應該稱為PAT)，還有DHCP功能，可以自動配發IPv4私有地址。
簡單的說，我連接在有線網路上面的時候，所使用的是IPv6網路，因此可以正常連線網際網路，但是不能連接「待測網站」。
我連接在Wi-Fi的時候，所使用的是IPv4網路，在NAT後面，因此，可以連接所有的網站，也包含「待測網站」。
所有的謎團，所有的靈異現象，全部都解開了！
我之所以會嚇出一身冷汗，是因為，我完全沒有預期到，我竟然可以透過電信業的網路盒，直接使用IPv6連網。而且，完全分辨不出來，我到底是在IPv6網路，還是IPv4網路上面。
我覺得有點慚愧。因為，身為網際網路工作者，我竟然忘了想起IPv6的存在。
One more thing…只可惜，當時我沒有將畫面擷取下來。之後我回到相同的網路，想要將畫面重新擷取，卻發現，電信業者已經將IPv6功能關閉了。我拿自己家裡的相同電信業者的寬頻網路盒來測試，也不能取得IPv6地址。電信業者並沒有在網站上公開這個功能，看起來，只是我運氣好(或者說，運氣不好)，剛好遇到測試中的網路功能。
不過，我也歡迎大家在下方的留言區，分享您所遇到過的「靈異現象」！我們可以一起來找找，問題可能出現在哪裡。
我記錄這一個故事，其實還有一個目的。
正因為在Windows 10上面使用IPv6網路技術，原來會讓人完全察覺不出來，到底我們人是連接在IPv6網路，還是在IPv4上面。因此，未來我如果提到，「Internet」、「Internet Protocol」、「IP」、「網際網路」，只要我沒有特別說明，我將調整我的習慣，我所指的，就是IPv6。
如果是跟舊的技術有關，我才會單獨指出，是IPv4。
「IP」我所指的，就是預設的、IPv6。
「IPv4」我所指的，就是舊的網際網路技術。
我是洪李吉。我的網站是「Cisco學習資訊分享」。我們下次見！
很多網管工作的朋友，不能立刻接受IPv6網路技術的原因，我的觀察，是因為感覺到IPv6技術好複雜。我設計了這個簡易的網路架構圖，來說明，感覺不一定完全正確，IPv6其實可以遠比IPv4容易設定。在這個架構圖裡面，一共只有4套路由器，8個網段。其中路由器、路由器之間，一共只有6個網段，再加上用戶端、伺服器端各一個網段。只有這樣，就這麼簡單的拓樸。
假設給定的需求只有「連接用戶端、伺服器」，不限定第三層的協定，使用IPv4或者是IPv6。我們分別完成它們的設定，然後來做兩者之間的比較。
IPv4設定連接傳統的IPv4設定的流程，我們必須先分配IPv4地址。地址決定好之後，我們再到路由器上面，設定IP地址還有路由協定。
我們會發現，大部分時間，竟然是花費在IPv4地址的計算，而不是路由器的設定。
下面我只列出R1的設定。
hostname R1
interface Loopback0
ip address 10.0.0.1 255.255.255.255
!
interface Ethernet1/0
description To R2
ip address 10.0.12.1 255.255.255.0
!
interface Ethernet1/1
description To R3
ip address 10.0.13.1 255.255.255.0
!
interface Ethernet1/2
description To R4
ip address 10.0.14.1 255.255.255.0
!
interface Ethernet2/0
description To Client
ip address 10.1.0.1 255.255.255.0
!
router ospf 1
network 10.0.0.0 0.255.255.255 area 1
!
end
下面是IPv4路由表。
R1>show ip route
...
C 10.1.0.0/24 is directly connected, Ethernet2/0
L 10.1.0.1/32 is directly connected, Ethernet2/0
O 10.2.0.0/24 [110/20] via 10.0.13.3, 00:01:24, Ethernet1/1
...
R2>show ip route
...
O 10.1.0.0/24 [110/20] via 10.0.12.1, 00:05:11, Ethernet1/0
O 10.2.0.0/24 [110/20] via 10.0.23.3, 00:02:37, Ethernet1/1
R3>show ip route
O 10.1.0.0/24 [110/20] via 10.0.13.1, 00:02:48, Ethernet1/0
C 10.2.0.0/24 is directly connected, Ethernet2/0
L 10.2.0.3/32 is directly connected, Ethernet2/0
...
R4>show ip route
...
O 10.1.0.0/24 [110/20] via 10.0.14.1, 00:05:59, Ethernet1/0
O 10.2.0.0/24 [110/20] via 10.0.34.3, 00:03:32, Ethernet1/2
R4>
IPv6設定連接IPv6的設定流程，我們並不需要設定路由器、路由器之間的地址，因為，IPv6原本就會自動產生「鍊路內本地地址」(Link Local)，更棒的是，大部分的路由協定，只需要「鍊路內本地地址」，就已經可以正常工作了。
下面我只列出R1的設定。
hostname R1
ipv6 unicast-routing
!
interface Loopback0
ipv6 address FDE0:0:0:1::1/64
ipv6 ospf 1 area 1
!
interface Ethernet1/0
description To R2
ipv6 enable
ipv6 ospf 1 area 1
!
interface Ethernet1/1
description To R3
ipv6 enable
ipv6 ospf 1 area 1
!
interface Ethernet1/2
description To R4
ipv6 enable
ipv6 ospf 1 area 1
!
interface Ethernet2/0
description To Client
ipv6 address FDE0:0:0:100::1/64
ipv6 ospf 1 area 1
!
ipv6 router ospf 1
!
end
下面是IPv6路由表。
R1>show ipv6 route
IPv6 Routing Table - default - 9 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
B - BGP, R - RIP, H - NHRP, I1 - ISIS L1
I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary, D - EIGRP
EX - EIGRP external, ND - ND Default, NDp - ND Prefix, DCE - Destination
NDr - Redirect, O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1
OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2, l - LISP
...
C FDE0:0:0:100::/64 [0/0]
via Ethernet2/0, directly connected
L FDE0:0:0:100::1/128 [0/0]
via Ethernet2/0, receive
O FDE0:0:0:200::/64 [110/20]
via FE80::C803:72FF:FE33:1C, Ethernet1/1
...
R1>
R2>show ipv6 route
...
O FDE0:0:0:100::/64 [110/20]
via FE80::C801:78FF:FE7F:1C, Ethernet1/0
O FDE0:0:0:200::/64 [110/20]
via FE80::C803:72FF:FE33:1D, Ethernet1/1
...
R2>
R3>show ipv6 route
...
O FDE0:0:0:100::/64 [110/20]
via FE80::C801:78FF:FE7F:1D, Ethernet1/0
C FDE0:0:0:200::/64 [0/0]
via Ethernet2/0, directly connected
L FDE0:0:0:200::3/128 [0/0]
via Ethernet2/0, receive
...
R3>
R4>show ipv6 route
...
O FDE0:0:0:100::/64 [110/20]
via FE80::C801:78FF:FE7F:1E, Ethernet1/0
O FDE0:0:0:200::/64 [110/20]
via FE80::C803:72FF:FE33:1E, Ethernet1/2
...
R4>
為什麼為什麼有這麼大的差異？IPv4主要的問題，是在於沒有自動產生「鍊路內本地地址」的功能。因此，所有的路由器、路由器之間的網段，全部都需要手動檢查設定IP地址。除了手動設定這些地址之外，IPv4地址更需要手動詳細檢查，一一確認，子網段的分割、遮罩長度的定義、十進位二進位轉換計算、網段內地址是否相符…等等等。
光是地址分配，再加上檢驗的步驟，將會比全部的路由器命令輸入設定，都還要更花時間。而且計算過程，讓人非常痛苦。最糟糕的是，非常、非常容易出錯。
結論您管理IPv4時所遇到的痛苦，在新的IPv6世界裡面，很多都已經自動消失了。希望這個資訊，讓您更有動力，將網路協定改成IPv6。
One more thing…不設定路由器、路由器之間的IPv6單播路由地址，的確也有缺點。假設我們習慣於使用 PING、TRACEROUTE工具，來確認，某路由器的指定鍊結是否正常工作，這個老習慣就不能工作了。
我建議別再使用以上的老習慣。改從路由協定本身，確認鄰居的狀態的同時，也確認鍊路的工作狀態。例如OSPF鄰居、EIGRP鄰居。只要鄰居的狀態是維持住的，代表著鍊路狀態也是正常工作的。
我是洪李吉。我的網站是「Cisco學習資訊分享」。我們下次見！
今年2020年11月初，我開始注意到全球IPv6的BGP路由表，突破了十萬筆，也就是100K筆。雖然中間有幾天又彈回十萬筆以下，不過，這一週左右以來倒是穩定的突破了100K。這是一個有趣的里程碑，代表著，IPv6的使用者人數、電信業者、企業，都越來越多，數量上已經來到一定的規模了。我記錄下這個里程碑，順便分享兩個我的觀察。
IPv6 BGP筆數會上上下下浮動
| | | 資料來源：https://twitter.com/bgp6_table/status/1330964625127583744/photo/1 |
Internet是一個分散式管理的網路，每一家組織、電信業者、企業，彼此之間並沒有直接的管理強制性。因此當需要的時候，電信業者、企業可能會各自自主的、動態的新增路由資訊、或者移除路由資訊。例如，將沒有用到的合法網段，從BGP設定中移除，因此，全球的BGP筆數可能會減少。
例如，為了流量負載分散，可能需要將一個大網段分割成多筆的小網段路由資訊，分別送給不同的鄰接公司或是不同線路，因此，全球的BGP筆數可能動態增加或減少。
當然，正常的網路擴充增加網段，或者是公司解散繳回網段，或者設定錯誤，都可能造成筆數浮動的結果。
| | | 資料來源：IPv6 CIDR Report for 30 Nov 20 |
IPv6 BGP筆數的預測，相當準確APNIC或是RIPE的預測網頁，都指出，大約會在2020下半年，突破100K。我個人認為這些推估都相當準確。
| | | 資料來源：APNIC, "BGP in 2019 - The BGP Table" |
| | | 資料來源：RIPE, "BGP in 2016" |
IPv6 BGP筆數成長的比例，比IPv4高去年2019年大約十月，IPv6 BGP筆數來到80K左右，經過一年的時間，目前成長到了100K，也就是，成長率大約是25% (=20/80)。
相同的時間，去年2019年大約十月，IPv4 BGP筆數來到80萬筆(800K)左右，經過一年左右的時間，目前成長到了大約85萬筆(850K)，也就是，成長率大約是6.25% (=5/80)。
因此IPv6 BGP筆數成長的比例，比IPv4高，而且，高很多。
One more thing…有關IPv6 BGP需要佔用路由器的記憶體空間估計，我找不到IPv6第一手的記憶體使用量的樣本，我用之前「IPv4 BGP每十萬筆需要大約80 Megabytes」來估算。
因為IPv6單一個地址，是IPv4的四倍長，我粗略的估計，大約記憶體的使用量應該不會超過四倍，也就是「IPv6每十萬筆需要大約不超過320 Megabytes。」
我的估計，跟您的觀察有多大的誤差呢？歡迎大家一起在下方留言指正了！
| | | 高雄港出口，從「打狗英國領事館文化園區山上官邸」俯瞰台灣、高雄市 |
我是洪李吉。我的網站是「Cisco學習資訊分享」。我們下次見！
【好的東西儘量放分公司，爛的放總公司】
我曾經在某家公司工作。當時我在總公司，管理全公司整個集團的IP網路。因為每年的預算有限，籌備年度軟、硬體升級的時候，我經常必須抉擇，到底應該先升級「分公司」的路由器交換器，還是「總公司」的。和一般人直覺相反，我也沒有詳細和其他人討論分享，我自己心裡面的取捨，其實是「好的東西儘量放分公司，爛的放總公司」。為什麼？我來聊一聊我的這個內心原則。
分公司的人力、技術資源比較有限第一，「分公司」的人力數量，技術支援熟練度，通常都比「總公司」的團隊更有限制。
分公司的資訊技術支援，在我的觀察，一般都遠不及總公司。光是從人力來看，在總公司，通常會有專業分工的技術團隊，例如，專門有一群人做伺服器的任務、另外一群Windows作業系統，或者是還有一群人做網路。每個領域都有專門的團隊，分工執行。但是在分公司，通常都沒有這麼多的資訊人力。
少數的幾個員工，當他們在值班的時候，可能同時必須負責處理伺服器，又要同時處理Windows作業系統，還要處理網路的問題。如果我們給他們比較糟糕，問題很多的的路由器、交換器的話，當遇到問題的時候，他們不一定能夠像總公司專門的技術團隊能夠熟練的處理，時間上也不允許他們，花太多的力氣去判斷，光是「網路」這個技術領域，到底發生什麼狀況，只因為一個員工，同時要負責好多系統或任務。
還有技術文件，或是教育訓練的資源，「分公司」普遍來說都比較欠缺。
深入的技術問題，我寧可盡量控制在「總公司」內發生，專業團隊可以就近直接處理。別讓這些複雜的技術問題，發生在「分公司」裡面。
只要「分公司」的人沒辦法當地就近處理，接下來就是要「總公司」自己的團隊下去處理。如果經常需要「總公司」的團隊派人去處理，馬上我們就必須面對的二個問題。
分公司的距離好遠，交通的時間和金錢花費都很高第二，「分公司」的距離好遠，來回交通的時間和金錢，花費都很高。
距離越遠，交通的時間和金錢花費就會越高。這是直接的結果。
緊急狀況的時候，「總公司」的人即使願意花費交通的時間跟金錢，到現場去處理，有的時候也是趕不上時效性、達不到時間的目標，「緩不濟急」。例如網路斷線的狀況，只要故障沒有排除，好多系統會立刻停止工作。
另外，「總公司」的員工，通常還有很多任務要去處理，不論是「年度」的、「季度」的申請流程、報表、安全稽核等等，全部都必須由「總公司」的員工處理。如果你把有限的時間都花在交通上，其實也是很不划算的。
另外，我自己當時工作的時候，我沒有太多的時間去加班，我也不太願意加班，我也必須保留時間給我的家人。我盡量減少不必要的差旅交通。
只要我能夠遠端處理，我盡量只透過遠端處理。
盡量減少不必要的「總公司」往來「分公司」的之間的交通時間跟花費，我不只是可以幫公司省錢，我也不需要經常加班，因為我在正常辦公時間我就可以把所有的事情處理好。不會將時間浪費在交通和旅行上面。
障礙現場當地就能直接處理的問題，盡量能夠在當地直接解決。
萬一障礙還是不能解決的時候，我們只剩下一個選擇：請廠商協助。
新的產品比較容易取得廠商的技術支援第三，新的產品新的軟體硬體系統等等，通常比較容易取得廠商的技術支援。我相信這一個觀察點，也許注意到的朋友會比較少。
以網路硬體為例子，一套路由器或是交換器，假設已經是超過10年以上的老產品，備用的零件通常比較缺乏、昂貴、而且不齊全，即使廠商願意幫你提供支援服務。
比較新的，或者說是不要太老舊的產品，廠商的技術服務人員，也會得到比較多的教育訓練資源。
廠商比較願意支援新的產品，也比較有能力支援新的產品，通常也代表著，我們可以用比較有經濟效益的價格，來取得相同的支援服務內容。
太老舊產品，我就不會放在「分公司」。我那時候能夠做的是，舊的產品留在「總公司」使用，堪用的繼續用，能不更新就不急著更新。也就是說「分公司」全部都更新完了，最後我才會開始更新「總公司」的軟硬體系統。
結論這個取捨的原則，減少了我很多非必要的出差時間。幫我節省了非常多的力氣，我也不太需要經常加班，同時，我也幫公司節省了很多金錢，一舉數得。
One more thing...其實還有一個關鍵的核心功能需求，就是「所有分公司的系統，必須能夠只透過網路，遠端就可以管理」。
所有的描述或假設，我的出發點都是，「分公司」軟硬體系統最低的要求，就是我一定要能夠從遠端去管理。
這些放在分公司的路由器、交換器，我其實從總公司，都可以透過IP網路來監看。異常日誌、存儲空間用完、電源、風扇模組故障、等等，我在總公司我其實都可以觀察得到。即使問題即將發生，我通常會提早察覺預測得出來。
| | | 國泰金融大樓台灣、台中市 |
我是洪李吉。我的網站是「Cisco學習資訊分享」。我們下次見！
首先我要澄清，製作這個影片，我並不想要教大家，去破解別人的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學習資訊分享」。我們下次見！
【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 zoneset vsan 4”來確認，包含“set4C”的Full Zone Set並沒有自動被傳送出去。Enhanced Zoning，加強模式如果我們希望Full Zone Set會自動同步到所有的MDS，同時，在編輯Zone Set的時候，MDS幫我們做編輯鎖定，只有一位管理者可以做Zone Set編輯，避免Basic Zoning所可能產生的內容相互覆蓋的風險，我們需要改良過的Enhanced Zoning。要開啟Enhanced Zoning模式，我們只需要挑選一套MDS，下達“zone mode enhanced vsan 4”即可。這個開啟的結果，會自動傳遞生效到所有的MDS。我們可以透過“show zone status vsan 4”命令，來確認所有的MDS已經變更成Enhanced Zoning。開啟Enhanced Zoning模式的同時，原本新增的 Zone Set “set4C”，自動會傳遞到所有的MDS。我們可以再次透過“show zoneset vsan 4”命令確認。Enhanced Zoning之下，Zone Set的編輯和啟用我們再次加入“set4D”，我們依然可以驗證，包含“set4D”的Full Zone Set會被自動同步到所有的MDS。首先我們會注意到，在Enhanced Zoning工作模式之下，任何MDS上面的Zone Set編輯，都會鎖定所有MDS的編輯功能。直到我們下達生效解鎖的Commit命令“zoneset commit vsan 4”。這個命令執行完成後，我們可以再次透過“show zoneset vsan 4”確認，同步成功。假設因為需要，我們必須啟用“set4D”，我們可以到任何的一套MDS，下達“zoneset activate name set4D vsan 4”。最後我們使用“show zoneset active vsan 4”來確認，的確啟用中的Zone Set，已經正確變成 “set4D”。加強模式Enhanced Zoning同時提供了基礎模式的啟用功能和CFS的同步完整Zoning設定的服務內容，再加上編輯鎖定、自動同步，是更佳的工作模式。全新的SAN安裝，應該直接設定成Enhanced Zoning。One more thing…FC協定是存儲網路協定，雖然不是TCP/IP的通訊封包協定，但是因為有相似的特性，只要願意多花一些時間，TCP/IP的工作者也可以快速熟練SAN協定。最棒的是，Cisco在SAN或是TCP/IP都有硬體，MDS的命令集基本上就是NX-OS環境，因此轉換上不存在太多的障礙。
| | | 「東方寺」和盛開的櫻花台北市士林區 |
我是洪李吉。我的網站是「Cisco學習資訊分享」。我們下次見！
最近不少人在討論「全球 43 億個 IPv4 地址今日正式耗盡」，例如這一篇。我相信起因，是因為RIPE的Nikolas Pediaditis幾天前的一封公開Email，宣布RIPE NCC的IPv4地址，已經全部發放完畢。
https://www.ripe.net/ripe/mail/archives/ncc-announce/2019-November/001380.html
Dear 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地址。電信業者跟「區域網際網路註冊中心」申請地址的時候，一定會考慮到預留未來可能增加的客戶數，批次申請。因此，一定還有庫存可以使用。
電信業者依然可以分配客戶使用的IPv4地址，這個事實，跟「區域網際網路註冊中心」的IPv4地址已經用完了的事實，兩者並不衝突。
「區域網際網路註冊中心」IPv4地址用完了，最著急的不是使用網路的各位，而是電信業者，或者是需要專用IPv4地址的大型企業。因為他們必須跟「區域網際網路註冊中心」申請IPv4地址，而「區域網際網路註冊中心」的確已經用完了，因此他們目前都只能排隊，等待奇蹟的出現，或者是，必須改用IPv6地址。
我想告訴大家的是，別擔心，您很可能已經天天都連接在IPv6網路上，而且使用好一陣子了。我今天來分享，我如何知道我已經連接在IPv6網路上面。
工具一：Google IPv6 Testhttps://ipv6test.google.com/
Google的這個網站不會告訴您太細節的資訊。他只會說，您的環境使用IPv6沒有問題。即使您現在沒有連接在IPv6網路上面，只要可以打開Google，您就會知道您的環境能不能在只有IPv6的新世界中使用。
| | | 我的PC沒有連接在IPv6，但是依然可以檢測IPv6支援。(Chrome, Windows 10) |
工具二：“test-ipv6.com” 網站https://test-ipv6.com
這個網站會告知您的電腦目前所使用的IPv6地址，還有您目前所連接的網路環境，是否支援IPv6。
| | | 範例：沒有連接到IPv6 (Chrome, Windows 10) |
| | | 範例：連接到IPv6。連接IPv6成功，會多出一個TAB「Other IPv6 Sites」。(Chrome, Windows 10) |
令我比較意外的是，我手邊的 iPhone手機、Android手機，也已經是IPv6使用中，更精準的描述是，IPv6/IPv4 Dual Stack雙協議。我的電信業者是中華電信。
| | | iPhone (iPhone SE, Safari) 成功連接 IPv6 的畫面 |
| | | Android (Samsung S8, Stock Browser) 成功連接 IPv6 的畫面 |
所以我才說，您很可能已經天天都連接在IPv6網路上，而且使用好一陣子了！所以，您完全不需要擔心，IPv4地址用完的問題。
我目前還沒有機會，分別拿各家電信業者的行動網路，都來測試看看，結果如何。如果您看了這篇文章，是否可以在下方留言，跟我分享，您使用不同電信業者的結果如何呢？
One more thing…
IPv4地址即將用完，已經不算是什麼新鮮的新聞了。事實上，我判斷也不太可能有這麼一天，IPv4地址「百分之百」的全部乾淨的被用完。這是因為，「區域網際網路註冊中心」，或者是電信業者的內部，持續的都在做IPv4地址回收的工作。就算今天真的都用完了，改天也有可能因為回收，又多出一段IPv4地址，可以讓「區域網際網路註冊中心」再分配。
因此，大家也不需要覺得意外，即使最近每年都在討論IPv4地址已經用完，可是怎麼IPv4地址好像一直都沒有真正用完的一天。
有些公司或組織倒閉了、消失了，之前分配給這些公司的地址，當然可以回收使用。
有些公司或組織當年分配到A等級地址，後來發現，其實用不了這麼多，當然也可以繳回回收。例如美國的史丹佛大學自發性的在2000年繳回36.0.0.0/8。
我是洪李吉。我的網站是「Cisco學習資訊分享」。我們下次見！
我們普通的網際網路使用者，只需要將網路連接到網際網路服務業者(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學習資訊分享」。我們下次見！
| | | 「林蔭大道」香港中文大學 |
這一週，全球的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學習資訊分享」。我們下次見！
我們經常需要做網段內的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-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學習資訊分享」，我們下次見！
在台灣我經常觀察到，好多公司的資訊機房內，會在機櫃頂端放著好幾包「乖乖」餅乾。難道這麼做，機房就真的會變得「乖乖」嗎？我今天來聊聊這個輕鬆的話題。
「乖乖」風潮
到底是誰先發起了這股「乖乖」風潮，今天應該已經是不可考證了。
大致上的起因，是因為資訊系統維護的日常工作當中，經常發生一些過於巧合的意外。一直都很穩定的系統，偏偏在放假前一天停止服務；有些從來都不曾故障過的硬體，半夜忽然故障發送告警；更新軟體每一次操作都成功，就只有我操作的這一次，軟體重啟後才察覺到服務帶不起來、等等等。
某些朋友也許在偶然間發現，如果在資訊機房、機櫃頂，放了幾包「乖乖」餅乾之後，這種巧合的意外，「感覺起來」，好像比較不會發生。似乎「放乖乖」和「更穩定」兩者之間，猶如真的存在某些關聯性。
這是迷信嗎？
「感覺起來」有關連性，不代表可以從客觀的統計過程當中，歸納出相同的關聯性。假設我們要永久的釐清，需要去蒐集數據，來證明「放乖乖」和「更穩定」兩者是否相關，或是不相關。
我還沒有找到研究報告，我個人目前也還沒有機會進行這種統計。我的確沒有足夠的證據，來指出這就是迷信。
我的看法
不過，我直觀認為，因為下面這幾個理由，「放乖乖」不只不會讓系統更穩定，反過來，還可能增加資訊機房的維護風險。
第一、可能散發香味
「乖乖」的包裝，經常會因為各種原因，釋放出餅乾的香味，甚至於我們人站在旁邊，都聞得到。機房內部擺了這種有機會洩漏香味的餅乾，反而會增加了吸引老鼠、蟑螂、螞蟻的風險。
老鼠會啃食任何物體，包括「光纖」、「網路線」。蟑螂、螞蟻有可能在溫暖的網路孔洞內結巢產卵。這些可能性將變成潛在的機房安全風險。
第二、地震時餅乾袋會掉落
雖然餅乾本體不重，但是當地震時，從機櫃頂落下的時候，高度落差的重力加速度的結果，撞斷一兩個光纖接頭的可能性是很大的。
或者，餅乾袋摔落後萬一破損，很可能造成餅乾散落一地，在資訊機房內，真的很不容易清理乾淨。
第三、彩色包裝袋干擾視線
沒有擺放餅乾的時候，很容易直接用肉眼察覺，機房、機櫃頂並沒有不該出現的異物。
當花花綠綠的彩色包裝袋，擋住視線的時候，要辨認到底是異物、或是單純的餅乾，變得非常困難。
簡單的結論就是，我建議大家，千萬別在機房、機櫃頂，繼續擺放「乖乖」餅乾了！
| | | 哲徑、和校訓碑文香港中文大學 |
One more thing…
很多意外的發生，只要花點時間仔細分析，其實背後都有發生的原因。沒有解決背後的因素，意外將會一直重複發生。我這裡試著分析前面提到的三個例子。
「一直都很穩定的系統，偏偏在放假前一天停止服務」：很可能是系統設計的缺陷，例如一段時間之後，只要硬碟、記憶體滿了，隨時會停止服務。
「有些從來都不曾故障過的硬體，半夜忽然故障發送告警」：只要是旋轉的物體，都會磨損，最後就故障。這包括散熱風扇、硬碟。
以上兩者，平常、白天也可能會發生，只不過，沒有打擾到管理人員的休息時間，大部分的管理人員不會記得曾經發生過。
「更新軟體每一次操作都成功，就只有我操作的這一次，重啟後才察覺到服務帶不起來」：軟體的更新，有失敗的風險是正常的。如果要提早發現風險，更新的軟體最好預先在測試環境中，確認更新的操作過程和結果，再到生產系統操作。
這幾天，農曆的中元節快要到了，很多公司都會用餅乾來做拜拜，「乖乖」當然也是熱門選項之一。
我的提議是，「乖乖」餅乾是要發給「工程師」，在休息室吃的，不是讓您擺在機櫃上面的。吃完「乖乖」以後，「工程師」們才有充足的力氣，努力讓您的機房變「乖乖」。
我是洪李吉！我的網站是「Cisco學習資訊分享」。歡迎常回來逛逛！
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
在搭乘飛機的時候，每個人都會被告知手機(移動電話)必須要切換成飛航模式、或者是關機。大家也許看過了下面的這個趣味影片。我相信，每個人一定都很好奇：為什麼？
影片中，這幾個質疑，我相信大家也很想要知道為什麼：
1. 造價九千萬的飛機，會被我的美金四十元的iPod Shuffle所干擾？
2. 難道我可以用我的任天堂3DS來綁架這架飛機？
3. 為什麼飛機不會干擾到我的手機？
4. 其他手機也不會干擾到我的手機？
5. 我上次忘了關機，最後也沒事啊！
國語字幕的影片，請參考這一個。
一切的恐懼，我相信都是來自於這個熟悉的聲音
(這個原本的聲音影片已經被移除，我替換成下面這個。大家可以搜尋 "GSM noise"找到類似的聲音素材)
只要當我們的手機靠近喇叭、麥克風，如果剛好又接到電話、或是簡訊的時候，一定都會聽到這個急速的、”達達達”的干擾聲音。
我在觀賞Air Crash Investigation這一系列的電視影集後，我才發現，駕駛員和塔台之間的通訊，都還是類比式系統。也就是說，只要有乘客的手機正在通訊，這樣子的 “達達達” 聲音，的確會造成駕駛員聽不到塔臺說話的內容。
造價九千萬的飛機，會被我的美金四十元的iPod Shuffle所干擾？
只有駕駛員、塔臺之間的通話會被干擾。其他例如GPS、羅盤、飛行數據傳輸等等，因為頻率段都和手機沒有重疊，其實都不會被干擾。
只有導航用的聲音通話會被干擾，跟數位化的導航系統，是完全無關的。
從工作原理來看，只需要將手機切換到飛航模式，不要發射電磁波，其實是完全不會有干擾問題的。大部分的國家，規定都已經修正成只需要切換到飛航模式。不過，一切請依照當地的法律，聽從空服員的指示，一定不會出問題。
難道我可以用我的任天堂3DS來綁架這架飛機？
當然不行。
為什麼飛機不會干擾到我的手機？
其他手機也不會干擾到我的手機？
移動電話目前使用的技術，自從第二代(Second Generation, 2G, GSM)之後，全部是使用”數位式”的通訊技術。數位式的通訊技術的特性，因為聲波已經預先被轉換成0或是1的數字，只要干擾的信號，不會造成0或是1的數字的辨識錯誤，或是數字可修復，完全不會有聲音內容錯誤(干擾)的問題。
我上次忘了關機，最後也沒事啊！
這些”達達達”的干擾聲音，一般駕駛員，的確可以透過重複、或是覆誦的方式，來確認塔臺的指令已經正確收到，因此，我們的確幾乎沒有聽過，真的因為通訊干擾，而直接造成飛安危害的事故。但是，駕駛員在飛機起降過程，其實都是非常忙碌的，少部分人為了自己的方便，造成駕駛員的分心，真的不是聰明的做法。
另外，飛機即使已經降落到地面了，塔臺還是有可能要透過類比系統，來告知駕駛員，必需改換滑行道、停機閘門，等等。請務必等到飛機已經停到停機閘門，完全靜止不動了以後，再將手機從飛航模式，切換回正常模式。
One more thing…
通常飛機距離最接近的移動電話基地台，都還有非常遠的距離。如果在飛機上面，直接連接通訊，一來需要浪費大量的手機電力來發射信號，同時，因為好幾百人的手機同時登入基地台，即使信號強度不是問題，登入所要花的時間，一定也都是平常的好幾倍。
我自己的習慣是，進到航站大樓內，剛從飛機下來的乘客比較稀少的區域，我才切換到正常模式，來減少手機電力的浪費，和等待的時間。給大家參考！
| | | 吉野櫻。玉淵潭公園，中國北京市 |
大家好！我是洪李吉。大家應該已經知道，Google即將停止Google plus服務。如果您是來自於Google+找到我的「Cisco學習資訊分享」網站，或者是您透過Google+訂閱這個網站的話，我建議，將訂閱方式，儘快修改成我下面的建議：Twitter、Facebook、或是Email其中之一。
Twitter服務是我認為最接近於Google+的服務。未來我會將原本打算張貼在Google+的內容，全部改在Twitter這裡發布。
如果您本身就使用Twitter，歡迎您直接跟隨(Follow)我的帳號：@hongliji
https://twitter.com/hongliji
即使您沒有使用Twitter，我也建議您將Twitter網址加成書籤，偶爾過來逛逛。大致上，「Cisco學習資訊分享」網站內，只會有我自己寫的內容。但是，如果我發現其他作者好的、有趣的內容作品，我會在Twitter這裡分享。
接下來是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已經公告停止支援了。客戶如果硬要使用停止支援的路由器，客戶需要承擔大部分的風險。
好可惜！所損失的一百萬美金，足夠買好多好多全新的路由器了。
我給企業的建議1. 立刻盤點現有的路由器，尤其是連結到、暴露在Internet上面的。 2. 立刻跟硬體供應商確認，哪些路由器已經停止支援的，或者是即將停止支援的，應該立刻、儘快更換。 3. 仍然有支援的路由器，需要逐一確認，上面的作業系統已經是最新修補過的版本。
| | | 銀杏大道(イチョウ並木)，日本北海道大學 |
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上面，同時不讓來賓看到密碼。事實上，這個方法一點都不安全。來賓只需要讀過這篇文章，一樣可以將您以為看不到的密碼，給顯示出來的。
企業客戶，別再使用這種只求心安的密碼保護方式了！
| | | 吉野櫻、綠柳樹、藍天、好多遊客玉淵潭公園西門，中國北京市 |
當我們觀察到，一個網路交換器的物理埠上面，學習到多重的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:12:5A00:15:5D00:17:FA00:1D:D800:50:F2 | | XenSource | 00:16:3E | | KVM (QEMU) | 52:54:00 |
前面這些列表，所假設的，都是虛擬機器只使用各廠牌方案預設的、保留的MAC地址範圍。事實上，虛擬機器的管理者，很容易就可以透過各種設定，將MAC地址改換到其他的OUI範圍內。因此，這個方法，只能算是一個簡單的輔助的工具。使用時，需要注意它的限制。Welcome to virtualized world!
| | | 吉野櫻下，仰望著天空玉淵潭公園，中國北京市 |