雙域容災組網(wǎng)場景，用戶接入后在主用UPF建立會話，長Ping內(nèi)網(wǎng)地址可Ping通。執(zhí)行中斷雙域主用UPF腳本文件，長Ping中斷。

終端使用飛行模式后再次接入，SMF與雙域備用UPF可正常建立會話，但仍不可訪問內(nèi)網(wǎng)，Ping測不通時互轉隧道發(fā)送報文異常，主備UPF雙方都無法收到企業(yè)回復報文。

NF互轉類問題的排查思路如下：

1.通過用戶數(shù)據(jù)跟蹤或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（服務器回復報文依據(jù)匯聚CE到主備UPF的GRE隧道優(yōu)先級高低決定回程路徑）→備用UPF（主用UPF判斷該報文不是自己的，因此通過互轉隧道地址（和N9同網(wǎng)段)發(fā)送給備用UPF）→終端。

4. 在UPF網(wǎng)元進行NF互轉隧道互Ping測試，采用本端N9地址作為源地址Ping對端N9地址，可以Ping通，Trace測試有相應路徑?；ing測試時在EM分別針對主備UPF進行DPDK抓包測試，發(fā)現(xiàn)兩套UPF在測試期間都有收發(fā)包。 5. 在UPF網(wǎng)元上進行上行抓包、下行抓包進行排查，確定業(yè)務報文沒有經(jīng)過UPF的互轉隧道地址流動到對方UPF，分析補丁包影響，確保非版本問題。 6. 由于NF互轉隧道經(jīng)過防火墻節(jié)點，因此需要協(xié)調(diào)防火墻側排查是否進行了相關攔截。

1.經(jīng)防火墻側排查，容災測試期間，在防火墻可以看到有相關會話產(chǎn)生，但并未將UPF互轉隧道的GRE報文進行轉發(fā)，進一步排查發(fā)現(xiàn)防火墻未放通GRE隧道，因此需要配置service gre命令放通隧道協(xié)議。

2.相關信息：GRE VPN互備是在兩個UPF/PGW-U之間配置互轉隧道，通過轉發(fā)靜態(tài)地址用戶的業(yè)務流，實現(xiàn)靜態(tài)地址用戶能夠在兩個UPF/PGW-U上備份接入，提高網(wǎng)絡可靠性。

靜態(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è)服務器，如下圖所示。

審核編輯：劉清