最近有個下訂到到貨快兩年的核心交換器到，適逢最近開始著手大量python網管的構築。如今重新審視，感覺到很多網路的概念被重新理解，發現對概念的理解更加到達根基點或者稱為原理，對網路的理解可能要遠超於公司前輩了。
說到設備更換或遷移，最重要的是什麼？就是將新設備上架與線路重接後，對所有設備而言，自己所屬的網路都是通的。
舊(手動)的思維是什麼？就是我們先取得設備設定檔，將設定同義轉換到新設備上，最後在依(舊設備)順序，重新接在新設備上。
有時候會發現，假設所有Port都同屬一個VLAN，所有Port也沒有Description，那其實線順序亂掉也無妨，也能保證能用。
不過為了美觀與整齊，假設能有功夫作出順序，那作出順序來，能讓後面管理更好理解些。真亂序接回在關鍵點上反而對人來說是一場噩夢，尤其是核心交換器部分更需要有秩序接法。
我們希望網路能通，於是盡可能還原設定與接線順序，盡可能還原之前的樣貌，最好百分之百還原，因為原本的樣貌是沒問題的，如果有問題基本上會在漫長的使用中被發現改正，時間便來到遷移之前。
為了能百分之百還原，可以看成兩個層面: 設定層、實體層。
設定層為自身設備上的設定。
實體層為自身與其他設備的連結關係。
如果設定層的設定能同義轉換，線路只要照原順序接回去，就能達到實體層去配合設定層，而還原網路環境。
假設都每一Port都同VLAN，於是實體層(線路)隨意接，就能達到設定層去配合實體層，而還原網路環境。
最花功夫(人力)的是什麼？就是調查實體線路接線順序與連通情況，接著就是拔線照計劃接回去，第三就是做設定上的同義轉換。這三大環節，都需要具備「細心」，一旦哪個環節錯誤，可能就未能還原網路環境，導致網路不通，倘若IT不熟自身 環境，這時候要排查是非常困難的，因為之前沒有記錄此環節資訊，就是痛苦。
但仔細思考，其實不論是「實體層去配合設定層」或是「設定層去配合實體層」，我們都是要做到一點，實體去對應到其該有的設定，也就是相互連結。
「設定層去配合實體層」則是最節省人力的方式，節省人力也意味著是復原時間最少的方式，即便目前AI生成多麼厲害，對任何需要人力的項目都沒有辦法。
有沒有什麼網路架構，是可以讓設定層去配合實體層？答案是role-based，這在Aurba Total Solution是做得到的。但Aruba Total Solution並不是任何環境都做得到的，因為資源不足，就算資源足，網管人員技術跟知識可能也不足以維持。
Role-based其實就是SDN(Software Defined Network)，這是個宣傳常見名詞，但軟體要怎樣定義網路？這其實才是關鍵技術。為了要保證任意接都能通的前提下，勢必要想出任意接能通的方案，就需要對網路基礎有概念，更重要的是角色間的連結與關係，才能寫出泛用的方法。
會講SDN的人，多半對網路基礎沒有深刻瞭解。(？)
回到SDN的立場，要達到設定層去配合實體層，需要關鍵一點，必須從實體層得到資訊，不去限制實體層接、不接或亂接，然後再依實體層來的資訊去讓設定層再去配合實體層。
什麼是設備能從實體層得到的資訊？最通用的就是MAC Address。
在Role-based的網路架構中，可以針對MAC或是802.1x的帳密資訊去得到對應的VLAN跟相關權限。所以SDN的實作，依據MAC去判斷給與對應的相關設定，是個真實存在的做法。
依照SDN的做法，先將MAC Address綁定來源Port的設定，變成對應的，查MAC得到設定就像查字典查詞得到解釋。一旦MAC Address從來源Port來被學到，就把該Port設定給成MAC Address所對應的設定。
這樣人力就能大解放，不用調查本來的實體線路順序與連通情況，也不用按線路記錄順序接回，線路任意接，隨後靠SDN帶對應的設定，使實體與設定的關係跟更換前一致，就如同還原更替前的網路環境。
SDN也可以讓Switch與Switch間自動綁成Link-Aggregation，接兩條就綁兩條，接三條就綁三條。核心算法就是之前的提到MAC Table的空集合去判斷兩Switches各一Interface是否相鄰。
要完成SDN，就需要先有個程式，再蒐集資訊，在更替期間不間斷地跑，使Switch接收到的資訊能影響網路設定。如果設備都是上線那還好，但多半都是在離峰時間像是午休、下班或週末去切換，設備不在線，蒐集不到資訊，使得SDN未能切換完整。
線路有接但未通，人為設定；線路有接有通，SDN設定。
簡單來說「人只要記錄有接線的Port」，其餘交給SDN，就能得到完整轉換的建議。有接沒通，需要讓線路接到對應Port，設定可以由SDN或人為操作。若線路有接有通，就能交給SDN設定。