某运营商反馈车载电脑相关业务出现时好时坏的情况，经常需要重启车载电脑恢复业务。通过Ping等方式进行网络测试，发现从监控室电脑Ping车载设备，出现不规律、不定期的少量丢包现象。
对丢包问题进行定位排查、故障复现和测试。经过多轮测试，多方面分析及多网元协调。故障现象大致如下：
1. 车载CPE和企业内网AR路由器之间启用VxLAN隧道协议，当监控室Ping车载设备IP出现丢包时，AR直接Ping CPE终端基本上也会丢包。
2. 车载CPE下挂视频监控、串口服务器、硬盘录像机和车载电脑，共4个业务，分别对这些业务进行单个及多个业务组合接入情况测试，发现只有车载电脑接入后，Ping丢包现象才复现。
3. CPE单独接入车载电脑进行Ping网络测试，无论是VxLAN隧道内业务Ping（如：19.51.22.82 Ping 19.51.22.241），还是AR Ping CPE终端（如10.100.100.2 Ping 179.10.25.15），均出现间歇性丢包的现象。此时5G网络或者VxLAN隧道并未断链，如下图所示。
在上图中红色框1内是监控室电脑登录AR录取Ping CPE 179.10.25.15，红色框2内是监控室电脑远程桌面到车载电脑，并在车载电脑中Ping 19.51.22.241。
一、组网图
该业务场景中组网如下图所示，需要特别注意5G CPE与N6的AR路由器采用VxLAN方式对接。
二、抓包分析
针对丢包问题，在AR路由器Ping CPE和车载电脑Ping监控中心时，分别在CPE终端、5G基站及核心网UPF几个节点进行抓包，结果分析如下：
1. 下行抓包，当AR路由器10.100.100.2 Ping CPE终端179.10.25.15时，在UPF、基站，以及终端上同时抓包。
2. 分析终端抓包结果，发现前12个报文未收到，从第13个报文开始有reply，如下图所示。
3. 分析基站抓包结果，同样未收到前12个request报文，如下图所示。
4. 分析UPF抓包结果，UPF仅收到了来自N6的ICMP报文，未转换成GTP<ICMP>的N3报文发给基站，如下图所示。
5. 因此，初步判定Ping报文在UPF中丢失。
6. 分析UPF丢包问题，对UPF配置及抓包结果进行多次比对和分析，确定本次测试Ping丢包的CPE终端在核心网UPF上因建流数量太多，达到阈值后被核心网流控。
核心网为了使资源合理分配，避免单用户无限制占用资源，配置了单用户粒度建立流的最大数目为4000，DNN粒度用户建立流总数最大为2400，如下图所示。
7. 该配置表示目标DNN在网终端建立总数超过2400就会被限流，而限流的终端不固定，与当时终端业务相关，因此会出现不规律丢包或业务异常。
8. 根据流统计分析，测试CPE（179.10.25.15）在0.1s内创建约20个流链接，如下图所示。
9.分析终端建立流数量过大问题：终端在进行VxLAN报文封装时，针对每个报文封装的VxLAN随机使用不同的源端口，并且AR路由器对报文进行VxLAN封装时也随机使用不同源端口，而不同源端口的流都视为一个流链路，因此该终端相关的流链数量很大。
此外，终端业务对流释放较慢，整体上很容易达到核心网设置的阈值导致被流控，如下图所示。
三、业务分析
10. CPE下挂4个业务，经测试，仅车载电脑的业务出现丢包情况，而且从抓包分析结果看，由于业务建链过多，导致终端建立流的数量过大导致丢包。分析车载电脑业务，截取车载电脑端口使用情况如下图所示。
11. 与用户沟通了解到，车载电脑除了对接监控室相关设备，还需要对接车管所及三方系统等，连接数量比较其他业务要多很多。
13. 综上所述，本次丢包故障主要原因有三：
车载电脑对接多个系统，连接数量多，超出预估。
CPE终端和AR路由器对报文进行VxLAN封装的源端口随机不固定，导致流建立数量过大，超过核心网UPF设置的阈值。
核心网UPF设置的允许用户建立流数量阈值设置小。
1.由于CPE终端和AR路由器在对报文进行VxLAN封装时，均在随机使用不同端口进行建立流，导致流数量过大。建议CPE终端和AR路由器对VxLAN协议栈进行修改，规定固定端口作为VxLAN封装的源端口，减少流链路。
2. 取消VxLAN组网，使用NAT映射方式，即在驾校内部AR路由器上进行终端地址+端口映射，在CPE上做车载设备映射，如下图所示。
该方案需详细了解业务端口，且车载设备各个业务不能使用重复端口，监控中心及其他系统可以访问AR路由器的NAT。
我们是一群平均从业年限5+的通信专业工程师。 关注我们，带你了解通信世界的精彩！
