一、ADC—應用交付
1.1 作用
負載均衡：服務器負載、鏈路負載、全局負載；
業務改造：網站IPv6改造、網站HTTPS改造；
網站加速：協議加速、內容加速。
1.1.1 詳細劃分
服務器負載：
--基於域名的七層負載均衡、應用健康檢查，提升服務器集羣的使用效率，平滑擴展服務能力；
--AX提供多重健康檢測技術：基於網絡和傳輸層的ICMP、TCP-ECHO等方式、檢查連通性、基於應用層的方式，TCP、UDP、HTTP、HTTPS、DNS、SMTP、POP3等、基於內容自定義與第三方腳本實現；
--AX提供豐富的調度算法（L4調度算法）：分析業務流量P/Port，基於預定策略進行分配、靜態算法：輪詢、加權輪詢、IP哈希等、動態算法：最小連接、最快響應等；
--AX提供個性化的調度算法（L7調度算法）：分析http請求，基於URL、Cookie、Method等進行調度、基於不同的七層策略規則、調度到不同服務器；
鏈路負載均衡：被動探測技術，監測鏈路質量並調整流量，指定不同應用（視頻、P2P2下載）選擇不同鏈路（動態鏈路切換、應用引流）
全局負載均衡和應用雙活：在多數據中心節點之間實現資源就近訪問和應用層的負載均衡，可與山石網科防火牆的孿生模式結合；
網站IPv6改造：國內領先的IPv6溯源技術，記錄L7應用層日誌
網站HTTPS業務改造：專用硬件SSL卸載，業界領先的SSL處理性能，內網WAF/IPS只需處理沒銘文流量，無額外消耗，支持過密SM2/SM3/SM4算法；[HTTP明文傳輸暴露用戶名密碼等敏感信息]
傳統服務器SSL加密的缺陷：性能低、證書管理複雜、WAF/IPS等處理HTTPS流量成本高。
應用性能優化：多種性能優化技術，提升服務器的響應速度和傳輸性能，通過連接池技術，平滑處理浪涌流量。
雙向流量的處理：僅需部署一臺設備在網絡邊界即可實現
會話保持技術：源IP、Cookie、SSL ID、URL哈希、首部哈希等算法、基於不同調度需求，實現同一規則調度到相同服務器
入站負載 Smart DNS：基於鏈路狀態、源地址等條件、選擇最優的鏈路地址、用戶獲得最優鏈路地址、向最優鏈路地址發起業務訪問
二、支持項目
支持IPv6 SLB、支持出站負載均衡、支持入站負載均衡--SmartDNS、支持DNS代理
2.1.1 AX推薦網站升級IPv6適用方案（均爲反向代理模式：和兩端設備分別連接，應用層清晰可見，支持轉換）
2.1.1.1 方案1—服務器是單一的IPv4，AX做反向代理提供IPv6地址
優勢：
1、保護用戶已有投資：服務器無需修改和替換，依然處理IPv4業務，AX部署在內網服務器前，對內網或外網用戶訪問服務器都可以提供IPv6業務，而防火牆一般部署在網絡邊界，NAT-PT只能提供外網用戶到內網服務器的轉換；
2、識別HTTP中的IPv4地址並改寫成IPv6地址：NAT-PT只能做網絡層轉換，不能進行深度識別；
3、IPv4用戶訪問222.test.com，dns返回1.1.1.1，IPv4用戶直接訪問，不經過AX，IPv6用戶訪問時經過AX；
2.1.1.2 方案2—IPv4和IPv6服務器共同組成集羣，AX支持同時負載均衡
優勢;
1、IPv4和IPv6服務器靈活組合：AX可以靈活控制HTTP業務單獨由後臺的IPv4服務器提供（更穩定），或者單獨由IPv6服務器提供（更符合合規性），或者二者同時提供，可以直觀的展現升級後網站的IPv4訪問量和IPv6訪問量，便於用戶瞭解升級效果；
2、升級過程業務不中斷：服務器增量升級，先新增IPv6雙棧服務器，再逐漸下架老舊IPv4服務器，AX支持後臺IPv4/IPv6雙棧服務器，AX溫暖上線和溫暖下線技術，保證新增和下架服務器不影響已有用戶業務；
2.2 LLB出站負載均衡
根據延遲、丟包、抖動、帶寬四個因素計算子網在不同鏈路的權重，沒計算出權重之前，是ECMP；
檢查TCP流量，不檢查UDP和ICMP；
鏈路的權重，也是根據多因素進行自動計算；
被動抽樣率，默認1/23，可以隱藏命令手動調整；
策略路由以及靜態路由中手動指定的權重，是靜態優先級，如果沒有走智能LLB，纔會被選擇。
2.3 入站負載均衡—LLB inbound-SmartDNS
功能詳解
當DNS代理和SmartDNS代理都開啓後，DNS代理的優先級高於SmartDNS
2.4 DNS代理
DNS代理（DNS Proxy）用來劫持客戶端的DNS請求，並重新構造DNS請求發往DNS代理服務器，收到DNS代理服務器的應答之後，再重新構造DNS應答發送給客戶端。DNS代理的過程如下：
價值：引流—將特定域名，引入到特定的DNS服務器來進行代理解析；
冗餘—配置多臺DNS服務器進行代理；
安全—將客戶端的DNS請求代理到安全的DNS服務器；
高效—將客戶端的DNS請求代理到合理的ISP運營商。
三、功能配置
3.1 出站負載均衡（WebUI）
1、智能LLB可與目的路由（DBR）/ 策略路由（PBR）綁定使用，目的路由：創建多條等價路由，策略路由：配置多個等價出口
2、配置接口帶寬
3、創建LLB模板——智能LLB探測規則
4、創建LLB規則——將LLB模板與路由綁定
最多支持64條綁定關係
5、鏈路監控配置
監控>鏈路狀態監控>鏈路配置，如果需要看到右側抖動、延遲、丟包率的鏈路狀態，根據應用進行過濾查看，應用維度需要勾選“啓用”
注：鏈路狀態監控可單獨開啓，對鏈路進行日常維護，故障維護
nat pool功能說明：
L3S會對所有inbound和outbound流量進行監控
對outbound流量監控延時和抖動，丟包，帶寬利用率
對inbound流量監控丟包，帶寬利用率
LLB會使用outbound流量的TCP被動監測結果
此時，如果想查看outbound流量監控結果，就需要配置NAT Pool，指定內網主機SNAT之後的地址，也就是outbound流量的源地址。
如果想查看inbound流量的被動監測結果，就要配置NAT Pool，把DNAT之前的IP地址包含進來，看公網客戶端與這些IP地址的TCP被動監測結果
可以進行應用維度的統計：不開啓應用識別，能統計到協議級別；開啓之後，統計到應用級別。
默認採集頻率1/32，如果在測試網絡中流量較少，需要調整該採集頻率爲1
3.2 入站SmartDNS配置
3.3 DNS代理配置
1、創建域名簿，指定需要進行DNS代理的域名
2、創建DNS代理rule1，用於匹配DNS服務器發起的查詢，需配在最前。
目的是，對於DNS服務器自身發起的遞歸查詢，不進行代理。也就是，域名服務器無法解析域名時，向根域名服務器發起的查詢
3、創建DNS代理rule 2，用於匹配內網用戶發起DNS查詢
DNS代理流量，不會被LLB進行負載，只會選擇ECMP中的第一條路由。導致的問題，如果一個是聯通DNS，一個是電信DNS，選擇了首選DNS之後，會一直從一個接口出。如果綁定了出接口，如果active，那就必定從此出接口出，也就是，也無法對此DNS流量進行LLB。對於解析結果，客戶端發起訪問時，優先級高於LLB，訪問流量也不會
3.3.1 DNS代理服務器選擇
指定DNS代理服務器時，支持設置爲首選、綁定出接口，其優先級如下：
1.首選DNS代理服務器。如果指定了首選，優先選擇首選
2.綁定了出接口的代理服務器。有多個時，輪詢選擇
3.未綁定出接口且未設置爲首選。有多個時，輪詢選擇
注：首選與綁定出接口不衝突，綁定了出接口時，也可以設置爲首選；最多隻能選擇一個首選服務器。
如果首選綁定了出接口，但是出接口和DNS Server路由的出口，不一致，則此DNS Serve爲inactive，就會根據優先級進行選擇。
3.3.2 DNS代理服務器探測
服務器探測
代理動作爲Proxy時，DNS代理根據探測結果選擇代理server進行代理解析，DNS代理不會選擇inactive的服務器進行代理，探測流程如下：
»路由檢查。若路由不可達，則爲inactive；否則進行下一步檢查
»路由與出接口一致性檢查。若DNS代理server未綁定出接口，直接進行下一步檢查；若DNS代理server綁定出接口，但路由出接口與綁定出接口不一致，則爲inactive，否則進行下一步檢查
»服務器可達性檢測。定期發送DNS探測報文至代理server，如果收不到DNS應答，則爲inactive；如果可以收到DNS應答，則爲active
»探測報文，如果第一個失敗，則每隔10s發送一次，失敗三次，則判定DNS Server失效。
注：PPPoE, DHCP等下發的DNS服務器，以及配置的DNS服務器，不參與DNS代理
DNS代理只支持對dst-port = 53的UDP類型的DNS請求進行代理，對TCP類型的DNS請求報文進行透傳
DNS代理只支持對QueryType爲A或AAAA的DNS請求進行代理，對其它請求類型的DNS報文進行透傳
3.4 DNS Snoop被動探測
3.5 Debug
debug dp basic
debug self（DNS代理報文爲From self，需要開啓該開關）
debug dp dns proxy
debug dp filter dst-port 53
debug dp filter src-port 53
3.6 其他
日誌記錄
全局模式下，開啓ip domain response-log時，DNS代理解析成功時，可記錄network日誌，如：
2018-08-03 11:44:37, INFO@NET: DNS Response: domain t101.test.com, ttl 200, IP address 130.1.1.101
DNS session
show session [src-ip client_ip] [application dns]可以過濾dns session，查看用戶的DNS請求報文是否經過我們設備
代理服務器狀態
show dp-config dns-proxy可以查看所有代理服務器的狀態，Active表示服務器可用，Inactive表示服務器探測失敗
四、AX產品規格及其部署架構
4.1 產品規格
4.2 AX系列性能介紹
注：“S”型號具備硬件SSL加速卡，大幅度提高SSL性能
4.3 AX部署架構
|
組網模式 |
串接部署 |
單臂部署 |
透明部署 |
三角部署 |
|
部署位置 |
交換機和服務器之間 |
旁掛交換機 |
交換機和服務器之間 |
旁掛交換機 |
|
負載模式 |
LLB/SLB |
LLB/SLB |
SLB |
SLB |
|
特點 |
L3路由模式 |
引流到AX |
特殊需求使用 |
報文來回路徑不一致 |
|
優勢 |
可以溯源、接口壓力小 |
現網環境影響較小、減少單點故概率 |
現網環境影響較小 |
低時延、大吞吐 |
|
劣勢 |
現網改動大、需要更細緻瞭解組網架構 |
SNAT無法溯源、接口壓力大 |
定位較困難 |
配置複雜、功能簡單、只支持L4 |
五、AX常見故障類型
5.1 連通性
問題：客戶端和服務器均可達，通過AX地址訪問不通，客戶端直接訪問服務器業務正常
故障點：沒有配置Snat
解決方案：AX配置SNAT的2種方式：SNAT規則、虛擬服務下下開啓自動SNAT
SNAT規則（同防火牆）
虛擬服務器下開啓自動SNAT
5.2 業務分擔不均
問題：業務訪問正常，觀察後端服務器流量，各個業務流量分擔不均衡
故障點：調度算法、會話保持
（1） AX可以基於“源IP”、“Cookie”等進行會話保持
基於“源IP”的會話保持，由於源地址數量較少/經過NAT轉換
解決方案：沒有會話保持需求，關閉會話保持
選擇其他種類會話保持
（2）AX調度算法選擇不當
輪詢、加權輪詢、IP哈希等，基於後端服務適當選擇
5.3 業務訪問慢
某客戶原來業務訪問正常、部署AX之後，業務偶發訪問慢/失敗
組網架構：單臂部署 業務類型：HTTP
解決方案：排除錯誤，查看是否爲AX導致
排障步驟：
1.基於替換法，確認一定有問題
2.基於剔除法、確認只有訪問某臺服務器有問題
3.查看日誌信息，無思路
4.基於分層方式，將業務切換到L4，沒有問題
5.按照原理分析，L7與L4的區別，L7爲代理模式
6.是否七層代理之後連接建立有問題
7.基於分段，首先抓包分析客戶端到AX之間業務報文，貌似無問題
8.AX與服務端報文、MSS值爲150…