Cisco

我們藉由一個連接三個辦公室，三個網段的簡單拓樸，來說明連接辦公室網路，維護正確的路由表內容的時候，到底應該使用靜態路由，還是多多運用動態路由協定。網路拓樸中，三部路由器，分別代表一個獨立辦公室，背後各只有一個區域網路、LAN網段。圖中每一個區域網路，我只列出一部電腦，來代表網段內的使用者，或者是伺服器。為了聚焦在路由表本身，IP地址已經全部配發完成。電腦上面只有基本網路連接功能。我們的目標是，完全接通三個辦公室中，不同的區域網路，區域網路內的任何電腦、電腦之間，都必須完全連通。路由表的基本知識回顧我們先回顧路由表的基本知識。路由器在轉送每一個封包的時候，一律查詢路由表。封包的目的地地址，如果在路由表中存在定義，那就按照路由表的定義轉送。反過來看，封包的目的地地址，如果在路由表中找不到定義，這個封包就會被直接丟棄。回到三個辦公室的情況。任何從電腦出發的封包，要到達其他辦公室的電腦的話，看完網路拓樸，我們馬上知道，都必須穿越兩次不同的路由器。因此，第一站的路由器裡面的路由表，必須包含兩個遠端辦公室網段的資訊，封包才有機會，被往下一部路由器轉送。事實上，拓樸中的三部路由器，上面的路由表，都必須包含對面遠端兩個辦公室的網段資訊，否則，完全的接通，肯定無法實現。路由表的初始內容接下來，我們觀察路由器上面，路由表的初始內容。初始的路由表的內容，有一些資訊是自動產生的。例如，直接相連的網段。除此之外，全部都必須透過我們的設定，來將缺少的路由表加進來。這樣的初始內容，肯定是不夠的，因此網路連通性，還不存在。所以，我們開始加入缺少的路由表內容。要加入路由表，我們有兩個選擇。靜態路由動態路由協定我們兩者都試試看，先別急著下結論。最後我們再來比較，哪一個工具比較好。加入路由表方法一：使用靜態路由依照剛才分析的結果，我們需要在三部路由器上面，分別透過靜態路由工具，來加入各兩筆的靜態路由資訊。以R1為例子，需要在IP、IPv4分別加入這兩筆：[R1]ip route 10.2.1.0 255.255.255.0 10.0.12.2ip route 10.3.1.0 255.255.255.0 10.0.13.3ipv6 route fd10:2:1::/64 Ethernet1/0 FE80::200:FF:FE12:2ipv6 route fd10:3:1::/64 Ethernet1/1 FE80::200:FF:FE13:3完成之後

不安裝額外軟體，在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,Interfac

就在三天前，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問題，我提出下面幾個思考的切入點，來避免我的工作網路遇到，跟進行中的「蘇伊士運河」事故一樣糟糕的結果。停止服務事件，發生的機率有多大？雖然我沒有具體的統計數字，但是，經驗上告訴我，纜線、路由器、交換器、防火牆，任何可單獨安裝的硬體單位，一年內完全沒有任何故障的機率，幾乎是零。就算完全沒有故障，也只能算是運氣好。我必須預期，一條纜線，一個路由器，一個交換器，一個防火牆，就在未來的一年內，一定會產生故障的事件。在這個情境下，來

我這幾天在「網路攻防戰」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使用人數大增。同時最近這幾年，

今年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」字母後面，我開始遲疑了，我到底應不應該，接著按下Ente

很多網管工作的朋友，不能立刻接受IPv6網路技術的原因，我的觀察，是因為感覺到IPv6技術好複雜。我設計了這個簡易的網路架構圖，來說明，感覺不一定完全正確，IPv6其實可以遠比IPv4容易設定。在這個架構圖裡面，一共只有4套路由器，8個網段。其中路由器、路由器之間，一共只有6個網段，再加上用戶端、伺服器端各一個網段。只有這樣，就這麼簡單的拓樸。 假設給定的需求只有「連接用戶端、伺服器」，不限定第三層的協定，使用IPv4或者是IPv6。我們分別完成它們的設定，然後來做兩者之間的比較。IPv4設定連接傳統的IPv4設定的流程，我們必須先分配IPv4地址。地址決定好之後，我們再到路由器上面，設定IP地址還有路由協定。我們會發現，大部分時間，竟然是花費在IPv4地址的計算，而不是路由器的設定。下面我只列出R1的設定。hostname R1interface 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/0L        10.1.0.1/32 is directly connected, Ethernet2/0O&

今年2020年11月初，我開始注意到全球IPv6的BGP路由表，突破了十萬筆，也就是100K筆。雖然中間有幾天又彈回十萬筆以下，不過，這一週左右以來倒是穩定的突破了100K。這是一個有趣的里程碑，代表著，IPv6的使用者人數、電信業者、企業，都越來越多，數量上已經來到一定的規模了。我記錄下這個里程碑，順便分享兩個我的觀察。IPv6 BGP筆數會上上下下浮動資料來源：https://twitter.com/bgp6_table/status/1330964625127583744/photo/1Internet是一個分散式管理的網路，每一家組織、電信業者、企業，彼此之間並沒有直接的管理強制性。因此當需要的時候，電信業者、企業可能會各自自主的、動態的新增路由資訊、或者移除路由資訊。例如，將沒有用到的合法網段，從BGP設定中移除，因此，全球的BGP筆數可能會減少。例如，為了流量負載分散，可能需要將一個大網段分割成多筆的小網段路由資訊，分別送給不同的鄰接公司或是不同線路，因此，全球的BGP筆數可能動態增加或減少。當然，正常的網路擴充增加網段，或者是公司解散繳回網段，或者設定錯誤，都可能造成筆數浮動的結果。資料來源：IPv6 CIDR Report for 30 Nov 20IPv6 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的四倍長，

【好的東西儘量放分公司，爛的放總公司】我曾經在某家公司工作。當時我在總公司，管理全公司整個集團的IP網路。因為每年的預算有限，籌備年度軟、硬體升級的時候，我經常必須抉擇，到底應該先升級「分公司」的路由器交換器，還是「總公司」的。和一般人直覺相反，我也沒有詳細和其他人討論分享，我自己心裡面的取捨，其實是「好的東西儘量放分公司，爛的放總公司」。為什麼？我來聊一聊我的這個內心原則。分公司的人力、技術資源比較有限第一，「分公司」的人力數量，技術支援熟練度，通常都比「總公司」的團隊更有限制。分公司的資訊技術支援，在我的觀察，一般都遠不及總公司。光是從人力來看，在總公司，通常會有專業分工的技術團隊，例如，專門有一群人做伺服器的任務、另外一群Windows作業系統，或者是還有一群人做網路。每個領域都有專門的團隊，分工執行。但是在分公司，通常都沒有這麼多的資訊人力。少數的幾個員工，當他們在值班的時候，可能同時必須負責處理伺服器，又要同時處理Windows作業系統，還要處理網路的問題。如果我們給他們比較糟糕，問題很多的的路由器、交換器的話，當遇到問題的時候，他們不一定能夠像總公司專門的技術團隊能夠熟練的處理，時間上也不允許他們，花太多的力氣去判斷，光是「網路」這個技術領域，到底發生什麼狀況，只因為一個員工，同時要負責好多系統或任務。還有技術文件，或是教育訓練的資源，「分公司」普遍來說都比較欠缺。深入的技術問題，我寧可盡量控制在「總公司」內發生，專業團隊可以就近直接處理。別讓這些複雜的技術問題，發生在「分公司」裡面。只要「分公司」的人沒辦法當地就近處理，接下來就是要「總公司」自己的團隊下去處理。如果經常需要「總公司」的團隊派人去處理，馬上我們就必須面對的二個問題。分公司的距離好遠，交通的時間和金錢花費都很高第二，「分公司」的距離好遠，來回交通的時間和金錢，花費都很高。距離越遠，交通的時間和金錢花費就會越高。這是直接的結果。緊急狀況的時候，「總公司」的人即使願意花費交通的時間跟金錢，到現場去處理，有的時候也是趕不上時效性、達不到時間的目標，「緩不濟急」。例如網路斷線的狀況，只要故障沒有排除，好多系統會立刻停止工作。另外，「總公司」的員工，通常還有很多任務要去處理，不論是「年度」的、「季度」的申請流程、報表、安全稽核等等，全部都必須由「總公司」的員工處理。如果你把有限的時間都花在交通上，其實也是很不划算的。另外，我自己當時工作的時候，我

首先我要澄清，製作這個影片，我並不想要教大家，去破解別人的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網路服務，但是，我們一定要有足夠的能力，來監視企業場

【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

最近不少人在討論「全球 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 快照為什麼我現在跟電信

我們普通的網際網路使用者，只需要將網路連接到網際網路服務業者(Internet Service Provider，ISP)，剩下的網際網路的連通工作，業者會在幕後幫我們完成。但是站在網際網路服務業者的角度，業者不只是必須跟國際的ISP連接，在國內，也必須同時跟國內的其他業者ISP相連接。於是，我們需要一個額外的腳色，專門服務業者和業者之間的網路封包的連通和交換。這個額外的腳色，就是 Internet Exchange (IX)，我稱為「網際網路交換中心」。我藉著下面假想的、台灣的例子，我們就可以理解網際網路交換中心，扮演什麼重要的功能。假想情境：五家業者首先，我先假設台灣國內有五家網際網路服務業者。這五家業者，各自租用連接到外國的國際線路，來讓各自的租用客戶，可以跟國際的Internet 相接通。這樣已經可以讓網際網路開始工作了。但是，並不是很有效率。我假設台灣國內某個熱門的購物網站，伺服器架設在業者一(ISP 1)。熱門購物網站的用戶端，肯定不只是業者一自己內部的租用客戶，一定也有不少的用戶，是來自於業者三、或者是業者五。這時候問題來了。業者三租用客戶的封包，必須先跑到國外，才能再連回到業者一。反方向的流量，或者是業者五的用戶，也有完全相同的困擾。在這個情境下，網路依然可以接通，只不過，所走的路徑並不是最短路徑，網路延遲時間會非常高。同時，出國的國際線路，單價很高，頻寬很貴，這並不是最經濟的網路連接方式。可能方案一 業者之間直拉國內線路在這個假想的情境中，我假設業者一和業者三、業者五之間，願意投資直拉的線路。這時候，封包就可以改成走台灣國內的線路。國內的線路，跟國際的線路比較，相對的單價比較便宜，同時網路延遲時間也比較短。因此，流量最佳化的問題解決了。下一個新的問題是，假設每一家業者，都有熱門的網站，都需要服務來自不同業者內的租用客戶，而且每一家業者之間，都願意投資直拉的線路。如果真的這樣拉線路，最後這個業者和業者之間的線路網，本身就會變得非常複雜。我知道，很多讀者可能覺得，畫面中的拓樸只有10條線路，感覺起來不算很複雜。但是，當業者數目越來越多的時候，例如台灣國內有20家業者，這時候線路的數字，就來到了190條 (20X19/2) 了！永久方案：網際網路交換中心我們需要一個獨立的腳色，也就是本文的主角「網際網路交換中心」(Internet Exchange, IX)。只要「網際網路交換中心」存在，業者和業者兩

這一週，全球的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

這是昨天(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泰國、曼谷市我們可以趁著這次的事故，順便檢視，我們的工作系統，是否還有單點故障全體故障的問題存在。我這裡另外提醒兩點，跟網路有關的注意事項。作業風險區，請清楚標示只要有可能造成單點故障全體故障的關鍵地點、空間，無論是硬體、軟體、線路，都應該清楚的標示。必須要讓任何操作維護的工作人員，都很容易察覺到，在附近作業必須特別小心注意。例如，我們可以透過掛牌、顏色、三角錐、等等，來提醒所有的工作人

在台灣我經常觀察到，好多公司的資訊機房內，會在機櫃頂端放著好幾包「乖乖」餅乾。難道這麼做，機房就真的會變得「乖乖」嗎？我今天來聊聊這個輕鬆的話題。「乖乖」風潮到底是誰先發起了這股「乖乖」風潮，今天應該已經是不可考證了。大致上的起因，是因為資訊系統維護的日常工作當中，經常發生一些過於巧合的意外。一直都很穩定的系統，偏偏在放假前一天停止服務；有些從來都不曾故障過的硬體，半夜忽然故障發送告警；更新軟體每一次操作都成功，就只有我操作的這一次，軟體重啟後才察覺到服務帶不起來、等等等。某些朋友也許在偶然間發現，如果在資訊機房、機櫃頂，放了幾包「乖乖」餅乾之後，這種巧合的意外，「感覺起來」，好像比較不會發生。似乎「放乖乖」和「更穩定」兩者之間，猶如真的存在某些關聯性。這是迷信嗎？「感覺起來」有關連性，不代表可以從客觀的統計過程當中，歸納出相同的關聯性。假設我們要永久的釐清，需要去蒐集數據，來證明「放乖乖」和「更穩定」兩者是否相關，或是不相關。我還沒有找到研究報告，我個人目前也還沒有機會進行這種統計。我的確沒有足夠的證據，來指出這就是迷信。我的看法不過，我直觀認為，因為下面這幾個理由，「放乖乖」不只不會讓系統更穩定，反過來，還可能增加資訊機房的維護風險。第一、可能散發香味「乖乖」的包裝，經常會因為各種原因，釋放出餅乾的香味，甚至於我們人站在旁邊，都聞得到。機房內部擺了這種有機會洩漏香味的餅乾，反而會增加了吸引老鼠、蟑螂、螞蟻的風險。老鼠會啃食任何物體，包括「光纖」、「網路線」。蟑螂、螞蟻有可能在溫暖的網路孔洞內結巢產卵。這些可能性將變成潛在的機房安全風險。第二、地震時餅乾袋會掉落雖然餅乾本體不重，但是當地震時，從機櫃頂落下的時候，高度落差的重力加速度的結果，撞斷一兩個光纖接頭的可能性是很大的。或者，餅乾袋摔落後萬一破損，很可能造成餅乾散落一地，在資訊機房內，真的很不容易清理乾淨。第三、彩色包裝袋干擾視線沒有擺放餅乾的時候，很容易直接用肉眼察覺，機房、機櫃頂並沒有不該出現的異物。當花花綠綠的彩色包裝袋，擋住視線的時候，要辨認到底是異物、或是單純的餅乾，變得非常困難。---簡單的結論就是，我建議大家，千萬別在機房、機櫃頂，繼續擺放「乖乖」餅乾了！哲徑、和校訓碑文香港中文大學One more thing…很多意外的發生，只要花點時間仔細分析，其實背後都有發生的原因。沒有解決背後的因素，意外將會一直重複發生。我這裡試著分析前面提到的三個

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 WirelessCCNA資格維持(Recertification)這部分最大的改變，就是未來參加任何Cisco的課程，包含教室、線上、自修，只要是Cisc

大家好！我是洪李吉。大家應該已經知道，Google即將停止Google plus服務。如果您是來自於Google+找到我的「Cisco學習資訊分享」網站，或者是您透過Google+訂閱這個網站的話，我建議，將訂閱方式，儘快修改成我下面的建議：Twitter、Facebook、或是Email其中之一。TwitterTwitter服務是我認為最接近於Google+的服務。未來我會將原本打算張貼在Google+的內容，全部改在Twitter這裡發布。如果您本身就使用Twitter，歡迎您直接跟隨(Follow)我的帳號：@honglijihttps://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_USOne more thing…Google即將停止Google+的服務，的確讓我感到很意外。網路界不變的定律，就是網路的技術和知識，將會持續的不停的改良和改變。未來「Cisco學習資訊分享」網站，也將會持續不停的改良和改變。希望這個網站的內容，能夠不停的帶給大家有用的資訊！我在沙燕橋上，往沙田公園、瀝源橋方向拍攝。畫面中的橋，就是瀝源橋。