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

涉及UDM/PCF網(wǎng)元OMU虛機和ISBG網(wǎng)元的OMP虛機，不間斷出現(xiàn)“網(wǎng)絡流量異?！备婢?。

問題分析如下：

1.告警發(fā)生在多個網(wǎng)元環(huán)境，涉及不通的主機以及主機集合，以及多個業(yè)務TOR，按照問題發(fā)生的規(guī)律性排除單臺的硬件故障。

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

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

4.按照問題發(fā)生的嚴重度，優(yōu)先選擇告警最頻繁的網(wǎng)元虛擬機做抓包定位分析，同時結合歷史數(shù)據(jù)做規(guī)律性排查。

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

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



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

3.TECS網(wǎng)絡流量異常告警產(chǎn)生機制，如圖5所示。



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

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

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

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

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

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

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

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

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



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

6.UDM/PCF網(wǎng)元OMU虛機：

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

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

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

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

e.TIPI是立刻重傳，只要接收方發(fā)現(xiàn)接收的消息不連續(xù)，會給發(fā)送消息方請求重傳，請求方接收到重傳請求，會立刻重傳。

7.ISBG網(wǎng)元的OMP虛機：

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



a.收發(fā)包峰值時刻深入分析確定，峰值收發(fā)包均由網(wǎng)元性能統(tǒng)計采集數(shù)據(jù)產(chǎn)生。

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

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

8.S-CSCF用戶數(shù)按模塊統(tǒng)計，如下圖所示。



9.內存庫占用按模塊統(tǒng)計，如下圖所示。



10.查看“SCSCF 用戶數(shù)按模塊統(tǒng)計”、“內存庫占用按模塊統(tǒng)計”性能統(tǒng)計任務發(fā)現(xiàn)：

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

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

c.性能統(tǒng)計與外部信令交互區(qū)分通道執(zhí)行，此性能統(tǒng)計流量瞬時突增不會波及VoLTE業(yè)務流程，對業(yè)務無影響。

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

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

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

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

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

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

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