双域容灾组网场景,用户接入后在主用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上,再转发到企业服务器,如下图所示。
审核编辑:刘清
全部0条评论
快来发表一下你的评论吧 !