山石網科-Hillstone-雙ISP接入流量故障排錯終結篇

各位，很久不見。

近期在維護山石網科的防火牆中遇到一個比較有表明性質的案例，故在時候拿出來和你們作簡單的分享。好了，很少說。

                                                                  -------來自一家運營商的網工分享

背景：

    山石網科設備-E2800 

    華爲S5700-52C-EI

    單ISP（CTC）線路接入

    私有云+傳統IDC業務混合部署

需求：

    新增一條CNC-ISP出口，提高聯通進出、電信進出訪問的優化，杜絕單電信異網傳輸延遲問題，加強網絡的可靠性、冗餘性和健壯性，進而將數據流量訪問進行合理的分配和科學的利用。

改造前拓撲：

改造前拓撲特色：

全網品字形結構，實現全部節點冗餘。規避單點故障風險

三層核心與防火牆直接交叉聚合進一步保證內網高可靠性

缺點：

1.出口單ISP接入，用戶側拓撲確實規避了，但未提供運營商側冗餘和高可行

2.內網三層核心數據傳輸，假若單點設備某線路故障後，沒辦法合理流量分割（此點純我的見解，各位如有不一樣意見，歡迎直接指出。）

改造後拓撲：

改造後拓撲特色：

1.雙ISP運營商接入，保證運營商側冗餘高可靠性

2.實現清晰的流量分割，保證網工的運維工做開展順利（

目前沒發覺有任何缺點：

 （請各位直接指正）

好了，到此全部的背景和改造需求所有介紹完畢，內網傳輸的注意事項和配置技巧以及各類ACL各類PBR我就不詳細說了。今天只聊邊緣設備和運營商側的故事。

上菜！！！！

山石網科側配置需求：

    1.出口網絡

       缺省出口-電信，浮動靜態-聯通

    2）若是配置等價出局，電信和聯通就只能五五分流量，這裏引進策略路由PBR，強制抓取源進行扔聯通下一跳的作法

 

    2.SNAT轉換配置：

    3.DNAT轉換配置：

     圖省略，配置倆個，一個純電信映射，一個純聯通映射

PS：至於爲何聯通接口是浮動狀態也能正常轉發流量和作NAT映射。一方面是目前使用的版本，山石的NAT是基於全局vrouter的作的，同時還有一個前提，上聯的電信和聯通的數據是作過異網融合在一臺設備上的。還有一個緣由有點深，之後介紹

    4.策略放行：

     這裏省略，無難度

到這裏，全部配置所有完成，進行測試也是所有走向正常。開始測試須要定向走聯通線路的服務器

從內到外,策略路由配置前，缺省走電信出口：

策略路由配置後，流量走聯通出口：

到這裏，問題在接下來的一週出來了。客戶反饋增長了雙ISP出口後，聯通的對外的FTP服務，監控查到流量仍然電信出口上跑。我開始方了！！

我立馬展現出網工傲嬌清高的一面，「不可能的事情，我來檢查，給我等着！！！」接下來，我驗證後，一臉懵B的樣子想着爲何，不敢吭聲擔憂用戶主管拍我。

聯通的FTP服務器測試下載：

聯通出口cacti監控截圖：

電信出口同一時間cacti監控截圖：

問題分析和排查：

  關鍵詞：源進不源出

  按照開啓逆向路由，【思科RPF,reverse path forwarding、山石Reverse route】

  理論上該問題是能獲得解決的，可是問題依舊。繼續思考！！！檢查策略路由策略配置文件，也沒有任何問題，都是一切正常的。繼續思考！！

·······最後，實在折騰了2天以後，打電話給山石的原廠技術工程師諮詢，工程師建議將公網地址也放入到策略路由的源地址簿中。

注：原廠工程師建議這樣作，具體的原理並無詳細介紹，但後面我再stone os 的數據包處理流程中發現了這樣作的緣由。

  優化後配置以下：

再回去從新測試FTP下載，而後查看流量走向：

聯通出口和電信出口比較：（測試圖體現了配置前和配置後的流量變化）

你們能夠很明顯看到，優化配置後（即紅色箭頭標記地方）流量從電信口換到聯通口了。問題終獲得解決，皆大歡喜。

PS：在優化配置後，FTP出現中斷

電信出口：

聯通出口：

最後，最後，你們懂得，去客戶現場「賠禮道歉，磕頭」。願世界和平。把學習看成一種生活方式········