雙域容災組網場景，用戶接入后在主用UPF建立會話，長Ping內網地址可Ping通。執行中斷雙域主用UPF腳本文件，長Ping中斷。

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

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

1.通過用戶數據跟蹤或EM DPDK抓包，確認UPF是否正常將報文轉發，若不轉發，則排查本端UPF本身問題。

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

3. 若對端UPF已接收到報文但未轉發，則排查對端UPF。

4.若對端UPF接收到報文且轉發，但未收到N6回復報文，則排查N6或企業側。

互轉隧道異常問題的排查過程如下：

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

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

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

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

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

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

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

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

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

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

審核編輯：劉清