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

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

NF互轉(zhuǎn)類問題的排查思路如下：

1.通過用戶數(shù)據(jù)跟蹤或EM DPDK抓包，確認UPF是否正常將報文轉(zhuǎn)發(fā)，若不轉(zhuǎn)發(fā)，則排查本端UPF本身問題。

2. 若對端UPF未接收到報文，則排查NF互轉(zhuǎn)鏈路的轉(zhuǎn)發(fā)節(jié)點（交換機、防火墻等）。

3. 若對端UPF已接收到報文但未轉(zhuǎn)發(fā)，則排查對端UPF。

4.若對端UPF接收到報文且轉(zhuǎn)發(fā)，但未收到N6回復(fù)報文，則排查N6或企業(yè)側(cè)。

互轉(zhuǎn)隧道異常問題的排查過程如下：

1. 互轉(zhuǎn)隧道（GRE）測試時，主用UPF和備用UPF配置N9地址，地址段分別為：

雙域主UPF互轉(zhuǎn)隧道（N9地址段）：2409290C650A、2409290C650B、2409290C650C。

雙域備UPF互轉(zhuǎn)隧道（N9地址段）：2409290C660A、2409290C660B、2409290C660C。

2. 當主用UPF恢復(fù)時，上下行的路徑為：UE→基站→備用UPF→業(yè)務(wù)交換機→CMNET CE→CMNET FW→CR→......(中間路徑未知)→CR→另一機房CMNET FW→CMNET CE→業(yè)務(wù)交換機→主用 UPF。 3. 互轉(zhuǎn)隧道測試原理分析：

已在備用UPF上建立會話的用戶，且主用UPF故障恢復(fù)后的上行媒體報文路徑：備用UPF的N6→匯聚CE→客戶服務(wù)器。

下行媒體報文路徑：客戶服務(wù)器→匯聚CE→主用UPF的N6（服務(wù)器回復(fù)報文依據(jù)匯聚CE到主備UPF的GRE隧道優(yōu)先級高低決定回程路徑）→備用UPF（主用UPF判斷該報文不是自己的，因此通過互轉(zhuǎn)隧道地址（和N9同網(wǎng)段)發(fā)送給備用UPF）→終端。

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

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

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

靜態(tài)地址用戶的下行報文在主用UPF/PGW-U上找不到用戶上下文時，可以通過互轉(zhuǎn)隧道轉(zhuǎn)發(fā)到備用UPF/PGW-U上進行處理；UPF/PGW-U和企業(yè)服務(wù)器間的鏈路異常時，UPF/PGW-U發(fā)給企業(yè)服務(wù)器的靜態(tài)地址用戶上行報文通過互轉(zhuǎn)隧道首先轉(zhuǎn)發(fā)到備份的UPF/PGW-U上，再轉(zhuǎn)發(fā)到企業(yè)服務(wù)器，如下圖所示。

審核編輯：劉清