# UPF假活：PFCP心跳排查战 **概述**：5G SA核心网割接后的深夜，PDU会话建立成功率突然跳水，网元看起来“活着”，用户却大面积上不了网。本文以一次脱敏复盘案例为主线，拆解SMF与UPF之间的N4/PFCP心跳机制，完整还原“告警收敛→信令统计→双端抓包→传输比对”的四步排查法，最终实锤根因：防火墙漏放行PFCP回程报文。文章同步给出PFCP关键参数表、修复前后的配置对比，以及一套可直接落地的核心网抓包工具链与变更军规。所有协议细节锚定3GPP TS 29.244与Wireshark官方文档，案例数字为脱敏量级还原。 ## 目录 - 一、深夜惊魂：会话成功率跳水的时间线 - 二、先补课：PFCP——SMF与UPF之间的心跳线 - 三、排查四步法：从告警面打到抓包面 - 四、根因实锤：一条没放行的回程路 - 五、修复与验证：参数怎么调，监控怎么补 - 六、经验沉淀：核心网运维的抓包工具链与四条军规 - 参考来源 ## 一、深夜惊魂：会话成功率跳水的时间线 先交代背景。这是某省运营商5G SA核心网的一次夜间传输割接：按等保整改要求，要在SMF与UPF之间插入两台防火墙做安全域隔离。割接窗口选在凌晨零点，话务低谷，方案评审都过了，一切看起来很 routine。 以下案例为笔者亲历项目的复盘改写，局点、网元型号与数据均已脱敏，数字保留量级以还原现场。 | 时间 | 事件 | 现象与判断 | | --- | --- | --- | | 23:47 | 割接开始 | SMF-UPF间流量切换至新防火墙链路 | | 00:12 | 自动拨测告警 | PDU会话建立拨测连续失败 | | 00:20 | 成功率跳水 | 会话建立成功率从99.5%量级跌至92%量级，且持续抖动 | | 00:35 | 第一轮排查 | UPF CPU、内存、会话数均正常，“排除网元过载” | | 00:58 | 信令跟踪 | N4接口PFCP会话建立超时占比异常升高 | | 01:15 | 双端抓包 | SMF与UPF两侧同时镜像抓包，比对心跳与请求响应 | | 01:40 | 传输比对 | 防火墙drop日志与丢包时间点吻合 | | 02:05 | 应急处置 | 防火墙策略放通PFCP双向，关联逐步恢复 | | 02:30 | 业务恢复 | 成功率回到99.5%基线，转入观察期 | 这个案例最有教学价值的地方在于它的“迷惑性”：UPF进程活着、告警平台上它在线、KPI只跌不崩——典型的“假活”。老用户已建立的会话大部分不受影响，掉的是新建会话；而新建会话失败会触发终端反复重试，表现为用户“刷不出网页、打不开App”，投诉在半小时后才姗姗来迟。如果只盯网元告警，你会在错误的方向上耗一整夜。 ## 二、先补课：PFCP——SMF与UPF之间的心跳线 要看懂这个案子，得先理解N4接口上的PFCP协议。 5G核心网把“控制”与“转发”分离（CUPS思想），SMF管脑子，UPF管手脚。两者之间的控制通道就是N4接口，跑的协议叫PFCP（Packet Forwarding Control Protocol，包转发控制协议）。它的标准化载体是3GPP TS 29.244，标题就叫《Interface between the Control Plane and the User Plane nodes》，2016年9月随Rel-14立项（对应CUPS工作项），由CT4工作组负责，2026年6月的CT#112会议上刚更新了Rel-20的20.0.0版本——一个快十岁、仍在活跃演进的老兵。 PFCP有几个关键设计，直接决定了后面排查的走向： **第一，它跑在UDP上，注册端口8805。** UDP无连接、无内建保活，协议层自己设计了心跳机制来维持"PFCP Association"（PFCP关联）。 **第二，心跳机制是生命线。** SMF与UPF周期互发Heartbeat Request/Response，每条消息携带24比特的Sequence Number（序号）用于请求响应匹配，同时携带Recovery Time Stamp（恢复时间戳）——对端重启后时间戳会变，本端据此发现“对方重启过”，删除旧会话并重建关联。如果连续多次心跳Request等不到Response，本端就判定关联失效，极端情况下会触发会话级清理。这正是“假活”的机关：只要心跳丢得够多，SMF眼中的UPF就是“死了”，哪怕UPF进程其实活得好好的。 **第三，除了心跳，PFCP还内建了负荷与过载控制。** Wireshark的PFCP字段参考里能直接看到`pfcp.cp_function_features.load`（LOAD，负荷控制）和`pfcp.cp_function_features.ovrl`（OVRL，过载控制）等特性标志；还定义了`User Plane Path Failure Report`（用户面路径故障上报），让UPF能主动把GTP-U路径质量问题报告给SMF。这套设计意味着：路径劣化本来是有"吹哨人"机制的，前提是报文能通。 **第四，会话用F-SEID标识。** SMF在建会话时分配F-SEID（含IP地址+会话ID），UPF据此把每一条PFCP会话与用户面对应起来。排查时按F-SEID过滤信令跟踪，是最快的定位手段之一。 下面这张参数表，建议存进运维手册： | 项目 | 说明 | | --- | --- | | 承载协议 | UDP，IANA注册端口8805 | | 关联管理 | Association Setup/Update/Release + 周期Heartbeat维持 | | 心跳消息 | Heartbeat Request/Response，携带Sequence Number与Recovery Time Stamp | | 可靠性机制 | 标准定义了响应等待定时器与重传次数（T3/N1），默认值标准允许多种实现，具体以各厂家官方文档为准 | | 判死条件 | 工程上通常为连续2~3次心跳无响应即判关联失效（工程惯例，非标准强制值） | | 会话标识 | F-SEID，按会话过滤信令的第一索引 | | 内建保护 | 负荷控制LOAD、过载控制OVRL、路径故障上报UPFR | 心跳周期设多长是个平衡术：设短了，传输抖一下就误判；设长了，真故障发现变慢。常见工程配置在10秒量级，但具体取值以各厂家官方文档为准。 ## 三、排查四步法：从告警面打到抓包面 复盘整个过程，可以提炼成一张排查流程图，核心思想是：**告警面圈范围→信令面定接口→抓包面看报文→传输面找凶手**，每一层都为下一层缩小包围圈。 ```mermaid flowchart TD A["凌晨告警：PDU会话建立成功率跳水"] --> B["第一步：圈定故障面"] B --> B1["受影响UPF清单与时间窗"] A --> C["第二步：网管信令跟踪"] C --> C1["N4接口统计：会话建立超时为主"] C1 --> D["第三步：SMF与UPF双端镜像抓包"] D --> D1["SMF侧：Request重传无Response"] D --> D2["UPF侧：Response已正常发出"] D1 --> E["第四步：比对防火墙drop日志"] D2 --> E E --> F{"回程报文是否被丢"} F -->|是| G["根因：策略漏放行8805回程"] F -->|否| H["根因：链路丢包或哈希震荡"] G --> I["修复：补放行策略"] H --> J["修复：换光模块并调心跳参数"] I --> K["验证：拨测恢复与长曲线观察"] J --> K ``` **第一步：圈定故障面，别急着重启。** 拨测系统0:12告警后，先做的是把“哪些UPF、哪些SMF、哪个时间窗”三要素圈出来。结论是只有割接涉及的两组SMF-UPF对受影响，同池其他网元正常——这就把“全网性故障”排除了，矛头直指变更。凌晨排查的铁律：**故障范围与最近变更加交集，命中就先回退再深究**。但当时评估回退防火墙需要重新变更审批，耗时比定位还长，于是选择继续往下打。 **第二步：网管信令跟踪，定接口。** 在网管上对失败呼叫做信令回放，按失败原因分类：N4会话建立超时占了绝对大头，而不是N11（SMF-AMF）或N7（SMF-PCF）接口报错。接口定位到N4，就锁定了SMF与UPF之间的通道。这里有个细节：信令跟踪显示SMF发出了PFCP Session Establishment Request，但迟迟等不到Response，与拨测失败时间点吻合。 **第三步：双端抓包，看报文。** 单端抓包会骗人，双端抓包才见真相。在SMF和UPF侧同时镜像抓包，用Wireshark分析——它对PFCP的支持很完善，官方字段参考里`pfcp.recovery_time_stamp`、`pfcp.sequence_number`、`pfcp.cause`、`pfcp.response_time`等字段一应俱全（PFCP解析能力从Wireshark 2.6版本就开始提供）。两侧包一对比，结论非常清晰： - SMF侧：Heartbeat Request与Session Establishment Request按Sequence Number重传了多次，无任何Response； - UPF侧：Response报文明明白白发出来了，序号与请求一一对应。 ```mermaid sequenceDiagram participant S as SMF participant F as 防火墙与传输 participant U as UPF S->>F: Heartbeat Request 序号N F->>U: 去程放行 正常转发 U-->>F: Heartbeat Response 序号N F-->>S: 回程未放行 静默丢弃 Note over S: 连续多次无响应 判关联失效 S->>U: 会话清理 触发批量告警 ``` **第四步：传输面比对，找凶手。** “两侧都发了、中间收不到”，凶手只能在传输路径上。调取防火墙会话日志与drop日志，按源目IP和端口8805过滤——drop记录与丢包时间点严丝合缝地吻合。同时复盘还发现第二处隐患：ECMP等价路径中的一条链路光模块收光功率劣化，存在0.1%量级的持续丢包，叠加当时较紧的心跳判死阈值，偶发心跳抖动被放大成关联震荡。一处配置错、一处硬件病，撞在同一个夜里。 ## 四、根因实锤：一条没放行的回程路 把根因摊开讲透。 **直接根因：防火墙安全策略漏放行PFCP回程报文。** 割接方案里，防火墙策略按“安全域互访矩阵”配置，写策略的同事按TCP业务思维配了显式放行，但PFCP是UDP 8805，且只配了SMF侧发起的方向，UPF侧的Response回程没有显式条目，被默认deny静默丢弃。UDP防火墙处理有个特性：会话表项依赖首包方向建立，去程放通、回程无策略的流，会被直接丢弃。于是形成完美陷阱——**去程通、回程断、无拒绝响应（静默丢包）**，SMF只能靠超时与重传慢慢“感觉到不对”。 **为什么KPI只跌不崩？** 因为关联失效的判定需要连续多次心跳超时，会话清理与重建有窗口期；部分时段心跳恰好靠最后重传续上命，就表现为成功率“抽风式”抖动而非断崖。这种介于“好”与“坏”之间的灰色状态，是夜间故障最难缠的形态。 **放大因素：心跳判死阈值偏紧。** 该局点当时配置的判死次数偏保守（2次），对0.1%量级的链路丢包几乎没有容错。传输抖一下，误判就发生一次；误判一次，SMF与UPF间的会话状态就震荡一轮。协议层面标准允许各实现自行设定心跳周期与判死门限，具体行为以各厂家官方文档为准——但无论哪家，“紧心跳+劣链路”的组合都是定时炸弹。 **为什么常规告警没第一时间抓到？** 因为告警规则是“每次心跳失败即上报告警”，0点后零星的抖动告警被淹没在夜班的例行噪音里，直到拨测成功率告警才把事情顶到台面。告警治本的教训在上一篇讲过：**要盯状态变迁，不要盯单次失败**——这个原则在N4接口上同样成立。 ## 五、修复与验证：参数怎么调，监控怎么补 应急处置只用了两步：防火墙双向显式放行UDP 8805；受影响SMF-UPF对逐对触发关联重建。02:30成功率回到99.5%基线。但真正有价值的是复盘后的长效整改： | 整改项 | 故障前/期间 | 修复后 | 理由 | | --- | --- | --- | --- | | 防火墙策略 | 仅去程放行8805 | 双向显式放行，禁用静默丢弃 | PFCP为UDP无连接，回程必须显式保障 | | 心跳判死阈值 | 连续2次失败判死 | 调整为3次（工程值） | 容纳0.1%量级链路抖动，减少误判 | | 心跳周期 | 10秒 | 保持10秒 | 不宜拉长，避免真故障发现变慢 | | 告警规则 | 每次心跳失败即告警 | 仅关联判死触发高级别告警 | 告警量降约九成，噪音出清 | | 传输验收 | 无N4专项检查 | 新增N4/SBI策略核对+抓包基线 | 变更前先验通，不等业务撞墙 | | 主动拨测 | 无 | 5分钟级PDU会话建立拨测 | 分钟级发现会话面劣化 | | 硬件巡检 | 例行 | ECMP成员链路光功率纳入月巡 | 消除0.1%丢包的隐性放大器 | 验证阶段做了三件事：一是恢复后连续72小时观察`pfcp.response_time`维度的长曲线，确认无周期性毛刺；二是人为制造一次防火墙策略回退演练（维护窗口内），验证新告警规则能在判死瞬间准确上报告警；三是把本次的抓包文件归档为“基线包”，供下次变更比对——健康状态的PFCP长什么样，必须先有标本，出事才知差异。 ## 六、经验沉淀：核心网运维的抓包工具链与四条军规 这个案子出在5G SA的N4接口上，但方法论适用于整张核心网。沉淀成可复用的资产，是复盘的最终目的。 **工具链分四层：** 1. **采集层**：网元侧镜像口+专业抓包设备（支持长时间滚存），关键接口（N4/N2/N11/S1-MME/GTP-U）平时就布好采集点，故障时“开箱即抓”； 2. **分析层**：Wireshark做单包深挖（PFCP、NGAP、NAS、GTP-U解析成熟），配合tshark脚本做批量统计——比如一条命令统计所有无响应的PFCP请求； 3. **信令层**：网管信令跟踪按用户号码/IMSI/F-SEID回放全流程，负责“快”，Wireshark负责“深”，两者互为补充； 4. **验证层**：自动化拨测（PDU会话建立、注册、PDU释放三板斧）+ KQI长曲线，负责“事后看得见”。 **四条军规，建议写进变更检查单：** **军规一：涉传输变更，核心网必抓基线包。** 任何在核心网之间插设备、调策略、动路由的割接，割接前后各抓一份对照包。本次故障如果00:12就有基线对比，00:20就能锁死防火墙，省一小时。 **军规二：UDP控制面协议纳入防火墙策略核对清单。** PFCP（8805）、GTP-U（2152）、SBI相关UDP面、Diameter……逐协议列端口、逐方向确认放行，并明确要求“禁用静默丢弃、drop必须留日志”。静默丢包是排查天敌——它不给任何反馈，全靠超时猜。 **军规三：心跳类参数遵循“松紧适度、整体一致”。** 判死阈值过紧，传输毛刺放大成业务震荡；过松，真故障雪崩式蔓延。调整后必须做一次主动注入式演练（人为断链验证判死时效），确认参数与预案匹配。 **军规四：告警只报状态变迁，不报单次失败。** 心跳失败是症状，关联失效才是事件。告警规则按“状态机迁移”设计，配合拨测KQI兜底，让夜班先看到“真问题”，再看细节。 最后说点感悟。5G核心网服务化之后，大家的注意力都被SBA、HTTP/2、NRF服务发现吸走了，容易忘了N4上还跑着一个UDP时代的“老古董”。但恰恰是PFCP这种无连接、静默丢包、靠心跳续命的协议，对传输层的 sins（丢包、不对称、策略遗漏）最敏感。核心网排障二十年，我的一条底层经验始终没变：**当两个网元都说自己发了，答案永远在中间的路上。** 抓包，双端抓，别猜。 ## 参考来源 1. [3GPP TS 29.244 «Interface between the Control Plane and the User Plane nodes»](https://www.3gpp.org/DynaReport/29244.htm) — PFCP协议的官方规范主页：Rel-14于2016年立项、CT4工作组负责、CUPS工作项背景，2026年6月CT#112发布Rel-20 20.0.0版本（本文协议机制、心跳与序号设计均以此为锚） 2. [Wireshark Display Filter Reference: PFCP](https://www.wireshark.org/docs/dfref/p/pfcp.html) — Wireshark官方PFCP字段参考：`recovery_time_stamp`、`sequence_number`、`response_time`、LOAD/OVRL特性标志、User Plane Path Failure Report等字段均出自此页，佐证Wireshark自2.6版本起原生解析PFCP 3. [IANA Service Name and Transport Protocol Port Number Registry](https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml) — PFCP注册端口8805/UDP的官方登记处 --- > 本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵**爱卫生**（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 > 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。 > [!tip] 51学通信知识星球 > **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 > **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 > **当前规模**：5200 篇主题 / 990 个回答，198 元/年。 > **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 > **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。