TECS資源池上報網絡流程異常告警的問題處理

某資源池TECS上報網絡流程異常告警，告警單次持續15秒-4分鐘之間。

涉及UDM/PCF網元OMU虛機和ISBG網元的OMP虛機，不間斷出現“網絡流量異?！备婢?。

問題分析如下：

1.告警發生在多個網元環境，涉及不通的主機以及主機集合，以及多個業務TOR，按照問題發生的規律性排除單臺的硬件故障。

2.在線TECS版本和硬件組合已在多個站點使用，未發生相關情況，排除軟件版本和硬件的兼容性問題。

3.結合具體現場情況，上層業務多為測試版本，需要重點定位在上層業務和TECS的配合。

4.按照問題發生的嚴重度，優先選擇告警最頻繁的網元虛擬機做抓包定位分析，同時結合歷史數據做規律性排查。

本次網絡流量異常告警涉及網絡虛機多，但問題原因類似，以下涉及的TECS以排查一個網元虛機為例。

1.通過告警詳情，TECS檢查虛機對應端口性能統計，如下圖所示。



2.從告警詳情中得知虛機NFV-R-xxx-56OMP_L的vhu599f535d-1f端口在接收的21859個包中，丟了380個包，丟包率為1.7%。隨即統計了該虛機端口指標，發現虛機端口流入有丟包，端口流出沒有丟包。

3.TECS網絡流量異常告警產生機制，如圖5所示。



a.虛擬機的每一個虛口，對應DVS虛交換都有兩個隊列緩存，用于DVS和該虛口收發包的處理。一個收隊列（VM--->DVS方向，默認隊列長度1024），一個發隊列（DVS--->VM方向，默認隊列長度1024）。該告警是對應DVS的發隊列，即DVS發送報文給虛擬機的方向（圖中紅線示例部分）。

b.DVS收到物理口進來的報文后，根據相應的轉發規則，將對應的報文向不同的虛擬機的虛口轉發，發送的報文會進入發送隊列。

c.DVS根據隊列的標志位狀態決定是否產生中斷信號，通知虛擬機接收發送隊列的包（隊列標志位狀態由虛擬機內部收包進程維護：當虛擬機內正在處理收包時，置標志位狀態標記DVS為不需要發送中斷信號通知虛擬機處理收包；當虛擬機內沒有處理收包時，置標志位標記DVS為需要立即發送中斷信號通知虛擬機處理收包）。

d.當虛擬機沒能及時取走隊列的數據，DVS發向虛擬機虛口的報文填滿隊列時，則會出現隊列消息積壓，超過了隊列的長度，后續多余的報文就會因為無法入隊列而被丟棄，丟棄的報文數統計在overrun中。

e.DVS每隔5秒檢測一次overrun的統計和本周期內收包總數的比值，如果連續3次檢測，overrun的報文占比達到告警門限（丟包超過千分之一），就會上報告警。

f.計算節點上可以使用統計命令dvs show-dpifstats，采集所有虛擬機虛口和物理網口的收發包歷史統計信息，命令需要通過多次采集后，根據采集的結果，觀察虛口是否存在tx_overrun的統計增加。如果存在虛口在采集的周期內增加現象，說明虛擬機處理DVS發送隊列的報文不及時（或者處理能力不足），無法及時消費隊列的報文導致報文overrun。 g.DVS處理能力如下，本次問題的核心不是DVS的處理能力，而是在于業務虛擬機的處理能力。

25G網卡帶寬分配比例為0.24（DVS最大處理能力為12Gbps）。

10G網卡帶寬分配比例為0.35（DVS最大處理能力為 7Gbps）。

4.由于網絡流量異常告警不止一個種類的虛機，統計了4個月非凌晨操作時間的“網絡流量異?！钡臍v史告警，結果如下圖所示。



5.采集觀察每一類虛機指標發現，丟包均為DVS 發送報文給虛擬機的方向。且同類型虛機都是入向到端口有丟包，可以判定是上層網元虛機原因，需要上層業務虛機側協助排查。

6.UDM/PCF網元OMU虛機：

a.現場停止OMU虛機的端到端信令跟蹤任務后，告警不再出現。

b.現網OMU創建大量端到端信令跟蹤任務，未及時進行清理，會出現該現象，原因為：現場OMU 有N個SC。

c.當前信令跟蹤任務同步機制為：每條信令跟蹤任務數據約4K記錄，需要全表同步，即每次信令跟蹤任務激活，都會把所有信令跟蹤任務數據全量同步至前臺。

d.此外，MP向SC同步數據時，要乘以SC個數，即每次要同步N*4K*300的數據。大包需要進行分包，造成一次往前臺同步的數據量很大，造成虛機流量過大，出現告警。

e.TIPI是立刻重傳，只要接收方發現接收的消息不連續，會給發送消息方請求重傳，請求方接收到重傳請求，會立刻重傳。

7.ISBG網元的OMP虛機：

針對資源池DVS進行抓包分析，發現存在瞬間大量包集中收發情況，5秒內瞬時沖高收發27000個包，之后立即恢復正常，如下圖所示。



a.收發包峰值時刻深入分析確定，峰值收發包均由網元性能統計采集數據產生。

b.以日志采集為例，該時刻約產生27000個包，其中“SCSCF 用戶數按模塊統計”性能統計任務瞬間產生12596個包；“內存庫占用按模塊統計”性能統計任務瞬間產生13617個包。

c.兩個性能統計任務瞬間合計產生26213個包（12596+13617=26213），說明資源池產生流量峰值與“SCSCF 用戶數按模塊統計”、“內存庫占用按模塊統計”兩個性能統計任務有關聯。

8.S-CSCF用戶數按模塊統計，如下圖所示。



9.內存庫占用按模塊統計，如下圖所示。



10.查看“SCSCF 用戶數按模塊統計”、“內存庫占用按模塊統計”性能統計任務發現：

a.兩性能統計任務勾選全量模塊對象，實際應用中只需勾選真實激活的SMP模塊即可（CDB、OMP以及未激活SMP模塊無需勾選），按真實應用只需勾選47個SMP測量對象。

b.其余勾選的測量對象（CDB、OMP以及未激活SMP模塊）為無效對象，導致處理性能統計上報的網卡上流量突增，流量突增時會影響底層資源池產生瞬時流量告警。

c.性能統計與外部信令交互區分通道執行，此性能統計流量瞬時突增不會波及VoLTE業務流程，對業務無影響。

d.此性能統計流量突增產生少量丟包情況。由于性能統計數據上報有重傳機制保障，不會影響性能統計數據整粒度采集，所以對性能統計數據呈現無影響。此外，由于流量沖高是瞬時行為，因此對網元自身CPU影響不大。

11.“SCSCF 用戶數按模塊統計”、“內存庫占用按模塊統計”兩個統計任務勾選了大量的無效性能統計測量對象，導致性能統計數據采集異常，單個網卡流量短暫沖高，偶發性造成短時間少量丟包，導致底層資源池產生端口流量異常告警，但不會影響網元業務及性能統計。

1.通過如下方式暫時規避該問題：

a.UDM / PCF：現場測試階段，盡量控制信令跟蹤任務在30個以下，完成測試后刪除測試號碼的跟蹤任務。

b.ISBG：“SCSCF 用戶數按模塊統計”、“內存庫占用按模塊統計”兩個統計任務去除測量對象勾選。

2.網絡流量異常告警是監控上層網元運行正常的重要告警之一，例如當上層網元虛機有下電或者重啟都會產生網絡流量異常告警，可通過告警信息判斷涉及網元、對應虛機及端口。

3.本次網絡流量異常告警主要是因為上層網元有抓包或信令跟蹤導致，告警本身無業務影響。