就在三天前，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學習資訊分享」。我們下次見！