既然 display ip interface brief显示物理链路是 UP 的，说明 MSR3640 这一侧的物理层基本正常。问题大概率出在链路质量（丢包/延迟）、加密参数协商或中间设备策略上。建议按以下顺序进行分层排查：
一、 物理与链路层深度检查（不要只看UP）
虽然接口显示 UP，但可能存在“软损伤”，导致 IKE 保活报文丢失。
检查接口错包统计
在 MSR3640 上执行：
display interface GigabitEthernet x/x/x # 连接纵向加密的那个口
重点关注：Input/Output errors、CRC、Frame errors。如果有持续增长的计数，说明链路存在物理层抖动或双工不匹配，这会导致协商报文被丢弃。
强制双工与速率（关键）
纵向加密装置通常不支持或不建议使用自协商。建议在 MSR3640 接口视图下强制配置，确保与加密装置一致：
interface GigabitEthernet x/x/x
undo negotiation auto
speed 1000 # 或 100，根据加密装置能力
duplex full
不匹配的双工模式是导致频繁协商的隐形杀手。
二、 网络层连通性质量测试
“频繁协商”往往是因为 IKE 保活报文（UDP 500/4500）在途中丢失，导致对端认为隧道已死。
长 Ping 测试
从 MSR3640 或加密装置的外网口，向调度主站对端网关发起大包长 Ping：
ping -c 100 -s 1400 x.x.x.x # 发送100个1400字节的大包
判断标准：观察是否有连续丢包或延迟忽大忽小。电力专网中常见的 SDH/PTN 链路瞬断或拥塞，会直接导致隧道反复重建。
检查路由黑洞
确认去往调度主站的路由下一跳确实指向正确的出口，且没有路由震荡（可通过 display ip routing-table x.x.x.x动态观察几分钟）。
三、 纵向加密装置侧排查（重点）
MSR3640 只是通道，故障源大概率在加密装置本身或参数配置。
排查点

检查命令/位置

说明


CPU/内存负载​

登录加密装置管理界面

负载过高会导致加解密超时，触发重协商。


隧道日志​

查看装置日志

寻找 “IKE Timeout”、“Phase1/2 Failed” 等关键字，确认是第几阶段失败。


SA生存时间​

检查隧道策略

如果 SA Lifetime（生存时间）设置过短（如几分钟），会人为造成频繁重协商。


参数一致性​

比对主站配置

加密算法、认证算法、DH组、PSK密钥必须与主站侧完全一致，差一个字符都会导致反复失败。
四、 中间设备策略（防火墙/策略路由）
MSR3640 与调度主站之间通常还有传输设备或防火墙。
会话超时时间：中间防火墙的 UDP 会话超时时间如果小于 IKE 的 DPD（Dead Peer Detection）检测时间，会主动切断连接，导致频繁重连。建议将 UDP 500/4500 及 ESP（协议号50）的会话超时调长。
策略路由干扰：检查是否有策略路由（PBR）将部分加密流量引向了错误路径，造成非对称路由。
五、 抓包定位（终极手段）
如果以上均无果，在 MSR3640 连接加密装置的接口上做端口镜像，抓取 IKE 协商报文。
过滤条件：udp.port == 500 or udp.port == 4500
分析重点：观察是谁发起了 DELETE报文（主动拆除隧道），以及拆除前是否有大量的重传（证明是丢包导致）。
快速行动清单
【必做】​ 在 MSR3640 接口下强制 speed 1000和 duplex full，关闭自协商。
【必做】​ 从加密装置外网口 Ping 对端网关 100 次，统计丢包率。
【必做】​ 登录纵向加密装置，检查 CPU 利用率和隧道日志中的错误码。

"纵向加密装置到调度主站间频繁协商"这个是什么东西

虽然 display ip interface brief 显示端口 up，但这只代表物理层正常。而设备间的“频繁协商”，通常是IPSec VPN或类似加密隧道的安全关联（SA）在反复建立。既然物理链路已排除，建议将排查重点放在以下更深层次的方面：

 一、深入检查物理与链路层状态

即使端口 up，底层仍可能存在错误，导致上层协议不稳定。

• 检查错包统计：重点查看 CRC 等错误是否持续增长，这常是网线、光模块等问题。

• 检查协商模式：确认路由器与纵向加密装置及对端设备的速率和双工模式是否一致，需确保均为“自协商”或同为一致的强制设置。

• 检查第二层环路：验证网络（尤其路由器下联口）是否因环路而收到大量 STP TC 报文，引发网络不稳定。

 二、聚焦加密隧道配置与状态

纵向加密核心是隧道功能，必须保证配置细节一致。

• 核对隧道参数：登录两端加密装置，仔细核对IKE协商模式（主/野蛮）、加密/认证算法、DH组、SA生存周期、预共享密钥等，必须完全一致。

• 检查路由与ACL：检查路由器中是否有到对端的安全策略导致IPSec流量被丢弃。同时核对加密装置上的隧道感兴趣流配置是否准确双向对称。

 三、验证网络与应用层连通性

• 分路径Ping测试：推荐通过“长Ping”抓取丢包规律。选择网络空闲时，在路由器直接 ping 对端加密装置地址，进行长时间压力测试，同时配合排除中间防火墙等设备。

• 端到端应用测试：在调度主站与厂站业务终端间进行应用（如总召）模拟，确认业务层稳定性，验证策略是否精确覆盖。

 四、排查时钟同步、MTU与资源

• 检查NTP时间同步：确保加密装置、路由器等所有设备时间同步。证书验证依赖时间戳，偏差过大会导致认证失败。

• 处理MTU/分片问题：加密报文变大，若未分片可能被丢弃。尝试 ping -l 1472 命令测试路径MTU。

• 检查设备负载：在路由器上使用 display cpu-usage 和 display memory-usage 检查负载。CPU/内存过高可能导致无法及时处理协商报文。

 五、查看日志与考虑软件问题

• 查看加密装置日志：登录加密装置，查看其系统日志和告警信息。

• 查看路由器日志：在路由器执行 display logbuffer 查看有无 OSPF/6/OSPF_LAST_NBR_DOWN 等联动日志

• 升级软件版本：如果所有排查都无效，可考虑将路由器升级至最新稳定版本排除已知Bug

MSR3640 纵向加密↔调度主站 频繁协商排查思路（接口物理 UP 但协议 / 业务频繁协商）

一、先定现象核心

二、按顺序逐项排查（现场直接照着做）

1. 端口自协商与双工速率（最常见诱因）

• 速率：1000M/100M 是否稳定
• 双工：Full 全双工，不要 Half 半双工
• 有无 Input error、CRC、帧错误、溢出包

2. 查看接口报文差错、丢包、广播风暴

• CRC 错误、输入输出错误、丢弃报文
• 广播 / 组播报文暴增（风暴会挤掉加密协商报文）
  有差错就是线路、光模块、网线、法兰、纤芯质量问题。

3. MTU 不匹配（电力调度纵向加密高频坑）

4. 中间是否有环路、二层震荡

• 环路、MSTP/STP 震荡
• IRF / 聚合口单链路故障切换
  都会瞬间断流几秒，导致加密协商中断重连。

5. MSR3640 ACL、安全策略、限速丢包

1. 是否配置了 ACL 拒绝 / 限制 加密协议端口
2. 是否做了 流量限速、CAR 限流，把协商报文误丢
3. 是否有 会话老化时间过小，空闲会话被删掉，触发重协商

6. 链路时延、抖动、丢包（调度专网关键）

7. 路由震荡、静态路由 / OSPF 频繁收敛

8. 光模块 / 跳线 / 法兰衰减问题（物理层隐性故障）

三、最简排查顺序（现场直接执行）

1. 接口看 速率双工、CRC 错包
2. 两端强制 1000M 全双工
3. 全网统一 MTU 1480/1500
4. 长 ping 大包测 丢包时延抖动
5. 查 ACL / 限速是否丢弃协商报文
6. 查二层环路、STP / 链路聚合震荡
7. 查光功率、纤线法兰质量
8. 查路由是否频繁收敛

都是AI。

纵向加密装置与调度主站频繁协商、隧道不停重协商

路由器 MSR3640 链路物理 / 协议都 Up，排查全维度思路（直接照着逐项查即可）

一、先定性核心现象

二、必查排查维度（按优先级从高到低）

1. 链路层质量排查（接口 Up 但有错包、抖动）

• Input/Output error、CRC、drop、overrun、collision 是否持续增长
• 接口是否有速率双工不匹配（强制 / 自协商错乱）
• 是否有光功率过低、光模块衰耗、网线 / 尾纤劣质

2. 全网链路丢包、时延抖动排查（最常见）

• 是否有偶发丢包、随机超时
• 时延是否忽高忽低、抖动大

3. MTU 与 TCP/IP 分片问题（电力纵向高发）

• 中间链路 MTU 不统一、没做 MTU 适配、没开启分片
• 路由器、纵向加密、运营商链路 MTU 不一致
  大包被静默丢弃，小包正常通，接口一直 Up

4. 路由器 ACL / 防火墙 / 策略是否静默丢弃协商报文

1. 公网 / 专线入接口是否有 ACL、packet-filter、安全策略
2. 是否拦截了纵向加密专用协议端口、ESP/AH、自定义协商端口
3. 是否有 会话表老化、空闲断开 策略

5. 路由层面：路由震荡、来回切换

• 到调度主站是否存在双路由、优先级一样、频繁刷新路由
• 静态路由是否被动态路由抢占
• 下一跳是否偶尔飘移

6. 路由器空闲老化、TCP / 会话超时参数过小

• 纵向加密隧道空闲报文间隔大于路由器会话老化时间
• 路由器主动删除会话，加密设备检测不到保活，重新协商

7. 纵向加密自身配置参数不匹配

1. 两端协商超时时间、保活报文间隔 是否一致
2. 隧道空闲断开时间 是否设置过短
3. 加密设备本身 CPU 高、日志告警、自身链路探测机制过于灵敏

8. 中间运营商 / 专线链路伪 Up

• 专线 PON / 传输设备偶发瞬断
• 运营商二层隔离、端口限速、队列拥塞
  可让运营商做链路误码、丢包率、端口队列拥塞排查。

三、极简排查操作步骤（你现在就能逐条敲）

1. 看接口：display interface 查 CRC / 错包 / 丢包计数是否增长
2. 长 ping 大包：测丢包、时延抖动
3. 测 MTU 大包不分片 ping，定位分片丢包
4. 查接口 ACL、packet-filter 是否拦截加密协商 / ESP 报文
5. 查路由表是否频繁震荡、下一跳飘移
6. 调整路由器 TCP MSS、接口 MTU 适配纵向加密
7. 核查路由器会话老化时间是否过小
8. 让纵向加密厂家查自身保活间隔、协商超时配置

四、一句话总结