雙域容災組網場景,用戶接入后在主用UPF建立會話,長Ping內網地址可Ping通。執(zhí)行中斷雙域主用UPF腳本文件,長Ping中斷。
終端使用飛行模式后再次接入,SMF與雙域備用UPF可正常建立會話,但仍不可訪問內網,Ping測不通時互轉隧道發(fā)送報文異常,主備UPF雙方都無法收到企業(yè)回復報文。
NF互轉類問題的排查思路如下:
1.通過用戶數據跟蹤或EM DPDK抓包,確認UPF是否正常將報文轉發(fā),若不轉發(fā),則排查本端UPF本身問題。
2. 若對端UPF未接收到報文,則排查NF互轉鏈路的轉發(fā)節(jié)點(交換機、防火墻等)。
3. 若對端UPF已接收到報文但未轉發(fā),則排查對端UPF。
4.若對端UPF接收到報文且轉發(fā),但未收到N6回復報文,則排查N6或企業(yè)側。
互轉隧道異常問題的排查過程如下:
1. 互轉隧道(GRE)測試時,主用UPF和備用UPF配置N9地址,地址段分別為:
雙域主UPF互轉隧道(N9地址段):2409290C650A、2409290C650B、2409290C650C。
雙域備UPF互轉隧道(N9地址段):2409290C660A、2409290C660B、2409290C660C。
2. 當主用UPF恢復時,上下行的路徑為:UE→基站→備用UPF→業(yè)務交換機→CMNET CE→CMNET FW→CR→......(中間路徑未知)→CR→另一機房CMNET FW→CMNET CE→業(yè)務交換機→主用 UPF。 3. 互轉隧道測試原理分析:
已在備用UPF上建立會話的用戶,且主用UPF故障恢復后的上行媒體報文路徑:備用UPF的N6→匯聚CE→客戶服務器。
下行媒體報文路徑:客戶服務器→匯聚CE→主用UPF的N6(服務器回復報文依據匯聚CE到主備UPF的GRE隧道優(yōu)先級高低決定回程路徑)→備用UPF(主用UPF判斷該報文不是自己的,因此通過互轉隧道地址(和N9同網段)發(fā)送給備用UPF)→終端。
4. 在UPF網元進行NF互轉隧道互Ping測試,采用本端N9地址作為源地址Ping對端N9地址,可以Ping通,Trace測試有相應路徑。互Ping測試時在EM分別針對主備UPF進行DPDK抓包測試,發(fā)現兩套UPF在測試期間都有收發(fā)包。 5. 在UPF網元上進行上行抓包、下行抓包進行排查,確定業(yè)務報文沒有經過UPF的互轉隧道地址流動到對方UPF,分析補丁包影響,確保非版本問題。 6. 由于NF互轉隧道經過防火墻節(jié)點,因此需要協(xié)調防火墻側排查是否進行了相關攔截。
1.經防火墻側排查,容災測試期間,在防火墻可以看到有相關會話產生,但并未將UPF互轉隧道的GRE報文進行轉發(fā),進一步排查發(fā)現防火墻未放通GRE隧道,因此需要配置service gre命令放通隧道協(xié)議。
2.相關信息:GRE VPN互備是在兩個UPF/PGW-U之間配置互轉隧道,通過轉發(fā)靜態(tài)地址用戶的業(yè)務流,實現靜態(tài)地址用戶能夠在兩個UPF/PGW-U上備份接入,提高網絡可靠性。
靜態(tài)地址用戶的下行報文在主用UPF/PGW-U上找不到用戶上下文時,可以通過互轉隧道轉發(fā)到備用UPF/PGW-U上進行處理;UPF/PGW-U和企業(yè)服務器間的鏈路異常時,UPF/PGW-U發(fā)給企業(yè)服務器的靜態(tài)地址用戶上行報文通過互轉隧道首先轉發(fā)到備份的UPF/PGW-U上,再轉發(fā)到企業(yè)服務器,如下圖所示。
審核編輯:劉清
-
交換機
+關注
關注
20文章
2598瀏覽量
98869 -
SMF
+關注
關注
0文章
14瀏覽量
8685 -
UPF
+關注
關注
0文章
49瀏覽量
13463 -
GRE
+關注
關注
0文章
19瀏覽量
8555
原文標題:ZXUN xGW-UPF雙域容災局點互轉隧道異常的問題處理
文章出處:【微信號:ztedoc,微信公眾號:中興文檔】歡迎添加關注!文章轉載請注明出處。
發(fā)布評論請先 登錄
相關推薦
評論