在同一台控制器與同一版本上，Total Memory數值理論上是不會變的。
某天突然發現同一台控制器的Total Memory的數值竟然有變動，第一時間就想到是不是更新韌體的問題。
使用一臺配置4GB記憶體，使用8.10.0.6版本時，得到的Total Memory為3776100。
將韌體降版到8.6.0.20時，得到的Total Memory為3776184。
因此，其實「升降韌體版本」，會導致偵測到的Total Memory有所變動。
JN的電腦網路日常
網路教學與日常學習
JN的電腦網路日常
網路教學與日常學習
2023/04/12 Netmiko網管構思
任何一個收集資訊並呈現的程式都需要具有三部分:
- 蒐集資訊並整理
- 將整理資訊儲存
- 將儲存的資訊取出應用
藉此去切割不同module該設計的功能，為了讓不同module可以順利串接，就需要制定一套共用的語言命名邏輯。
網管構思最難的不是在於寫Code，而是訂一套Rule，這Rule要能協調三部分順利運行。
蒐集資訊並整理
這部份使用CLASS，讓網路設備變成類別，可以依照輸入的設備清單變成一個個實例。實例中包含連線、下指令、過濾出資訊。
這部份以Netmiko作為主力，輸入的設備清單也建議轉成Netmiko友善的格式，白話就是Netmiko連線需要什麼資訊、下指令。
將整理資訊儲存
整個程式最耗費資源與時間的部分就是蒐集資訊並整理，因此若是將資訊妥善儲存下來，即便略過第一部分，也可以從儲存的資訊去還原第一部分得到的結果。
比較通用記錄的方式是: 時間、設備IP、指令、結果。
以設備清單加上執行時間點作為資料夾，如此可以應用在不同場域，避免相互干擾。
能儲存的方式有許多種，建議依循資料庫的思維去整理分割資料表。這對於下一部分應用會很有幫助，能很快速的直接使用。
這部份先以csv為主，後續轉為sqlite。
將儲存的資訊取出應用
如果能套用資料庫，開發這部份就是非常迅速且容易的。
應用的話取決於想要呈現的內容以及使用什麼應用程式呈現，我們需要把資訊再過濾並重新整合，變成最後應用程式能使用的資料與格式。
共同命名規則
如果是順序法撰寫，會發現一個設備能找到很多個MAC Address，MAC Address格式也不一樣。到了第三部分，就會開始應用這些取得的資訊，會重新定義各種資訊在整理過程中是什麼角色，寫套算法，開始演算，然後取得最終想要的結果。
這時候，資訊被重新定義的角色就很適合作為模板的Value名稱，更適合將於各品牌的同意義不同名稱變成一致的名稱。
2023/04/12 透過ARP+MAC Table追蹤終端所接的Edge Switch。
透過ARP與MAC Table找到設備是網路工程師的基本工，常用技術之一。
原理很簡單，鎖定住一個IP之後，就以ARP取得該IP的MAC，然後透過MAC Table不斷往下追查直至Edge Switch。
那如果在「程式化」的前提下，這套思路只能專心處理一個MAC，會顯得沒有效率。執行次數會幾乎等於ARP總數，實際上只希望讓執行次數跟Switch數目相同就好。
以下是程式化的思路
- 假設所有Switch的IP與MAC是已知的，為「MgmtIP」跟「MgmtMAC」。
- 先取得所有Switch的ARP跟MAC Table，ARP得到「EndpointIP」與「EndpointMAC」、MAC Table得到「EndpointMAC」、「EndpointLinkedInterface」。
- 以ARP數目最多的Switch當做Core Switch。
- 擇一條(群)ARP為主，建立串列Switches，如果該「EndpointMAC」的「EndpointLinkedInterface」上能找到Switch的「MgmtMAC」，將該Switch放入該ARP的Switches串列。
- 計算Switch的CoreSwitchDistance，從Switches串列中取出沒有CoreSwitchDistance的Switch，以Core的「「MgmtIP」跟透過MAC Table找到「EndpointLinkedInterface」，該Interface上有幾個存在於Switches串列中Switch的「MgmtMAC」再加1(補上CoreSwitch)即為該Switch的CoreSwitchDistance。
- 將ARP的Switches串列以Switch的CoreSwitchDistance重新排序，以小至大排列。
- 以ARP為主，建立字串SwitchesPath，從CoreSwitch到CoreSwitchDistance最遠的Switch，將DeviceInfo(可以是SwitchName、MgmtIP等擇一)與「EndpointLinkedInterface」加到字串SwitchesPath中。
照以上步驟，如此可知道CoreSwitch到Endpoint所經的路徑，經過優化的話，可以讓執行次數為Switch數。
網工界TextFSM模板-ntc_templates
雖然Netmiko可以支援TextFSM去處理輸出文本，但是網路品牌那麼多，就算是同一家也不見得指令都是一套邏輯，要產生TextFSm模板是相當費工的，一是要取得指令輸出的Data，二是要針對Data做模版，因此，還是找大神做出直接使用會比較省工。
ntc_templates是一個集TextFSM版本的模組，看到這篇文章《写textfsm模板太难？看这里-ntc-templates》，發現Windows是不能直接運行ntc_templates，不過也沒關系，進到github，正如這篇文章的參考文件，裡面就是可以用的template，會發現其實也不是應有盡有。
當然要自己刻的話，取得下指令後的DATA是很容易的，但是template要寫好就要寫好正則表達式，就需要一點技術，例如IP Address要怎麽匹配？不妨就直接看ntc_templates內的template去觀摩(照抄)，至少不會寫不好。
以下是個人的Github連結，會放上目前有做的template。
部落格撰寫指南與分類標準
這篇用於記錄與說明撰寫方針與標籤、分類的標準說明。
撰寫指南
無
標籤
網路技能類
- 網路基礎: 入門需要學會的，電子書會寫到的。
- 網路進階: 進階去應付更多場景與需求需要學會的，電子書會寫到的。
- 網路專業: 電子書沒有寫到的，學會靠個人觀察與領悟。
文章描述本體
- 如Aruba、Windows等諸多……
分類
20230407 檢查某牌據說是供電問題的PoE Switch
如果有品牌迷思，可能就嫌棄這一牌。
為了給AP供電，買了好幾台以link結尾牌子的PoE Switch。
剛好就有一台據說是故障的，請我檢查。
插上三顆AP都沒有無法PoE供電問題，不過Switch一上電就能聞到焦味，而且隨著時間與負載更長更重時，焦味更明顯。
電器的焦味通常跟高電阻脫離不了關係，電流會以熱能損失出去，於是越來越熱，就會產生焦味。
至於好端端的設備為什麼會有焦味？拆機看最準。焦味通常意味著不要長時間運行，積熱到一定時就會燒起來。
即使知道，還是一台台負載接上，焦味越來越重。過一陣子，突然設備內發出一個聲響，就嚇得趕緊把電源斷開。再開時，下排燈號就亮不起來了。
我認為PoE Switch是一個吃電重的設備，如果設計不良，長時間運行是一件很可怕的事情。Switch應該在有焦味的時候，就跳出告警，不讓使用。
最讓我震驚的是，我居然明顯在作死。人無畏，就一步步越做越危險的事情，真是不應該。
Aruba保固條款
Aruba AP是有條件終身保，保到停售EOS(End of sale)後五年。一旦發生故障等，就能報修去以良品更換，因此更換。
保修除外部分
This Limited Warranty does not apply to expendable or consumable parts and does not extend to any product from which the serial number has been
removed or that has been damaged or rendered defective (a) as a result of accident, misuse, abuse, contamination, improper or inadequate
maintenance or calibration or other external causes; (b) by operation outside the usage parameters stated in the user documentation that shipped with
the product; (c) by software, interfacing, parts or supplies not supplied by HPE; (d) improper site preparation or maintenance; (e) virus infection; (f) loss
or damage in transit; or (g) by modification or service by anyone other than (i) HPE, (ii) an HPE authorized service provider, or (iii) your own installation
一般來說，AP故障的因素可歸責於人損的因素居多，網路接口針腳歪斜或斷掉非常常見，而這種屬於保固排除範圍，希望還是能妥善安裝跟保存，以避免送修被拒絕。
Aruba Airwave熱感圖繪製指南
Aruba Airwave內有個「Visual RF」的功能，可以用於繪製模擬熱感圖，以幫助人能更直覺看見無線訊號的涵蓋範圍。
要以「Visual RF」繪製熱感圖，以下為事前準備項目。
- 準備好平面圖，需要具有比例尺或是標示實際長度。
- 準備好無線資訊(如:無線涵蓋需求、AP數目、AP型號或AP擺放位置)
以下為進行的步驟:
- 新增園區
- 新增樓宇
- 新增樓層並匯入圖面
- 校正圖面尺寸
- 觀察圖面建築規劃
- 擺放AP
- 截圖各樓層熱感圖圖面，並且截圖各樓層AP數目統計。
- 匯出樓層平面圖備份
以下為建議項目:
- 長度建議使用「米 meter」。
- 樓層命名為「XF」
- 資料夾建議以「日期」命名，將來可能會有多個版本。
- AP建議以交錯擺法或是蜂巢狀擺法，不要用矩形擺法。
- 若是AP數目受限，且中間有走道而兩側有房間，建議以閃電狀擺法至房間內，而不要擺在中間走道。上下層則鏡向閃電狀擺法。
- 牆壁畫了，熱感圖通常會比實際較差。不畫牆壁，熱感圖通常會比實際較好。基於多種原因而圖面僅供參考，所以建議不畫牆壁，可省下不少工。
- Aruba OS(v8)預設EIRP，2.4GHz為6-9，5GHz為12-18。而規劃的AP-535 TX功率，2.4GHz為12dBm，5GHz為12dBm；規劃的AP-505，2.4GHz為18dBm，5GHz為18dBm。
- 平面圖無法完整呈現現場資訊，且AP功率會動態調整，因此熱感圖僅供參考。
- 熱感圖目的是幫助瞭解訊號涵蓋範圍而進行弱處改善，沒有改善的需求就沒有做熱感圖必要性。
Aruba控制器靜態一對一NAT設定
靜態一對一NAT常用於將Server做內部外部IP連結，使得連線外部IP就等同於連線到內部IP。
以下示範為將「172.16.3.40」對上「172.16.254.202」。
首先，要先設定NAT Pool。
記得Static(靜態)要打勾。
接著，要新增一條Policy，新增NAT規則。
最後，將interface套上對應的Policy。
Aruba 虛擬控制器(VMC) 使用 RemoteAP模式
虛擬控制器因為缺少TPM(Trusted Platform Module)模組，且TPM憑證是放在MM(Mobilty Master)上，因此直接使用AP內建憑證會無法使用，需要使用自簽(self-signed)憑證。
首先先讓AP以CAP模式跟控制器報到，之後如圖設定:
Deployment: Remote
Authentication: Certificate
Truset anchor: self-signed
RAP除了需要切換模式之外，還需要設一組內部IP，供RAP跟控制器以Tunnel溝通使用。
如果從VMC看LOG出現以下，代表ip pool沒有設定，因此get ip address失敗。
Apr 6 11:06:55 2023 isakmpd[6313]: <103103> <6313> <WARN> |ike| 172.16.3.128:56221-> IKE SA Deletion: IKE2_delSa peer:172.16.3.128:56221 id:2674563824 errcode:ERR_IKESA_CLEARED saflags:0x51 arflags:0x801
Apr 6 11:06:55 2023 isakmpd[6313]: <103061> <6313> <ERRS> |ike| Unable to get IPv4 Address from pool
Apr 6 11:06:55 2023 l2tp[6587]: <306419> <6587> <ERRS> |l2tp| shared_cli_get_addr(): Caller:ike. Failed to get ip address from L2TP pool:default-l2tp-pool.
Apr 6 11:06:55 2023 isakmpd[6313]: <103061> <6313> <ERRS> |ike| Unable to get IPv4 Address from pool2023/03/30 Aruba7205升到8.10.0.6版本後，某些型號AP無法順利被控管
這是一個救火的案子，前陣子釋出個資安漏洞消息，如果要解決漏洞，需要將控制器版本升至8.10.0.5以上，而我那漏洞消息公佈的前一陣子，也做了不少升級到8.10.0.5版本，所以漏洞發佈後，我其實沒做升級的。
那陣子，也不少把控制器升級到8.10.0.6版本，不過都沒有發生啥異常。如果說升級就會導致某型號完全不能用，那肯定是個大事件，OS發表前早就該被測出了，發表後公測也早該被測出了，畢竟8.10.0.6發佈到這次客戶升級控制器也過了快一個月，因此我推測是個案，但也無法驗證是不是通例。
基於救火，就教客戶重置AP，再從IAP網頁管理介面去轉換。原負責同事是這麼想得，但是失敗了。
跳出錯誤訊息「圖像驗證失敗…」，我就知道是使用機器中翻英，原本英文詞是「image」，也就是我們常說的韌體。
從log可以看出來，從客戶的Aruba7205 8.10.0.6版本下載的OS，是無法通過驗證的。要怎麽知道檔案有沒有被篡改？有些下載網站會提供檔案的HASH值，像是以SHA去HASH整個檔案得出來的值，只要檔案被改一個bit，產出的HASH值就完全不同，只要將下載來的檔案比對網站上提供的HASH值，若一樣就代表可信任，如果不一樣就要當心了！
因此，我覺得問題是出在控制器的apimages中。
身為Aruba 4個P的我，因此又更深掘那些電子書跟討論都不會寫的基礎運作。
如果AP要被納管的話，AP使用的image是從控制器身上下載的。而且「檢查版本，下載iamge」這個步驟是AP被納管過程中第一次重開機部分，也就是最優先檢查的部分。如果AP的OS跟控制器的OS版本不一致，AP就會從控制器上下載OS，如此一來達到AP會主動跟控制器版本對齊。
AP在同版本不同型號的控制器上切換，是不需要重新下載OS的。實測也證實，AP沒有再重新下載OS。
藉此，我去比較客戶的Aruba7205跟其他的VMC或是70xx系列的AP image，發現客戶出問題的apimage跟VMC與70xx系列同AP型號的apimage是不同大小的，而VMC與70xx系列的apimage是相同大小的，所以是客戶控制器中的apimage有問題，這也跟AP的Log對得上。如果是實體控制器，可使用「dir flash」去檢查apimages內的檔案大小。
解決狀況遠比找出造成狀況的原因還重要。
接下來就要知道，到底AP去檢查跟控制器版本時，條件是以檢查apimage檔案大小一致？還是檢查版本訊息一致？
「我只是想知道解決方法可不可行。」我拿到一顆504測試，因為都是用同樣的image所以可以替代。
答案是，檢查版本訊息一致即可。
所以幫AP刷正常的韌體，就能讓AP正常被客戶的控制器納管。然而幫AP刷IAP韌體是新手境界，而刷成Thin AP韌體就是高手境界，想刷，要先有個Thin AP的韌體，這沒有放在ASP可供下載呢。
想想之後，我覺得大概只有我出馬才能解決了。
在公司使用AP-504測試可以過，方法就是讓AP先刷到正常的AOS 8.10.0.6，接著再去跟客戶的控制器報到，避免AP更新錯誤的image，避免image檢驗失敗而失聯。
到客戶端，很快，我就讓五顆505，能被控制器控管，提供正常穩定的無線服務。然後發現565也是同樣的image，只是這一段就快不起了😂。
TextFSM正則表達式無法使用()
如果在template使用包含「()」的pattern，會跳出類似的錯誤提示「Value ‘([\(\)]+)’ must be contained within a ‘()’ pair.」。
目前問題已經被修正。來源
TextFSM使用1.1.2版本的話，會受到影響。
升級至1.1.3版本，就能解決狀況。
題外
最近在弄網路設備的template，剛好就碰到資訊帶有「( )」，括號內的訊息重要度蠻高的，所以得找到解決辦法。
日後應該會在github發表一些TextFSM模板跟Netmiko搭配應用，也會在這裡發表詳細說明跟介紹。