chinese直男口爆体育生外卖, 99久久er热在这里只有精品99, 又色又爽又黄18禁美女裸身无遮挡, gogogo高清免费观看日本电视,私密按摩师高清版在线,人妻视频毛茸茸,91论坛 兴趣闲谈,欧美 亚洲 精品 8区,国产精品久久久久精品免费

0
  • 聊天消息
  • 系統(tǒng)消息
  • 評論與回復(fù)
登錄后你可以
  • 下載海量資料
  • 學(xué)習(xí)在線課程
  • 觀看技術(shù)視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會(huì)員中心
創(chuàng)作中心

完善資料讓更多小伙伴認(rèn)識你,還能領(lǐng)取20積分哦,立即完善>

3天內(nèi)不再提示

TECS資源池上報(bào)網(wǎng)絡(luò)流程異常告警的問題處理

中興文檔 ? 來源:中興文檔 ? 2023-06-07 09:41 ? 次閱讀
加入交流群
微信小助手二維碼

掃碼添加小助手

加入工程師交流群

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

涉及UDM/PCF網(wǎng)元OMU虛機(jī)和ISBG網(wǎng)元的OMP虛機(jī),不間斷出現(xiàn)“網(wǎng)絡(luò)流量異?!备婢?/p>

問題分析如下:

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

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

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

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

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

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

59ff2850-0485-11ee-90ce-dac502259ad0.png

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

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

5a1d3e3a-0485-11ee-90ce-dac502259ad0.png

a.虛擬機(jī)的每一個(gè)虛口,對應(yīng)DVS虛交換都有兩個(gè)隊(duì)列緩存,用于DVS和該虛口收發(fā)包的處理。一個(gè)收隊(duì)列(VM--->DVS方向,默認(rèn)隊(duì)列長度1024),一個(gè)發(fā)隊(duì)列(DVS--->VM方向,默認(rèn)隊(duì)列長度1024)。該告警是對應(yīng)DVS的發(fā)隊(duì)列,即DVS發(fā)送報(bào)文給虛擬機(jī)的方向(圖中紅線示例部分)。

b.DVS收到物理口進(jìn)來的報(bào)文后,根據(jù)相應(yīng)的轉(zhuǎn)發(fā)規(guī)則,將對應(yīng)的報(bào)文向不同的虛擬機(jī)的虛口轉(zhuǎn)發(fā),發(fā)送的報(bào)文會(huì)進(jìn)入發(fā)送隊(duì)列。

c.DVS根據(jù)隊(duì)列的標(biāo)志位狀態(tài)決定是否產(chǎn)生中斷信號,通知虛擬機(jī)接收發(fā)送隊(duì)列的包(隊(duì)列標(biāo)志位狀態(tài)由虛擬機(jī)內(nèi)部收包進(jìn)程維護(hù):當(dāng)虛擬機(jī)內(nèi)正在處理收包時(shí),置標(biāo)志位狀態(tài)標(biāo)記DVS為不需要發(fā)送中斷信號通知虛擬機(jī)處理收包;當(dāng)虛擬機(jī)內(nèi)沒有處理收包時(shí),置標(biāo)志位標(biāo)記DVS為需要立即發(fā)送中斷信號通知虛擬機(jī)處理收包)。

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

e.DVS每隔5秒檢測一次overrun的統(tǒng)計(jì)和本周期內(nèi)收包總數(shù)的比值,如果連續(xù)3次檢測,overrun的報(bào)文占比達(dá)到告警門限(丟包超過千分之一),就會(huì)上報(bào)告警。

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

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

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

4.由于網(wǎng)絡(luò)流量異常告警不止一個(gè)種類的虛機(jī),統(tǒng)計(jì)了4個(gè)月非凌晨操作時(shí)間的“網(wǎng)絡(luò)流量異?!钡臍v史告警,結(jié)果如下圖所示。

5a27f582-0485-11ee-90ce-dac502259ad0.png

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

6.UDM/PCF網(wǎng)元OMU虛機(jī):

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

b.現(xiàn)網(wǎng)OMU創(chuàng)建大量端到端信令跟蹤任務(wù),未及時(shí)進(jìn)行清理,會(huì)出現(xiàn)該現(xiàn)象,原因?yàn)椋含F(xiàn)場OMU 有N個(gè)SC。

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

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

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

7.ISBG網(wǎng)元的OMP虛機(jī):

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

5a36ba68-0485-11ee-90ce-dac502259ad0.png

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

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

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

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

5a54c684-0485-11ee-90ce-dac502259ad0.png

9.內(nèi)存庫占用按模塊統(tǒng)計(jì),如下圖所示。

5a67e48a-0485-11ee-90ce-dac502259ad0.png

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

a.兩性能統(tǒng)計(jì)任務(wù)勾選全量模塊對象,實(shí)際應(yīng)用中只需勾選真實(shí)激活的SMP模塊即可(CDB、OMP以及未激活SMP模塊無需勾選),按真實(shí)應(yīng)用只需勾選47個(gè)SMP測量對象。

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

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

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

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

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

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

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

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

3.本次網(wǎng)絡(luò)流量異常告警主要是因?yàn)樯蠈泳W(wǎng)元有抓包或信令跟蹤導(dǎo)致,告警本身無業(yè)務(wù)影響。






審核編輯:劉清

聲明:本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點(diǎn)僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學(xué)習(xí)之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問題,請聯(lián)系本站處理。 舉報(bào)投訴
  • PCF
    PCF
    +關(guān)注

    關(guān)注

    0

    文章

    32

    瀏覽量

    21344
  • DVS
    DVS
    +關(guān)注

    關(guān)注

    0

    文章

    18

    瀏覽量

    9932
  • 虛擬機(jī)
    +關(guān)注

    關(guān)注

    1

    文章

    973

    瀏覽量

    30683
  • ToR
    ToR
    +關(guān)注

    關(guān)注

    0

    文章

    8

    瀏覽量

    10647
  • NFV
    NFV
    +關(guān)注

    關(guān)注

    3

    文章

    118

    瀏覽量

    34966

原文標(biāo)題:TECS資源池上報(bào)網(wǎng)絡(luò)流程異常告警的問題處理

文章出處:【微信號:ztedoc,微信公眾號:中興文檔】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。

收藏 人收藏
加入交流群
微信小助手二維碼

掃碼添加小助手

加入工程師交流群

    評論

    相關(guān)推薦
    熱點(diǎn)推薦

    Linux磁盤空間告警的常見原因和診斷方法

    磁盤空間告警是運(yùn)維工作中最常見的告警類型之一。當(dāng)磁盤空間耗盡時(shí),應(yīng)用程序無法寫入日志、數(shù)據(jù)庫無法正常提交、容器無法創(chuàng)建新鏡像,甚至系統(tǒng)日志寫入失敗會(huì)導(dǎo)致難以診斷的連鎖故障。本文從實(shí)際運(yùn)維經(jīng)驗(yàn)出發(fā),提供一套完整的磁盤空間問題定位和解決流程
    的頭像 發(fā)表于 04-08 14:25 ?97次閱讀

    如何控制告警聲音,或者實(shí)現(xiàn)長鳴告警?

    如何控制告警聲音,或者實(shí)現(xiàn)長鳴告警?
    發(fā)表于 01-20 17:10

    使用setjmp及l(fā)ongjmp函數(shù)處理異常

    ,例如在發(fā)生錯(cuò)誤或異常時(shí),直接跳轉(zhuǎn)到錯(cuò)誤處理資源釋放的代碼,而不需要逐層返回。setjmp和longjmp函數(shù)定義在setjmp.h頭文件中,其語法為: int setjmp(jmp_buf
    發(fā)表于 12-11 08:00

    電能質(zhì)量在線監(jiān)測裝置的多級告警閾值功能是如何實(shí)現(xiàn)的?

    與設(shè)備耐受度。以下從技術(shù)架構(gòu)、實(shí)現(xiàn)流程、核心機(jī)制三方面詳細(xì)解析: 一、技術(shù)架構(gòu):分層實(shí)現(xiàn)多級告警能力 多級告警閾值功能的實(shí)現(xiàn)依賴于硬件層、數(shù)據(jù)處理層、閾值管理層、
    的頭像 發(fā)表于 12-10 14:32 ?598次閱讀
    電能質(zhì)量在線監(jiān)測裝置的多級<b class='flag-5'>告警</b>閾值功能是如何實(shí)現(xiàn)的?

    C++程序異常處理機(jī)制

    1、什么是異常處理? 有經(jīng)驗(yàn)的朋友應(yīng)該知道,在正常的C和C++編程過程中難免會(huì)碰到程序不按照原本設(shè)計(jì)運(yùn)行的情況。 最常見的有除法分母為零,數(shù)組越界,內(nèi)存分配失效、打開相應(yīng)文件失敗等等。 一個(gè)程序
    發(fā)表于 12-02 07:12

    線路保護(hù)光纖通道異常處理方法

    通道異常的 常見原因、處理步驟及預(yù)防措施 ,幫助運(yùn)維人員快速定位問題,提升故障處理效率。 廣州郵科光纖線路保護(hù)系統(tǒng) 一、光纖通道異常的常見表現(xiàn) 當(dāng)線路保護(hù)光纖通道出現(xiàn)
    的頭像 發(fā)表于 11-17 10:01 ?1524次閱讀
    線路保護(hù)光纖通道<b class='flag-5'>異常</b><b class='flag-5'>處理</b>方法

    API接口調(diào)用中的網(wǎng)絡(luò)異常及解決方案

    一、連接類異常:“無法建立通信鏈路” 連接類異常的核心問題是 客戶端與API服務(wù)器之間無法成功建立TCP連接 ,導(dǎo)致調(diào)用請求“發(fā)不出去”,是網(wǎng)絡(luò)層最基礎(chǔ)的異常類型。 1. 常見場景與原
    的頭像 發(fā)表于 11-17 09:22 ?926次閱讀

    如何處理電能質(zhì)量在線監(jiān)測裝置時(shí)鐘模塊自動(dòng)同步異常的情況?

    針對性解決方案。以下是具體處理流程和操作方法: 一、通用前置步驟:明確異常類型與核心信息 處理前需先收集關(guān)鍵信息,避免盲目操作: 確認(rèn)同步方式 :通過裝置 Web 界面或手冊,明確當(dāng)前
    的頭像 發(fā)表于 10-27 10:16 ?1230次閱讀

    交換機(jī)光模塊收發(fā)光超閾值無告警問題的處理方法

    某互聯(lián)網(wǎng)電視CDN網(wǎng)絡(luò)使用ZXR10 5960-56QU-HC交換機(jī)作為承載設(shè)備,通過光口與城域網(wǎng)設(shè)備以及CDN服務(wù)器對接,承載互聯(lián)網(wǎng)電視視頻流量。日常運(yùn)行中發(fā)現(xiàn)設(shè)備沒有上報(bào)光模塊收發(fā)光超閾值告警,造成無法對互聯(lián)網(wǎng)電視的
    的頭像 發(fā)表于 10-16 09:34 ?1055次閱讀
    交換機(jī)光模塊收發(fā)光超閾值無<b class='flag-5'>告警</b>問題的<b class='flag-5'>處理</b>方法

    Linux服務(wù)器入侵檢測與應(yīng)急響應(yīng)流程

    作為一名運(yùn)維工程師,你是否曾在凌晨3點(diǎn)接到告警電話?服務(wù)器異常、流量暴增、CPU飆升...這些可能都是入侵的征兆。本文將分享一套完整的Linux服務(wù)器入侵檢測與應(yīng)急響應(yīng)流程,讓你在面對安全事件時(shí)有條不紊,快速定位并解決問題。
    的頭像 發(fā)表于 08-21 17:29 ?2210次閱讀

    碳化硅襯底 TTV 厚度測量數(shù)據(jù)異常的快速診斷與處理流程

    摘要 本文針對碳化硅襯底 TTV 厚度測量中出現(xiàn)的數(shù)據(jù)異常問題,系統(tǒng)分析異常類型與成因,構(gòu)建科學(xué)高效的快速診斷流程,并提出針對性處理方法,旨在提升數(shù)據(jù)
    的頭像 發(fā)表于 08-14 13:29 ?1361次閱讀
    碳化硅襯底 TTV 厚度測量數(shù)據(jù)<b class='flag-5'>異常</b>的快速診斷與<b class='flag-5'>處理</b><b class='flag-5'>流程</b>

    信而泰×DeepSeek:AI推理引擎驅(qū)動(dòng)網(wǎng)絡(luò)智能診斷邁向 “自愈”時(shí)代

    有效降低整體運(yùn)維成本l 優(yōu)化人力資源:AI自動(dòng)化處理大量重復(fù)性監(jiān)控、初步分析與告警任務(wù),釋放高級工程師精力,使其專注于更具戰(zhàn)略性的復(fù)雜問題與創(chuàng)新。l 提升資源利用率:AI可基于分析結(jié)果
    發(fā)表于 07-16 15:29

    C#上位機(jī)與運(yùn)動(dòng)控制卡網(wǎng)絡(luò)通訊的周期上報(bào)

    使用C#上位機(jī)編程實(shí)現(xiàn)運(yùn)動(dòng)控制卡網(wǎng)絡(luò)通訊的周期上報(bào)功能
    的頭像 發(fā)表于 06-26 13:59 ?977次閱讀
    C#上位機(jī)與運(yùn)動(dòng)控制卡<b class='flag-5'>網(wǎng)絡(luò)</b>通訊的周期<b class='flag-5'>上報(bào)</b>

    智能電纜通斷采集機(jī),實(shí)時(shí)監(jiān)測精準(zhǔn)告警

    產(chǎn)品作用 電纜通斷采集主機(jī)是一款高度智能化的監(jiān)控設(shè)備,主要用于實(shí)時(shí)監(jiān)測電纜的通斷狀態(tài),并在異常情況下及時(shí)觸發(fā)告警。該設(shè)備支持多種移動(dòng)信號,確保數(shù)據(jù)傳輸?shù)姆€(wěn)定性和可靠性。適用于電力、通信、交通、安防等
    的頭像 發(fā)表于 06-21 09:54 ?736次閱讀
    智能電纜通斷采集機(jī),實(shí)時(shí)監(jiān)測精準(zhǔn)<b class='flag-5'>告警</b>

    TECS OpenStack資源池虛擬機(jī)網(wǎng)絡(luò)二層地址無法互通的問題處理

    某運(yùn)營商TECS OpenStack使用主機(jī)overlay SDN方案組網(wǎng),運(yùn)維人員在創(chuàng)建虛擬機(jī)測試虛擬機(jī)網(wǎng)絡(luò)狀態(tài)時(shí)發(fā)現(xiàn)問題:在其中一臺主機(jī)上創(chuàng)建兩臺同網(wǎng)段虛擬機(jī),虛擬機(jī)之間二層地址無法Ping通,但是可以Ping通網(wǎng)關(guān)地址,如圖1所示。
    的頭像 發(fā)表于 06-12 09:28 ?1001次閱讀
    <b class='flag-5'>TECS</b> OpenStack<b class='flag-5'>資源</b>池虛擬機(jī)<b class='flag-5'>網(wǎng)絡(luò)</b>二層地址無法互通的問題<b class='flag-5'>處理</b>