MSR5560路由器

会触发路由器向下发送 ICMP 目标不可达报文，这是链路中断后路由收敛间隙 + 路由失效引发的正常网络行为，并非真实攻击，纵向加密设备将该报文误判为攻击告警。下面结合组网、协议、报文流转拆解原理，并给出优化方案。
一、组网 & 协议梳理
1. 拓扑链路
服务器 / 业务设备 → 接入交换机 → 纵向加密装置 → MSR5560（场站路由器）
MSR5560 双上行链路 → 两台汇聚路由器 → 传输网 → 主站网络
2. 路由与承载协议
内网互通：OSPF（IGP，负责站内、骨干网路由传递）
跨 VPN / 广域路由、公网 / 跨站点路由：BGP + MPLS VPN
双上行：等价路由 / 主备路由，实现链路冗余。
二、单条上行接口中断后，ICMP 不可达产生完整原理
阶段 1：物理 / 接口中断，路由快速失效
MSR5560 其中一条上行互联接口 Down：
接口状态变为 Down，设备立刻感知直连邻居失效；
OSPF：邻居关系断开、LSA 老化 / 刷新，该链路对应的路由条目开始失效；
BGP：TCP 邻居断开，对应 BGP 路由撤销（Withdraw），MPLS VPN 对应的标签转发表、VPN 路由同步失效。
此时存在两种路由场景，都会产生 ICMP 不可达：
场景 A：原流量走故障链路，路由未完成收敛（最常见）
故障前：部分服务器访问主站业务的流量，哈希 / 路由优选走故障上行链路；
链路中断瞬间：终端仍持续发包去往外部地址，报文送达 MSR5560；
路由器查表：原来的出接口已经 Down，路由条目还未全部刷新、备份路由未完成切换；
路由器判定：无有效路由可达目标地址。
根据 TCP/IP 协议规范，路由器会向报文源地址回复 ICMP 目标不可达（网络 / 主机不可达） 报文。
报文路径：MSR5560 → 纵向加密装置 → 接入交换机 → 服务器。
场景 B：路由收敛完成，但部分明细路由彻底消失
若故障链路承载了专属 VPN 路由 / 部分主站明细路由，且备份链路无对应路由：
收敛完成后，该部分外部路由在 MSR5560 路由表中彻底删除；
服务器继续访问这些目标地址，报文到达路由器；
设备查表无任何可达路由，依旧回复 ICMP 目标不可达。
阶段 2：纵向加密设备产生 “攻击告警” 的原因
纵向加密装置（安全类网关）内置异常报文 / 扫描攻击检测策略：
正常业务中，网关（MSR5560）极少主动向下发送大量 ICMP 不可达报文；
链路中断后，短时间内批量出现 ICMP 不可达回应包；
加密设备识别到网关地址高频发送 ICMP 不可达，匹配了预设攻击特征库，因此上报「ICMP 不可达攻击」告警。
核心区分：这是网络路由故障引发的协议正常应答，不是外部恶意攻击。
三、补充细节：双上行冗余为什么还会出现该问题？
收敛时间差
OSPF、BGP 均有收敛耗时（几秒～十几秒）。接口中断 → 路由撤销 → 备份路由生效 存在时间窗口，窗口内路由缺失，必然触发 ICMP 不可达。
流量分担场景加剧现象
双上行做等价路由（ECMP） 时，流量会按五元组哈希分摊到两条链路。单链路中断后，原本走故障链路的所有流量，在收敛间隙全部断流，批量触发 ICMP 回应，告警会更密集。
MPLS VPN 叠加影响
MPLS 依赖标签转发，上行中断后标签转发表同步失效，在路由 + 标签双重刷新期间，转发中断时间更长，ICMP 报文量更大。
四、现场优化方案（分两类：消告警 + 根治报文产生）
方案 1：临时处理（屏蔽误告警，不改动路由）
在纵向加密装置上配置白名单 / 策略：
放行 MSR5560 网关地址发出的 ICMP 不可达报文；
调整攻击检测阈值：放宽短时间内 ICMP 报文计数，避免正常网络行为误报。
方案 2：网络侧优化（减少 / 消除 ICMP 不可达报文，推荐）
1. 缩短路由收敛时间，压缩断流窗口（MSR5560 配置）
plaintext
# 1. OSPF 加快故障感知（接口侧）
interface 上行接口
ospf timer dead 10
ospf timer hello 4

# 2. 开启 OSPF 快速重路由（FRR），链路故障秒级切换，无路由空白期
ospf 1
frr

# 3. BGP 优化，加快邻居失效检测
bgp xxx
peer 对端地址 hold-time 10 keepalive 3
2. 双上行部署主备模式 + 路由优选
不使用 ECMP 等价路由，配置静态路由优先级 / 路由策略，指定主链路、备用链路。主链路中断后，路由无缝切换，大幅减少丢包与 ICMP 回应。
3. 设备关闭 ICMP 不可达回应（彻底杜绝该报文）
如果业务允许（无需网络连通性诊断），在 MSR5560 全局关闭 ICMP 目标不可达报文发送：
plaintext
system-view
undo ip unreachables
注意：关闭后设备不会再回复 ICMP 不可达，但终端会表现为直接丢包、超时，适合生产业务环境。
4. MPLS VPN 冗余加固
保证两条上行链路都完整发布所有 VPN 路由与标签，避免单链路故障导致部分路由彻底消失。
五、总结
现象本质：单上行接口 Down → 路由收敛间隙 / 路由缺失 → 路由器依规回复 ICMP 目标不可达；
告警原因：纵向加密设备将批量 ICMP 应答报文误判为网络攻击；
核心解决思路：优先优化路由收敛（OSPF FRR、缩短 Hello/Dead 时间），其次可关闭设备 ICMP 不可达功能，或在加密设备添加白名单屏蔽误告警。

一、 核心触发原理

1. 路由表项丢失（网络不可达）：
   由于您的路由器配置了 OSPF 和 BGP，当其中一个互联接口物理中断后，OSPF/BGP 邻居关系断开，原本通过该接口学习到的去往外部业务地址的路由条目会从路由表中撤销。如果另一个正常工作的互联接口也没有去往该目标网络的替代路由（例如没有配置等价路由或默认路由），路由器在收到发往这些外部地址的数据包时，会发现路由表中找不到匹配的转发路径。此时，路由器会将数据包丢弃，并向源端发送代码为 0 的“网络不可达” ICMP 报文。
2. 下一跳不可达（主机不可达）：
   即使路由表中仍保留着指向外部网络的路由，但如果该路由的“下一跳”网关正是连接在已中断接口上的对端设备，路由器将无法通过 ARP 解析到下一跳的 MAC 地址。在这种情况下，作为直连该网络的最后一个路由器，它会向源端发送代码为 1 的“主机不可达” ICMP 报文。

二、 为什么纵向加密设备会将其判定为“攻击告警”？

• 突发异常流量：当一个主链路突然中断时，大量原本应该正常转发的业务流量瞬间变成了“无法路由”的状态。路由器会在极短的时间内向源 IP 密集回传大量的 ICMP 目的不可达报文。
• 安全策略拦截：纵向加密设备类似于防火墙，其内置的安全引擎可能会将这种短时间内从内网网关（路由器）向外网/内网终端高频发送的 ICMP 差错报文，误认为是某种 ICMP Flood 攻击或扫描行为，从而触发了安全告警日志。

三、 排查与处理建议

1. 验证路由状态：在故障复现时，登录 MSR5560 执行 display ip routing-table 检查去往外部业务地址的路由是否缺失，或者下一跳是否失效。
2. 抓包分析 ICMP 代码：在纵向加密设备或路由器上抓取 ICMP 报文，查看 Destination Unreachable 的具体 Code 值（0 代表网络不可达，1 代表主机不可达），以精确定位是路由丢失还是下一跳失效。
3. 调整安全设备阈值：如果确认这是由链路切换引起的正常网络防御机制导致的误报，建议在纵向加密设备上调高针对 ICMP 差错报文的告警阈值，或将路由器的管理/互联 IP 加入 ICMP 告警白名单，避免干扰日常运维监控。