前段時間，上司要求重新優化我機關的網絡IP資源。本人第一次承擔這種項目，隻得硬着頭皮，摸石過河。雖然最後完成的并不十分完美，也總算獲得一些經驗，希望能夠與各位同為類似工作而煩惱的同行們一些幫助。 俗話說，磨刀不誤砍柴時。既然要實施該項目，那就先進行前期調研，做好需求分析。經過翻閱資料和與下級機關同僚的談話了解，得知目前網絡存在着一些問題：一是管理複雜。由于各種原因，各機關的技術人員較少接觸網絡裝置，是以當需要調整網絡裝置時，都隻能通過以前的資料對号入座，而不能直接調整交換機配置，這間接增加了技術人員的管理難度；二是位址混亂。由于網絡應用的增長速度大大超出了之前的規劃，導緻早前劃分的IP子網和Vlan不夠合理。某些機關占用了較多的IP位址，但使用率不到10%，而有些機關甚至需要額外的子網作為本機關IP資源。 找出了問題所在，就要制定項目目标了。首先，減少技術人員管理複雜度。這可以通過把機關内的Vlan去掉而達成；其次，根據各機關需要，重新劃分IP子網，并保持每個機關最多使用一個C段位址（内部位址），其餘額外加的位址都去掉。 既然制定了目标，是否可以立即做呢？答案是否定的，還必須考慮項目實施與目前狀況之間的沖突，也就是可行性。由于之前的網絡規劃着重考慮了安全性方面的問題，各機關内設定了較多的子網。這是第一個問題的現狀。而由于我機關在近期部署了正版企業版防毒軟體，以及較為完善的桌面管理系統，加上不斷嚴格的網絡使用管理制度，安全問題已經退居次席了；而且我機關沒有OA（囧），通過網絡傳播的機密資訊也較少，Vlan的存在也就相對不那麼重要了。這使得第一個目标順理成章。 但第二個目标就有難度了。由于我機關所有工作站使用靜态IP位址，是以若改變IP位址，必須要求技術人員到每台工作站上進行修改。而由于跨段更換IP位址肯定會造成一段時間内的部分工作站無法上網（哪部分與網關端有關，若是在工作站修改前配置新網關，則沒有修改的工作站暫時無法上網；若在之後配置新網關，則修改好的工作站暫時無法上網）。而且若跨機關調整IP資源，則需要制定嚴格的先後順序，否則會出現兩機關同時使用同一個網段的可能。最後，經過多次例會，确定所有機關的IP調整僅限于本機關内，在滿足一段時間内應用所需前提下，僅保留一個Vlan和一個子網。 經過調整，最終目标如下：1、删除各機關多餘Vlan，僅保留一個；2、采取多除少補的方式，使個機關隻保留一個子網。實施時盡可能減少網絡中斷的時間。 終于到了具體技術實施的環節。由于改工作站資訊的工作就由各機關技術人員配合完成了，本人主要負責交換機這一塊。這裡主要是解決如何盡可能減少網絡中斷時間的問題。首先考慮目前網絡狀況：
每個機關都有不同的Vlan，每個Vlan對應一個IP子網。Vlan内的工作站全部使用子網内的IP位址，子網長度和指向SVI的網關。由于計劃盡可能使得各機關使用原來的IP位址段，實際上除了其它網段的IP位址外，需要改IP位址的工作站隻占少部分。絕大部分的IP位址都可以歸為一個24位子網路遮罩的子網。對此，有兩種方法可以使得更改子網路遮罩、網關不影響網絡連通性： 一、網管員先記錄目前核心交換機上各SVI的IP位址。然後在交換機上做配置，删除多餘的vlan，shutdown掉各SVI，把所有端口都歸入最終一個vlan内。在該剩下的vlan SVI上配上定好的網關IP，并把之前記錄的SVI以secondary的形式配上。這時工作站若發出對原網關的ARP請求，新網關将以自己的MAC位址作為ARP應答。是以工作站将以SVI（網關B）的MAC作為外網資料包的二層目的位址。待所有工作站改完IP後，再删除這些secondary位址。這裡要注意的是，必須要删除或者shutdown掉原SVI，才能在最終的SVI内配置secondaryIP位址，否則會報錯：位址已存在。 二、在滿足如下條件時，使用proxy-arp： 1、目前的IP與最終的SVI同在一個子網内； 2、原SVI（網關A）三層可達最終的SVI（網關B）。 其流程是：各工作站先配好最終的子網路遮罩和網關，最後由網管删除。有人可能會問，子網路遮罩、網關位址與Vlan相對應的SVI不同，能上外網嗎？隻要滿足上述兩個條件，答案就是可以的。當滿足條件1時，為工作站配上新的掩碼、網關後，工作站通路外網時，通過比較子網路遮罩，發現資料包目的地在“子網外”，是以它将把資料包發到“同一子網内的”網關B（條件1）。由于是同一子網内的，是以工作站發送一個ARP請求廣播。這時，配置了proxy-arp的原SVI（網關A）收到該廣播請求後，檢查網關B是否三層可達。若可達（條件2），則把自己的MAC以arp應答的形式回複工作站。最後，工作站還是以SVI（網關A）的mac作為外網資料包的二層目的位址。待所有工作站改完IP後，再删除vlan、SVI，配上新的vlan和SVI。 兩種方法有利有弊。第一種方式，某些路由協定不支援接口下的secondary位址作為接口釋出；第二種方式有一定的條件限制。實際操作時，根據不同的情況選擇不同的方式。 最終效果圖示：
總結：整個項目耗時一個月（不包括前期調研。當然其中還有其它項目打斷過，我也還有其它工作忙乎），共涉及到26個地點共幾乎500個工作站。當然相對配工作站的同志們老說，我算是輕松活了，但也搞得焦頭爛額的。以下是小弟總結出來的一些經驗： 一、拜托各位網絡設計的大哥，前期規劃再做細一點，以發展的眼光看問題。盡可能不要留給後來的小弟幹這活，混口飯吃吃而已 二、強烈建議各位網管員使用DHCP，可以節省大量的經曆研究其它網絡優化的問題