網絡現狀

某集團公司的分部有多個網點，先期組網整個分部在同一網段內，即分部Web服務器、網點主機地址全部在總部分配的10.0.0.0/20地址段內，如圖1虛線左下部分。

該種組網方式雖簡單，但卻存在諸多問題，如同網段內主機過多，MAC地址表過大，廣播對網絡影響大，網絡性能低，ARP欺騙頻繁等等。為徹底解決上述問題，擬對網絡地址進行改造，對總部分配的地址組子網化，每個網點單獨的網絡，分配64個地址。地址分配表如表1所示。整個網絡改造計劃如下：

1、因地址是總部統(tǒng)一分配的，所以新規(guī)劃的地址與原地址存在包含關系，需新增一臺交換機，用作網絡改造后的網點的接入網關，新增交換機與原分部核心交換機之間增加三層連接，新增交換機默認路由指向原分部核心交換機。

表1 地址分配表

2、每個網點新增一條專線，并規(guī)劃獨立的VLAN，網關設在新增交換機上。

3、改網點交換機及網點主機的掩碼及網關，IP地址不變。

4、在原核心交換機上，新增改造后網點的路由，指向新增交換機。

5、測試成功后，拆原祼纖。

6、分部Web服務器等需在所有網點改造完成后再實施掩碼與網關的變更，否則未改造的網點會網絡不通。

注意：該種改造方法可以逐個網點改造，且網點及中心IP地址本身不變（僅變更掩碼及網關），對應用配置無影響。

圖1 原網絡拓撲圖

圖2 改造后的網絡拓撲圖

網點1改造過程中的拓撲如圖2所示。根據上述步驟實施網點1的網絡變更，改造后發(fā)現網點1的主機10.0.1.1（以下簡稱網點主機）能ping通分部Web服務器10.0.0.1（以下簡稱分部服務器），但將原祼纖拆除后，卻不能ping通分部服務器。為什么會這樣呢？在ping通的情況下，祼纖承載什么作用呢？我們來分析一下，網點主機IP為10.0.1.1，掩碼為255.255.255.192，當它發(fā)起ping分部服務器10.0.0.1時，經比較，發(fā)現目標主機為非本網段主機，于是將“ping包”發(fā)給網關（新增交換機）處理，新增交換機查找路表，將“ping包”發(fā)給分部核心交換機處理，分部核心交換機發(fā)現目標主機在本交換機的一個直連接口上，于是直接發(fā)給分部服務器。當然，通迅是雙向的，當分部服務器收到網點主機的“ping包”時，它會怎么處理呢？分部服務器的地址為10.0.0.1，掩為255.255.240.0，經比較，發(fā)現目標主機10.0.1.1與本機為為同網段的，就會發(fā)廣播包查它的MAC地址，而祼纖此時是正常的，網點主機通過祼纖返回MAC地址給分部服務器，“ping回包”就通過祼纖直接回傳給網點PC機。由此可以看出，數據的往返路徑是不一致的，上行走新增的專線，下行還是走原來的裸纖，這樣當祼纖中斷后，網絡自然就不通了。

問題似乎無解了，從分部服務器這端來說，因為掩碼問題，認為改造后網點主機跟它是同網段的，自然不會將數據包扔給網關處理，這樣祼纖就不能拆除，網絡改造宣布失敗。

有沒有辦法讓分部服務器的“ping回包”發(fā)給分部核心交換機呢？因為只有它才能將改造后網點的數據包發(fā)往正確的目的地。這時，ARP代理閃了一下，能否用ARP代理解決分部服務器的MAC廣播呢？答案是肯定的。在分部核心交換機的VLAN接口上增加配置 arp-proxy enable （注意，不同廠商的交換機命令不一樣），這樣就能完美的解決祼纖拆除后的網絡通迅問題?，F在我們來看下，arp-proxy究竟起到了什么作用。還是分部服務器的“ping回包”，當分部服務器通過廣播查找網點主機的MAC地址時，分部核心交換機收到了該廣播包，于是查找自己的路由表，發(fā)現自己的路由表中有去往網點1的路由，隨即回復，告訴分部服務器，網點主機的MAC就是它自己。分部服務器收到后，構造目標MAC為分部核心交換機的數據包，發(fā)給分部核心交換機，分部核心交換機查找路由表，將數據發(fā)給新增交換機，這樣將“ping回包”通過新專線返回給網點主機。至此，網絡改造得以繼續(xù)進行。

這次碰到的問題，雖然解決起來只有一條命令，但卻需要平時多多了解網絡技術?！昂穹e而薄發(fā)”，只有平時注重網絡知識的積累，才能在碰到問題時信手拈來，快速地解決網絡中碰到的問題，保障網絡運行安全、穩(wěn)定。