防火墙，每天上班时间网络卡顿

确认防火墙带宽支持情况

没问题的话 

做一下负载均衡功能

酒店防火墙上班 8:30 定时卡顿定位思路
现象：每天早上 8:30 上班时段，有线、无线同时卡顿；出口总带宽才跑不到 300M，远小于 500M+1000M 物理带宽，不是出口带宽打满。有线无线核心物理分离，全部流量过防火墙；3 条外网：50M 财务专线、500M 企业专线、1000M 家庭宽带。
关键点：有线无线同时卡，说明故障点在防火墙层面，不是无线 AP、不是内网核心（有线无线物理分离，两边同时出问题，排除各自内网）。出口带宽利用率低，排除公网出口拥塞。
按排查优先级梳理故障点（酒店场景高频）
1、会话数 / 会话资源耗尽（酒店这类 NAT 大并发场景头号嫌疑）
8:30 酒店员工上班、住客起床大量终端上线，大量新建 TCP/UDP 会话。
现象：接口带宽不高，但防火墙并发会话数冲到上限、新建会话速率超限。表现就是上网卡顿、网页转圈、DNS 解析慢；看带宽看不出来。
排查命令（H3C F1000/V7）
plaintext
display session table statistics
display resource usage
display cpu‑usage
display memory
重点看：
当前并发会话数，距离设备规格上限是否很近；
每秒新建会话速率是否持续冲高；
是否大量会话老化超时堆积（酒店终端很多手机频繁断连重连）。
酒店典型坑：NAT 会话老化时间用默认值，大量无效僵尸会话占满会话表，早上批量终端上线直接打满会话资源，带宽跑不上去，全网卡顿。
处理：调整 NAT 会话老化时间，缩短 UDP、TCP 非活跃会话老化；检查是否开启会话过载保护。
2、NAT 地址池源端口耗尽（非常典型，带宽很低但是业务卡）
三条出口，多 NAT 地址池。大量内网终端同时发起访问，NAT 转换端口耗尽。
表现：带宽占用很低，但是部分报文 NAT 转换失败，随机丢包，网页卡顿、打开慢。
plaintext
display nat address‑pool usage
display nat session statistics
看 NAT 池端口利用率，如果端口占用接近 100%，就是该问题。
酒店大量手机终端，每一个应用都要占用 NAT 端口；很多人误以为带宽小就不会出现端口耗尽，这是误区。
3、策略路由 / 多 WAN 选路、链路探测在 8:30 触发异常
三条出口：50M 财务专线、500M 企业专线、1000M 家庭宽带。
如果开启多链路探测、链路质量检测，早上大量终端流量上来，链路探测误判，频繁切换链路；策略路由反复重选，报文乱转发，业务卡顿。
负载分担算法问题：流量集中跑到某一条链路上，另外两条空闲。虽然总带宽才 300M，但某一条链路被打满。
核查：
plaintext
display link‑group statistics
display policy‑route statistics
看各个 WAN 接口实际流量分布，是不是流量全部压在某一条链路上，其余链路几乎没流量。
注意：财务 50M 专线，是否有策略路由把部分普通用户流量错误导向财务专线，早上业务上来把 50M 财务链路打满。
4、安全策略 / 特征库定时更新（8 点半定时触发）
IPS/AV 特征库定时更新任务配置在早上 8‑9 点；更新过程 CPU 冲高。
威胁日志大量告警，IPS 大量丢包，造成上网卡顿。
plaintext
display cpu‑usage history
display ips statistics
看 8:30 时间段 CPU 是否突然冲高。
临时验证：上班前临时关闭 IPS/AV，观察卡顿现象是否消失。
5、DNS 解析瓶颈（酒店场景极高概率）
早上大量终端并发 DNS 请求，防火墙 DNS 代理、或者内网 DNS 服务器压力大。
现象：网页打不开，刷很久，但是 ping 公网 IP 正常。带宽、会话看着都正常。
测试：卡顿的时候，ping 公网 IP（223.5.5.5）通不通；nslookup 测试域名解析延迟。
6、日志输出压力过大
Syslog 大量输出，防火墙 CPU 被日志任务占高。如果配置大量 debug、海量威胁日志外发，早高峰终端产生海量日志，占用设备 CPU。
卡顿时段查看 CPU，日志模块占用占比。
快速现场验证手段（定位根因）
卡顿发生的时候，第一时间登录防火墙，抓现场数据，不要等故障恢复：
plaintext
display cpu‑usage history
display memory‑usage history
display session table statistics
display nat address‑pool usage
display interface brief
display link‑group statistics
对比：故障时间和非故障时间，上面指标差异。
临时隔离测试：故障的时候，临时把全部流量切单条 WAN 出口，看卡顿是否消失，用来定位多 WAN 负载分担是否问题。
容易踩坑的业务细节
财务 50M 专线，确认普通酒店用户流量没有被策略路由分流到财务专线，50M 带宽很小，一旦混入用户流量早高峰直接拥塞。
有线无线两套核心，但是全部流量过防火墙，内网侧两个 VLAN / 两个接口，注意防火墙域间策略、域间限流 QoS 是否配置，是否有 QoS 队列丢包。
plaintext
display qos queue‑statistics interface GigabitEthernet x/x
看接口队列是否丢包。
需要你日志 / 配置重点提取的信息
故障 8:30 时段的 CPU、内存曲线；
会话表统计，最大并发会话、每秒新建会话；
NAT 地址池端口利用率；
三个 WAN 口各自带宽占用，确认流量分布；
是否开启 IPS、AV、应用识别；定时任务时间表；
策略路由 / 链路组配置，确认财务专线是否被普通用户复用。
补充：带宽不到 300M，远小于总出口能力，优先怀疑会话资源、NAT 端口耗尽、CPU 冲高、DNS、多 WAN 选路异常，而不是物理出口带宽不足。

配置不合理。无法承载大量用户的接入。

卡顿情况是什么样？是延迟高，还是速率慢？是所有接入用户都卡顿，还是部分？三条线路的用户都会卡吗？卡顿期间防火墙的向内/向外端口带宽使用率怎么样？大致的接入终端数量是多少？有没有溢出？设备本机的cpu/内存使用率是多少？

这些都要核查，顺便提醒下，不要把自己的完整配置信息发布到网络上，特别是没有进行脱敏的原始配置🤔