目   錄

 

 

廠商聯絡方式

 

Hillstone400 服務熱線—— 400 828 6655

在解決使用者故障前一定要清晰瞭解使用者的現場環境，並生成《 XXX 客戶服務過程記錄》。

如果已經進行過調查則確認使用者環境是否有變化，修改原有《 XXX 客戶服務過程記錄》，另存為一個新的文件。

 

指示燈	顏色	說明
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 山石網科資料中心防火牆的管理員口令丟失，請與當地代理商聯絡或透過系統復位的方法將密碼恢復為出 廠預設值（警告：系統復位的同時所有裝置資訊都會恢復出廠設定，配置檔案會被刪除，請謹慎使用！）

 

命令檢視裝置版本資訊，如果版本低，是否存在 BUG

 

確定是否是因裝置引起的。

在移除裝置不會影響網路應用或影響較小容易調整且使用者允許的情況下，將懷疑有故障的裝置從網路中移出，看應用是否正常。如果還不正常則要懷疑是否有其他故障。建議解決其他故障後再將裝置還原回原來狀態。

單獨測試故障部分鏈路及應用。

擴充套件模組出現故障時，請對裝置進行以下檢查：

l   檢查擴充套件模組是否與背板緊密接觸，松不脫螺絲是否已經擰緊。

l   確認當前的 StoneOS 版本為 StoneOS 5.0 。

l   使用 show module 命令檢視擴充套件模組的狀態資訊，具體請檢視《 Hillstone 山石網科資料中心防 火牆命令手冊》。

冷卻系統包括風扇盤和過濾網。當風扇盤故障或過濾網堵塞時，機箱不能良好散熱，導致溫度升高， 如果溫度過高，系統將自動關閉。

當冷卻系統出現故障時，請對裝置進行以下檢查：

l   使用 show environment 命令檢視裝置的溫度和風扇盤轉速，具體請檢視《 Hillstone 山石網科 資料中心防火牆命令手冊》。

l   檢視風扇盤指示燈。風扇正常執行時，指示燈為綠色常亮；當指示燈顯示紅色，表示一個或更多的 風扇故障，請儘快更換風扇盤，避免系統過熱，具體操作參閱冷卻系統更換。

使用者可以根據電源指示燈的狀態來判斷產品電源系統是否發生故障，電源指示燈的狀態及含義請參照 指示燈含義。電源系統工作正常時，電源指示燈應該保持綠色常亮；電源指示燈不亮時，請對裝置進行以 下檢查：

l   裝置電源線是否連線正確。

l   裝置的供電電源與所要求的電源是否一致。

配置系統故障處理

裝置上電後，如果配置系統正常，將在配置終端上顯示啟動資訊；如果配置系統出現故障，配置終端 可能無顯示或者顯示錯誤資訊。

若配置終端無顯示資訊，請先進行如下檢查 :

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 全雙工。

調整裝置其他引數。

 

地址表錯誤

  故障定位

檢查是否學到真實的 MAC 地址。

本端和對端是否一致。

確認是否有地址衝突。

確認是否有 ARP 攻擊。

  解決辦法

臨時解決：

清理錯誤的 MAC 地址表。

手工繫結 MAC 對應關係。

最終解決：

找到 MAC 地址表錯誤的原因。

清理網路攻擊源。

值

  故障定位

也請參考 :

小包能 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 策略中是否已將相應協議及埠號放開；

檢查防火牆通訊策略中是否已將相應協議及埠號放開；

策略

檢查防火牆 NAT 策略中是否已將相應地址、協議及埠號進行了正確的轉換；

有時會因地址轉換後 NAT 和 MAP 不一致導致應用不通。

接收正常，發出的郵件經常被退。

可能因 NAT 和 MAP 不一致，導致地址反解析錯誤，地址被拒絕。

也請參考 :

部分網路銀行的驗證比較嚴格，可能因地址轉換導致登陸 IP 與訪問的 IP 不同，造成訪問被拒絕。

策略

如果是 HTTP 、 FTP 、 SMTP 、 POP3 等服務，檢查應用埠繫結中是否有此應用服務的埠。

檢查防火牆 DPI 策略中是否已將相應服務放開；

也請參考 :

表

也請參考 :

  解決辦法

搞清使用者需求。

分析資料流程。

調整策略。

到期重啟問題

預設出廠裝置有測試 License ，如果裝置測試 License 到期後未匯入正式 License 或續期測試 License ，重啟後則防火牆恢復出廠配置（原配置檔案儲存在防火牆內，但無法引導）。

 

佔用率過高

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 攻擊防護功能。

 

異常處理

在 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

 

不生效的處理

l   檢查伺服器本身埠是否開啟。

l   檢查是否有從外到內的策略是否有放行，源地址為 any 目的地址為對映後的公網地址。

l   檢查內網伺服器閘道器配置是否正確

 

診斷與排錯

資料流基本步驟

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

 

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: 199924 flag: 801): 192.168.1.12:3332->202.106.0.20:53

  flow1(if id: 10 flow id: 199925 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: 199924 flag: 811): 192.168.1.12:3332->202.106.0.20:53

  flow1(if id: 10 flow id: 199925 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)