網絡結構

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

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

圖1 網絡拓撲結構

改造計劃

整個網絡改造計劃如下：

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

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

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

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

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

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

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

表1 地址分配表

網點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ā)給分部服務器。

圖2 網絡改造結構

當然，通迅是雙向的，當分部服務器收到網點主機的“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接口上增加配置arpproxy enable （注意，不同廠商的交換機命令不一樣），這樣就能完美地解決祼纖拆除后的網絡通迅問題。

現在我們來一看下，arpproxy究竟起到了什么作用。還是分部服務器的“Ping回包”，當分部服務器通過廣播查找網點主機的MAC地址時，分部核心交換機收到了該廣播包，于是查找自己的路由表，發(fā)現自己的路由表中有去往網點1的路由，隨即回復，告訴分部服務器，網點主機的MAC就是它自己。分部服務器收到后，構造目標MAC為分部核心交換機的數據包，發(fā)給分部核心交換機，分部核心交換機查找路由表，將數據發(fā)給新增交換機，這樣將“Ping回包”通過新專線返回給網點主機。至此，網絡改造得以繼續(xù)進行。

經驗總結

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