hillstone現場故障處理指導手冊
目 錄
1 Hillstone廠商聯繫方式
Hillstone400服務熱線——400 828 6655
2 進行用戶環境調查
在解決用戶故障前一定要清晰瞭解用戶的現場環境，並生成《XXX客戶服務過程記錄》。
如果已經進行過調查則確認用戶環境是否有變化，修改原有《XXX客戶服務過程記錄》，另存爲一個新的文檔。
3 故障處理基本思路
指示燈 | 顏色 | 說明 |
PWR | 綠色常亮 | 系統電源工作正常 |
橙色常亮 | 電源工作異常 | |
紅色常亮 | 電源工作異常，此時系統處於關閉狀態 | |
熄滅 | 系統沒有供電或處於關閉狀態 | |
STA | 綠色常亮 | 系統啓動並正常運行 |
綠色閃爍 | 系統已啓動並且正常工作 | |
紅色常亮 | 系統啓動失敗或者系統異常 | |
ALM | 紅色常亮 | 系統告警 |
綠色閃爍 | 系統處於等待狀態 | |
熄滅 | 系統正常 | |
橙色閃爍 | 系統正在使用試用許可證 | |
橙色 | 試用許可證到期，無合法許可證 | |
HA | 綠色常亮 | 只有一臺設備，工作在master狀態 |
綠色閃爍 | 有一主一備兩臺設備，本設備工作master狀態 | |
橙色閃爍 | 有一主一備兩臺設備，本設備工作slave狀態 | |
紅色閃爍 | HA工作異常 | |
LNK | 綠色常亮 | 端口與對端設備通過網線或光纖連接且連接正常 |
熄滅 | 端口與對端設備無連接或端口連接失敗 | |
ACT | 橙色閃爍 | 端口處於收發數據狀態 |
熄滅 | 端口無數據傳輸 |
設備不能通過某些pc實現管理，原因：
l 查看設備時候配置有可信任主機，並且該地址是否在可信任主機列表中。
web下位置：系統-設備管理-可信任主機
cli下命令：show admin host
l 添加可信任主機及權限方法：
web下位置：系統-設備管理-可信任主機-新建
cli下命令：SA(config)# admin host A.B.C.D/M any
如果 Hillstone 山石網科數據中心防火牆的管理員口令丟失，請與當地代理商聯繫或通過系統復位的方法將密碼恢復爲出 廠默認值（警告：系統復位的同時所有設備信息都會恢復出廠設置，配置文件會被刪除，請謹慎使用！）
l 使用 show vession 命令查看設備版本信息，如果版本低，是否存在BUG
確定是否是因設備引起的。
在移除設備不會影響網絡應用或影響較小容易調整且用戶允許的情況下，將懷疑有故障的設備從網絡中移出，看應用是否正常。如果還不正常則要懷疑是否有其他故障。建議解決其他故障後再將設備還原回原來狀態。
單獨測試故障部分鏈路及應用。
4 各類故障處理
擴展模塊出現故障時，請對設備進行以下檢查：
l 檢查擴展模塊是否與背板緊密接觸，鬆不脫螺絲是否已經擰緊。
l 確認當前的 StoneOS 版本爲 StoneOS 5.0。
l 使用 show module 命令查看擴展模塊的狀態信息，具體請查看《Hillstone 山石網科數據中心防 火牆命令手冊》。
冷卻系統包括風扇盤和過濾網。當風扇盤故障或過濾網堵塞時，機箱不能良好散熱，導致溫度升高， 如果溫度過高，系統將自動關閉。
當冷卻系統出現故障時，請對設備進行以下檢查：
l 使用 show environment 命令查看設備的溫度和風扇盤轉速，具體請查看《Hillstone 山石網科 數據中心防火牆命令手冊》。
l 查看風扇盤指示燈。風扇正常運行時，指示燈爲綠色常亮；當指示燈顯示紅色，表示一個或更多的 風扇故障，請儘快更換風扇盤，避免系統過熱，具體操作參閱冷卻系統更換。
用戶可以根據電源指示燈的狀態來判斷產品電源系統是否發生故障，電源指示燈的狀態及含義請參照 指示燈含義。電源系統工作正常時，電源指示燈應該保持綠色常亮；電源指示燈不亮時，請對設備進行以 下檢查：
l 設備電源線是否連接正確。
l 設備的供電電源與所要求的電源是否一致。
4.1.4 Console配置系統故障處理
設備上電後，如果配置系統正常，將在配置終端上顯示啓動信息；如果配置系統出現故障，配置終端 可能無顯示或者顯示錯誤信息。
若配置終端無顯示信息，請先進行如下檢查:
l 電源是否正常。
l 配置電纜連接是否正確。
l 終端配置是否正確。 若以上檢查未發現問題，則可能是配置電纜故障，請進行檢查。
此部分主要檢查線路是否正常。
故障定位
雙絞線：
l 檢查網線線序是否符合規範。
l 檢查網線接口是否插牢，是否正常。
l 檢查指示燈狀態是否正常。
l 網線內有斷線情況，可能導致指示燈正常但線路不通。
l 檢查線路所經路徑上是否有大功率設備干擾。
l 檢查線纜長度，是否超過105米。一般情況下，線路過長很容易引起信號強度下降、線路干擾過大。
光纖：
l 檢查光纖接口是否插牢。
l 檢查光纖類型和設備接口類型是否相符，單模、多模。
l 如果是單模光纖，如果激光功率太強或太弱也會導致通訊異常。檢查是否需要使用衰減器。
解決辦法
更換合格的線路。
如果是單模光纖激光強度異常，需要使用測試儀檢測，調整強度即可。
如果是激光過強，可以用纏繞光纖的辦法進行衰減，可以達到衰減器的效果。
參考資料
RJ45網線水晶頭排線範參考如下：
1 2 3 4 5 6 7 8
T568A的線序爲：白綠，綠，白橙，藍，白藍，橙，白棕，棕
T568B的線序爲：白橙，橙，白綠，藍，白藍，綠，白棕，棕
不使用HUB或交換機兩機連接，兩端分別用T568A和T568B；
使用HUB或交換機則統一使用T568B。
一般情況下，網線只有1 2和3 6四根線起作用。
傳輸距離與速度：
超五類雙絞線的最大傳輸距離爲105米，平均傳輸速度爲100M（最大峯值155M）。前提是雙絞線的各項性能指標都要達到超五類雙絞線的標準。
故障定位
檢查線路通信狀態。
使用PC或單獨設備直連此鏈路，測試鏈路質量、速度。
檢查用戶接入設備狀態，運行參數、跳線等是否正常。
如果是端到端設備檢查兩端設置是否一致。
SDH網絡使用的協議轉換器可能因局端作了環路，造成大量廣播，現象類似於環路，可能造成防火牆不能正常收發。
案例：
ADSL：可能因ADSL提供商原因造成無法正常通訊，此時使用PC直接連接（可能是撥號，也可能是路由），測試線路是否能夠正常傳輸，檢查丟包率，測試接入速度。
專線：某單位採用SDH專線連接各分支，發現不通，經鏈路提供商測試物理線路正常。詳細瞭解發現，此單位適用端到端的轉換設備（SDH-ETH），但兩端的轉換設備的跳線設置不通，即兩端設備的工作模式不同。將兩端設備設成同一模式後線路通訊正常。
解決辦法
請線路提供商調整線路；
調整接入設備的參數；
調整端到端設備的模式；
故障定位
檢查兩端設備協商速率及全雙工/半雙工模式。
檢查兩端設備是否一致。
察看數據包收發數量，查看是否有隻有發包沒有收包，或收發包差距非常明顯的情況。
察看校驗錯誤包是否很多。
解決辦法
調整兩端設備配置，100兆鏈路推薦設爲：兩臺設備都設爲100M全雙工。
調整設備其他參數。
4.2.1.2.3 MAC地址表錯誤
故障定位
檢查是否學到真實的MAC地址。
本端和對端是否一致。
確認是否有地址衝突。
確認是否有ARP×××。
解決辦法
臨時解決：
清理錯誤的MAC地址表。
手工綁定MAC對應關係。
最終解決：
找到MAC地址表錯誤的原因。
清理網絡×××源。
故障定位
也請參考: ping
小包能ping通，但大包無法ping通，很可能是MTU問題。
部分應用不通，但其他應用正常也有可能與MTU值有關。
可以用Ping大包的方式測試是否有MTU問題。
故障原因
防火牆接口MTU值能小於嵒機MTU值，例如：
當防火牆的接口MTU值設爲1300時，主機的MTU值缺省爲1500時，主機穿過防火牆的連接能夠打開服務器的相關頁面，但修改相關的資料時無法提交成功。分析爲防火牆接口MTU值比主機MTU值小，主機與服務器協商出合適的MSS值，但經過IP層封裝後的某些數據包就會大於1300但不大於1500，並且對不大於1500的包DF位置1，這樣的包到達防火牆後就被防火牆丟棄了。因此就會出現能夠打開網頁，但修改資料無法提交成功及通過網頁收發郵件無法上傳附件等現象。建議正常情況下要修改防火牆的MTU值。
解決辦法
嘗試調整防火牆MTU值，使之符合應用的要求。
可以通過抓包分析判斷MTU值。
故障定位
檢查Vlan的設置，是否有需要的Vlan號；
檢查接口設置，確認關聯接口屬於Trunk需要的Vlan範圍。檢查接口的NativeID。
檢查前後設備的Vlan配置。
故障原因
防火牆在Trunk模式下，如果想要前後設備的Vlan通訊，必須在防火牆Vlan設置裏綁定相應的Vlan號。
解決辦法
故障定位
檢查相鄰設備Vlan配置，Vlan號、Trunk設置。
注意相鄰設備Trunk類型。部分路由交換設備的默認協議是dot1q，但如果防火牆接入則可能造成無法正常穿越，需要手工將路由交換設備的協議指定爲dot1q纔可以。
解決辦法
正確配置防火牆接口、Vlan等參數；
遇到前後設備採用默認Vlan類型，即便默認類型也是802.1q，也要手工設置爲802.1q。
故障定位
檢查防火牆自身ARP表是否真實
確認網絡中是否有ARP×××，可能因ARP×××造成IP-MAC地址對應錯誤。
部分網絡監控、管理軟件採用ARP×××原理工作，確認網絡是否有類似軟件。如：網絡執法官、P2P控制軟件等。
故障原因
ARP×××會造成受影響的防火牆及客戶端ARP表錯誤，即造成IP地址與MAC地址對應錯誤，使得數據報不能正確地發送給真實的主機。
解決辦法
在防火牆及所有客戶端均進行ARP綁定。
清除網絡內ARP×××源。
參考資料
要了解故障原理，我們先來了解一下ARP協議。
在局域網中，通過ARP協議來完成IP地址轉換爲第二層物理地址（即MAC地址）的。ARP協議對網絡安全具有重要的意義。通過僞造IP地址和MAC地址實現ARP欺騙，能夠在網絡中產生大量的ARP通信量使網絡阻塞。
ARP協議是“Address Resolution Protocol”（地址解析協議）的縮寫。在局域網中，網絡中實際傳輸的是“幀”，幀裏面是有目標主機的MAC地址的。在以太網中，一個主機要和另一個主機進行直接通信，必須要知道目標主機的MAC地址。但這個目標MAC地址是如何獲得的呢？它就是通過地址解析協議獲得的。所謂“地址解析”就是主機在發送幀前將目標IP地址轉換成目標MAC地址的過程。ARP協議的基本功能就是通過目標設備的IP地址，查詢目標設備的MAC地址，以保證通信的順利進行。
每檯安裝有TCP/IP協議的電腦裏都有一個ARP緩存表，表裏的IP地址與MAC地址是一一對應的，如下表所示。
主機 IP地址 MAC地址
A 192.168.16.1 aa-aa-aa-aa-aa-aa
B 192.168.16.2 bb-bb-bb-bb-bb-bb
C 192.168.16.3 cc-cc-cc-cc-cc-cc
D 192.168.16.4 dd-dd-dd-dd-dd-dd
我們以主機A（192.168.16.1）向主機B（192.168.16.2）發送數據爲例。當發送數據時，主機A會在自己的ARP緩存表中尋找是否有目標IP地址。如果找到了，也就知道了目標MAC地址，直接把目標MAC地址寫入幀裏面發送就可以了；如果在ARP緩存表中沒有找到相對應的IP地址，主機A就會在網絡上發送一個廣播，目標MAC地址是“FF.FF.FF.FF.FF.FF”，這表示向同一網段內的所有主機發出這樣的詢問：“192.168.16.2的MAC地址是什麼？”網絡上其他主機並不響應ARP詢問，只有主機B接收到這個幀時，才向主機A做出這樣的迴應：“192.168.16.2的MAC地址是bb-bb- bb-bb-bb-bb”。這樣，主機A就知道了主機B的MAC地址，它就可以向主機B發送信息了。同時它還更新了自己的ARP緩存表，下次再向主機B發送信息時，直接從ARP緩存表裏查找就可以了。ARP緩存表採用了老化機制，在一段時間內如果表中的某一行沒有使用，就會被刪除，這樣可以大大減少ARP緩存表的長度，加快查詢速度。
從上面可以看出，ARP協議的基礎就是信任局域網內所有的人，那麼就很容易實現在以太網上的ARP欺騙。對目標A進行欺騙，A去Ping主機C卻發送到了DD-DD-DD-DD-DD-DD這個地址上。如果進行欺騙的時候，把C的MAC地址騙爲DD-DD-DD-DD-DD-DD，於是A發送到C上的數據包都變成發送給D的了。這不正好是D能夠接收到A發送的數據包了麼，嗅探成功。
A對這個變化一點都沒有意識到，但是接下來的事情就讓A產生了懷疑。因爲A和C連接不上了。D對接收到A發送給C的數據包可沒有轉交給C。
做“man in the middle”，進行ARP重定向。打開D的IP轉發功能，A發送過來的數據包，轉發給C，好比一個路由器一樣。不過，假如D發送ICMP重定向的話就中斷了整個計劃。
D直接進行整個包的修改轉發，捕獲到A發送給C的數據包，全部進行修改後再轉發給C，而C接收到的數據包完全認爲是從A發送來的。不過，C發送的數據包又直接傳遞給A，倘若再次進行對C的ARP欺騙。現在D就完全成爲A與C的中間橋樑了，對於A和C之間的通訊就可以瞭如指掌了。
故障定位
測試對方設備是否有ARP綁定。
詢問對方管理人員是否有ARP綁定。
可能因對端設備壓力較大、運行故障等原因造成對方ARP表不能及時更新，表現的現象和ARP綁定相似。
故障原因
如果對方存在ARP綁定會造成發過去的所有數據包均被丟棄，使得網絡不通。
解決辦法
要求對方重新綁定。
修改防火牆對應接口MAC地址爲綁定的地址。
如果是假綁定，多等待一段時間、多重啓幾次防火牆，或重啓對方設備都有可能解決。
4.2.2.1.1 故障定位
通過Ping、Tracert等方式確定整個路徑上的各個節點的工作狀態。
定位問題出現在那臺設備上。
檢查有問題設備的路由表。
檢查傳輸過程中是否有NAT，轉換是否正常。
一般按照下面的方法進行。
可分爲Ping小包、Ping大包兩種方式。
要按照網絡拓撲，由近及遠，依次ping各個IP。
ping x.x.x.x -t
ping x.x.x.x -l 1472 -f
ping長度爲1472的滿包，-f表示不分片
ping x.x.x.x -l 1473
ping長度爲1473的包，此包超過最大單包長度，測試MTU問題；
測試線路由近及遠的各個節點，目前可能因中間設備導致不通。此方法僅在少數環境下有效。
4.2.2.1.2 路由分析
要從路由中明確數據包的傳輸路徑，分析數據包是否能夠正確的傳出並返回。
配置時需要用命令行將靜態路由發佈出去
發佈靜態路由命令
OSPF redistribute static
還有發佈IP、發佈直連路由
4.2.2.1.3 解決辦法
如果路由錯誤則調整路由表。
如果NAT設置錯誤則調整NAT策略。
MTU問題則須調整MTU值。
首先確定服務所使用的協議及端口號；
故障定位
PF策略
檢查防火牆PF策略中是否已將相應協議及端口號放開；
檢查防火牆通訊策略中是否已將相應協議及端口號放開；
NAT策略
檢查防火牆NAT策略中是否已將相應地址、協議及端口號進行了正確的轉換；
有時會因地址轉換後NAT和MAP不一致導致應用不通。
接收正常，發出的郵件經常被退。
可能因NAT和MAP不一致，導致地址反解析錯誤，地址被拒絕。
也請參考: 考慮雙出口路由
部分網絡銀行的驗證比較嚴格，可能因地址轉換導致登陸IP與訪問的IP不同，造成訪問被拒絕。
DPI策略
如果是HTTP、FTP、SMTP、POP3等服務，檢查應用端口綁定中是否有此應用服務的端口。
檢查防火牆DPI策略中是否已將相應服務放開；
也請參考: 路由分析
也請參考: ARP
解決辦法
搞清用戶需求。
分析數據流程。
調整策略。
4.2.4 設備測試License到期重啓問題
默認出廠設備有測試License，如果設備測試License到期後未導入正式License或續期測試License，重啓後則防火牆恢復出廠配置（原配置文件保存在防火牆內，但無法引導）。
4.3.1 CPU佔用率過高
l 查看設備當前吞吐是否到達設備極限，如果到達設備極限，建議通過減少通過設備流量，或者更換其他高性能防火牆的方式來解決。
l 查看設備是否開啓太多的統計集，如果統計集功能開啓較多會佔用較大cpu，建議通過關閉統計集的方法來降低cpu的使用率。如果確實需要開啓統計集，建議在一定時間內開啓，待結果統計出來後即刻關閉統計集。
l 查看設備是否開啓debug，cli下輸入 show debug 如果開啓建議關閉debug，方法：使用命令undebug all。
l 設備開啓太多佔用cpu資源的功能，建議暫時關閉部分功能，或者更換高性能防火牆。
l 查看設備上是否有DoS/DDos×××流量，開啓×××防護中的SYN Flood和UDP Flood×××防護功能。
通過show session generic 或web 查看到設備session數使用過多，解決方法：
l 在統計集中開啓基於用戶的session數統計，查看具體session數字過大的ip，手動將該ip的session刪除，命令：clear session src-ip ip-address，來暫時降低設備的session。
l 通過配置session-limit的形式來控制用戶的session數
l 查看設備上是否有DoS/DDos×××流量，開啓×××防護中的SYN Flood和UDP Flood×××防護功能。
4.3.3 HA異常處理
在HA正常配置後，如果網絡結果不發生變化，很少出現問題。如果出現問題一般是由於HA心跳線由於某種原因斷開所致。
建議出現問題後先通過下面的幾個命令查看HA狀態，可以先暫時將備用設備的HA功能關閉，檢查兩臺設備HA部分配置是否一致，確認無誤後再開啓備用設備的HA功能。
查看HA狀態命令:
l show ha link status //查看HA link 狀態 ，確認HA link接口狀態是否正常。
l show ha group config //查看HA group 配置狀態 ，確認HA group相關配置。
l show ha group 0 //通過查看HA group 0 狀態 ，確認對端狀態是否正常。
l show ha cluster //查HA簇配置信息。
l show ha sync state config //查看HA配置同步狀態。
l no ha cluster //關閉HA配置。
l 確認用戶到到網關是否丟包，如果內網網關丟包請檢查內網交換、路由問題。
l 確認到內網不丟包，到外網網關丟包，請檢查從防火牆上到外網網關是否有丟包，如果丟包請聯繫線路供應商檢查鏈路質量。
l 確認從防火牆上到外網網關不丟包，請檢查防火牆cpu是否很高，如果cpu高請根據cpu高的處理方法操作。
l 確認cpu不高，請開啓接口帶寬統計集，查看接口帶寬是否佔滿，如果帶寬佔滿，請考慮通過配置qos功能對流量做控制。
l 確認帶寬不高，請檢查snat的轉換後地址源端口占用檢測，使用命令show snat resource vrouter trust-vr
4.3.5 目的NAT不生效的處理
l 檢查服務器本身端口是否開啓。
l 檢查是否有從外到內的策略是否有放行，源地址爲any 目的地址爲映射後的公網地址。
l 檢查內網服務器網關配置是否正確
5 debug診斷與排錯
5.1 debug數據流基本步驟
1、關閉debug信息輸出到console
no logging debug to console
2、清除緩存debug日誌信息
clear logging debug
3、設置debug過濾器
debug dp filter {src-ip | src-port | proto | dst-ip | dst-port}
4、開啓debug功能
debug dp basic
5、發起數據流訪問
6、查看debug日誌信息
show logging debug
7、關閉debug
undebug all 或 連擊“ESC”兩次 （必須退出，否則影響CPU性能）
8、查看調試功能開啓或者關閉狀態
show debug
9、查看debug 過濾器
show dp-filter
10、刪除debug過濾器
undebug dp filter id
5.2 各種情況下debug信息
hostname(config)# sh log deb
2009-03-04 16:17:39, DEBUG@FLOW: core 0 (sys up 0x8e65ae ms): 001d.7294.e5f6->00
1c.5402.8c00, size 73, type 0x800, vid 0, port ethernet0/0
Switchid is 8(interface ethernet0/0) port ethernet0/0
Start l3 forward
Packet: 192.168.1.12 -> 202.106.0.20, id: 8369, ip size 59, prot: 17(UDP): 3332
-> 53
① No session found, try to create session
----------------First path creating new session-----------------
--------VR:trust-vr start--------
192.168.1.12:3332->202.106.0.20:53
② No DNAT configured for this VR
③ Get nexthop if_id: 10, flags: 0, nexthop: 10.188.9.1
④ Found the reverse route for force revs-route setting
⑤ Matched source NAT: snat rule id:1
Matched source NAT: source port3332->port3332
--------VR:trust-vr end--------
⑥ Pak src zone trust, dst zone untrust, prot 17, dst-port 53.
Policy 1 matches, ===PERMIT===
⑦ Identified as app DNS (prot=17). timeout 60.
flow0 src 192.168.1.12 --> dst 202.106.0.20 with nexthop 0.0.0.0 ifindex 0
flow1 src 202.106.0.20 --> dst 10.188.9.100 with nexthop 192.168.1.12 ifindex 8
flow0's next hop: 192.168.1.12 flow1's next hop: 10.188.9.1
crt_sess->revs_rres.nextop: 192.168.1.12, crt_sess->revs_rres.nexthop 10.188.9.1
Application 7 hasn't been registered, don't need do ALG
APP inited for application 7
The following session is installed
⑧ session: id 99962, prot 17, flag a, created 9332, life 60
flow0(if id: 8 flow id: 1×××4 flag: 801): 192.168.1.12:3332->202.106.0.20:53
flow1(if id: 10 flow id: 1×××5 flag: 800): 202.106.0.20:53->10.188.9.100:3332
Session installed successfully
-----------------------First path over---------------------
⑨ Found the session 99962
session: id 99962, prot 17, flag 4a, created 9332, life 60
flow0(if id: 8 flow id: 1×××4 flag: 811): 192.168.1.12:3332->202.106.0.20:53
flow1(if id: 10 flow id: 1×××5 flag: 810): 202.106.0.20:53->10.188.9.100:3332
Set fast code to fe proc
Go to fe proc directly
Got mac: ip:10.188.9.1, mac:001c.5400.1dc1
L3 forward, out if is ethernet0/2
msw_dsa_tag_encap_from_cpu: TX packet from interface ethernet0/2, vid 0 cos 0.
-----------------First path creating new session-----------------
--------VR:trust-vr start--------
192.168.1.12:55577->10.188.7.10:53
No DNAT configured for this VR
Failed to get route to 10.188.7.10 (找不到路由存在)
Dropped: Can't find forwarding route. Abort!!
deny session:flow0 src 192.168.1.12 --> dst 10.188.7.10 Deny session installed s
uccessfully
--------VR:trust-vr end--------
-----------------------First path over (session not created)
Droppped: failed to create session, drop the packet
-----------------First path creating new session-----------------
--------VR:trust-vr start--------
192.168.1.12:4716->202.106.0.20:53
No DNAT configured for this VR
Get nexthop if_id: 10, flags: 0, nexthop: 10.188.9.1
Found the reverse route for force revs-route setting
Matched source NAT: snat rule id:1
Matched source NAT: source port4716->port4716
--------VR:trust-vr end--------
Pak src zone trust, dst zone untrust, prot 17, dst-port 53.
No policy set in this ctxt, default ===DENY=== (找不到策略允許)
Dropped: Can't find policy/policy denied. Abort!!
deny session:flow0 src 192.168.1.12 --> dst 202.106.0.20 Deny session installed successfully
-----------------------First path over (session not created)