作为对应行业通用叫法SD-WAN（Software Defined Wide Area Network，软件定义广域网）的产品形态呈现，AD-WAN分支解决方案遵循业内SD-WAN标准，采用SDN网络可编程、逻辑集中控制的核心思想，统一融合智能网络管理、智能控制、智能分析，实现“管”、“控”、“析”三维一体的融合网络控制中枢和智能大脑，网络全域覆盖，实现端到端的网络和业务自动化、可视化、精细化的网络管理，如下图1-1所示。

AD-WAN分支解决方案不仅兼具SD-WAN的种种优势，同时结合广域网分布广、接入形态多样、网络质量变化频繁等特点，采用设备自主智能选路，全网链路拓扑、质量集中呈现等多种形式，实现了SDN在广域网的最佳实践。

图1-1 AD-WAN分支解决方案

AD-WAN分支解决方案通过如下表1-1所示的技术，解决了当前广域网面临的网络弹性差、业务爆炸式增长、安全形式严峻、运维日趋复杂的问题。

表1-1 AD-WAN分支解决方案技术

当前广域网面临的挑战	AD-WAN分支解决方案技术
网络弹性差	极简开局：网络管理员只需在远程服务器上进行基础配置，无需在开局现场配置设备即可完成网络开局，大大降低了开局成本。网络随需而动：一方面企业用户可以灵活选择Internet、4G/5G等线路无差别接入，不再依赖于传统昂贵的运营商专线，同时支持接入多种云服务商及混合云，为客户最大限度降低成本，保护客户投资；另一方面提供超强的业务弹性扩容能力，动态调整网络规模，降低了用户对网络变化的敏感度。
业务爆炸式增长	应用智能选路：基于链路类型、链路带宽、链路质量和时间段等丰富的选路和调度策略进行精细化的选路，保障应用的网络需求和用户的最佳网络体验。全面WAN加速：通过TFO、BBRv2、DRE、LZ、FEC、包复制、Web Cache等多种加速手段，提高应用流量的传输速度和传输质量。
安全形式严峻	本地安全：支持IPS、状态防火墙、URL过滤、防病毒等多种安全业务部署，对外提供丰富的安全保障能力，实现安全保障。云防御：支持SASE云防御部署，基于云服务提供的全方位安全服务，可以实现随时随地按需部署，降低分支对安全硬件的依赖，减轻分支网络维护复杂性，为用户提供网络和云安全融合的一站式解决方案。
运维日趋复杂	智能网络分析：基于Netstream技术从全网、站点等不同角度对应用流量实时采集，快速感知网络变化，同时采用大数据分析技术和AI算法，实现全网状态智能分析。可视化运维：提供基于全网的多维度可视化能力，实现故障先知先决，极大提升快速定位的效率，变被动运维为主动运维。

1.3 典型组网架构

1.3.1 总部+分支（Hub-Spoke组网）

· 适用场景

适用于业务主要部署在总部，并且分支之间没有或者仅有少量的业务互访需求的企业。

· 特点

¡ 分支通过MSTP专线或Internet（例如5G网络）访问部署在总部的业务。

¡ 分支设备可选用支持5G插卡的路由器实现5G网络接入功能。分支5G路由器具有大带宽，兼容4G网络、双5G卡高可靠性等特点。

¡ 分支之间进行业务交互时，需要通过总部中转。

· 组网拓扑

如图1-2所示，分支到总部采用单层Hub-Spoke组网，组网扁平化。其中，总部作为Hub站点、各分支作为Spoke站点。

图1-2 总部+分支（Hub-Spoke组网）

1.3.2 分支入云（Hub-Spoke组网）

· 适用场景

适用于业务部署在公有云，分支通过公有云访问这部分业务的企业。

· 特点

¡ VSR可以直接在公有云部署。

¡ 支持部署主备公有云，当主公有云故障时，分支业务可切到备公有云上，提高可靠性。

¡ 支持多种云部署，例如：阿里云、紫光云、天翼云等。

· 组网拓扑

如图1-3所示，分支到公有云采用单层Hub-Spoke组网，组网扁平化。其中，公有云作为Hub站点、各分支作为Spoke站点。

图1-3 分支入云（Hub-Spoke组网）

1.3.3 总部+分支（多总部组网）

· 适用场景

适用于业务部署在多个总部，并且每个总部均需要为分支提供业务支持的企业。

· 特点

¡ 支持多总部多活，即该组网中可以同时部署多个总部，多主多备，其中主总部负责处理业务，备总部提供备份，例如三总部，则可部署2主1备。采用多主多备的方式，既可以在多活总部之间进行负载分担和业务备份，又可以通过备总部进一步提供备份，增强可靠性保障。

¡ 分支之间进行业务交互时，需要通过总部中转。

· 组网拓扑

如图1-4所示，多总部的本质是采用多个Hub站点的Hub-Spoke组网。

图1-4 总部+分支（多总部组网）

1.3.4 总部+分支（Full-mesh组网）

· 适用场景

适用于分支不多，或者分支之间有大量业务互访需求的企业。

· 特点

¡ 灵活拓扑、弹性扩容。

¡ 分支之间支持Full-mesh组网和Partial-mesh组网。

¡ 分支之间进行业务交互时，不需要通过总部中转，可以直接互通。

· 组网拓扑

如图1-5所示，在Full-mesh组网中，分支和总部之间，以及各个分支之间建立全连接。

图1-5 总部+分支（Full-mesh组网）

1.3.5 总部+汇聚+分支（三级分层组网）

· 适用场景

适用于省-市-地县，或者全国-各省-各市等三级网络架构明确的企业。

· 特点

¡ 网络结构清晰，网络规模易扩展。

¡ 分支到总部可以逐级分段接入，也可以直通总部。

¡ 分支之间进行业务交互时，可以通过汇聚节点中转，也可以直接互通。

· 组网拓扑

如图1-6所示，三级分层组网可以看作是两段单层组网模型的叠加。在该组网中，通过将整个网络划分成多个区域，之后再将多个区域之间通过集中的汇聚节点进行互联。

图1-6 总部+汇聚+分支（三级分层组网）

1.3.6 多租户POP组网（MSP运营组网）

· 适用场景

适用于希望由运营商/MSP（Managed Service Provider，管理服务提供商）代建广域网分支网络的企业。

· 特点

¡ 企业可直接租用运营商的广域网分支网络服务，降低企业网络建设成本。

¡ POP（Point Of Presence，入网点）站点内相同租户通过POP站点互通，跨POP站点租户通过POP点接入运营商骨干网，以满足全球运营需求。

¡ 各租户路由、业务隔离，使用HQoS技术为不同的租户提供不同的服务。

· 组网拓扑

如图1-7所示，多租户POP组网需要部署POP站点，租户站点和POP站点按照Hub-Spoke方式组网。

图1-7 多租户POP组网（MSP运营组网）

2 故障排查思路及信息收集

AD-WAN分支方案作为新一代智能分支广域网解决方案，集成了自动化开局、智能选路、云端运维、业务可视化、安全管控等多项技术，广泛应用于总部—分支—云端多层组网架构。其故障排查不仅涵盖传统的物理层、链路层和协议层，还需重点关注策略下发、业务连通、控制器管理、云平台对接以及运维自动化等环节。为帮助工程师高效应对分支网络的复杂场景，建议采用“分层分域、协同联动、流程闭环”的排障体系。

本章将为一线运维工程师提供系统化的故障定位与处理方法，包括常见故障类型归纳、排查分层分域原则及标准化故障处理流程等内容，助力提升运维效率与网络稳定性。

2.1 常见故障类型与影响分析

AD-WAN分支组网方案常见故障类型如表2-1所示。

表2-1 常见故障类型与影响分析

故障类型	故障现象与告警	可能影响范围	推荐查阅章节
设备上线/注册故障	新设备无法注册、ZTP自动开局失败、控制器未纳管、上线流程异常或报错	新增分支、批量上线、设备替换	自动化开局与设备上线类故障处理
控制器通信故障	控制器与设备NETCONF、WebSocket、SSL等管理通道不通；策略下发失败；控制通道中断	全网/部分分支站点	· AD-WAN控制器故障处理 · 自动化开局与设备上线类故障处理
物理链路/接口故障	接口down、链路抖动、丢包、硬件告警（模块/网线）、无线链路不稳定（3G/4G/5G）	单站点/多站点/业务链路	· 分支互联与隧道类故障处理 · 链路质量与调度问题故障处理
路由/隧道建立故障	BGP/OSPF邻居异常、Overlay隧道未收敛、VPN互通异常、路由环路等	分支与总部、分支间、云互通	· 路由与智能选路类故障处理 · 链路质量与调度问题故障处理
策略下发/同步故障	策略未下发、配置不同步、分流/QoS/ACL/切片未生效、策略冲突/错误	应用流量异常、全网业务	· AD-WAN控制器故障处理 · 路由与智能选路类故障处理
安全相关故障	SSH登录失败、URL过滤失效、AAA认证失败等	分支接入、业务访问控制	安全接入与保障类故障处理
运维监控故障	设备监控数据丢失、NQA测试失败、NTP时间未同步、日志/告警采集异常、自动运维脚本失效、SNMP/gRPC异常	运维管理域、网络可视化、管理接口	运维与可视化类故障处理

2.2 故障定位分层分域原则与排查顺序建议

AD-WAN分支网络架构由AD-WAN控制器与大量分支CPE设备组成，广泛覆盖总部、分支、云平台等多层级区域，具备规模大、设备分布广、接入方式多样等特点。为高效、准确定位分支网络中的故障根因，建议采用“分层分域、逐步缩小、协同联动”的排查思路。

2.2.1 分层分域排查原则

1. 分层排查

· 物理层：设备、电源、硬件自检、链路、接口状态、光模块、指示灯等。

· 链路层：接口Up/Down状态、链路收发、丢包、延迟、抖动、聚合链路、WAN（专线/Internet/4G/5G）等。

· 网络/协议层：IP地址、ARP/MAC、DHCP、BGP/OSPF邻居状态、路由表、隧道接口、NAT、SRv6 Policy等。

· 传输/隧道层：隧道协商与状态、加密、NAT穿越、VPN互通等。

· 业务/策略层：策略下发、分流、DPI、QoS、ACL、切片、应用保障、业务连通性。

· 管理/控制层：控制器通信、管理通道、策略同步、设备注册、告警监控、自动化脚本、业务调度。

· 如怀疑为控制器相关问题，建议及时与控制器运维团队联动，并参考控制器专用手册。

2. 分域排查

· 地理域：单站点/多站点/总部/分支/云端等。

· 网络域：本地接入/汇聚/出口/跨域互联/云平台等。

· 业务域：单业务/多业务/音视频/关键业务等。

· 设备域：单一CPE、总部核心、汇聚设备、云接入网关等。

2.2.2 控制器与设备排查顺序建议

1. 单台设备/单分支上线或业务异常（如新分支上线失败、单站点业务不通等）

· 优先排查分支设备本地问题：包括物理层（电源、链路、接口）、链路层（WAN/Internet/4G/5G）、协议层（IP、ARP、BGP等）、隧道状态、业务配置等，先排除本地硬件和转发面故障。

· 如设备本地无异常，或发现与控制器注册、策略下发、管理通道等相关问题，再进一步排查控制器侧（设备注册列表、策略下发状态、控制通道日志等）。

2. 多分支批量上线/全网策略统一下发失败或大面积业务同步异常

· 优先排查AD-WAN控制器平台：关注控制器与各分支设备的通信状态、批量注册/纳管、策略编排与下发、控制器日志、南向接口等，判断是否为管控面统一异常。

· 同时关注分支设备与控制器的通信链路、注册状态和策略同步情况。

3. 发现设备与控制器通信中断、注册失败、策略下发失败、业务编排失败等特有告警

· 同步排查控制器与设备两端，重点关注控制器南向通道（如NETCONF/WebSocket/SSL）连通性、设备注册状态、设备日志及相关链路是否正常。

· 必要时及时与控制器运维团队协同处理。

4. 复杂或无法归因的问题

建议并行排查控制器与设备两端，保持信息同步，协同联动，必要时联合总部、分支、云平台多团队协作，快速定位问题根因。

2.3 故障排查与处理流程

建议严格按照以下步骤执行，实现高效准确的故障处理与闭环管理：

(1) 故障现象确认：收集用户反馈和系统告警，明确受影响的业务、站点和设备，详细记录问题现象及发生时间。

(2) 影响范围界定：判断故障影响范围，是单点、局部还是全网，并细化到具体链路、业务、网络层或管理面。

(3) 关键信息收集：收集相关日志、告警、接口/协议状态、业务流量、配置快照及控制器下发状态等关键信息。

(4) 分层分域定位：按照“物理→链路→网络→隧道→业务/策略→管理/控制”顺序，逐层逐域排查。

(5) 分析可能原因并制定验证措施：针对故障现象（如上线失败、链路中断、隧道未建立、策略失效）和系统告警，综合分析潜在原因，结合故障处理手册、典型故障案例库和经验，制定有针对性的验证方案。

(6) 定位根因并处理：逐步排查并定位故障根因，现场优先快速恢复服务。如无法现场解决，及时升级工单，上报至更高级别支持团队或厂商专家处理。

(7) 业务验证：故障修复后，及时对受影响的业务、设备和系统进行验证，确保服务全面恢复，用户体验正常。

(8) 事件复盘与经验总结：事件结束后，复盘处理过程和影响范围，分析根因，总结经验，完善典型故障案例库和操作流程，提出流程优化建议和预防措施，不断增强团队的知识积累和故障防范能力。

3 AD-WAN控制器故障处理

3.1 控制组件日志收集步骤

3.1.1 SDWAN控制组件运行日志

使用系统管理员（admin）登录统一数字底盘，进入[系统>日志管理>运行日志列表]页面，所在目录选择“matrix-diag/SDWAN”，选择需要收集日志的起止时间，单击<查询>按钮查询对应的日志，单击<导出>按钮，导出所有日志，如图3-1所示。

图3-1 控制组件运行日志

3.1.2 WVAS组件运行日志

使用系统管理员（admin）登录统一数字底盘，进入[系统>日志管理>运行日志列表]页面，所在目录选择“matrix-diag/WVAS”，选择需要收集日志的起止时间，单击<查询>按钮查询对应的日志，单击<导出>按钮，导出所有日志，如图3-2所示。

图3-2 WVAS组件运行日志

3.1.3 SDWAN控制组件 操作日志

使用系统管理员（admin）登录统一数字底盘，进入[系统>日志管理>操作日志列表]页面，选择对应的时间，单击<查询>按钮，可以查询到对应操作日志，单击<导出>按钮，可以导出操作日志，如图3-3所示。

图3-3 导出操作日志

3.1.4 底盘WebSocket服务日志

控制组件和设备之间的通信需要通过底盘WebSocket服务，包括设备注册、配置下发等。使用系统管理员（admin）登录统一数字底盘，进入[系统>日志管理>运行日志列表]页面，所在目录选择“matrix-diag/SupportPlat/websocket/wsconn”，选择对应的时间，单击<查询>按钮，可以查询，单击<导出>按钮导出所有日志，如图3-4所示。

图3-4 导出WebSocket日志

由于WebSocket日志中会保存所有交互信息，因此日志可能比较大，如果日志过大，可以求助研发确认对应日志，下载单独的日志。

3.1.5 收集Matrix诊断信息

您可以通过如下步骤，查看Matrix的诊断信息。

(1) 在浏览器（如Chrome）中输入Matrix的GUI的登录地址（格式为：https://node_ip_address:8443/matrix/ui/），回车后打开Matrix GUI的登录界面。输入用户名和密码后，单击<登录>按钮进入Matrix GUI首页。

(2) 在Matrix GUI界面中，单击页面右上角的按钮，在弹出的菜单中单击[导出日志]菜单项即可导出日志到本地，如图3-5所示。

图3-5 导出日志菜单

3.1.6 收集设备日志

1. 收集设备诊断信息

(1) 直接登录设备收集诊断信息

收集设备的diag日志反馈，登录设备收集diag日志：

<Hub1> display diagnostic-information

Save or display diagnostic information (Y=save, N=display)? [Y/N]:

输入Y，保存diag日志，然后下载；输入N，显示diag日志然后直接收集。

(2) 通过控制器收集设备诊断信息，

登录控制器页面，进入[自动化>广域分支网络>维护保障>运维诊断>设备诊断]页面，可以收集设备的诊断信息，具体操作部署可以参考《AD-WAN分支7.2 WAN业务配置指导》。

2. 收集设备日志信息

收集设备日志信息：logfile文件收集。

[PE1]logfile save

The contents in the log file buffer have been saved to the files in flash:/logfile.

<PE1>cd flash:/logfile/

<PE1>dir

Directory of flash:/logfile

0 -rw- 354768 May 24 2021 21:19:01 logfile1.log.gz

1 -rw- 355413 May 24 2021 10:25:34 logfile10.log.gz

2 -rw- 355442 May 25 2021 08:15:30 logfile2.log.gz

3 -rw- 356789 May 25 2021 19:15:22 logfile3.log.gz

4 -rw- 355593 May 26 2021 06:15:32 logfile4.log.gz

5 -rw- 356788 May 26 2021 17:09:01 logfile5.log.gz

6 -rw- 357200 May 27 2021 04:49:02 logfile6.log.gz

7 -rw- 691708 May 27 2021 13:45:14 logfile7.log

8 -rw- 355235 May 23 2021 01:25:25 logfile7.log.gz

9 -rw- 355876 May 23 2021 12:25:36 logfile8.log.gz

10 -rw- 355563 May 23 2021 23:25:24 logfile9.log.gz

3.2 底盘问题处理

底盘通用问题请参考底盘故障处理手册。

3.2.1 集群单个节点异常故障处理

1. 故障描述

集群中的某个节点因为硬件故障无法恢复，需要更换新的节点服务器。

2. 故障处理步骤

目前分析器暂不宣称支持节点重建，分析器需要备份数据后卸载重装。

控制器和底盘进行节点重建，重建步骤参考底盘相关手册。

3.2.2 集群多个节点异常故障处理

1. 故障描述

集群中多个Master节点异常，需要更换新的节点服务器。

2. 故障处理步骤

系统文件备份，直接整个系统后进行数据恢复。具体安装过程参考安装手册。

3.2.3 常用基本命令

(1) 查看节点状态

[root@ucenter1 ~]# kubectl get node

NAME STATUS ROLES AGE VERSION

ucenter1 Ready master 28d v1.15.12

ucenter2 Ready master 28d v1.15.12

ucenter3 Ready master 28d v1.15.12

(2) 查看节点描述信息，能查看到节点的所有信息，包括所有Pod信息等

kubectl describe node * --------- (*为nodename，例如ucenter1)

[root@ucenter1 ~]# kubectl describe node ucenter1

Name: ucenter1

Roles: master

Labels: beta.kubernetes.io/arch=amd64

beta.kubernetes.io/os=linux

kubernetes.io/arch=amd64

kubernetes.io/hostname=ucenter1

kubernetes.io/os=linux

master=master1

node=node1

node-role.kubernetes.io/master=

platform=plat

role=master

Annotations: kubeadm.alpha.kubernetes.io/cri-socket: /var/run/dockershim.sock

node.alpha.kubernetes.io/ttl: 0

volumes.kubernetes.io/controller-managed-attach-detach: true

....略

(3) 查看所有Pod

[root@ucenter1 ~]# kubectl get pod -A

NAMESPACE NAME READY STATUS RESTARTS AGE

glusterfs-example glusterfs-8kkcz 1/1 Running 2 28d

glusterfs-example glusterfs-9qb7d 1/1 Running 2 28d

glusterfs-example glusterfs-g748m 1/1 Running 2 28d

glusterfs-example heketi-594549d6f5-9pb88 1/1 Running 1 12d

kube-system calico-node-c2kkv 1/1 Running 2 28d

kube-system calico-node-fjlhs 1/1 Running 2 28d

kube-system calico-node-jjrwv 1/1 Running 2 28d

kube-system coredns-795cc9c45c-9s9vq 1/1 Running 2 28d

kube-system coredns-795cc9c45c-tnrjh 1/1 Running 2 28d

kube-system grafana-798659d584-s44bn 1/1 Running 2 28d

kube-system grafana-798659d584-trw8j 1/1 Running 2 28d

..略

(4) 查看所有Pod详细信息

[root@ucenter1 ~]# kubectl get pods -A -o wide

glusterfs-example glusterfs-8kkcz 1/1 Running 2 28d 192.168.40.153 ucenter3 <none> <none>

glusterfs-example glusterfs-9qb7d 1/1 Running 2 28d 192.168.40.151 ucenter1 <none> <none>

glusterfs-example glusterfs-g748m 1/1 Running 2 28d 192.168.40.152 ucenter2 <none> <none>

glusterfs-example heketi-594549d6f5-9pb88 1/1 Running 1 12d 177.177.40.158 ucenter2 <none> <none>

kube-system calico-kube-controllers-5c6b7db866-c99mz 1/1 Running 2 28d 192.168.40.153 ucenter3 <none> <none>

kube-system calico-node-c2kkv 1/1 Running 2 28d 192.168.40.153 ucenter3 <none>

..略

(5) 查看指定namespace的Pod

常用namespace : 控制组件sdwan、分析组件sa、底盘服务service-software、Matrix系统服务kube-system

[root@sdwan1 ~]# kubectl get pods -n sdwan

NAME READY STATUS RESTARTS AGE

daq-5db94b8476-rxlrr 1/1 Running 0 2d4h

gateway-84d979d684-2824r 1/1 Running 0 2d4h

help-758798c87-v8k6r 1/1 Running 0 2d4h

msm-774f7c9cc7-tm6km 1/1 Running 0 2d4h

nacos-77bbc8dcb8-65xj6 1/1 Running 0 2d4h

nfm-55b6d6c78b-wx6qt 1/1 Running 0 2d4h

nso-86b6c74f6d-l4jqf 1/1 Running 0 2d4h

oam-65f5b887df-94xqf 1/1 Running 0 24h

pg-keeper-b82lk 1/1 Running 0 2d4h

pg-keeper-crnkb 1/1 Running 0 2d4h

pg-keeper-n8fcn 1/1 Running 0 2d4h

pg-proxy-fxp67 1/1 Running 0 2d4h

pg-proxy-h9dc6 1/1 Running 0 2d4h

pg-proxy-jbxh4 1/1 Running 0 2d4h

pg-sentinel-ddzlv 1/1 Running 0 2d4h

pg-sentinel-mf8vh 1/1 Running 0 2d4h

pg-sentinel-mxch4 1/1 Running 0 2d4h

redis-5f9685bd4b-r75tv 1/1 Running 0 2d4h

unicom-67bd9f446c-zzplt 1/1 Running 0 2d4h

vas-545d9b5664-dkr9c 1/1 Running 0 2d4h

web-74b5b65d6f-mcw2f 1/1 Running 0 2d4h

(6) 删除指定namespace的Pod，删除后会自动重新拉起。

kubectl delete pod XXX –n XXX

(7) 删除namespace为sdwan，name为oam-65f5b887df-94xqf

[root@ucenter1 ~]# kubectl delete pod oam-65f5b887df-94xqf -n sdwan

pod " oam-65f5b887df-94xqf" deleted

3.3 分析组件故障处理

本文档介绍SeerAnalyzer常见故障的诊断及处理措施。

3.3.1 收集日志信息

请通过如下步骤收集SeerAnalyzer操作日志、系统日志和运行日志。

(1) 在浏览器（如Chrome）中输入SeerAnalyzer的登录地址（格式为：http://sa_ip:30000/central，sa_ip为系统北向虚IP），回车后打开SeerAnalyzer的GUI登录界面。输入用户名和密码后，单击<登录>按钮进入SeerAnalyzer的GUI首页。

(2) 进入SeerAnalyzer后，单击[系统]菜单，进入系统设置页面。

图3-6 系统菜单

(3) 单击[日志管理]菜单项，进入日志管理页面。支持操作日志、系统日志、运行日志的配置和导出。

图3-7 操作日志界面

图3-8 系统日志界面

图3-9 运行日志界面

3.3.2 麒麟操作系统上部署或扩容分析组件失败

1. 故障描述

麒麟操作系统上无法部署或无法扩容分析组件。

2. 故障处理步骤

故障可能的原因：系统文件/etc/ssh/ssh_config配置中缺失StrictHostKeyChecking no这项配置。

故障处理步骤：在SeerAnalyzer每个节点的/etc/ssh/ssh_config配置文件的末尾增加一行StrictHostKeyChecking no配置。

3.3.3 采用南向网络部署分析组件时，触发集群网络中断异常

1. 故障描述

采用南向网络部署分析器时，触发集群节点间网络中断异常。

故障可能的原因：环境中存在多个网卡，并且部分网卡没有正确申请到IP地址时（使用了169.254.x.x网段地址）。安装分析组件时，部署节点会使用169.x.x.x的地址发送报文，触发ARP学习错误。

2. 故障处理步骤：

登录到报错信息中提示的节点上，执行命令lsof -i:50000，在南向网卡配置增加NOZEROCONF=yes配置，不生成169路由。

3.3.4 Pod运行状态CrashLoopBackOff

1. 故障描述

通过[系统>系统维护>容器化平台-平台资源]，选择Analyzer产品查看分析组件Pod运行状态，或通过远程登录服务器，使用kubectl get pod -n sa命令查看namespace为sa的Pod，若状态为“CrashLoopBackOff”则为异常状态。

图3-10 Pod运行状态

2. 故障处理步骤

Pod状态为“CrashLoopBackOff”的含义是Kubernetes试图启动该Pod，但是过程中出现错误，导致容器启动失败或者正在被删除。出现CrashLoopBackOff原因有很多，通常是由于依赖的数据库连接不上导致。可通过执行kubectl describe pod Pod名称 -n sa命令查看原因。

故障处理步骤如下：

(1) K8S会自动重启Pod，短暂等待Pod能否恢复。

(2) 如果不能自动恢复，请远程登录服务器，执行kubectl delete pod –nsa 异常状态pod名称命令重启异常状态的Pod。

(3) 如果上述操作完成后故障仍无法排除，请联系H3C技术支持工程师。

3.3.5 Flink流任务OOM问题

1. 故障描述

部分流处理任务由于内存限制导致任务产生OOM异常，任务对应pod频繁重启，无法处理业务，相关页面无数据。

2. 故障处理步骤

故障可能的原因：超出规格限制的业务量。

故障处理步骤如下：

在[分析>分析选项>任务管理]页面下找到需要调整的任务，手动调整“taskmanager容器内存限制”、“taskmanager进程内存限制”。建议每次调整增加1G，调整后的“taskmanager容器内存限制”需大于“taskmanager进程内存限制”300M。

图3-11 任务管理

3.3.6 系统断电或重启后Seamq实例状态异常

1. 故障描述

在节点系统断电或者系统重启后，Seamq服务会偶现非running状态的Pod，该Pod会处于不断重启的状态，重启次数不断增加，并且Pod状态会在CrashLoopBackOff和Running状态不停切换。

图3-12 Pod状态

2. 故障处理步骤

故障可能的原因：在节点系统断电或者系统重启后，致使该节点上运行的Seamq实例数据文件损坏，进而导致对应Pod一直处于不断重启的状态。

可以通过执行kubectl logs -nsa -f 异常seamq-pod名称 | grep "Found a corrupted index file"命令确认Seamq数据文件损坏。

故障处理步骤如下：

(1) 执行kubectl get pod -nsservice-software -owide | grep seamq命令获取对应异常Pod所在的节点

图3-13 Pod所在节点

(2) 执行如下命令进入到有文件损坏的节点目录：

cd /sa_data/kafka_data/data /

(3) 按顺序执行如下命令：

sudo rm -rf *

kubectl delete pod -nservice-software 异常seamq-pod名称

(4) 等待该异常Pod恢复正常即可

如果Seamq为三个实例Pod集群环境，一个节点文件损坏，不影响Seamq正常运行，多于一个节点文件损坏可能会影响Seamq服务运行；如果Seamq为单节点实例Pod环境，发生文件损坏，无法根本上保证Seamq服务正常运行和数据不丢失，通过上述操作恢复后，Seamq可以恢复正常，同时可能会损失部分数据。

4 自动化开局与设备上线类故障处理

4.1 问题描述

控制组件完成设备上线规划，设备导入或添加成功。设备通过U盘/邮件或手动开局，等待一段时间后，设备无法上线，控制组件显示设备离线。

设备上查询Websocket状态为离线状态：

<Spoke1>display cloud-management state

Cloud connection state : Unconnected //连接建立失败

Device state : Idle

Cloud server address : N/A

Cloud server domain name : 192.168.40.155

Cloud connection mode : Https

Cloud server authentication port : 12345

Cloud server connection port : N/A

Connected at : Mon Aug 16 09:41:30 2021

Duration : 00d 00h 00m 00s

Process state : Message received

Failure reason : Socket connection failed

Last down reason : Configuration changed (Details: N/A)

Last down at : Wed Aug 18 09:10:23 2021

Last report failure reason : N/A

Last report failure at : N/A

Dropped packets after reaching buffer limit : 0

Total dropped packets : 0

Last report incomplete reason : N/A

Last report incomplete at : N/A

Buffer full count : 0

4.2 问题排查思路

设备通过WebSocket主动注册上线，设备无法上线是由于WebSocket注册失败，一般需要通过远程或者串口登录设备进行问题排查，基本问题排查思路如图4-1所示。

图4-1 设备上线失败排查思路

4.3 排查控制组件配置

4.3.1 排查思路

确认控制组件上待注册设备是否已经添加，使用管理员登录控制组件，进入[自动化>广域分支网络>物理网络>设备管理]页面，确认待注册设备是否已经添加以及设备的SN是否正确或者软件序列号是否和设备配置一致，如图4-2所示。

图4-2 设备管理

设备SN查询方式：

<Spoke1>display license device-id

SN: 210150A19WX18C00000C //设备SN信息

Device ID: JFea-+XBt-@%i@-tmZ+-neRB-qbwe-HtL#-$zmQ

设备软件序列号配置：

cloud-management token simple+软件序列号

4.3.2 问题原因和解决方案

如果控制组件没有添加设备或设备的SN、软件序列号不正确，则设备无法注册成功。

需要手动添加设备并保障设备SN或者软件序列号正确。

4.4 排查设备注册配置

4.4.1 排查思路

设备通过U盘/邮件或手工配置开局，都需要下发基础注册配置，通过Telnet或者串口登录设备，确认设备注册配置是否已经正确下发。

设备注册配置举例如下：

dns proxy enable

cloud-management backup-server domain 120.1.1.1

cloud-management backup-server domain 120.1.2.1

cloud-management server domain 172.31.89.30

cloud-management keepalive 60

需要排查配置：

· 设备是否配置了dns proxy enable命令；

· 确认cloud-management注册地址是否正确：

¡ 通过私网注册：注册地址为控制组件统一北向地址；

¡ 通过公网注册：注册地址为控制组件统一北向地址映射到的公网地址；

· 是否有其它多余配置，例如注册端口号、注册密码配置等，注册使用的是默认19443端口，不需要注册密码，如果有对应配置则需要删除。

4.4.2 问题原因和解决方案

1. 设备手工开局

如果是手工开局部署，注册配置手工配置错误，则需要用户手工修改配置。

2. U盘/邮件开局

通过U盘/邮件开局配置下发错误，则需要确认控制组件的WebSocket模板配置是否正确，以及设备选择的WebSocket模板是否正确。

使用租户业务管理员登录统一数字底盘，进入[自动化>广域分支网络>网络规划>参数和模板 >模板配置>WebSocket模板]页面，确认WebSocket模板是否正确，是否有多个模板，如果设备通过公网注册，是否添加了对应的公网注册地址，如图4-3所示。

图4-3 WebSocket模板

进入[自动化>广域分支网络>物理网络>站点管理]页面，单击对应设备后面的编辑按钮，确认设备使用的Websocket模板是否正确，如图4-4所示。

图4-4 修改站点

确认WebSocket模板正确并且设备使用了正确的WebSocket模板，进入[自动化 >分支网络>物理网络>设备>U盘/邮件开局]页面，重新下载U盘或者发送开局邮件。

4.5 排查注册地址路由和端口是否可达

4.5.1 排查思路

1. 确认注册地址的路由

确认注册地址可达，在设备上查询到注册设备的路由，确认路由是否正确，排查命令：

<Spoke1>display ip routing-table 192.168.40.155

Summary count : 2

Destination/Mask Proto Pre Cost NextHop Interface

0.0.0.0/0 Static 60 0 0.0.0.0 Dia1

192.168.40.0/24 O_INTER 10 125 20.3.2.1 GE0/0

2. Ping注册地址是否可达

从设备上直接ping控制组件统一北向地址，确认是否可以ping通，排查命令：

<Spoke1>ping 192.168.40.155

Ping 192.168.40.155 (192.168.40.155): 56 data bytes, press CTRL_C to break

56 bytes from 192.168.40.155: icmp_seq=0 ttl=61 time=0.571 ms

56 bytes from 192.168.40.155: icmp_seq=1 ttl=61 time=0.308 ms

56 bytes from 192.168.40.155: icmp_seq=2 ttl=61 time=0.301 ms

56 bytes from 192.168.40.155: icmp_seq=3 ttl=61 time=0.297 ms

56 bytes from 192.168.40.155: icmp_seq=4 ttl=61 time=0.309 ms

--- Ping statistics for 192.168.40.155 ---

5 packet(s) transmitted, 5 packet(s) received, 0.0% packet loss

round-trip min/avg/max/std-dev = 0.297/0.357/0.571/0.107 ms

3. 确认业务端口是否可以访问

在设备上支持telnet命令，探测控制组件对应的TCP 19443端口是否可以访问。

探测成功如下，可以连接成功：

<Spoke1>telnet 192.168.40.155 19443

Trying 192.168.40.155 ...

Press CTRL+K to abort

Connected to 192.168.40.155 ...

The connection was closed by the remote host!

探测失败如下，超时无法连接：

<Spoke1>telnet 192.168.40.155 19443

Trying 192.168.40.155 ...

Press CTRL+K to abort

Connected to 192.168.40.155 ...

Failed to connect to the remote host!

4.5.2 问题原因和解决方案

1. 注册地址路由异常

查询注册地址路由异常，需要确认路由配置是否正确，邻居是否正常建立。

基本网络排查解决，本文档不详细描述。

2. 注册地址无法ping通

【问题原因】

路由正确的情况下，由于中间有防火墙，禁止了ping功能，导致注册地址无法ping通。

【解决方案】

控制组件注册不关注是否能ping通，如果防火墙放开了注册的端口，则不需要修复。

【问题原因】

需要指定特定的源地址才能ping通控制组件，例如用户网络规划只放通了Loopback管理口，确认指定源地址情况下可以ping通，探测命令：

<Spoke1>ping -a 30.1.1.5 192.168.40.155

Ping 192.168.40.155 (192.168.40.155) from 30.1.1.5: 56 data bytes, press CTRL_C to break

56 bytes from 192.168.40.155: icmp_seq=0 ttl=61 time=0.710 ms

56 bytes from 192.168.40.155: icmp_seq=1 ttl=61 time=0.387 ms

56 bytes from 192.168.40.155: icmp_seq=2 ttl=61 time=0.348 ms

56 bytes from 192.168.40.155: icmp_seq=3 ttl=61 time=0.349 ms

56 bytes from 192.168.40.155: icmp_seq=4 ttl=61 time=0.351 ms

--- Ping statistics for 192.168.40.155 ---

5 packet(s) transmitted, 5 packet(s) received, 0.0% packet loss

round-trip min/avg/max/std-dev = 0.348/0.429/0.710/0.141 ms

【解决方案】

手动修改WebSocket注册配置，指定注册使用的源地址：

<Spoke1>system-view

[Spoke1]cloud-management server domain 192.168.40.155 source-ip 30.1.1.5 //指定注册使用的源地址

[Spoke1]cloud-management backup-server domain 192.168.40.155 source-ip 30.1.1.5 //配置备注册服务器也可以指定源地址

3. TCP 19443端口无法访问

【问题原因】

控制组件前面有防火墙，防火墙没有放通TCP 北向虚IP:19443端口。

【解决方案】

修改防火墙配置，放通TCP 19443端口。

【问题原因】

控制组件通过NAT映射到公网，NAT没有映射控制组件统一北向地址的TCP 19443端口。

【解决方案】

修改NAT设备配置，映射控制组件统一北向地址的TCP 19443端口。

4.6 收集控制组件日志反馈研发

如果以上方式都无法排查出问题原因，则需要收集控制组件运行日志和对应的SN码，反馈控制组件日志给研发进行排查。需要收集的日志

(1) 底盘WebSocket日志，收集方法参考底盘WebSocket服务日志。

(2) SDWAN控制组件系统日志，收集方法参考SDWAN控制组件运行日志。

(3) 设备WebSocket debug日志，对应命令如下：

<Hub1-1>debugging cloud-management all

<Hub1-1>t d

The current terminal is enabled to display debugging logs.

<Hub1-1>t m

设备日志收集完成后需要关闭日志开关

<Hub1-1>undo debugging all

All possible debugging has been turned off.

5 分支互联与 隧道类故障处理

5.1 RR和CPE之间TTE无法建立

控制组件WAN业务部署完成，创建接入区CPE设备接入完成，RR和CPE之间的TTE连接无法建立。通过以下命令查询，存在无法建立的TTE或者没有查询到对应的TTE连接。

<Hub1-1>display sdwan tte connection

Destination SiteID/DevID/IfID/SysIP: 3/1/3/7.1.1.11

Destination IP/port: 8.1.1.1/4799

Source SiteID/DevID/IfID/SysIP: 5/1/1/7.1.1.14

Source IP/port: 172.1.5.2/4799

Created at: 2023/08/15 14:20:37

Status: Unreachable //状态时unreachable

State changed at: 2023/08/16 04:31:37

状态为Unreachable或无对应TTE连接时，可以参考以下步骤进行排查。

5.1.1 确认控制组件配置是否正确

参考《AD-WAN分支7.2 WAN业务配置指导》排查确认控制组件上的业务部署：

(1) RR和CPE设备是否加入的相同的WAN网络，是否有相同的传输网络（跨传输网开关关闭时需要有相同的传输网络），是否有相同的业务平面（相同平面才能建立TTE连接）。确保WAN网络详情配置状态为正常。

(2) CPE是否加入了对应RR的接入区，确认接入的部署状态为正常。

如果配置正确则继续进行排查。

5.1.2 确认TLS连接是否正常

CPE首先要和RR建立TLS连接交互TTE信息，确认CPE和RR之间的TLS连接是否正常。

CPE设备上执行如下命令：

[CPE1] display sdwan peer-connection status

System IP : 66.1.1.1 //连接RR设备的system IP

Peer IP/port: 90.2.1.2/2004 //连接RR设备的接口地址和端口号

VPN instance:

Status : Connected //和同一个RR设备（使用system ip标识）只要存在一条Connected状态即可

如果连接状态异常，则需要进行如下排查：

(1) 确认RR设备的sdwan server状态

[RR] display sdwan server status

SDWAN server: Enabled //状态开启

SDWAN server listening port: 2004 //监听端口

如果状态异常，确认RR设备对应配置，关键配置如下：

sdwan site-role cpe rr //角色里面包含RR

sdwan server port 1234 //端口号，缺省为2004，如果配置为2004则不会回显

sdwan server enable //sdwan Server是否已经启动

如果配置异常则确认控制组件上RR站点对应部署状态是否正常，收集控制组件日志。

(2) 确认CPE配置是否正常

关键配置如下：

sdwan site-role cpe rr //站点角色包含CPE

sdwan ssl-client-policy plc1 //使用ssl连接的policy

sdwan server system-ip 7.1.1.12 ip 172.1.6.1 //指定连接system ip对应的RR设备时需要远端（RR设备）的WAN口地址。同一个system ip可以指定多个WAN口地址，只需要一个地址连接成功即可。

sdwan server system-ip 7.1.1.12 ip 173.1.1.1

sdwan server system-ip 7.1.1.13 ip 173.1.4.1

如果配置有问题则需要排查控制组件配置，确认控制组件WAN详情和接入区是否正常。如果没有连接关系，有可能是RR设备的WAN口地址没有识别，可以删除RR设备对应的WAN详情，单击设备同步，然后再次添加WAN详情。

(3) 基础网络排查

从设备上直接ping RR的WAN口地址，确认是否可以ping通排查命令：

[Spoke1-2]ping 172.1.6.1

Ping 172.1.6.1 (172.1.6.1): 56 data bytes, press CTRL_C to break

56 bytes from 172.1.6.1: icmp_seq=0 ttl=255 time=0.157 ms

56 bytes from 172.1.6.1: icmp_seq=1 ttl=255 time=0.101 ms

56 bytes from 172.1.6.1: icmp_seq=2 ttl=255 time=0.174 ms

56 bytes from 172.1.6.1: icmp_seq=3 ttl=255 time=0.170 ms

56 bytes from 172.1.6.1: icmp_seq=4 ttl=255 time=0.156 ms

--- Ping statistics for 172.1.6.1 ---

5 packet(s) transmitted, 5 packet(s) received, 0.0% packet loss

round-trip min/avg/max/std-dev = 0.101/0.152/0.174/0.026 ms

[Spoke1-2]

确认业务端口是否可以访问，在设备上支持telnet命令，探测WAN口地址对应的TCP端口（确认为2004）是否可以访问。

探测成功如下，可以连接成功：

<Spoke1-2>telnet 172.1.6.1 2004

Trying 172.1.6.1 ...

Press CTRL+K to abort

Connected to 172.1.6.1 ...

The connection was closed by the remote host!

探测失败如下，超时无法连接：

<Spoke1-2>telnet 172.1.6.1 2004

Trying 172.1.6.1 ...

Press CTRL+K to abort

Connected to 172.1.6.1 ...

Failed to connect to the remote host!

如果网络排查有问题，则可能是中间防火墙或路由配置问题，请排查基础网络

(4) 接口为聚合口时建议在聚合口下配置service slot命令。

(5) 检查分支ssl使用的tls版本RR设备是否允许使用。

CPE设备输入以下命令查询ssl client信息：

<Spoke1-2>display ssl client-policy

Total number of SSL client policies: 1

SSL client policy: plc1 //查询上面CPE配置中的sdwan ssl-client-policy plc1一样的名称，控制组件下发名称就是plc1

SSL version: TLS 1.2 //使用的ssl版本

PKI domain:

Preferred ciphersuite:

RSA_AES_256_CBC_SHA

Server-verify: disabled

确认RR配置，确认是否允许了分支使用SSL版本，手动修改策略后需要undo sdwan server enable或者重新部署接入区,才使能生效）

[RR]display cu | begin security-enhanced level //查看RR的安全策略

security-enhanced level 1

undo ssl renegotiation disable

undo ssl version ssl3.0 disable

undo ssl version tls1.0 disable

undo ssl version tls1.1 disable

undo ssl version tls1.2 disable //允许了TLS 1.2建立连接

undo ssl version tls1.3 disable

如果以上方式都无法排查，需要收集设备信息反馈研发定位。

(6) 如果以上都正常，收集设备诊断信息反馈研发。

TLS连接建立正常的情况下，可以继续进行排查。

5.1.3 无法查询到CPE和RR之间的TTE

用户规划CPE和RR之间有TTE连接，实际查询时无法查询到对应的TTE连接（可达和不可达TTE都无法查询到），需要参考此节进行排查，否则可以继续下面排查。

正常TLS连接正确建立，CPE就会和RR交互TTE，在RR或CPE上查询站点的TTE信息。

站点TTE信息和隧道配置相关，确认TTE数量，路由域（RDID），NAT状态、SA（IPSEC加密）、TNID（传输网属性）是否符合预期。

<Spoke1-1> display sdwan site-tte

Site ID: 5 (local) //本机的TTE信息

Total number of TTEs: 2

********************************************************************************

DevID SysIP IfID Status Encap NAT SA RDID TNID

1 7.1.1.14 1 UP UDP IPv4 Disabled Disabled 401 11

1 7.1.1.14 2 UP UDP IPv4 Disabled Disabled 403 15

Site ID: 3 (remote) //远端的TTE信息，Site ID是全网唯一，控制组件自动分配，sdwan site-id 3命令来指定。

Total number of TTEs: 3

********************************************************************************

DevID SysIP IfID Status Encap NAT SA RDID TNID

1 7.1.1.11 1 UP UDP IPv4 Enabled Enabled 200 7

1 7.1.1.11 2 UP UDP IPv4 Enabled Enabled 200 7

1 7.1.1.11 3 UP UDP IPv4 Disabled Disabled 401 11

CPE设备上查询TTE信息时，发现没有对应的TTE连接（可达或不可达），一般是因为RR和CPE的WAN详情配置不一致导致，路由域/平面/传输网配置有问题，导致设备判断不需要建立TTE连接。

RR设备上进行查询时，如果分支有NAT（Enabled），则需要分支先主动发起TTE建连请求，总部才能查询到对应的TTE链接信息。

设备上也可以添加verbose参数查询详细的站点TTE信息，可以查询到平面信息等。

<Spoke1-1> display sdwan site-tte verbose

Site ID: 5 (local)

Site name: Branch1

Site role: RR/CPE

Device ID: 1

System IP: 7.1.1.14

Interface ID: 1

Group ID: - //平面编号

Interface name: Tunnel1

Status: UP

Encapsulation protocol: UDP IPv4

Encapsulation port: 4799

Tunnel destination VPN index: 0

Transport destination VPN index: 0

NAT: Disabled

NAT type: -

NAT public IP: -

NAT public port: -

SA: Disabled

Routing domain(name/ID): 401/401

Transport network(name/ID): Default.11/11

Restrict transport network : Disabled

Out physical interface: GigabitEthernet3/0

Source IP: 172.1.5.2

5.1.4 CPE和RR之间的不可达TTE排查

查询TTE状态为不可达时，则需要按照以下步骤排查：

(1) 对于Internet网络，中间可能有NAT设备，需要确认TTE建立的目的地址是否为NAT变换后的地址：

查询无法建立TTE的TTE 连接，确认TTE连接的目的地址：

<Spoke2> display sdwan tte connection unreachable

Destination SiteID/DevID/IfID/SysIP: 7/1/2/7.1.1.20

Destination IP/port: 10.100.1.2/12295 //确认建立TTE连接的目的地址是否为公网地址

Source SiteID/DevID/IfID/SysIP: 8/1/8/7.1.1.16

Source IP/port: 110.1.7.1/12295

Created at: 2024/02/07 06:31:36

Status: Unreachable

State changed at: 2024/02/07 06:31:36

Number of connections: 1

对端目的地址为私网地址时，TTE无法建立，分为两种场景排查：

a. 互联网接口通过NAT设备映射为固定公网地址：添加WAN详情时需要指定固定公网IP。设备隧道下会下发固定公网地址配置，对端设备建立TTE时目的地址为对应固定公网地址。

interface Tunnel2 mode sdwan udp

sdwan nat-global-ip 110.1.2.1 //固定公网地址配置

b. 分支互联网接口使用私网地址，通过运营商设备/光猫进行动态NAT变换，变为公网地址：添加WAN详情时需要指定STUN Server，由分支主动发起TTE建立请求，总部基于TTE建立请求确认对端公网地址并建立TTE连接。设备隧道下需要指定STUN Server，对应配置如下：

interface Tunnel2 mode sdwan udp

stun client destination-ip 127.0.0.1 //stun地址需要配置为127.0.0.1

(2) 确认到对端封装地址的路由是否可达且出接口是否和隧道下指定的出接口一致。

确认隧道口对应的出接口：

<spoke> display current-configuration interface Tunnel 1

interface Tunnel1 mode sdwan udp

bandwidth 10000

ip address unnumbered interface GigabitEthernet0/1

source GigabitEthernet0/1

tunnel out-interface GigabitEthernet0/1 //指定出接口

ipv6 address auto link-local

tunnel protection ipsec profile adwan-ipsec-profile

sdwan interface-id 1

sdwan routing-domain 10 id 10

sdwan transport-network Mobile.1.ipv4 id 1

sdwan keepalive interval 2 retry 5

Return

查询无法建立TTE连接的对端封装地址的路由出接口：

<spoke>display ip routing-table 220.1.1.1

Summary count : 3

Destination/Mask Proto Pre Cost NextHop Interface

0.0.0.0/0 Static 60 0 220.1.2.1 GE0/1

220.1.1.0/24 O_INTRA 10 12 20.1.2.1 GE0/2

220.1.1.1/32 O_INTRA 10 12 20.1.2.1 GE0/2 //出接口不一致

如果没有对应路由或者出接口不一致，则是底层路由问题。需要排查底层路由配置，确认是否底层路由发布问题。

(3) 排查基础网络，通过ping排查到封装目的地址的底层网络是否可达。由于封装使用的是UDP，只能排查基础路由。

(4) 分支使用家宽接入，原有TTE正常，运行一段时间后出现TTE无法建立的情况。

运营商会周期性回收、替换家宽的公网地址，有可能导致光猫出现session残留的情况，无法正确转发分支设备的TTE报文，导致TTE无法建立。

如果要明确定位可以参考下一步，收集设备的debug信息，确认总部是否收到了分支的TTE报文。

· 下面所有的排查和配置都要在分支设备上执行，由于总部会连接多个分支，不允许在总部隧道下添加对应配置。

· 分支排查/添加优化配置的隧道必须是1：1隧道，也就是说只能建立一条TTE连接，如果要和总部建立多条TTE连接，需要通过平面分成多条隧道。

· 整体排查和优化还是建议咨询路由器二线，配置优化有一定风险。

简单排查方法，确认出问题的隧道后，通过控制器修改隧道的UDP端口，登录控制器进入[自动化>广域分支网络>物理网络>隧道管理>SDWAN隧道]页面，查询到对应的隧道，单击操作里面的修改隧道的UDP封装端口号，如图5-1所示，修改端口号时不要修改为业务平面已经使用的端口号，防止出现端口冲突。

图5-1 修改SDWAN隧道

修改了封装端口号后，等待一段时间如果TTE可以恢复，则可能是由于运营商session残留导致。手动添加如下命令（注意路由器E6749L09及以后版本可以支持）。

[Spoke1-2]bfd init-fail-timer 30 //初始不通的情况下也能切换端口

登录控制器进入[自动化>广域分支网络>物理网络>站点配置 >WAN业务网络详情]页面，查找对应出问题的WAN详情，单击按钮修改WAN业务网络详情，使能动态UDP端口，如图5-2所示。

图5-2 修改WAN业务网络详情

优化配置完成，可以确认TTE状态。

(5) RR和CPE同时收集设备debug，确认报文通信是否正常。

定义ACL匹配对应封装报文，可以直接分支的UDP封装地址和端口

acl advanced 3333

rule 0 permit udp source 172.1.8.2 0 source-port eq 4799

rule 10 permit udp source 172.1.8.2 0 destination-port eq 4799

收集IP Packet相关的debug信息，对应命令如下：

<Spoke4-1>debugging ip packet acl 3333

<Spoke4-1>t d

The current terminal is enabled to display debugging logs.

<Spoke4-1>t m

The current terminal is enabled to display logs.

收集IP Packet相关的debug信息，可能需要清空一下快转表：

<Spoke4-2>reset ip fast-forwarding cache

打印日志举例：

<Spoke4-2>*Aug 21 07:32:48:568 2023 Spoke4-2 IPFW/7/IPFW_PACKET:

Sending, interface = GigabitEthernet3/0 //从对应接口发送了TTE报文

version = 4, headlen = 20, tos = 224

pktlen = 96, pktid = 23, offset = 0, ttl = 255, protocol = 17

checksum = 64909, s = 172.1.8.2, d = 8.1.1.4

channelID = 0, vpn-InstanceIn = 0, vpn-InstanceOut = 0.

VsysID = 1

prompt: Sending IP packet from local at interface GigabitEthernet3/0.

Payload: UDP

source port = 4799, destination port = 4799

checksum = 0x0000, length = 76.

*Aug 21 07:32:48:574 2023 Spoke4-2 IPFW/7/IPFW_PACKET:

Receiving, interface = GigabitEthernet3/0 //从对应接口收到了TTE报文，如果没有收到报文需要判断是否中间报文通信是否正常。

version = 4, headlen = 20, tos = 224

pktlen = 96, pktid = 147, offset = 0, ttl = 255, protocol = 17

checksum = 64785, s = 8.1.1.4, d = 172.1.8.2

channelID = 0, vpn-InstanceIn = 0, vpn-InstanceOut = 0.

VsysID = 1

prompt: Receiving IP packet from interface GigabitEthernet3/0.

Payload: UDP

source port = 4799, destination port = 4799

checksum = 0x0000, length = 76.

确认RR和CPE收发报文正否正常，收集完debug后一定要关闭开关。

<Spoke1-1>undo debugging all

All possible debugging has been turned off.

<Spoke1-1>undo t d

The current terminal is disabled to display debugging logs.

<Spoke1-1>undo t m

The current terminal is disabled to display logs.

<Spoke1-1>

(6) 收集信息求助研发共同定位。

5.2 CPE之间TTE无法连接

创建区域拓扑，配置分支之间可以直接互通，CPE之间也要建立TTE连接，但是查询发现CPE之间存在无法建立的TTE或者没有查询到对应的TTE连接。

<Hub1-1>display sdwan tte connection

Destination SiteID/DevID/IfID/SysIP: 3/1/3/7.1.1.11

Destination IP/port: 8.1.1.1/4799

Source SiteID/DevID/IfID/SysIP: 5/1/1/7.1.1.14

Source IP/port: 172.1.5.2/4799

Created at: 2023/08/15 14:20:37

Status: Unreachable //状态时unreachable

State changed at: 2023/08/16 04:31:37

状态为Unreachable或无对应TTE连接时，可以参考以下步骤进行排查。

5.2.1 确认控制组件配置是否正确

参考《AD-WAN分支7.2 WAN业务配置指导》排查确认控制组件上的业务部署：

(1) 确认区域拓扑是否指定了分支之间直接通信，区域拓扑下发是否正常

(2) 两台CPE设备是否加入的相同的WAN网络，是否有相同的传输网络（跨传输网开关关闭时需要有相同的传输网络），是否有相同的业务平面（相同平面才能建立TTE连接）。确保WAN网络详情配置状态为正常。

(3) 如果CPE之间通过Internet互通，确认一端必须有固定公网地址。

(4) CPE必须发布了本地VPN业务路由。

如果配置正确则继续进行排查。

5.2.2 CPE和RR的BGP邻居是否正常

参考RR和CPE之间TTE无法建立确认RR和CPE之间TTE连接正常。

确认RR和CPE之间BGP邻居状态，确认TNL地址族和L2VPN EVPN地址族都正常。

查询TNL地址族邻居状态：

<Spoke1-2>display bgp peer ipv4 tnl-encap-ext

BGP local router ID: 7.1.1.15

Local AS number: 6000

Total number of peers: 5 Peers in established state: 5

* - Dynamically created peer

Peer AS MsgRcvd MsgSent OutQ PrefRcv Up/Down State

7.1.1.11 6000 1691 77 0 0 00:53:17 Established

7.1.1.12 6000 41439 1219 0 15 15:32:27 Established

7.1.1.13 6000 37512 1068 0 15 15:32:24 Established

7.1.1.18 6000 967 26744 0 0 15:32:28 Established

7.1.1.19 6000 1090 41393 0 2 15:32:26 Established

查询l2vpn evpn地址族邻居状态：

<Spoke1-2>display bgp peer l2vpn evpn

BGP local router ID: 7.1.1.15

Local AS number: 6000

Total number of peers: 5 Peers in established state: 5

* - Dynamically created peer

Peer AS MsgRcvd MsgSent OutQ PrefRcv Up/Down State

7.1.1.11 6000 1691 77 0 8 00:53:21 Established

7.1.1.12 6000 41442 1220 0 11 15:32:31 Established

7.1.1.13 6000 37515 1068 0 11 15:32:28 Established

7.1.1.18 6000 967 26746 0 2 15:32:32 Established

7.1.1.19 6000 1090 41396 0 2 15:32:30 Established

确认邻居状态都正常。

5.2.3 无法查询到CPE之间的TTE

用户规划CPE之间有TTE连接，实际查询时无法查询到对应的TTE连接（可达和不可达TTE都无法查询到），需要参考此节进行排查，否则可以继续下面排查。

两台CPE都需要进行排查，必须两边都有待建立的TTE信息时采集建立TTE连接。

(1) 查询站点TTE状态

<Spoke1-1>display sdwan site-tte

Site ID: 5 (local) //本机的TTE信息

Total number of TTEs: 2

********************************************************************************

DevID SysIP IfID Status Encap NAT SA RDID TNID

1 7.1.1.14 1 UP UDP IPv4 Disabled Disabled 401 11

1 7.1.1.14 2 UP UDP IPv4 Disabled Disabled 403 15

Site ID: 3 (remote) //远端的TTE信息，Site ID是全网唯一，控制组件自动分配，sdwan site-id 3命令来指定。

Total number of TTEs: 3

********************************************************************************

DevID SysIP IfID Status Encap NAT SA RDID TNID

1 7.1.1.11 1 UP UDP IPv4 Enabled Enabled 200 7

1 7.1.1.11 2 UP UDP IPv4 Enabled Enabled 200 7

1 7.1.1.11 3 UP UDP IPv4 Disabled Disabled 401 11

确认站点TTE，确认是否有对端分支的站点TTE信息。站点TTE是RR通过TNL地址族进行反射，需要排查确认TNL地址族邻居是否正常，路由获取是否正常。

(2) 确认是否收到了对应的VPN业务路由且下一跳未修改为总部的system IP

两端CPE查询BGP路由表，查询对端的网段的优选路由，确认是否不携带system ip，保证CPE之间直接互通。命令如下：

<Spoke1-2>display bgp routing-table ipv4 vpn-instance VPN1 20.1.3.0

BGP local router ID: 7.1.1.15

Local AS number: 6000

Paths: 4 available, 4 best

BGP routing table information of 20.1.3.0/24:

From : 7.1.1.11 (7.1.1.11)

Rely nexthop : 0.0.0.0

Original nexthop: 7.1.1.16

OutLabel : 2

Community : <2:1>, <2:4>, <65535:3>, <65535:6>

Ext-Community : <RT: 2:2>

RxPathID : 0x0

TxPathID : 0x0

AS-path : (null)

Origin : incomplete

Attribute value : MED 0, localpref 200, pref-val 0

State : valid, internal, best, remoteredist

Originator : 7.1.1.16

Cluster list : 7.1.1.11

SystemIP : 7.1.1.11 //确认system ip所属的设备，携带的system ip一般为总部设备，通过总部转发。如果CPE之间直接互通。路由中不应该携带system ip

IP precedence : N/A

QoS local ID : N/A

Traffic index : N/A

VPN-Peer UserID : N/A

DSCP : N/A

EXP : N/A

Tunnel policy : NULL

Rely tunnel IDs : N/A

(3) 排查站点TTE信息，确认是否可以建立TTE连接

路由正常的情况下，排查CPE两端的站点TTE信息，确认是否可以建立TTE连接。

设备上也可以添加verbose参数查询详细的站点TTE信息，可以查询到平面信息等。

<Spoke1-1>display sdwan site-tte verbose

Site ID: 5 (local)

Site name: Branch1

Site role: RR/CPE

Device ID: 1

System IP: 7.1.1.14

Interface ID: 1

Group ID: - //平面编号

Interface name: Tunnel1

Status: UP

Encapsulation protocol: UDP IPv4

Encapsulation port: 4799

Tunnel destination VPN index: 0

Transport destination VPN index: 0

NAT: Disabled

NAT type: -

NAT public IP: -

NAT public port: -

SA: Disabled

Routing domain(name/ID): 401/401

Transport network(name/ID): Default.11/11

Restrict transport network : Disabled

Out physical interface: GigabitEthernet3/0

Source IP: 172.1.5.2

(4) 反馈信息给研发，配合分析定位

5.2.4 CPE之间存在不可达TTE排查

查询TTE状态为不可达时，则需要按照以下步骤排查：

(1) 确认到对端封装地址的路由是否可达且出接口是否和隧道下指定的出接口一致。

确认隧道口对应的出接口：

<spoke>display current-configuration interface Tunnel 1

interface Tunnel1 mode sdwan udp

bandwidth 10000

ip address unnumbered interface GigabitEthernet0/1

source GigabitEthernet0/1

tunnel out-interface GigabitEthernet0/1 //指定出接口

ipv6 address auto link-local

tunnel protection ipsec profile adwan-ipsec-profile

sdwan interface-id 1

sdwan routing-domain 10 id 10

sdwan transport-network Mobile.1.ipv4 id 1

sdwan keepalive interval 2 retry 5

Return

查询无法建立TTE连接的对端封装地址的路由出接口：

<spoke>display ip routing-table 220.1.1.1

Summary count : 3

Destination/Mask Proto Pre Cost NextHop Interface

0.0.0.0/0 Static 60 0 220.1.2.1 GE0/1

220.1.1.0/24 O_INTRA 10 12 20.1.2.1 GE0/2

220.1.1.1/32 O_INTRA 10 12 20.1.2.1 GE0/2 //出接口不一致

如果没有对应路由或者出接口不一致，则是底层路由问题。需要排查底层路由配置，确认是否底层路由发布问题。

(2) 排查基础网络，通过ping排查到封装目的地址的底层网络是否可达。由于封装使用的是UDP只能排查基础路由。

(3) 两端CPE同时收集设备debug，确认报文通信是否正常。

定义ACL匹配对应封装报文，可以直接分支的UDP封装地址和端口

acl advanced 3333

rule 0 permit udp source 172.1.8.2 0 source-port eq 4799

rule 10 permit udp source 172.1.8.2 0 destination-port eq 4799

收集IP Packet相关的debug信息，对应命令：

<Spoke1-1>debugging ip packet acl 3333

<Spoke1-1>t d

The current terminal is enabled to display debugging logs.

<Spoke1-1>t m

The current terminal is enabled to display logs.

收集IP Packet相关的debug信息，可能需要清空一下快转表：

<Spoke4-2>reset ip fast-forwarding cache

打印日志举例：

<Spoke4-2>*Aug 21 07:32:48:568 2023 Spoke4-2 IPFW/7/IPFW_PACKET:

Sending, interface = GigabitEthernet3/0 //从对应接口发送了TTE报文

version = 4, headlen = 20, tos = 224

pktlen = 96, pktid = 23, offset = 0, ttl = 255, protocol = 17

checksum = 64909, s = 172.1.8.2, d = 8.1.1.4

channelID = 0, vpn-InstanceIn = 0, vpn-InstanceOut = 0.

VsysID = 1

prompt: Sending IP packet from local at interface GigabitEthernet3/0.

Payload: UDP

source port = 4799, destination port = 4799

checksum = 0x0000, length = 76.

*Aug 21 07:32:48:574 2023 Spoke4-2 IPFW/7/IPFW_PACKET:

Receiving, interface = GigabitEthernet3/0 //从对应接口收到了TTE报文，如果没有收到报文需要判断是否中间报文通信是否正常。

version = 4, headlen = 20, tos = 224

pktlen = 96, pktid = 147, offset = 0, ttl = 255, protocol = 17

checksum = 64785, s = 8.1.1.4, d = 172.1.8.2

channelID = 0, vpn-InstanceIn = 0, vpn-InstanceOut = 0.

VsysID = 1

prompt: Receiving IP packet from interface GigabitEthernet3/0.

Payload: UDP

source port = 4799, destination port = 4799

checksum = 0x0000, length = 76.

确认RR和CPE收发报文正否正常，收集完debug后一定要关闭开关。

<Spoke1-1>undo debugging all

All possible debugging has been turned off.

<Spoke1-1>undo t d

The current terminal is disabled to display debugging logs.

<Spoke1-1>undo t m

The current terminal is disabled to display logs.

<Spoke1-1>

(4) 收集信息求助研发共同定位。

6 路由与智能选路类故障处理

6.1 BGP故障处理

6.1.1 BGP会话无法进入Established状态

1. 故障描述

本地路由器与对等体/对等体组建立的BGP会话无法进入Established状态。

2. 常见原因

本类故障的常见原因主要包括：

· BGP报文转发受阻。

· 建立/维持BGP TCP连接的报文被ACL过滤。

· 自治系统内，BGP邻居间的Router ID产生冲突。

· 指定了错误的对等体/对等体组的AS号。

· 指定对等体的地址为Loopback接口的IP地址时，对端未通过peer connect-interface命令将建立TCP连接所使用的源接口配置为Loopback接口，或者对端未通过peer source-address命令将建立TCP连接所使用的源地址配置为Loopback接口的地址。

· 建立BGP TCP连接时，BGP会话两端发送的TCP报文长度过大，在转发时被出接口MTU较小且无法对报文分片的中间节点丢弃，导致BGP TCP连接失败。

· 指定EBGP对等体的地址为Loopback接口的IP地址时，对端未配置peer ebgp-max-hop命令，以允许本地路由器同非直连邻居建立EBGP会话。

· BGP会话的两端未通过peer password命令配置相同的密钥，导致MD5认证失败。

· 配置peer ttl-security命令以开启指定对等体/对等体组的GTSM功能时，到达对等体/对等体组的最大跳数配置错误，导致对等体/对等体组无法通过GTSM检查。

· 对等体向本地路由器发送的BGP路由数量超过了peer route-limit命令设定的最大值，导致BGP会话断开。

· BGP路由器上配置了peer ignore、ignore all-peers或shutdown process命令，禁止建立BGP会话。

· 本地路由器与对端路由器没有在相同的地址族视图下使能路由信息交换能力。

3. 故障分析

本类故障的诊断流程如图6-1所示：

图6-1 BGP会话无法进入Established状态的故障诊断流程图

4. 处理步骤

(1) 检查与BGP邻居之间的通信链路是否正常。

a. 检查与邻居建立BGP会话的相关接口是否处于UP状态。

b. 通过ping命令方式检查与BGP邻居的连通性。如果Ping的结果为可达，则说明本地路由器与BGP邻居之间的通信链路正常，请执行步骤（2）。如果Ping的结果为不可达，请执行步骤c。

建议使用ping –a source-ip –s packet-size命令和ping ipv6 –a source-ipv6 –s packet-size命令来检测与BGP邻居的连通性。–a source-ip和–a source-ipv6参数指定了ICMP回显请求报文的源地址，方便用户同时检测两端的链路是否都正常；–s packet-size参数指定了发送的ICMP回显请求报文的长度，方便用户检测长报文在链路中的传输情况。Ping操作的源IP地址取用本端建立BGP会话使用的接口的IP地址，目的IP地址取用对端建立BGP会话使用的接口的IP地址。

c. 执行ping –a source-ip –s packet-size命令进行Ping操作，并逐步减小–s packet-size参数输入的值，当该参数减小到某个值时，Ping的结果变为可达，则表示建立BGP TCP连接时发送的TCP报文由于长度过长，在转发过程中被设备丢弃，导致了BGP会话无法进入Established状态。

- 此时可以重复执行ping –a source-ip –s packet-size命令，调整–s packet-size参数的取值，直至找到一个合适的取值（Ping的结果为可达的前提下，取尽量大的值，以提高转发效率），然后将该值设置为BGP报文转发出接口的MTU值。可通过在接口上执行ip/ipv6 mtu mtu-size或tcp mss value命令，或者在BGP实例视图/BGP-VPN实例视图下执行peer tcp-mss命令来设置出接口的MTU值；其中，ip/ipv6 mtu mtu-size命令配置的是MTU值，tcp mss value和peer tcp-mss命令配置的是TCP MSS值（TCP MSS＝MTU值－IP头部长度－TCP头部长度）。

- 也可以无需重复进行Ping操作，直接在系统视图下执行tcp path-mtu-discovery命令，开启TCP连接的Path MTU探测功能。之后，设备会根据探测机制自动获得建立TCP连接的路径上最小的MTU值，并计算得到MSS值，后续建立BGP TCP连接时，会使用计算得到的MSS值作为TCP报文的长度。

如果无论怎么调整–s packet-size参数的取值，Ping的结果均为不可达，请参见“Ping和Tracert故障处理”中的“Ping不通”进行后续的检查。

d. 如果故障仍不能排除，请执行步骤（2）

(2) 检查BGP TCP连接是否建立。

执行display tcp命令，查看显示信息中是否存在地址为本地路由器地址以及BGP邻居的地址、对端端口号为179、TCP连接状态为ESTABLISHED的条目。例如：

<Sysname> display tcp

*: TCP connection with authentication

Local Addr:port Foreign Addr:port State PCB

0.0.0.0:179 12.1.1.2:0 LISTEN 0xffffffffffffff9d

12.1.1.1:28160 12.1.1.2:179 ESTABLISHED 0xffffffffffffff9e

如果存在，则执行步骤（3）；如果不存在，则进行以下检查：

¡ 执行display ip routing-table或display ipv6 routing-table命令，查看路由表中是否存在对端建立BGP会话使用的IPv4/IPv6地址的IGP路由，如果不存在，请检查IGP路由的配置。常见的IGP路由协议故障处理方法，请参见对应协议的故障处理，例如“OSPF故障处理”。

¡ 执行display acl all命令，查看是否存在拒绝端口号为bgp的规则，例如：

<Sysname> display acl all

Advanced IPv4 ACL 3077, 2 rules,

ACL's step is 5

rule 1 deny tcp destination-port eq bgp

rule 2 deny tcp source-port eq bgp

如果存在这样的规则，请执行undo rule命令取消这些配置。

¡ 执行debugging tcp packet命令，根据Debug信息判断BGP建立TCP连接时是否存在安全认证失败，例如：

<Sysname> debugging tcp packet acl 3000

*Feb 5 20:03:39:289 2021 Sysname SOCKET/7/INET: -MDC=1;

TCP Input: Failed to check md5, drop the packet.

上述信息表明BGP建立TCP连接时MD5认证失败。请在建立BGP TCP连接的两端设备上均执行peer password命令配置相同的密钥。

<Sysname> debugging tcp packet acl 3000

*Feb 5 20:03:39:289 2021 Sysname SOCKET/7/INET: -MDC=1;

TCP Input: Failed to check keychain, drop the packet.

上述信息表明BGP建立TCP连接时keychain认证失败。请确保建立BGP TCP连接的两端设备上均通过执行peer keychain命令配置了keychain认证，并且同一时间内使用的key的标识符相同，以及相同标识符的key的认证算法和认证密钥一致。

<Sysname> debugging tcp packet acl 3000

*Feb 5 20:03:39:289 2021 Sysname SOCKET/7/INET: -MDC=1;

TCP Input: Failed to get IPSEC profile, index 500, name profile1(inpcb profile2), return 0x3fff.

上述信息表明BGP建立TCP连接时IPsec认证失败。请检查BGP会话两端设备的IPsec配置并确保在两端设备上均通过执行peer ipsec-profile命令应用了IPsec安全框架。

如果故障仍不能排除，请执行步骤（3）。

(3) 检查Router ID是否存在冲突，AS号是否配置错误。

a. 执行display bgp peer命令，根据显示信息中的“BGP local router ID”字段，判断是否存在Router ID配置冲突，如果存在冲突，请在需要建立BGP会话的BGP实例视图或BGP-VPN实例视图下执行router-id命令，修改BGP路由器的Router ID。例如：

<Sysname> display bgp peer ipv4 unicast

BGP local router ID: 12.1.1.1

Local AS number: 10

Total number of peers: 1 Peers in established state: 1

* - Dynamically created peer

Peer AS MsgRcvd MsgSent OutQ PrefRcv Up/Down State

12.1.1.2 20 3 3 0 0 00:00:25 Established

b. 执行display bgp peer命令，根据显示信息中的“AS”字段，判断是否为BGP对等体/对等体组指定了错误的AS号。如果AS号配置错误，则执行peer as-number命令为BGP对等体/对等体组指定正确的AS号。例如：

<Sysname> display bgp peer ipv4 unicast

BGP local router ID: 12.1.1.1

Local AS number: 10

Total number of peers: 1 Peers in established state: 1

* - Dynamically created peer

Peer AS MsgRcvd MsgSent OutQ PrefRcv Up/Down State

12.1.1.2 20 3 3 0 0 00:00:25 Established

c. 如果故障仍不能排除，请执行步骤（4）。

(4) 在BGP实例视图下执行display this命令，检查是否存在影响BGP会话的配置。

表6-1 影响BGP会话的配置检查项

检查项	描述
peer { group-name \| ipv4-address [ mask-length ] \| ipv6-address [ prefix-length ] } connect-interface interface-type interface-number	本端存在该配置时，BGP邻居也需要使用Loopback接口的地址建立BGP会话，可通过本命令或peer source-address命令配置
peer ipv4-address [ mask-length ] source-address source-ipv4-address peer ipv6-address [ prefix-length ] source-address source-ipv6-address	本端存在该配置时，BGP邻居也需要使用Loopback接口的地址建立BGP会话，可通过本命令或peer connect-interface命令配置
peer { group-name \| ipv4-address [ mask-length ] \| ipv6-address [ prefix-length ] } ebgp-max-hop [ hop-count ]	非直连网络上的邻居建立EBGP会话，或者直连网络设备使用Loopback接口建立EBGP会话时，BGP会话两端均需要配置本命令，为EBGP会话指定相应的最大跳数
peer { group-name \| ipv4-address [ mask-length ] \| ipv6-address [ prefix-length ] } ttl-security hops hop-count	存在该配置时，本地路由器从指定对等体收到的BGP报文中，TTL需要在255-“hop-count”+1到255之间，否则BGP报文将会被丢弃，如果本地路由器与对等体之间的跳数超过了hop-count，请通过本命令进行配置修改
peer { group-name \| ipv4-address [ mask-length ] \| ipv6-address [ prefix-length ] \| link-local-address interface interface-type interface-number } route-limit prefix-number [ reconnect reconnect-time \| percentage-value ] *	存在该配置时，表示如果本地路由器从指定对等体/对等体组接收的路由数量大于prefix-number值，路由器会自动断开与指定对等体/对等体组的会话。可通过降低对等体/对等体组发送的路由数量，或配置更大的prefix-number值，来避免BGP会话断开
peer { group-name \| ipv4-address [ mask-length ] \| ipv6-address [ prefix-length ] \| link-local-address interface interface-type interface-number } ignore [ graceful graceful-time { community { community-number \| aa:nn } \| local-preference preference \| med med } * ]	存在该配置时，BGP将不会与指定的对等体/对等体组建立BGP会话，此时可以通过执行undo peer ignore命令允许建立与对等体/对等体组的会话
ignore all-peers [ graceful graceful-time { community { community-number \| aa:nn } \| local-preference preference \| med med } * ]	存在该配置时，表明BGP禁止与所有对等体建立BGP会话。此时设备可能处于网络升级维护中，BGP进程暂时不可用，建议在网络升级维护完成后，执行undo peer ignore命令或undo ignore all-peers命令允许建立BGP会话
shutdown process	存在该配置时，表明BGP禁止与所有对等体建立BGP会话。此时设备可能处于网络升级维护中，BGP进程暂时不可用，建议在网络升级维护完成后，执行undo shutdown process命令允许建立BGP会话
地址族下的peer enable命令	建立BGP会话时，两端需要在同一个地址族下指定对端配置peer enable命令使能路由信息交互能力。存在该配置时，请检查对端是否也在相同地址族下配置了peer enable命令

如果故障仍不能排除，请执行步骤（5）。

(5) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息、告警信息。

5. 告警与日志

6.1.2 BGP会话Down

1. 故障描述

在设备上观察到BGP/5/BGP_STATE_CHANGED提示BGP会话状态变为Idle的日志打印信息，会话状态从Established变为Idle。

2. 常见原因

本类故障的常见原因主要包括：

· Keepalive或Update消息收发超时。

· TCP连接建立失败。

· 设备达到内存门限。

· BGP报文解析发生错误。

3. 故障分析

本类故障的诊断流程如图6-2所示。

图6-2 BGP会话Down的故障诊断流程图

4. 处理步骤

执行display bgp peer log-info命令，根据该命令的显示信息进一步确认BGP会话Down的原因。几种常见的BGP会话Down的原因如下：

· BGP定时器超时导致断开会话

如果log-info信息与下面的显示信息相似：

<Sysname> display bgp peer ipv4 3.3.3.3 log-info

Peer: 3.3.3.3

Date Time State Notification

Error/SubError

17-Jan-2022 14:48:34 Down Receive notification with error 4/0

Hold Timer Expired/ErrSubCode Unspecified

Keepalive last triggered time: 14:48:31-2022.1.17

Keepalive last sent time : 14:48:31-2022.1.17

Update last sent time : 14:48:24-2022.1.17

EPOLLOUT last occurred time : 14:48:30-2022.1.17

则表示BGP会话Down的原因是在会话保持时间内未能收到对等体发送的Keepalive或Update消息。在BGP会话保持定时器超时后，设备则会主动断开BGP会话，并向对端对等体发送Notification消息。

定时器超时的原因可能是设备正常发送了Keepalive或Update消息，但报文由于链路故障等原因无法到达对等体或对等体处理不及时，或者设备调度故障导致未能及时产生Keepalive或Update消息等。如需解决此问题，请在BGP会话的两端设备的Probe视图下，均执行display system internal bgp log命令，并收集该命令的显示信息，联系技术支持人员进行进一步分析。

· TCP连接错误导致BGP会话断开

如果log-info信息与下面的显示信息相似：

<Sysname> display bgp peer ipv4 1.1.1.1 log-info

Peer: 1.1.1.1

Date Time State Notification

Error/SubError

17-Jan-2022 14:42:01 Down Receive TCP_Connection_Failed event

则BGP会话Down的原因是TCP连接错误。BGP使用TCP作为其传输层协议，如果BGP会话两端设备间的TCP连接发生错误，BGP会话也会断开。如果用户观察到的显示信息与上述举例不相似，但是显示信息中包含了Notification消息错误码5/0，则也是由于TCP连接错误导致的BGP会话断开。

确认TCP连接发生错误后，请在BGP会话Down的两端设备的Probe视图中，均执行view /proc/tcp/tcp_log slot x命令（所有的单板/成员设备各执行一次），并收集该命令的显示信息，联系技术支持人员进行进一步分析。

· 内存不足导致BGP会话断开

如果log-info信息与下面的显示信息相似：

<Sysname> display bgp peer ipv4 1.1.1.1 log-info

Peer: 1.1.1.1

Date Time State Notification

Error/SubError

17-Jan-2022 15:38:53 Down Send notification with error 6/8

Entered severe memory state

17-Jan-2022 14:53:51 Down Send notification with error 6/8

No memory to process the attribute

表明设备没有足够内存处理BGP模块相关功能，导致BGP会话断开。此类错误原因对应log-info信息中的错误码6/8。

此时请在BGP会话Down的两端设备上，均执行display memory-threshold命令，获取内存告警门限相关信息，并记录display bgp peer log-info命令的显示信息，联系技术支持人员进行进一步分析。

· 报文解析错误导致BGP会话断开：

BGP会话两端的设备如果报文解析能力不同或版本不匹配，则BGP可能无法解析接收到的报文，导致BGP会话断开。此类错误原因对应log-info信息中的消息差错码1、2和3（即“Error/SubError”中的“Error”为1、2或3）。

请在BGP会话Down的两端设备上，均执行debugging bgp raw-packet、debugging bgp open以及debugging bgp update命令，并收集这些命令的显示信息以及display bgp peer log-info命令的显示信息，联系技术支持人员进行进一步分析。

· 如果display bgp peer log-info命令的显示信息中，提示的BGP会话Down的原因不属于以上任何一种常见的原因，请收集如下信息，并联系技术支持人员。

¡ display bgp peer log-info命令的显示信息。

¡ display system internal bgp log命令的显示信息。

¡ view /proc/tcp/tcp_log slot x命令的显示信息（所有的单板/成员设备各执行一次）。

¡ 设备的配置文件、日志信息、告警信息。

作为参考，BGP会话断开的详细原因及其对应的错误码如表6-2所示。

表6-2 邻居断开的详细原因列表

差错码/差错子码	会话断开的详细原因	说明
1/1	connection not synchronized	连接不同步，目前实现为收到的报文的报文头前16字节不全为F
1/2	bad message length	报文长度无效
1/3	bad message type	报文的类型无效
3/1	the withdrawn length is too large	撤销信息长度过长
	the attribute length is too large	属性长度过长
	one attribute appears more than once	同一个属性在一个Update消息中出现了多次
	the attribute length is too small	属性长度字段不足2字节
	exntended length field is less than two octets	属性长度为可扩展长度，但长度字段不足2字节
	the length field is less than one octet	属性长度为正常长度，但长度字段不足1字节
	link-state attribute error	链路状态属性形式错误
3/2	unrecognized well-known attribute	不支持的公认属性
3/3	attribute-type attribute missed	attribute-type类型的属性丢失，attribute-type取值包括： · ORIGIN · AS_PATH · LOCAL_PREF · NEXT_HOP
3/4	attribute flags error	属性标记错误
3/5	attribute-type attribute length error	attribute-type类型的属性长度错误，attribute-type取值包括： · AS_PATH · AS4_PATH · CLUSTER_LIST · AGGREGATOR · AS4_AGGREGATOR · ORIGIN · NEXT_HOP · MED · LOCAL_PREF · ATOMIC_AGGREGATE · ORIGINATOR_ID · MP_REACH_NLRI · COMMUNITIES · extended communities
3/5	attribute length exceeds	属性长度越界
3/6	invalid ORIGIN attribute	ORIGIN属性无效
3/8	invalid NEXT_HOP attribute	下一跳属性无效
3/9	invalid nexthop length in MP_REACH_NLRI (address-family)	address-family地址族MP_REACH_NLRI属性的Nexthop长度错误，address-family的取值包括： · 4u：表示IPv4单播地址族 · IPv4 Flowspec：表示IPv4 Flowspec地址族 · MPLS：表示MPLS地址族 · VPNv4：表示VPNv4地址族 · 6u：表示IPv6单播地址族 · VPNv6：表示VPNv6地址族 · L2VPN：表示L2VPN地址族
	the length of MP_UNREACH_NLRI is too small	MP_UNREACH_NLRI的长度小于3字节
	the MP NLRI attribute length exceeds	MP_REACH_NLRI 或MP_UNREACH_NLRI属性长度越界
	erroneous MP NLRI attribute end position	可达或不可达前缀结束位置与报文属性结束位置不同
3/10	invalid network field	网络字段无效
3/11	malformed AS_PATH	AS路径形式不对
4/0	Keepalive last triggered time	最后一次触发发送Keepalive消息时间
	Keepalive last sent time	最后一次发送Keepalive消息时间
	Update last sent time	最后一次发送Update消息时间
	EPOLLOUT last occurred time	最后一次发生EPOLLOUT时间
	Keepalive last received time	最后一次接收Keepalive消息时间
	Update last received time	最后一次接收Update消息时间
	EPOLLIN last occurred time	最后一次发生EPOLLIN时间
5/0	connection retry timer expires	ConnectRetry定时器超时
	TCP_CR_Acked event received	收到了TCP_CR_Acked事件
	TCP_Connection_Confirmed event received	收到了TCP_Connection_Confirmed事件
5/3	open message received	收到open消息
6/0	manualstop event received	收到manualstop事件
	physical interface configuration changed	物理配置改变，比如接口变化
	session down event received from BFD	收到BFD会话down事件
6/1	maximum number of prefixes reached	前缀数超过peer route-limit所配置的数目
6/1	maximum number of address-family prefixes reached	address-family地址族的前缀数超过peer route-limit所配置的数目，address-family的取值包括： · IPv4 unicast：表示IPv4单播地址族 · IPv6 unicast：表示IPv6单播地址族 · VPNv4：表示VPNv4地址族 · VPNv6：表示VPNv6地址族
6/2	configuration of peer ignore changed	配置peer ignore命令
6/3	address family deleted	地址族被删除
6/3	peer disabled	关闭对等体
6/4	administrative reset	执行reset bgp命令或者配置改变导致BGP会话重启
6/5	connection rejected	连接被拒绝
6/6	other configuration change	其他配置变化
6/7	connection collision resolution	连接冲突
6/7	two connections exist and MD5 authentication is configured for the neighbor	存在两个连接，且其中一个配置了MD5认证
6/8	· no memory to process the attribute：解析属性时内存不够 · no memory for the route：生成路由或者标签块信息时，获取不到内存 · no memory to generate unreachable NLRI：封装unreachable NLRI时申请不到内存 · no memory to generate a message：封装报文时申请不到内存 · can’t get the VPN RD：解析前缀时获取不到RD · can’t get the VPN routing table：解析前缀时获取不到VPN路由表 · can’t get the attributes：解析前缀时获取不到属性 · entered severe memory state：进入二级门限告警 · entered critical memory state：进入三级门限告警

5. 告警与日志

6.1.3 跨AS域的数据中心互联场景BGP路由环路

1. 故障描述

在图6-3所示的网络中，两个数据中心通过BGP协议跨AS进行互联。RR 1从数据中心2内的Border 3和Border 4处学习到前缀相同的BGP路由（假设路由前缀为10.110.0.0/16），路由的下一跳分别为Border 3和Border 4的Loopback接口地址，RR 1优选了来自Border 3或Border 4的路由。Border 1和Border 2通过BGP协议向RR 1发送缺省路由，缺省路由的下一跳分别为RR 1与Border 1之间的直连IP地址、RR 1与Border 2之间的直连IP地址。Border 3或Border 4重启时，在重启期间，数据中心1内的设备无法访问10.110.0.0/16网段，目的地址属于该网段内的数据报文在RR 1与Border 1之间或RR 1与Border 2之间循环发送，形成环路。

图6-3 跨AS域的数据中心互联场景组网图

2. 常见原因

在Border 3或Border 4未重启前，RR 1的BGP路由表和IP路由表与下表类似：

<RR1> display bgp routing-table ipv4

Total number of routes: 4

BGP local router ID is 9.9.9.9

Status codes: * - valid, > - best, d - dampened, h - history,

s - suppressed, S - stale, i - internal, e - external

a - additional-path

Origin: i - IGP, e - EGP, ? - incomplete

Network NextHop MED LocPrf PrefVal Path/Ogn

* >i 0.0.0.0/0 19.1.1.1 100 0 i

* i 29.1.1.2 100 0 i

* >e 10.110.0.0/16 3.3.3.3 0 0 20i

* e 4.4.4.4 0 0 20i

<RR1> display ip routing-table

Destinations : 25 Routes : 25

Destination/Mask Proto Pre Cost NextHop Interface

0.0.0.0/0 BGP 255 0 19.1.1.1 GE2/0/1

0.0.0.0/32 Direct 0 0 127.0.0.1 InLoop0

1.1.1.1/32 O_INTRA 10 1 19.1.1.1 GE2/0/1

2.2.2.2/32 O_INTRA 10 1 29.1.1.2 GE2/0/2

3.3.3.3/32 O_INTRA 10 1 39.1.1.3 GE2/0/3

4.4.4.4/32 O_INTRA 10 1 49.1.1.4 GE2/0/4

9.9.9.9/32 Direct 0 0 127.0.0.1 InLoop0

10.10.10.10/32 BGP 255 0 1.1.1.1 GE2/0/1

19.1.1.0/24 Direct 0 0 19.1.1.9 GE2/0/1

19.1.1.0/32 Direct 0 0 19.1.1.9 GE2/0/1

19.1.1.9/32 Direct 0 0 127.0.0.1 InLoop0

19.1.1.255/32 Direct 0 0 19.1.1.9 GE2/0/1

10.110.0.0/16 BGP 255 0 3.3.3.3 GE2/0/3

29.1.1.0/24 Direct 0 0 29.1.1.9 GE2/0/2

29.1.1.0/32 Direct 0 0 29.1.1.9 GE2/0/2

29.1.1.9/32 Direct 0 0 127.0.0.1 InLoop0

29.1.1.255/32 Direct 0 0 29.1.1.9 GE2/0/2

39.1.1.0/24 Direct 0 0 39.1.1.9 GE2/0/3

39.1.1.0/32 Direct 0 0 39.1.1.9 GE2/0/3

39.1.1.9/32 Direct 0 0 127.0.0.1 InLoop0

39.1.1.255/32 Direct 0 0 39.1.1.9 GE2/0/3

49.1.1.0/24 Direct 0 0 29.1.1.9 GE2/0/2

49.1.1.0/32 Direct 0 0 29.1.1.9 GE2/0/2

49.1.1.9/32 Direct 0 0 127.0.0.1 InLoop0

49.1.1.255/32 Direct 0 0 29.1.1.9 GE2/0/2

127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0

127.0.0.0/32 Direct 0 0 127.0.0.1 InLoop0

127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0

127.255.255.255/32 Direct 0 0 127.0.0.1 InLoop0

255.255.255.255/32 Direct 0 0 127.0.0.1 InLoop0

在上表中，RR 1通过IGP协议学习到Border 3和Border 4的Loopback接口路由。BGP网段路由10.110.0.0/16迭代到通过IGP学习的Border 3和Border 4的Loopback接口路由上。

假设Border 4进行了设备重启，在Border 4重启后，会话保持时间内RR 1仍不会断开与Border 4的会话，RR 1的路由表中仍会保留从Border 4接收到的10.110.0.0/16网段路由。但是由于下一跳4.4.4.4的IGP路由已经失效，且RR 1上不存在包含地址4.4.4.4的其他网段路由，来自Border 4的10.110.0.0/16网段路由只能迭代到缺省路由0.0.0.0/0上。

此时RR 1的BGP路由表中，来自Border 3的10.110.0.0/16网段路由到达下一跳的IGP路由的Metric值为1（对应上表中的路由表项“3.3.3.3/32 O_INTRA 10 1 39.1.1.3 GE2/0/3”），而来自Border 4的10.110.0.0/16网段路由到达下一跳的IGP路由的Metric值为0（对应上表中的路由表项“0.0.0.0/0 BGP 255 0 19.1.1.1 GE2/0/1”）。按照BGP路由的优选规则，RR 1优选来自Border 4的10.110.0.0/16网段路由，在路由转发表中，网段10.110.0.0/16的下一跳变为GigabitEthernet2/0/1。在转发目的地址属于10.110.0.0/16网段的报文时，RR 1会把报文错误地发送给Border 1，并且由于Border 1上10.110.0.0/16网段的路由学习自RR 1，Border 1又会把报文转发回RR 1，如此往复造成环路。

3. 故障分析

本类故障的诊断流程如图6-4所示。

图6-4 跨AS域的数据中心互联场景BGP路由环路的故障诊断流程图

4. 处理步骤

(1) 查看RR 1的BGP路由表和IP路由表。本步骤以图6-3的组网为例，来说明RR 1上的BGP路由表和IP路由表情况。

a. Border 4重启后，在RR 1与Border 4的会话断开前，在RR 1上执行display bgp routing-table ipv4命令可以看到来自Border 4的10.110.0.0/16网段路由仍然生效，并且被优选了。

<RR1> display bgp routing-table ipv4

Total number of routes: 5

BGP local router ID is 9.9.9.9

Status codes: * - valid, > - best, d - dampened, h - history,

s - suppressed, S - stale, i - internal, e - external

a - additional-path

Origin: i - IGP, e - EGP, ? - incomplete

Network NextHop MED LocPrf PrefVal Path/Ogn

* >i 0.0.0.0/0 19.1.1.1 100 0 i

* i 29.1.1.2 100 0 i

* >e 10.110.0.0/16 4.4.4.4 0 0 20i

* e 3.3.3.3 0 0 20i

b. 在RR 1上执行display ip routing-table verbose命令，可以看到10.110.0.0/16网段路由的出接口和真实下一跳变为了RR 1与Border 1之间的直连接口GigabitEthernet2/0/1以及直连IP地址19.1.1.1。

<RR1> display ip routing-table 10.110.0.0/16 verbose

Summary count : 1

Destination: 10.110.0.0/16

Protocol: BGP instance default

Process ID: 0

SubProtID: 0x6 Age: 00h00m19s

FlushedAge: 00h00m19s

Cost: 0 Preference: 255

IpPre: N/A QosLocalID: N/A

Tag: 0 State: Active Adv

OrigTblID: 0x0 OrigVrf: default-vrf

TableID: 0x2 OrigAs: 20

NibID: 0x16000002 LastAs: 20

AttrID: 0x2

BkAttrID: 0xffffffff Neighbor: 4.4.4.4

Flags: 0x10060 OrigNextHop: 4.4.4.4

Label: NULL RealNextHop: 19.1.1.1

BkLabel: NULL BkNextHop: N/A

SRLabel: NULL Interface: GigabitEthernet2/0/1

BkSRLabel: NULL BkInterface: N/A

Tunnel ID: Invalid IPInterface: GigabitEthernet2/0/1

BkTunnel ID: Invalid BkIPInterface: N/A

InLabel: NULL ColorInterface: N/A

SIDIndex: NULL BkColorInterface: N/A

FtnIndex: 0x0 TunnelInterface: N/A

TrafficIndex: N/A BkTunnelInterface: N/A

Connector: N/A PathID: 0x0

UserID: 0x0 SRTunnelID: Invalid

SID Type: N/A NID: Invalid

FlushNID: Invalid BkNID: Invalid

BkFlushNID: Invalid StatFlags: 0x0

SID: N/A

BkSID: N/A

CommBlockLen: 0 Priority: Low

MemberPort: N/A

c. 执行display ip routing-table命令，可以看到IP路由表中没有包含地址4.4.4.4的其他网段路由，缺省路由的下一跳出接口和下一跳IP也为GigabitEthernet2/0/1和19.1.1.1，由此可以判断出，来自Border 4的10.110.0.0/16网段路由迭代到了缺省路由上。

<RR1> display ip routing-table

Destinations : 25 Routes : 25

Destination/Mask Proto Pre Cost NextHop Interface

0.0.0.0/0 BGP 255 0 19.1.1.1 GE2/0/1

0.0.0.0/32 Direct 0 0 127.0.0.1 InLoop0

1.1.1.1/32 O_INTRA 10 1 19.1.1.1 GE2/0/1

2.2.2.2/32 O_INTRA 10 1 29.1.1.2 GE2/0/2

3.3.3.3/32 O_INTRA 10 1 39.1.1.3 GE2/0/3

9.9.9.9/32 Direct 0 0 127.0.0.1 InLoop0

10.10.10.10/32 BGP 255 0 1.1.1.1 GE2/0/1

19.1.1.0/24 Direct 0 0 19.1.1.9 GE2/0/1

19.1.1.0/32 Direct 0 0 19.1.1.9 GE2/0/1

19.1.1.9/32 Direct 0 0 127.0.0.1 InLoop0

19.1.1.255/32 Direct 0 0 19.1.1.9 GE2/0/1

10.110.0.0/16 BGP 255 0 4.4.4.4 GE2/0/1

29.1.1.0/24 Direct 0 0 29.1.1.9 GE2/0/2

29.1.1.0/32 Direct 0 0 29.1.1.9 GE2/0/2

29.1.1.9/32 Direct 0 0 127.0.0.1 InLoop0

29.1.1.255/32 Direct 0 0 29.1.1.9 GE2/0/2

39.1.1.0/24 Direct 0 0 39.1.1.9 GE2/0/3

39.1.1.0/32 Direct 0 0 39.1.1.9 GE2/0/3

39.1.1.9/32 Direct 0 0 127.0.0.1 InLoop0

39.1.1.255/32 Direct 0 0 39.1.1.9 GE2/0/3

49.1.1.0/24 Direct 0 0 29.1.1.9 GE2/0/2

49.1.1.0/32 Direct 0 0 29.1.1.9 GE2/0/2

49.1.1.9/32 Direct 0 0 127.0.0.1 InLoop0

49.1.1.255/32 Direct 0 0 29.1.1.9 GE2/0/2

127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0

127.0.0.0/32 Direct 0 0 127.0.0.1 InLoop0

127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0

127.255.255.255/32 Direct 0 0 127.0.0.1 InLoop0

255.255.255.255/32 Direct 0 0 127.0.0.1 InLoop0

如果查看路由表项的结果与上述情形不符，请联系技术支持人员获得帮助。

(2) 通过以下两种方式中的一种消除路由环路。

¡ 配置根据路由策略来过滤迭代到的下一跳路由。

在RIB IPv4地址族视图下配置protocol bgp nexthop recursive-lookup route-policy route-policy-name命令后，所有IPv4地址前缀的BGP路由的下一跳都只能迭代到通过路由策略route-policy-name过滤的路由上；在RIB IPv6地址族视图下配置protocol bgp4+ nexthop recursive-lookup route-policy route-policy-name命令后，所有IPv6地址前缀的BGP路由的下一跳都只能迭代到通过路由策略route-policy-name过滤的路由上。

在本故障诊断的场景下，可以在RR 1上创建一个缺省路由无法通过过滤的路由策略，并配置protocol bgp nexthop recursive-lookup route-policy route-policy-name或protocol bgp nexthop recursive-lookup route-policy route-policy-name命令指定该路由策略，使得BGP路由无法迭代到缺省路由上，从而消除BGP路由环路。

¡ 配置BGP与BFD联动功能。

开启BGP与BFD联动功能后，RR 1和Border 3、Border 4之间会使用BFD会话来检测链路，当Border 3或Border 4重启时，BFD可以快速检测到链路故障，RR 1会及时断开BGP会话，删除失效路由，即从Border 3或Border 4学习到的路由。BGP与BFD联动功能通过peer bfd命令进行配置，配置的详细指导以及注意事项请参见命令参考手册。

(3) 如果故障仍未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息、告警信息。

5. 告警与日志

6.1.4 Spine和Leaf设备跨AS连接场景BGP路由环路

1. 故障描述

在图6-5所示的网络中，Spine设备与Leaf设备处在不同的AS域中。Spine设备之间建立全互联的BGP连接，Spine 1和Spine 2与Leaf建立EBGP连接。Spine 2开启了负载分担功能，并且可以在EBGP和IBGP路由之间进行负载分担。Spine 1重启时，经过Spine 2到Leaf的流量有一半丢失。

图6-5 Spine和Leaf设备跨AS连接场景组网图

2. 常见原因

在Spine 1重启前，Spine 2的BGP路由表与下表类似：

<Spine2> display bgp routing-table ipv4

Total number of routes: 3

BGP local router ID is 2.2.2.2

Status codes: * - valid, > - best, d - dampened, h - history,

s - suppressed, S - stale, i - internal, e - external

a - additional-path

Origin: i - IGP, e - EGP, ? - incomplete

Network NextHop MED LocPrf PrefVal Path/Ogn

* >i 0.0.0.0/0 24.1.1.4 100 0 i

* >e 100.1.1.0/24 23.1.1.3 0 0 20i

* i 1.1.1.1 0 100 0 20i

Leaf 2分别从Leaf 1（23.1.1.3）和Spine 1（1.1.1.1）接收到100.1.1.0/24网段路由，从Spine 1接收到的100.1.1.0/24网段路由的下一跳为Spine 1的Loopback接口地址。

Spine 2的IP路由表与下表类似：

<Spine2> display ip routing-table

Destinations : 24 Routes : 25

Destination/Mask Proto Pre Cost NextHop Interface

0.0.0.0/0 BGP 255 0 24.1.1.4 GE2/0/1

0.0.0.0/32 Direct 0 0 127.0.0.1 InLoop0

1.1.1.1/32 O_INTRA 10 1 12.1.1.1 GE2/0/2

2.2.2.2/32 Direct 0 0 127.0.0.1 InLoop0

4.4.4.4/32 O_INTRA 10 1 24.1.1.4 GE2/0/1

12.1.1.0/24 Direct 0 0 12.1.1.2 GE2/0/2

12.1.1.0/32 Direct 0 0 12.1.1.2 GE2/0/2

12.1.1.2/32 Direct 0 0 127.0.0.1 InLoop0

12.1.1.255/32 Direct 0 0 12.1.1.2 GE2/0/2

14.1.1.0/24 O_INTRA 10 2 12.1.1.1 GE2/0/2

O_INTRA 10 2 24.1.1.4 GE2/0/1

23.1.1.0/24 Direct 0 0 23.1.1.2 GE2/0/3

23.1.1.0/32 Direct 0 0 23.1.1.2 GE2/0/3

23.1.1.2/32 Direct 0 0 127.0.0.1 InLoop0

23.1.1.255/32 Direct 0 0 23.1.1.2 GE2/0/3

24.1.1.0/24 Direct 0 0 24.1.1.2 GE2/0/1

24.1.1.0/32 Direct 0 0 24.1.1.2 GE2/0/1

24.1.1.2/32 Direct 0 0 127.0.0.1 InLoop0

24.1.1.255/32 Direct 0 0 24.1.1.2 GE2/0/1

100.1.1.0/24 BGP 255 0 23.1.1.3 GE2/0/3

127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0

127.0.0.0/32 Direct 0 0 127.0.0.1 InLoop0

127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0

127.255.255.255/32 Direct 0 0 127.0.0.1 InLoop0

255.255.255.255/32 Direct 0 0 127.0.0.1 InLoop0

对于来自Leaf的100.1.1.0/24网段路由，到达其下一跳的IGP路由为23.1.1.0/24，该IGP路由的Metric为0；对于来自Spine 1的100.1.1.0/24网段路由，到达其下一跳的IGP路由为1.1.1.1/32该IGP路由的Metric值为1。由于到达两条路由的下一跳的IGP路由的Metric值不相同，BGP路由表中两条100.1.1.0/24网段路由无法形成负载分担。这也是网络管理员需要的结果：到达Spine 2的目的地址属于100.1.1.0/24网段的流量，会被Spine 2全部直接转发给Leaf；而不是先发往Spine 1，再由Spine 1转发至Leaf。

Spine 3通过BGP协议向Spine 2发送了缺省路由，缺省路由的下一跳为Spine 3与Spine 2直连的接口IP地址。Spine 1重启后，在会话保持时间内，Spine 2仍不会断开与Spine 1的会话，Spine 2的路由表中仍会保留从Spine 1接收到的100.1.1.0/24网段路由。但是由于下一跳1.1.1.1的IGP路由已经失效，且Spine 2上不存在包含地址1.1.1.1的其他网段路由，来自Spine 1的100.1.1.0/24网段路由只能迭代到缺省路由0.0.0.0/0上。

此时Spine 2的BGP路由表中，来自Spine 1的100.1.1.0/24网段路由到达下一跳的IGP路由的Metric值变为0（对应上表中的路由表项“0.0.0.0/0 BGP 255 0 24.1.1.4 GE2/0/1”），与来自Leaf的100.1.1.0/24网段路由到达下一跳的IGP路由的Metric值相同。来自不同BGP对等体的两条100.1.1.0/24网段路由形成负载分担，导致经过Spine 2的目的地址属于100.1.1.0/24网段的流量有一半通过负载分担被发送给了Spine 3。而由于Spine 3上100.1.1.0/24的网段路由学习自Spine 1和Spine 2，Spine 3又会把流量转发回Spine 2，造成环路和路由丢失。

3. 故障分析

本类故障的诊断流程如图6-6所示。

图6-6 Spine和Leaf设备跨AS连接场景BGP路由环路的诊断流程图

4. 处理步骤

(1) 查看Spine 2的BGP路由表和IP路由表。本步骤以图6-5的组网为例，来说明Spine 2上的BGP路由表和IP路由表情况。

a. Spnie 1重启后，在Spnie 1与Spnie 2的会话断开前，在Spnie 2上执行display bgp routing-table ipv4命令可以看到来自不同设备的两条100.1.1.0/24网段路由同时被优选。

<Spine2> display bgp routing-table ipv4

Total number of routes: 3

BGP local router ID is 2.2.2.2

Status codes: * - valid, > - best, d - dampened, h - history,

s - suppressed, S - stale, i - internal, e - external

a - additional-path

Origin: i - IGP, e - EGP, ? - incomplete

Network NextHop MED LocPrf PrefVal Path/Ogn

* >i 0.0.0.0/0 24.1.1.4 100 0 i

* >e 100.1.1.0/24 23.1.1.3 0 0 20i

* >i 1.1.1.1 0 100 0 20i

b. 在Spine 2上执行display ip routing-table verbose命令，可以看到100.1.1.0/24网段的两条路由形成了等价，并且其中一条路由的真实下一跳为Spine 3的接口IP地址24.1.1.4、出接口为Spine 2与Spine 3直连的接口。

<Spine2> display ip routing-table 100.1.1.0/24 verbose

Summary count : 2

Destination: 100.1.1.0/24

Protocol: BGP instance default

Process ID: 0

SubProtID: 0x5 Age: 00h00m13s

FlushedAge: 00h00m13s

Cost: 0 Preference: 255

IpPre: N/A QosLocalID: N/A

Tag: 0 State: Active Adv

OrigTblID: 0x0 OrigVrf: default-vrf

TableID: 0x2 OrigAs: 20

NibID: 0x16000002 LastAs: 10

AttrID: 0x2

BkAttrID: 0xffffffff Neighbor: 1.1.1.1

Flags: 0x10060 OrigNextHop: 1.1.1.1

Label: NULL RealNextHop: 24.1.1.4

BkLabel: NULL BkNextHop: N/A

SRLabel: NULL Interface: GigabitEthernet2/0/1

BkSRLabel: NULL BkInterface: N/A

Tunnel ID: Invalid IPInterface: GigabitEthernet2/0/1

BkTunnel ID: Invalid BkIPInterface: N/A

InLabel: NULL ColorInterface: N/A

SIDIndex: NULL BkColorInterface: N/A

FtnIndex: 0x0 TunnelInterface: N/A

TrafficIndex: N/A BkTunnelInterface: N/A

Connector: N/A PathID: 0x0

UserID: 0x0 SRTunnelID: Invalid

SID Type: N/A NID: Invalid

FlushNID: Invalid BkNID: Invalid

BkFlushNID: Invalid StatFlags: 0x0

SID: N/A

BkSID: N/A

CommBlockLen: 0 Priority: Low

MemberPort: N/A

Destination: 100.1.1.0/24

Protocol: BGP instance default

Process ID: 0

SubProtID: 0x6 Age: 01h18m22s

FlushedAge: 00h00m13s

Cost: 0 Preference: 255

IpPre: N/A QosLocalID: N/A

Tag: 0 State: Active Adv

OrigTblID: 0x0 OrigVrf: default-vrf

TableID: 0x2 OrigAs: 20

NibID: 0x16000000 LastAs: 20

AttrID: 0x0

BkAttrID: 0xffffffff Neighbor: 23.1.1.3

Flags: 0x10060 OrigNextHop: 23.1.1.3

Label: NULL RealNextHop: 23.1.1.3

BkLabel: NULL BkNextHop: N/A

SRLabel: NULL Interface: GigabitEthernet2/0/3

BkSRLabel: NULL BkInterface: N/A

Tunnel ID: Invalid IPInterface: GigabitEthernet2/0/3

BkTunnel ID: Invalid BkIPInterface: N/A

InLabel: NULL ColorInterface: N/A

SIDIndex: NULL BkColorInterface: N/A

FtnIndex: 0x0 TunnelInterface: N/A

TrafficIndex: N/A BkTunnelInterface: N/A

Connector: N/A PathID: 0x0

UserID: 0x0 SRTunnelID: Invalid

SID Type: N/A NID: Invalid

FlushNID: Invalid BkNID: Invalid

BkFlushNID: Invalid StatFlags: 0x0

SID: N/A

BkSID: N/A

CommBlockLen: 0 Priority: Low

MemberPort: N/A

c. 执行display ip routing-table命令，可以看到IP路由表中没有包含地址1.1.1.1的其他网段路由，缺省路由的下一跳出接口和下一跳IP也为GigabitEthernet2/0/1和24.1.1.4，由此可以判断出，来自Spine 1的100.1.1.0/24网段路由迭代到了缺省路由上。

<Spine2> display ip routing-table

Destinations : 23 Routes : 24

Destination/Mask Proto Pre Cost NextHop Interface

0.0.0.0/0 BGP 255 0 24.1.1.4 GE2/0/1

0.0.0.0/32 Direct 0 0 127.0.0.1 InLoop0

2.2.2.2/32 Direct 0 0 127.0.0.1 InLoop0

4.4.4.4/32 O_INTRA 10 1 24.1.1.4 GE2/0/1

12.1.1.0/24 Direct 0 0 12.1.1.2 GE2/0/2

12.1.1.0/32 Direct 0 0 12.1.1.2 GE2/0/2

12.1.1.2/32 Direct 0 0 127.0.0.1 InLoop0

12.1.1.255/32 Direct 0 0 12.1.1.2 GE2/0/2

14.1.1.0/24 O_INTRA 10 2 24.1.1.4 GE2/0/1

23.1.1.0/24 Direct 0 0 23.1.1.2 GE2/0/3

23.1.1.0/32 Direct 0 0 23.1.1.2 GE2/0/3

23.1.1.2/32 Direct 0 0 127.0.0.1 InLoop0

23.1.1.255/32 Direct 0 0 23.1.1.2 GE2/0/3

24.1.1.0/24 Direct 0 0 24.1.1.2 GE2/0/1

24.1.1.0/32 Direct 0 0 24.1.1.2 GE2/0/1

24.1.1.2/32 Direct 0 0 127.0.0.1 InLoop0

24.1.1.255/32 Direct 0 0 24.1.1.2 GE2/0/1

100.1.1.0/24 BGP 255 0 1.1.1.1 GE2/0/1

BGP 255 0 23.1.1.3 GE2/0/3

127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0

127.0.0.0/32 Direct 0 0 127.0.0.1 InLoop0

127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0

127.255.255.255/32 Direct 0 0 127.0.0.1 InLoop0

255.255.255.255/32 Direct 0 0 127.0.0.1 InLoop0

如果查看路由表项的结果与上述情形不符，请联系技术支持人员获得帮助。

(2) 通过以下三种方式中的一种来消除路由环路。

¡ 配置根据路由策略来过滤迭代到的下一跳路由。

在本故障诊断的场景下，可以在Spine 2上创建一个缺省路由无法通过过滤的路由策略，并配置protocol bgp nexthop recursive-lookup route-policy route-policy-name或protocol bgp nexthop recursive-lookup route-policy route-policy-name命令指定该路由策略，使得BGP路由无法迭代到缺省路由上，从而消除BGP路由环路。

¡ 配置BGP与BFD联动功能。

开启BGP与BFD联动功能后，Spine 1和Spine 2之间会使用BFD会话来检测链路，当Spine 1重启时，BFD可以快速检测到链路故障，Spine 2会及时断开BGP会话，删除失效路由，即从Spine 1学习到的路由。BGP与BFD联动功能通过peer bfd命令进行配置，配置的详细指导以及注意事项请参见命令参考手册。

¡ 配置BGP负载分担时，不允许设备在EBGP和IGBP路由之间进行负载分担。

本例中的两条100.1.1.0/24网段路由分别来自IBGP会话和EBGP会话，在BGP进程中配置balance命令时，只要不指定eibgp参数，设备就不会在EBGP和IBGP路由之间进行负载分担，Spine 2就能根据BGP的选路规则只优选来自Leaf的100.1.1.0/24网段路由，保证全部流量的正常转发。

(3) 如果故障仍未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息、告警信息。

5. 告警与日志

6.2 OSPF故障处理

6.2.1 OSPF邻居Down

1. 故障描述

· OSPF邻居Down

· OSPF邻居震荡

2. 常见原因

本类故障的常见原因主要包括：

· BFD会话Down，即BFD检测到链路故障。

· 对端设备故障。

· CPU利用率过高。

· 链路故障。

· OSPF接口没有Up。

· 两端IP地址不在同一网段。

· OSPF两端参数的配置不匹配：

¡ Router ID配置冲突。

¡ 两端区域类型配置不一致。

¡ 两端OSPF验证配置不匹配。

¡ 两端定时器参数配置不一致。

¡ OSPF接口的网络类型不匹配。

3. 故障分析

本类故障的诊断流程如图6-7所示。

图6-7 OSPF邻居Down的故障诊断流程图

4. 处理步骤

(1) 通过命令行或日志查看OSPF邻居状态变为Down的原因。

执行display ospf event-log peer命令，显示信息中的Reason字段为邻居状态发生变化的原因，一般包含如下几种情况：

¡ DeadExpired

表示在邻居失效定时器超时前没有收到Hello报文，导致OSPF邻居状态变为Down。出现这种情况请执行步骤(2)。

¡ BFDDown

表示BFD会话Down导致OSPF邻居状态变为Down。出现这种情况请执行步骤(2)。

¡ IntVliChange或virtual link was deleted or the route it relies on was deleted

表示虚连接删除或者其依赖的路由删除导致邻居关系变为Down。出现这种情况请执行步骤(2)。

¡ 1-Way

表示对端OSPF状态首先变成Down，然后向本端发送1-way Hello报文，导致本端OSPF状态变为Init。出现这种情况请排查对端设备的故障。

¡ IntPhyChange

接口Down或者接口MTU改变导致邻居关系变为Down。此时，执行display interface [ interface-type [ interface-number | interface-number.subnumber ] ]命令查看接口的运行状态和相关信息，排查接口故障。其他情况请执行步骤(11)。

(2) 检查链路是否故障。

请执行ping命令，检查链路是否故障。如果链路正常，请执行步骤(3)。

(3) 检查CPU利用率是否过高。

请执行display cpu-usage命令检查CPU利用率。如果设备的主控板和接口板的CPU利用率过高，会导致OSPF无法正常收发协议报文，继而导致邻居震荡。可通过关闭一些不必要的功能解决此问题。如果CPU利用率不高，则执行步骤(5)。

(4) 检查内存利用率是否超过了内存利用率阈值。

请执行display memory-threshold命令，查看显示信息中的Current free-memory state，即系统当前内存使用状态。如果Current free-memory state为Minor、Severe或Critical，表示剩余空闲内存较少，可能会导致设备无法收发OSPF报文或处理OSPF报文速度较慢，请关闭一些不必要的功能尝试解决此问题。如果系统当前内存使用状态为Normal，则执行步骤(5)。

(5) 检查接口状态是否为UP。

执行display interface [ interface-type [ interface-number | interface-number.subnumber ] ]命令查看OSPF接口物理层的状态是否为UP。

¡ 如果接口物理层的状态为DOWN，说明接口故障，请首先解决此问题。

¡ 如果接口物理层的状态为UP，请执行display ospf interface命令查看OSPF协议下接口的状态是否正常。

- 如果OSPF接口状态为Down，检查OSPF进程下是否通过network命令通告了接口所属网段。如果OSPF未通告接口所属网段，则检查接口下是否使能了OSPF。如果接口使能了OSPF进程，请处理网络层接口故障问题。

- 如果OSPF下的接口协议状态正常，即接口状态为DR、BDR、DROther或PTP时，请执行步骤(6)。

(6) 检查两端IP地址是否在同一网段。

请执行display interface brief命令查看两端接口的IP地址：

¡ 如果两端接口的IP地址不在同一网段，请在接口视图下执行ip address命令修改两端的IP地址，使其在同一网段。

¡ 如果两端接口的IP地址处于同一网段，请执行步骤(7)。

(7) 检查各OSPF接口的MTU是否一致。

如果在OSPF接口上通过ospf mtu-enable命令将该接口发送的DD报文中MTU域的值填充为接口的MTU值（缺省情况下接口发送的DD报文中MTU域的值为0），则要求各个OSPF接口发送的DD报文中MTU域的值一致。否则，OSPF邻居无法协商成功。请执行display interface [ interface-type [ interface-number | interface-number.subnumber ] ]命令查看接口MTU信息：

¡ 如果接口的MTU值配置不一致，请在接口视图下执行mtu size命令，将各个接口的MTU值修改为一致。

¡ 如果接口的MTU值一致，请执行步骤(8)。

(8) 检查各接口的DR优先级是否非零。

对于Broadcast和NBMA类型的网络，为了保证正确选举出DR，需要保证至少有一个OSPF接口的DR优先级是非零的，否则两边的邻居状态只能达到2-Way。请使用display ospf interface命令查看OSPF接口信息，其中的Pri表示接口的DR优先级。

如果接口的DR优先级非零，请执行步骤(9)。

(9) 是否手工为NBMA网络或P2MP单播网络指定了邻居。

OSPF网络类型为NBMA或P2MP（unicast）时，必须通过peer命令手工指定邻居的IP地址。请在OSPF接口视图下使用display this命令查看接口的网络类型，如果接口的网络类型为NBMA或P2MP（unicast），请在OSPF视图下使用peer命令手工指定邻居的IP地址。

如果手工为NBMA网络或P2MP单播网络指定了邻居的IP地址，请执行步骤(10)。

(10) 检查两端OSPF的参数配置是否有错误。

a. 请使用display ospf命令检查两端OSPF Router ID配置是否冲突。如果OSPF Router ID配置冲突，请修改配置保证OSPF Router ID不再冲突。如果OSPF Router ID配置不冲突，请继续执行以下检查。

b. 请使用display ospf interface命令检查两端OSPF Area ID配置是否一致。如果OSPF Area ID配置不一致，请修改配置保证OSPF Area ID配置一致。如果OSPF Area ID配置一致，请继续执行以下检查。

c. 请使用display ospf interface命令检查两端接口的OSPF网络类型是否一致。如果OSPF网络类型不一致，请修改配置保证OSPF网络类型一致。需要说明的是，如果双方一端为PTP，另一端为Broadcast，那么邻居关系可以达到Full状态，但无法计算出路由信息。

如果接口的OSPF网络类型一致，请继续执行以下检查。

d. 请每隔10秒钟使用display ospf statistics error命令检查一次OSPF的错误统计信息，并持续5分钟。需要查看的信息包括：

- 查看Bad authentication type字段。如果这个字段值持续增长，说明建立OSPF邻居关系的两台设备上配置了不同的认证类型，请修改认证类型的配置，使两台设备上的认证类型保持一致。

- 查看Hello-time mismatch字段。如果这个字段值持续增长，说明OSPF接口上配置的Hello定时器的值不同，请修改Hello定时器的配置，使OSPF接口的Hello定时器的值保持一致。

- 查看Dead-time mismatch字段。如果这个字段值持续增长，说明OSPF接口上配置的Dead定时器的值不同，请修改Dead定时器的配置，使OSPF接口的Dead定时器的值保持一致。

- 查看Ebit option mismatch字段。如果这个字段值持续增长，说明OSPF区域类型不一致（例如，一端的OSPF区域类型为普通区域，另一端的OSPF区域类型为Stub）。请修改OSPF区域配置，使两端的区域类型保持一致。

如果故障依然存在，请执行步骤(11)。

(11) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息、告警信息。

5. 告警与日志

6.2.2 OSPF邻居无法达到FULL状态

1. 故障描述

OSPF的状态机包括Down、Init、2-way、Exstart、Exchange、Loading和Full。其中，稳定状态包括Down、2-way和Full：

· Down：表示未使能OSPF。

· 2-way：DRother之间的邻居关系。

· Full：形成邻接关系。

对于使用OSPF进行路由计算和路由转发的网络中，只有2-way和Full是正常的邻居状态。如果邻居状态既未处于2-way状态、也未处于Full状态，说明邻居关系不正常。

2. 常见原因

本类故障的常见原因主要包括：

· 链路故障，OSPF报文被丢弃。

· 接口的DR优先级配置不合理。

· 两端配置的OSPF MTU值不同。

3. 故障分析

本类故障的诊断流程如图6-8所示：

图6-8 OSPF邻居无法达到FULL状态的故障诊断流程图

4. 处理步骤

(1) 使用display ospf peer命令查看OSPF邻居信息，并根据不同的邻居状态进行相应的处理。

¡ 没有邻居信息。

表示OSPF邻居Down或者邻居震荡，请参见“OSPF邻居Down”故障处理。

¡ 邻居状态一直为Init。

表示对端设备收不到本端发送的Hello报文，此时请排查链路和对端设备是否故障。

¡ 邻居状态一直为2-way。

执行命令display ospf interface verbose查看设备在OSPF接口的DR优先级是否为0：

- 如果OSPF接口的DR优先级为0，那么邻居状态为2-way属于正常情况。

- 如果OSPF接口的DR优先级不为0，请执行步骤(2)。

¡ 邻居状态一直是Exstart。

表示设备始终在进行DD协商，但无法完成DD同步。如下两种情况可能导致该问题：

- 接口无法正常收发超大报文。

可以通过多次执行命令ping -s packet-size neighbor-address查看超大报文收发情况，将packet-size设置为1500或更大数值。如果无法Ping通，请先解决链路问题。

- 两端OSPF MTU配置值不一致。

如果OSPF接口下配置了ospf mtu-enable命令，请检查两端的OSPF MTU值是否相等。如果不相等，则修改接口下的MTU值。

如果故障没有解决，请执行步骤(2)。

¡ 邻居状态一直是Exchange。

表示设备在进行DD交换，请参见邻居状态一直为Exstart状态的处理。

如果故障没有解决，请执行步骤(2)。

¡ 邻居状态一直是Loading。

如果使用display ospf peer命令查看邻居状态一直处于Loading，可以尝试执行reset ospf [ process-id ] process命令重启OSPF进程。

如果故障没有解决，请执行步骤(2)。

(2) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息、告警信息。

5. 告警与日志

6.2.3 设备学习不到部分OSPF路由

1. 故障描述

运行OSPF的设备学习不到部分OSPF路由。

2. 常见原因

本类故障的常见原因主要包括：

· 双方一端的网络类型为P2P，另一端的网络类型为Broadcast，邻居关系达到Full状态，但是学习不到路由。

· OSPF进程下配置了filter-policy import命令。

· 本OSPF区域下配置了filter import命令。

· 其他OSPF区域下配置了filter export命令。

· 绑定了VPN实例的OSPF进程，该进程引入外部路由的Tag值与AS External LSA（Type-5）或NSSA External LSA（Type-7）中的Tag值一致。

· ABR设备不可达。

· 在ABR设备上，非骨干区的Summary LSA不参与路由计算。

· ASBR设备不可达。

· AS External LSA（Type-5）或NSSA External LSA（Type-7）的FA地址不可达。

· NSSA External LSA（Type-7）到达FA地址的路由与NSSA External LSA（Type-7）不在同一区域。

3. 故障分析

本类故障的诊断流程如图6-9、图6-10所示。

图6-9 设备学习不到OSPF路由故障诊断流程图一

图6-10 设备学习不到OSPF路由故障诊断流程图二

4. 处理步骤

(1) 检查建立邻居关系的双方是否一端的网络类型为P2P，另一端的网络类型为Broadcast。

如果一端的网络类型为P2P，另一端的网络类型为Broadcast，那么邻居关系可以达到Full状态，但无法计算出路由信息。

a. 请执行display ospf interface命令查看接口的网络类型。

<Sysname> display ospf interface

OSPF Process 1 with Router ID 5.5.5.5

Interfaces

Area: 0.0.0.1

IP Address Type State Cost Pri DR BDR

192.168.51.5 PTP P-2-P 1 1 0.0.0.0 0.0.0.0

b. 如果存在上述情况，请在OSPF接口视图下执行ospf network-type命令将本端设备与邻居设备的OSPF接口网络类型配置为一致。

如果不存在上述情况，请执行步骤(2)。

(2) 多次查看OSPF路由表，检查是否存在OSPF路由震荡的问题。

请执行display ip routing-table protocol ospf verbose命令，查看Age字段，确认是否存在震荡的OSPF路由。

¡ 如果某条或某些OSPF路由Age字段的数值一直很小，说明相应的OSPF路由发生震荡，请解决路由震荡问题。

¡ 如果不存在路由震荡的问题，请执行步骤(3)。

<Sysname> display ip routing-table protocol ospf verbose

Summary count : 3

Destination: 192.168.12.0/24

Protocol: O_INTER

Process ID: 1

SubProtID: 0x2 Age: 12h53m09s

Cost: 2 Preference: 10

IpPre: N/A QosLocalID: N/A

Tag: 0 State: Active Adv

OrigTblID: 0x0 OrigVrf: default-vrf

TableID: 0x2 OrigAs: 0

NibID: 0x13000003 LastAs: 0

AttrID: 0xffffffff Neighbor: 0.0.0.0

Flags: 0x10041 OrigNextHop: 192.168.51.1

Label: NULL RealNextHop: 192.168.51.1

BkLabel: NULL BkNextHop: N/A

SRLabel: NULL Interface: GigabitEthernet2/0/2

BkSRLabel: NULL BkInterface: N/A

SIDIndex: NULL InLabel: NULL

Tunnel ID: Invalid IPInterface: GigabitEthernet2/0/2

BkTunnel ID: Invalid BkIPInterface: N/A

FtnIndex: 0x0 ColorInterface: N/A

TrafficIndex: N/A BkColorInterface: N/A

Connector: 0.0.0.0 VpnPeerId: N/A

Dscp: N/A Exp: N/A

SRTunnelID: Invalid StatFlags: 0x0

SID Type: N/A SID: N/A

BkSID: N/A NID: Invalid

FlushNID: Invalid BkNID: Invalid

BkFlushNID: Invalid PathID: 0x0

CommBlockLen: 0

OrigLinkID: 0x0 RealLinkID: 0x0

Destination: 192.168.24.0/24

Protocol: O_INTER

Process ID: 1

SubProtID: 0x2 Age: 12h53m09s

Cost: 3 Preference: 10

IpPre: N/A QosLocalID: N/A

Tag: 0 State: Active Adv

OrigTblID: 0x0 OrigVrf: default-vrf

TableID: 0x2 OrigAs: 0

NibID: 0x13000003 LastAs: 0

AttrID: 0xffffffff Neighbor: 0.0.0.0

Flags: 0x10041 OrigNextHop: 192.168.51.1

Label: NULL RealNextHop: 192.168.51.1

BkLabel: NULL BkNextHop: N/A

SRLabel: NULL Interface: GigabitEthernet2/0/2

BkSRLabel: NULL BkInterface: N/A

SIDIndex: NULL InLabel: NULL

Tunnel ID: Invalid IPInterface: GigabitEthernet2/0/2

BkTunnel ID: Invalid BkIPInterface: N/A

FtnIndex: 0x0 ColorInterface: N/A

TrafficIndex: N/A BkColorInterface: N/A

Connector: 0.0.0.0 VpnPeerId: N/A

Dscp: N/A Exp: N/A

SRTunnelID: Invalid StatFlags: 0x0

SID Type: N/A SID: N/A

BkSID: N/A NID: Invalid

FlushNID: Invalid BkNID: Invalid

BkFlushNID: Invalid PathID: 0x0

CommBlockLen: 0

OrigLinkID: 0x0 RealLinkID: 0x0

Destination: 192.168.51.0/24

Protocol: O_INTRA

Process ID: 1

SubProtID: 0x1 Age: 12h54m07s

Cost: 1 Preference: 10

IpPre: N/A QosLocalID: N/A

Tag: 0 State: Inactive Adv

OrigTblID: 0x0 OrigVrf: default-vrf

TableID: 0x2 OrigAs: 0

NibID: 0x13000001 LastAs: 0

AttrID: 0xffffffff Neighbor: 0.0.0.0

Flags: 0x10c1 OrigNextHop: 0.0.0.0

Label: NULL RealNextHop: 0.0.0.0

BkLabel: NULL BkNextHop: N/A

SRLabel: NULL Interface: GigabitEthernet2/0/2

BkSRLabel: NULL BkInterface: N/A

SIDIndex: NULL InLabel: NULL

Tunnel ID: Invalid IPInterface: GigabitEthernet2/0/2

BkTunnel ID: Invalid BkIPInterface: N/A

FtnIndex: 0x0 ColorInterface: N/A

TrafficIndex: N/A BkColorInterface: N/A

Connector: 0.0.0.0 VpnPeerId: N/A

Dscp: N/A Exp: N/A

SRTunnelID: Invalid StatFlags: 0x0

SID Type: N/A SID: N/A

BkSID: N/A NID: Invalid

FlushNID: Invalid BkNID: Invalid

BkFlushNID: Invalid PathID: 0x0

CommBlockLen: 0

OrigLinkID: 0x0 RealLinkID: 0x0

(3) 检查OSPF进程下是否配置了filter-policy import命令。

某些场景下需要对路由信息进行过滤，实现业务隔离。请检查是否存在OSPF路由被错误过滤的情况。

a. 请在本端设备出现问题的OSPF进程下执行display this命令，查看该OSPF进程下是否配置了filter-policy import命令，导致OSPF路由被过滤。

[Sysname-ospf-1] display this

ospf 1

import-route direct

filter-policy 2000 import

area 0.0.0.1

network 192.168.51.0 0.0.0.255

nssa

return

b. 如果OSPF进程下配置了filter-policy import命令，请查看该命令引用的过滤规则的配置信息。

- 对于filter-policy import命令引用ACL规则进行路由过滤的情况，请执行display acl { acl-number | name acl-name }命令查看ACL的配置信息。

- 对于filter-policy import命令引用前缀列表进行路由过滤的情况，请执行display ip prefix-list命令查看地址前缀列表的配置信息。

- 对于filter-policy import命令引用路由策略进行路由过滤的情况，请执行display route-policy命令查看路由策略的配置信息。

如果路由被过滤规则拒绝，请结合组网及实际业务需求确认过滤规则的配置是否合理。如果不合理，请修改filter-policy import命令引用的过滤规则。

c. 如果该路由没有被拒绝，或者该OSPF进程并没有配置filter-policy import过滤策略，请执行步骤(4)。

(4) 检查OSPF进程的LSDB是否包含未学习到的OSPF路由的LSA。

请根据OSPF进程未学习到的路由信息的类型选择不同的故障处理方式。

¡ OSPF区域内路由

如果OSPF进程缺失区域内路由，请在用户视图下执行display ospf [ process-id ] lsdb router命令，检查LSDB是否包含该区域中所有的Router LSA信息。

<Sysname> display ospf 100 lsdb router

OSPF Process 100 with Router ID 5.5.5.5

Area: 0.0.0.1

Link State Database

Type : Router

LS ID : 5.5.5.5

Adv Rtr : 5.5.5.5

LS age : 7

Len : 36

Options : ASBR O NP

Seq# : 80000026

Checksum : 0x5f1f

Link Count: 1

Link ID: 192.168.51.1

Data : 192.168.51.5

Link Type: TransNet

Metric : 1

Type : Router

LS ID : 1.1.1.1

Adv Rtr : 1.1.1.1

LS age : 8

Len : 36

Options : ASBR ABR O NP

Seq# : 8000002a

Checksum : 0x534a

Link Count: 1

Link ID: 192.168.51.1

Data : 192.168.51.1

Link Type: TransNet

Metric : 1

- 如果OSPF进程的LSDB缺失Router LSA，请执行步骤(7)。

- 如果OSPF进程的LSDB包含完整的Router LSA，但是无法计算出路由信息，请执行步骤(7)。

¡ OSPF区域间路由

如果OSPF进程缺失区域间路由，请在用户视图下执行display ospf [ process-id ] lsdb summary命令，检查LSDB是否包含其他所有区域的Network Summary LSA。

<Sysname> display ospf lsdb summary

OSPF Process 1 with Router ID 5.5.5.5

Area: 0.0.0.1

Link State Database

Type : Sum-Net

LS ID : 192.168.24.0

Adv Rtr : 1.1.1.1

LS age : 576

Len : 28

Options : O NP

Seq# : 8000001f

Checksum : 0x4c25

Net Mask : 255.255.255.0

Tos 0 Metric: 2

Type : Sum-Net

LS ID : 192.168.12.0

Adv Rtr : 1.1.1.1

LS age : 576

Len : 28

Options : O NP

Seq# : 8000001f

Checksum : 0xc6b7

Net Mask : 255.255.255.0

Tos 0 Metric: 1

- 如果OSPF进程的LSDB缺失Network Summary LSA，检查本区域下是否配置了filter import命令，或者Network Summary LSA的发布者所在区域下是否配置了filter export命令。如果filter import命令或filter export命令引用的过滤规则错误地过滤掉了Network Summary LSA，请修改过滤规则相关配置。

filter import命令和filter export命令可以引用ACL、前缀列表、路由策略对Network Summary LSA进行过滤，请分别使用display acl { acl-number | name acl-name }命令、display ip prefix-list命令、display route-policy命令查看相应的配置信息。

- 如果OSPF进程的LSDB包含完整的Network Summary LSA，但是无法计算出路由信息，请执行步骤(7)。

¡ O_ASE路由或者O_NSSA路由

如果OSPF进程缺失O_ASE路由，请在用户视图下执行display ospf [ process-id ] lsdb ase命令。检查LSDB是否包含AS External LSA。

<Sysname> display ospf 100 lsdb ase

OSPF Process 100 with Router ID 1.1.1.1

Link State Database

Type : External

LS ID : 10.1.1.0

Adv Rtr : 1.1.1.1

LS age : 713

Len : 36

Options : O E

Seq# : 80000001

Checksum : 0x934b

Net Mask : 255.255.255.0

TOS 0 Metric: 1

E Type : 2

Forwarding Address : 192.168.51.5

Tag : 1

如果OSPF进程缺失O_NSSA路由，请在用户视图下执行display ospf [ process-id ] lsdb nssa命令，检查LSDB是否包含NSSA External LSA。

<Sysname> display ospf 100 lsdb nssa

OSPF Process 100 with Router ID 1.1.1.1

Area: 0.0.0.0

Link State Database

Area: 0.0.0.1

Link State Database

Type : NSSA

LS ID : 192.168.51.0

Adv Rtr : 5.5.5.5

LS age : 965

Len : 36

Options : O NP

Seq# : 8000001f

Checksum : 0x1dfa

Net Mask : 255.255.255.0

TOS 0 Metric: 1

E Type : 2

Forwarding Address : 192.168.51.5

Tag : 1

Type : NSSA

LS ID : 10.1.1.0

Adv Rtr : 5.5.5.5

LS age : 965

Len : 36

Options : O NP

Seq# : 8000001f

Checksum : 0x6840

Net Mask : 255.255.255.0

TOS 0 Metric: 1

E Type : 2

Forwarding Address : 192.168.51.5

Tag : 1

- 如果OSPF进程的LSDB缺失AS External LSA或NSSA External LSA，请执行步骤(7)。

- 如果OSPF进程的LSDB包含完整的AS External LSA或NSSA External LSA，但是无法学习到O_ASE路由或者O_NSSA路由的情况，请执行步骤(7)。

(5) 检查ABR设备是否可达。

区域间路由是ABR设备发布的，如果本端设备和ABR设备之间路由不可达，则会导致本端设备无法学习到区域间路由。

a. 请在本端设备执行display ospf [ process-id ] lsdb summary命令，查看Adv Rtr字段，该字段为通告Network Summary LSA的Router ID，即ABR的Router ID。

<Sysname> display ospf 100 lsdb summary

OSPF Process 100 with Router ID 5.5.5.5

Area: 0.0.0.1

Link State Database

Type : Sum-Net

LS ID : 192.168.12.0

Adv Rtr : 1.1.1.1

LS age : 913

Len : 28

Options : O E

Seq# : 80000001

Checksum : 0x5d45

Net Mask : 255.255.255.0

Tos 0 Metric: 1

b. 请在本端设备执行display ospf abr-asbr命令，查看Destination字段和RtType字段，RtType字段取值为ABR时，Destination字段为ABR的Router ID。查看到此类路由信息时，说明存在到达为ABR的路由。

<Sysname> display ospf 100 abr-asbr

OSPF Process 100 with Router ID 5.5.5.5

Routing Table to ABR and ASBR

Type Destination Area Cost Nexthop RtType

Intra 1.1.1.1 0.0.0.1 1 192.168.51.1 ABR

c. 如果abr-asbr信息中不包含到达通告Network Summary LSA的ABR的路由，请执行步骤(7)。

d. 如果abr-asbr信息中包含到达通告Network Summary LSA的ABR的路由，且本设备为ABR设备，请检查OSPF区域是否为骨干区域。

- 如果OSPF区域为非骨干区域（区域ID不为零），根据RFC 2328的规定，ABR设备不会对非骨干区的Network Summary LSA进行计算，没有区域间路由是正常现象。

- 如果OSPF区域为骨干区域（区域ID为零），但是没有学习到区域间路由，请执行步骤(7)。

e. 如果abr-asbr信息中包含到达通告Network Summary LSA的ABR的路由，且本OSPF进程绑定了VPN实例。请检查OSPF进程下是否配置了vpn-instance-capability simple命令。如果OSPF进程下配置了vpn-instance-capability simple命令，请执行步骤(7)。

如果OSPF进程下未配置vpn-instance-capability simple命令，故障处理方式如表6-3所示。

表6-3 OSPF进程下未配置vpn-instance-capability simple命令的故障处理方式

DN比特位是否置位	故障处理方式
未配置vpn-instance-capability simple命令，且Network Summary LSA的Option字段包含DN比特位（即DN比特位置位）	根据RFC 2328的规定，私网OSPF进程不会使用DN比特位置位的Network Summary LSA进行路由计算。没有对应的区域间路由是正常现象
未配置vpn-instance-capability simple命令，且Network Summary LSA的Option字段不包含DN比特位	请执行步骤(7)

(6) 检查ASBR设备是否可达，检查是否有防环检测。

O_ASE路由和O_NSSA路由是ASBR设备发布的，如果本端设备和ASBR设备之间路由不可达，则会导致本端设备无法学习到AS外部的路由。

a. 请执行display ospf [ process-id ] lsdb [ ase | nssa ]命令，查看Adv Rtr字段，该字段为通告AS External LSA（Type-5）或NSSA External LSA（Type-7）的Router ID，即ASBR的Router ID。

<Sysname> display ospf 100 lsdb ase

OSPF Process 100 with Router ID 1.1.1.1

Link State Database

Type : External

LS ID : 10.1.1.0

Adv Rtr : 1.1.1.1

LS age : 169

Len : 36

Options : O E

Seq# : 80000001

Checksum : 0x934b

Net Mask : 255.255.255.0

TOS 0 Metric: 1

E Type : 2

Forwarding Address : 192.168.51.5

Tag : 1

<Sysname> display ospf 100 lsdb nssa

OSPF Process 100 with Router ID 1.1.1.1

Area: 0.0.0.0

Link State Database

Area: 0.0.0.1

Link State Database

Type : NSSA

LS ID : 192.168.51.0

Adv Rtr : 5.5.5.5

LS age : 156

Len : 36

Options : O NP

Seq# : 80000001

Checksum : 0x59dc

Net Mask : 255.255.255.0

TOS 0 Metric: 1

E Type : 2

Forwarding Address : 192.168.51.5

Tag : 1

Type : NSSA

LS ID : 10.1.1.0

Adv Rtr : 5.5.5.5

LS age : 156

Len : 36

Options : O NP

Seq# : 80000001

Checksum : 0xa422

Net Mask : 255.255.255.0

TOS 0 Metric: 1

E Type : 2

Forwarding Address : 192.168.51.5

Tag : 1

b. 请执行display ospf abr-asbr命令，查看Destination字段和RtType字段，RtType字段取值为ASBR时，Destination字段为ASBR的Router ID。查看到此类路由信息时，说明存在到达为ASBR的路由。

<Sysname> display ospf 100 abr-asbr

OSPF Process 100 with Router ID 1.1.1.1

Routing Table to ABR and ASBR

Type Destination Area Cost Nexthop RtType

Intra 5.5.5.5 0.0.0.1 1 192.168.51.5 ASBR

c. 如果abr-asbr信息中不包含到达通告AS External LSA或NSSA External LSA的ASBR的路由，请执行步骤(7)。

d. 如果abr-asbr信息中包含到达通告AS External LSA或NSSA External LSA的ASBR的路由，且LSA的Forwarding Address字段不为零，需要检查Forwarding Address的可达性及路由类型。

请在用户视图下执行disply ospf routing forwarding-address { mask-length | mask }命令查询是否存在到达Forwarding Address的路由。

<Sysname> display ospf 100 routing 192.168.51.5 24

OSPF Process 100 with Router ID 1.1.1.1

Routing Table

Routing for network

Destination Cost Type NextHop AdvRouter Area

192.168.51.0/24 1 Transit 0.0.0.0 5.5.5.5 0.0.0.1

Total nets: 1

Intra area: 1 Inter area: 0 ASE: 0 NSSA: 0

Forwarding Address的可达性及路由类型对OSPF是否能够学习到O_ASE路由或O_NSSA路由的影响如表6-4所示。

表6-4 Forwarding Address的可达性及路由类型对O_ASE路由或O_NSSA路由的影响

Forward Address是否可达	故障处理方式
不可达	如果通过display ospf routing forwarding-address { mask-length \| mask }命令无法查看到路由信息，说明Forwarding Address不可达，请执行步骤(7)
可达	如果外部路由是由NSSA External LSA（Type-7）通告的，根据RFC 3101的规定，要求到达Forwarding Address的路由所在区域与NSSA External LSA所在区域相同。如果Area字段标明的区域号与NSSA External LSA所在的区域不同，OSPF不使用此类NSSA External LSA进行路由计算。因此，没有对应的外部路由是正常现象
可达	通过display ospf routing forwarding-address { mask-length \| mask }命令查看到的路由的Type字段为Type1或者Type2，说明到达Forwarding Address的路由类型是外部路由。根据RFC 2328的规定，到达非零Forwarding Address的路由类型不允许是外部路由，OSPF不使用此类LSA进行路由计算。因此，没有对应的外部路由是正常现象

e. 如果abr-asbr信息中包含到达通告AS External LSA或NSSA External LSA的ASBR的路由，且本OSPF进程绑定了VPN实例。

请检查本OSPF进程下是否配置了vpn-instance-capability simple命令。如果OSPF进程下配置了vpn-instance-capability simple命令，请执行步骤(7)。

如果OSPF进程下未配置vpn-instance-capability simple命令，故障处理方式如表6-5所示。

表6-5 OSPF进程下未配置vpn-instance-capability simple命令的故障处理方式

DN比特位是否置位

故障处理方式

未配置vpn-instance-capability simple命令，且AS External LSA或者NSSA External LSA的Option字段包含DN比特位

根据RFC 2328的规定，私网OSPF进程不会使用DN比特位置位的AS External LSA或者NSSA External LSA进行路由计算。没有对应的外部路由是正常现象

未配置vpn-instance-capability simple命令，且AS External LSA或者NSSA External LSA的Option字段不包含DN比特位

请执行display ospf命令查看Default ASE parameters字段，确认AS External LSA或者NSSA External LSA的Tag值是否与私网OSPF进程的Tag值相同：

· 对于Tag值相同的情况，根据RFC 2328的规定，私网OSPF进程不会使用此类LSA进行路由计算。因此，没有对应的外部路由是正常现象

· 对于Tag值不同的情况，请执行步骤(7)

(7) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息、告警信息。

5. 告警与日志

6.2.4 网络中IP地址冲突导致路由震荡

1. 故障描述

OSPF组网中不同设备上配置相同的接口IP地址，会导致OSPF路由震荡。出现此问题时，设备通常伴随如下现象：

· 执行命令display cpu-usage查看到设备CPU使用率较高。

· OSPF频繁地老化LSA、重新生成LSA。

· 设备路由频繁刷新、路由计算出错。

2. 处理步骤

以图6-11为示例说明此类故障的处理方式。其他组网与该组网处理此类故障的思路是相同的。

图6-11 网络中IP地址冲突导致路由震荡组网示例

(1) ‍在OSPF网络中的各个设备上每隔一秒执行一次display ospf [ process-id ] lsdb命令，查看每台设备的OSPF链路状态数据库（LSDB）信息。

(2) 检查是否存在LSA老化异常的情况。

同时满足如下条件时，说明LSA老化异常。

a. 在Device A上发现同一个AdvRouter通告的Network LSA（Type-2）的老化时间（Age）非自然增长，一直为最小值，且Sequence字段增加很快。例如在如下显示信息中，LinkStateID为172.168.0.1的Network LSA的Age非自然增长，短时间内Sequence从8000002D快速增长为8000002F。

<Sysname> display ospf 100 lsdb

OSPF Process 100 with Router ID 10.1.1.1

Link State Database

Area: 0.0.0.0

Type LinkState ID AdvRouter Age Len Sequence Metric

Router 3.3.3.3 3.3.3.3 797 48 80000009 0

Router 1.1.1.1 1.1.1.1 835 36 80000005 0

Router 4.4.4.4 4.4.4.4 798 36 80000004 0

Router 10.1.1.1 10.1.1.1 415 36 80000007 0

Router 2.2.2.2 2.2.2.2 415 48 80000015 0

Network 192.168.0.2 3.3.3.3 802 32 80000002 0

Network 172.168.0.3 4.4.4.4 791 32 80000002 0

Network 172.168.0.1 10.1.1.1 7 32 8000002D 0

<Sysname> display ospf 100 lsdb

OSPF Process 100 with Router ID 10.1.1.1

Link State Database

Area: 0.0.0.0

Type LinkState ID AdvRouter Age Len Sequence Metric

Router 3.3.3.3 3.3.3.3 810 48 80000009 0

Router 1.1.1.1 1.1.1.1 848 36 80000005 0

Router 4.4.4.4 4.4.4.4 811 36 80000004 0

Router 10.1.1.1 10.1.1.1 428 36 80000007 0

Router 2.2.2.2 2.2.2.2 428 48 80000015 0

Network 192.168.0.2 3.3.3.3 815 32 80000002 0

Network 172.168.0.3 4.4.4.4 804 32 80000002 0

Network 172.168.0.1 10.1.1.1 4 32 8000002F 0

b. 在Device B上相同Network LSA的Age不断在3600和其他较小值之间切换，而且Sequence字段增加很快。例如在如下显示信息中，LinkStateID为172.168.0.1的Network LSA的Age在3600和其他较小值之间切换，短时间内Sequence从80000023快速增长为80000041。

<Sysname> display ospf 100 lsdb

OSPF Process 100 with Router ID 2.2.2.2

Link State Database

Area: 0.0.0.0

Type LinkState ID AdvRouter Age Len Sequence Metric

Router 3.3.3.3 3.3.3.3 708 48 80000009 0

Router 1.1.1.1 1.1.1.1 746 36 80000005 0

Router 4.4.4.4 4.4.4.4 709 36 80000004 0

Router 10.1.1.1 10.1.1.1 329 36 80000007 0

Router 2.2.2.2 2.2.2.2 327 48 80000015 0

Network 172.168.0.3 4.4.4.4 702 32 80000002 0

Network 192.168.0.2 3.3.3.3 713 32 80000002 0

Network 172.168.0.1 10.1.1.1 3600 32 80000023 0

<Sysname> display ospf 100 lsdb

OSPF Process 100 with Router ID 2.2.2.2

Link State Database

Area: 0.0.0.0

Type LinkState ID AdvRouter Age Len Sequence Metric

Router 3.3.3.3 3.3.3.3 748 48 80000009 0

Router 1.1.1.1 1.1.1.1 786 36 80000005 0

Router 4.4.4.4 4.4.4.4 749 36 80000004 0

Router 10.1.1.1 10.1.1.1 369 36 80000007 0

Router 2.2.2.2 2.2.2.2 367 48 80000015 0

Network 172.168.0.3 4.4.4.4 742 32 80000002 0

Network 192.168.0.2 3.3.3.3 753 32 80000002 0

Network 172.168.0.1 10.1.1.1 7 32 80000041 0

c. 在Device C上，相同Network LSA的Age一直为3600，或者偶尔没有这条LSA，而且Sequence字段增加很快。例如在如下显示信息中，LinkStateID为172.168.0.1的Network LSA的Age为3600，或者偶尔没有这条LSA；存在这条LSA时，短时间内Sequence从80000309增长到80000346。

<Sysname> display ospf 100 lsdb

OSPF Process 100 with Router ID 3.3.3.3

Link State Database

Area: 0.0.0.0

Type LinkState ID AdvRouter Age Len Sequence Metric

Router 3.3.3.3 3.3.3.3 740 48 8000000D 0

Router 4.4.4.4 4.4.4.4 759 36 80000008 0

Router 10.1.1.1 10.1.1.1 364 36 8000000B 0

Router 2.2.2.2 2.2.2.2 366 48 80000019 0

Network 172.168.0.3 4.4.4.4 755 32 80000006 0

Network 192.168.0.2 3.3.3.3 744 32 80000006 0

Network 172.168.0.1 10.1.1.1 3600 32 80000309 0

<Sysname> display ospf 100 lsdb

OSPF Process 100 with Router ID 3.3.3.3

Link State Database

Area: 0.0.0.0

Type LinkState ID AdvRouter Age Len Sequence Metric

Router 3.3.3.3 3.3.3.3 745 48 8000000D 0

Router 4.4.4.4 4.4.4.4 764 36 80000008 0

Router 10.1.1.1 10.1.1.1 369 36 8000000B 0

Router 2.2.2.2 2.2.2.2 371 48 80000019 0

Network 172.168.0.3 4.4.4.4 760 32 80000006 0

Network 192.168.0.2 3.3.3.3 749 32 80000006 0

<Sysname> display ospf 100 lsdb

OSPF Process 100 with Router ID 3.3.3.3

Link State Database

Area: 0.0.0.0

Type LinkState ID AdvRouter Age Len Sequence Metric

Router 3.3.3.3 3.3.3.3 1302 48 8000000D 0

Router 4.4.4.4 4.4.4.4 1321 36 80000008 0

Router 10.1.1.1 10.1.1.1 926 36 8000000B 0

Router 2.2.2.2 2.2.2.2 928 48 80000019 0

Network 172.168.0.3 4.4.4.4 1317 32 80000006 0

Network 192.168.0.2 3.3.3.3 1306 32 80000006 0

Network 172.168.0.1 10.1.1.1 3600 32 80000346 0

(3) 检查是否存在OSPF路由震荡。

在Device B上每隔一秒执行一次display ospf [ process-id ] routing命令，查看路由是否震荡。

<Sysname> display ospf 100 routing

OSPF Process 100 with Router ID 2.2.2.2

Routing Table

Routing for network

Destination Cost Type NextHop AdvRouter Area

192.168.0.0/24 1 Transit 0.0.0.0 3.3.3.3 0.0.0.0

172.168.0.0/24 1 Transit 0.0.0.0 10.1.1.1 0.0.0.0

Total nets: 2

Intra area: 2 Inter area: 0 ASE: 0 NSSA: 0

<Sysname> display ospf 100 routing

OSPF Process 100 with Router ID 2.2.2.2

Routing Table

Routing for network

Destination Cost Type NextHop AdvRouter Area

192.168.0.0/24 1 Transit 0.0.0.0 3.3.3.3 0.0.0.0

172.168.0.0/24 2 Transit 192.168.0.2 4.4.4.4 0.0.0.0

Total nets: 2

Intra area: 2 Inter area: 0 ASE: 0 NSSA: 0

当OSPF路由发生震荡，且多次执行display ospf peer命令发现邻居关系没有发生震荡时，可以判断该OSPF组网中存在IP地址冲突。同时，由于Network LSA（Type-2）是由DR发布的，说明产生冲突的设备中有一台设备是DR。

如果任一台设备上出现两个LinkState ID相同的Network LSA，并且这两个Network LSA老化异常。说明产生冲突的设备均为DR。

<Sysname> display ospf 100 lsdb

OSPF Process 100 with Router ID 10.1.1.1

Link State Database

Area: 0.0.0.0

Type LinkState ID AdvRouter Age Len Sequence Metric

Router 3.3.3.3 3.3.3.3 367 48 80000021 0

Router 4.4.4.4 4.4.4.4 369 36 80000013 0

Router 10.1.1.1 10.1.1.1 477 36 80000012 0

Router 2.2.2.2 2.2.2.2 403 48 8000002B 0

Network 192.168.0.1 2.2.2.2 395 32 80000002 0

Network 172.168.0.1 3.3.3.3 3600 32 8000002B 0

Network 172.168.0.1 10.1.1.1 9 32 80000036 0

<Sysname> display ospf 100 lsdb

OSPF Process 100 with Router ID 10.1.1.1

Link State Database

Area: 0.0.0.0

Type LinkState ID AdvRouter Age Len Sequence Metric

Router 3.3.3.3 3.3.3.3 460 48 80000021 0

Router 4.4.4.4 4.4.4.4 462 36 80000013 0

Router 10.1.1.1 10.1.1.1 570 36 80000012 0

Router 2.2.2.2 2.2.2.2 496 48 8000002B 0

Network 192.168.0.1 2.2.2.2 488 32 80000002 0

Network 172.168.0.1 3.3.3.3 3600 32 80000034 0

Network 172.168.0.1 10.1.1.1 6 32 80000041 0

(4) 定位产生冲突的设备。

结合display ospf lsdb的显示信息，找到产生IP地址冲突的设备。

¡ 产生冲突的设备中，仅有一台设备为DR。

根据异常Network LSA的AdvRouter，可以找到产生该Network LSA的DR设备；然后根据Network LSA中的LinkState ID找到产生IP地址冲突的接口，确定该接口的IP地址。根据接口的IP地址以及网络IP地址规划，找到另外一台产生冲突的设备。

在本例中，可以判断Router ID为10.1.1.1的DR设备接口IP地址与其他设备接口IP地址冲突，产生冲突的IP地址是172.168.0.1。然后根据网络IP地址规划，找到与DR设备接口IP地址冲突的另外一台设备。

¡ 产生冲突的设备均为DR。

根据异常Network LSA的AdvRouter，可以找到产生该Network LSA的DR设备；然后根据Network LSA中的LinkState ID找到产生IP地址冲突的接口。

(5) 根据网络IP地址规划修改冲突一方的IP地址。

(6) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息、告警信息。

3. 告警与日志

6.3 等价路由故障处理

6.3.1 流量在等价路由的下一跳上没有进行负载分担或负载分担不均匀

1. 故障描述

· 流量在等价路由的一个或多个下一跳上没有进行负载分担：执行display counters rate outbound interface命令查看接口报文发送速率时，观察到等价路由的一个或多个出接口的速率为0。

· 流量负载分担不均匀：执行display counters rate outbound interface命令查看接口报文发送速率时，观察到等价路由的一个或多个出接口的速率明显偏低。

2. 常见原因

本类故障的常见原因主要包括：

· 下一跳数量超过设备支持的最大数量。

· 指定出接口的路由未配置或没有正常下发。

· 出接口物理连接或数据链路层协议状态没有UP。

· 接口IP地址与对端接口IP地址不在同一网段。

· 下一跳ARP/ND表项不存在。

· 负载分担方式配置不合理。

· 硬件资源不足。

· 流量的上一跳设备配置了负载分担。

3. 故障分析

本类故障的诊断思路如图6-12所示。

图6-12 等价路由没有进行负载分担或者流量负载分担不均匀故障诊断流程图

‌

4. 处理步骤

(1) 检查下一跳的数量是否超过设备支持的最大数量。

a. 执行display max-ecmp-num命令查看系统支持的最大IPv4等价路由条数，执行display ipv6 max-ecmp-num命令查看系统支持的最大IPv6等价路由条数。

b. 查看指定目的地址的等价路由数量：执行display ip routing-table ip-address longer-match命令查看指定目的地址的IPv4路由信息。执行display ipv6 routing-table ipv6-address longer-match命令查看指定目的地址的IPv6路由信息。显示信息中目的地址相同、下一跳不同的多条路由即为等价路由。根据显示信息中的Summary count字段，并排除掉掩码长度与指定目的IP地址不同的路由信息，即可得到指定目的地址的等价路由数量。

- 如果指定目的地址的等价路由下一跳数量达到了设备支持的最大等价路由数量，则之后再配置的下一跳不会下发给路由表。如果需要修改路由表中的等价路由下一跳，则需要先删除已有的等价路由配置，再配置新的等价路由下一跳。

- 如果路由下一跳的数量没有超过设备支持的最大数量，请执行步骤(2)。

(2) 检查路由是否正确下发。

请执行display ip routing-table [ vpn-instance vpn-instance-name ] ip-address [ mask-length | mask ] [ longer-match ] verbose或display ipv6 routing-table [ vpn-instance vpn-instance-name ] ipv6-address [ prefix-length ] [ longer-match ] [ verbose ]命令，查看指定目的地址的路由信息。如果路由表中没有指定下一跳和出接口的等价路由，则需要检查路由的配置。如果路由配置无问题，请执行步骤(3)。

(3) 检查出接口物理连接和数据链路层协议状态是否UP。

执行display interface [ interface-type [ interface-number | interface-number.subnumber ] ]或display ipv6 interface [ interface-type [ interface-number ] ] [ brief ]命令查看接口物理层状态，如果接口物理层或数据链路层协议状态不是UP，请先处理接口或链路故障问题。如果出接口物理连接和数据链路层协议状态是UP，请执行步骤(4)。

(4) 检查两端IP地址是否在同一网段。

分别本设备和下一跳设备上执行display interface brief或display ipv6 interface brief命令查看两端接口的IP地址：

¡ 如果两端接口的IP地址不在同一网段，请在接口视图下执行ip address/ipv6 address命令修改两端的IP地址，使其在同一网段。

¡ 如果两端接口的IP地址在同一网段，请执行步骤(5)。

(5) 检查下一跳ARP/ND表项是否存在。

(6) 执行display arp查看ARP表项，执行display ipv6 neighbors查看ND表项，若表项不存在，请处理ARP/ND表项问题。如果设备上存在该等价路由下一跳的ARP/ND表项，请执行步骤(7)。

(7) 检查负载分担方式的配置是否合理。

执行display ip load-sharing mode命令用来查看设备当前使用的负载分担方式。如果负载分担的方式是逐流，则设备会为相同负载分担因素（例如源IP地址、目的IP地址、源端口号等）的报文选择同一个下一跳，负载分担方式不合理会导致负载分担不均匀。合理的负载分担方式可以确保设备划分出足够多、足够均匀的数据流（数据流的数量不少于下一跳数量）。

¡ 如果负载分担方式不合理，请根据报文的实际情况选择合适的字段，并执行ip load-sharing mode命令修改负载分担方式。例如指定目的地址的报文携带了不同的源IP地址、IP协议号、目的端口号等字段，则可以把这些字段添加到负载分担方式中。如果将负载分担方式充分调整后故障仍然存在，请执行步骤(8)。

¡ 如果负载分担方式合理，请执行步骤(8)。

(8) 检查硬件资源是否不足。

对于交换机、路由器等存在硬件转发芯片的设备，请检查硬件资源是否不足。通过display system internal fib prefix [ vpn-instance vpn-instance-name] entry-status f命令查看下驱动失败的IPv4 FIB表项信息，或执行display system internal ipv6 fib prefix [ vpn-instance vpn-instance-name ] entry-status f命令查看下驱动失败的IPv6 FIB表项信息。只要存在表项信息，则此设备存在硬件资源不足的情况。请关闭不必要的功能来降低硬件使用率。如果故障依然存在，请执行步骤(9)。

(9) 检查流量的上一跳设备是否配置了负载分担。

如果某个配置了负载分担的设备向本设备发送了流量，则受到负载分担算法的影响，该流量在被发往下一跳设备时会出现负载分担不均匀的情况，此种情况无需处理。请检查其他未配置负载分担的设备发送过来的流量是否也有负载分担不均匀的情况，如果也有此种情况，请执行步骤(10)。

(10) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息、告警信息。

5. 告警与日志

6.4 智能选路故障处理

6.4.1 选路错误，未选中最高优先级链路进行业务流量转发

1. 故障描述

基于链路优先级选路时，业务流量未选择优先级最高的链路Tunnel 1进行转发，而是选择了次优先级链路Tunnel 2进行转发。

2. 常见原因

本类故障的常见原因主要包括：

· 高优链路的路由不可达。

· 不存在到达业务流量目的IP的等价路由。

· 高优链路带宽利用率超过带宽下限阈值。

· 高优链路的链路质量不满足要求。

3. 故障分析

本类故障的诊断流程如图6-13所示。

图6-13 选路错误，未选中最高优先级链路进行业务流量转发的故障诊断流程图

4. 处理步骤

(1) 确认优先级最高的链路Tunnel 1路由是否可达。

a. 执行命令display tunnel flow-statistics查看当前业务流量选中的路径信息（Interface），即链路Tunnel 2。

<Sysname> display tunnel flow-statistics flow 100

Flow 100:

Interface Out pps Out bps

Tunnel2 20 9600

b. 执行display ip fast-forwarding cache查看业务流量的五元组信息（即出接口为Tunnel 2），获取业务流量的目的IP（DIP）。

<Sysname> display ip fast-forwarding cache

Total number of fast-forwarding entries: 1

SIP SPort DIP DPort Pro Input_If Output_If Flg

7.0.0.13 68 8.0.0.1 67 17 GE2/0/3 Tunnel2 5

c. 执行display fib查看是否存在到达DIP的等价路由且等价路由中包含链路Tunnel 1。

如果不存在等价路由，则检查并修改路由配置，确保存在到达DIP的等价路由中包含链路Tunnel 1，此时Tunnel 1才可以参与智能选路。

如果存在等价路由，则执行步骤(2)。

<Sysname> display fib

Route destination count: 5

Directly-connected host count: 0

Flag:

U:Useable G:Gateway H:Host B:Blackhole D:Dynamic S:Static

R:Relay F:FRR

Destination/Mask Nexthop Flag OutInterface/Token Label

8.0.0.1/32 127.0.0.1 UH Tunnel1 Null

8.0.0.1/32 127.0.0.1 UH Tunnel2 Null

(2) 确认优先级最高的链路Tunnel 1的带宽利用率。

a. 确认带宽阈值。查看RIR-SDWAN视图下，是否配置flow priority-based-schedule enable命令。如果未配置该命令，则带宽下限阈值为80%；如果配置该命令，则带宽利用率下限阈值为flow priority-based-schedule bandwidth-threshold命令指定的下限阈值（缺省为20%）。

b. 执行display rir sdwan bandwidth tunnel命令查看Tunnel 1的带宽利用率（Bandwidth usage）是否超过带宽下限阈值。

如果未超过带宽下限阈值，则表示带宽满足选路条件，请执行步骤(3)。

如果超过带宽下限阈值，则表示带宽不满足选路条件，请确认Tunnel 1的带宽配置是否与隧道物理出接口的带宽匹配。若带宽不匹配，请在Tunnel 1视图下通过bandwidth命令修改Tunnel 1的带宽；若带宽匹配，则选择Tunnel 2属于智能选路正常现象，因为Tunnel 1的带宽使用率不满足选路条件，所以设备会将业务流量调度到低优先级的链路Tunnel 2上。

<Sysname> display rir sdwan bandwidth tunnel 1

Tunnel bandwidth info:

Interface Total bandwidth Remaining bandwidth Bandwidth usage

Tunnel1 200 kbps 200 kbps 0 %

Output interface bandwidth info:

PeerTTE: SiteID=1 DeviceID=2 IfID=2

Interface Total bandwidth Remaining bandwidth Bandwidth usage

GE2/0/1 200 kbps 200 kbps 0 %

(3) 确认优先级最高的链路Tunnel 1的链路质量。

a. 执行display rir sdwan flow命令查看Tunnel 1的CQI值，确认CQI值是否为100分。

如果CQI值为100分，执行步骤(4)；

如果CQI值低于100分，执行步骤b；

<Sysname> display rir sdwan flow 1

Flow ID: 1

Session expected bandwidth: 2000 kbps

Quality policy: Yes

Tunnels with different preference values:

Preference: 8

Tunnel1

Site ID Device ID Interface ID CQI

100 1 100 80

100 2 110 90

b. 执行display rir sdwan link-quality命令查看Tunnel 1的丢包率（PktLoss (per mill)）、延时（Delay (msec)）和抖动（Jitter (msec)）。

<Sysname> display rir sdwan link-quality

Tunnel1

Interface ID=1

Peer TTE: Site ID=1 Device ID=2 Interface ID=3

Connectivity: Connected

PktLoss (per mill): 0

Delay (msec) : 0

Jitter (msec) : 0

c. 将Tunnel 1的丢包率、延时和抖动与RIR-SDWAN视图下配置的业务丢包率阈值（packet-loss threshold）、业务延迟阈值（delay threshold）和业务抖动阈值（jitter threshold）一一进行比较。若丢包率、延时或抖动存在超过阈值的现象，则表示链路质量不满足选路条件，设备选择Tunnel 2属于智能选路正常现象，因为Tunnel 1的链路质量不满足选路条件，所以设备会将业务流量调度到链路质量满足选路条件的链路Tunnel 2上。

d. 如果希望链路Tunnel 1的CQI值快速恢复100分，则可以在RIR-SDWAN视图下将业务丢包率阈值（packet-loss threshold）、业务延迟阈值（delay threshold）和业务抖动阈值（jitter threshold）调大，使Tunnel 1的链路质量满足选路条件。

(4) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息、告警信息。

5. 告警与日志

7 链路质量与调度问题故障处理

7.1 无法查询到Overlay链路质量信息

控制组件上链路质量查询为--，无法查询到链路质量。

图7-1 无法查询到Overlay链路质量信息

需要排查确认原因，具体排查步骤如下：

7.1.2 控制组件排查

控制组件上链路质量都是设备探测后上报的，可以在设备上查看链路质量信息：

<Spoke2> display rir sdwan link-quality

Tunnel1:

Interface ID=1

Peer TTE: Site ID=3 Device ID=1 Interface ID=1

Connectivity : Connected

PktLoss (per mill): 0

Delay (msec) : 0

Jitter (msec) : 0

Peer TTE: Site ID=4 Device ID=1 Interface ID=1

Connectivity : Connected

PktLoss (per mill): 0

Delay (msec) : 0

Jitter (msec) : 0

Peer TTE: Site ID=7 Device ID=1 Interface ID=1

Connectivity : Connected

PktLoss (per mill): 0

Delay (msec) : 0

Jitter (msec) : 0

Interface

如果设备上链路质量信息查询正常，可以在控制组件上手动同步一下设备状态。

图7-2 同步设备状态

7.1.3 版本排查

确认一下设备版本，设备老的版本在外层报文进行着色完成INQA探测。如果运营商修改了外层报文，可能导致质量探测失败。

解决方法：路由器需要升级到E6749L09及之后的版本，防火墙暂不支持。

7.1.4 NTP状态排查

设备之间必须NTP时间同步，INQA才能探测出质量信息。

确认设备的NTP服务状态，如果未配置NTP，请参考《AD-WAN分支7.2 WAN业务配置指导》完成NTP配置。

<Spoke2> display current-configuration | include clock

clock protocol ntp //通过NTP同步系统时间

<Spoke2> display ntp-service status

Clock status: synchronized //状态需要为同步

Clock stratum: 12

System peer: 7.1.1.11

Local mode: client

Reference clock ID: 7.1.1.11

Leap indicator: 00

Clock jitter: 0.000092 s

Stability: 0.000 pps

Clock precision: 2^-21

Root delay: 0.64087 ms

Root dispersion: 37.07886 ms

Reference time: e886f715.62a02210 Wed, Aug 16 2023 7:19:49.385

System poll interval: 1024 s

7.1.5 隧道下未配置service slot

路由器：堆叠或框式设备需要在UDP封装的SDWAN隧道口上配置service slot/service chasis x slot x命令指定设备的转发板；

防火墙：都为堆叠模式需要在UDP封装的SDWAN隧道口上配置service slot/service chasis x slot x命令指定设备的转发板。

interface Tunnel1 mode sdwan udp

bandwidth 400000000

service slot 3 //需要支持转发板卡

ip address unnumbered interface LoopBack100

source LoopBack100

ipv6 address auto link-local

sdwan interface-id 1

sdwan routing-domain 100 id 100

sdwan transport-network Default.1 id 1

sdwan encapsulation udp-port 4799

sdwan collaboration peer-device-id 2

如果未配置Service Slot命令则INQA质量探测失败，请参考《AD-WAN分支7.2 WAN业务配置指导》完成此配置。

如果配置都正确，请收集信息反馈研发。

7.2 链路探测丢包率过大

7.2.1 排查控制器和设备相关配置

请参考无法查询到Overlay链路质量信息完成配置相关排查。

7.2.2 排查设备限速配置以及接口统计

确认WAN口是否配置了LR限速，由于运营商提供的带宽小于接口带宽，因此需要对WAN口进行限速，否则可能会导致运营商侧丢包。

1. 展开链路信息，确认具体Overlay隧道相关信息

查找对应Overlay质量异常的链路，展开链路如下图所示，两端设备和接口分别为Spoke1-2的GE0/1口和Hub2的Ten-GE4/0/2口。

图7-3 确认具体Overlay隧道相关信息

2. 确认对应接口下是否配置了LR限速

登录对应设备，例如登录设备Spoke1-2，查询接口配置，确认接口下是否配置了LR限速。

[Spoke1-2]display current-configuration interface GigabitEthernet 0/1

interface GigabitEthernet0/1

port link-mode route

bandwidth 10000

ip address 12.1.2.1 255.255.255.0

qos lr outbound cir 10000 cbs 625000 ebs 0 //LR限速配置，确认是否配置了限速，且限速和运营商承诺带宽是否一致，

return

如果未配置限速请补充配置，配置方式请参考《AD-WAN分支7.2 WAN业务配置指导》。

3. 查询接口是否有丢包

查看接口统计，确认接口是否有丢包：

[Spoke1-1]display interface GigabitEthernet 0/1

GigabitEthernet0/1

Current state: UP

Line protocol state: UP

...略

Output queue - Urgent queuing: Size/Length/Discards 0/1024/0 //确认出方向队列是否有丢包

Output queue - Protocol queuing: Size/Length/Discards 0/500/0

Output queue - Class Based Queuing: Size/Discards 0/0

当前版本INQA质量探测会将本地限速丢包也统计在丢包中，如果流量过大导致了丢包，INQA统计丢包为正常现象。

7.2.3 排查底层物理链路是否有丢包

1. 展开链路信息，确认具体Overlay隧道相关信息

查找对应Overlay质量异常的链路，展开链路如下图所示，两端设备、隧道接口和物理接口分别为Spoke1-2的Tunnel1，对应物理接口GE0/1口和Hub2的Tunnel1，对应物理接口Ten-GE4/0/2口。

图7-4 确认具体Overlay隧道相关信息

2. 确认隧道封装地址

确认Overlay隧道（TTE）对应的underlay封装地址。对于Internet链路， WAN口地址可能经过NAT变换，需要确认可以在Underlay探测的封装地址：

(1) 确认分支和总部站点对应的站点ID，进入[自动化>广域分支网络>物理网络>站点管理]页面，展开可以查询到对应的站点ID和Device ID。分支Spoke1-2属于站点Branch1，对应站点ID 4，设备编号为2，因此Device ID为2；总部Hub1-2属于站点HQ1，对应站点ID 7，设备编号为2，因此Device ID为2；如下图所示：

图7-5 确认分支和总部站点对应的站点ID

(2) 由于分支可能使用动态NAT变换（运营商进行地址变换并且无法反向访问），因此建议在分支设备上进行Underlay探测。

(3) 在分支设备上查询TTE封装地址，对应命令如下，根据Site ID、Device ID和IfID确认对应的TTE。其中Destination IP/port就是对端封装地址和端口，对端封装地址为12.1.1.1，端口4799。Source IP/port就是本端封装地址和端口，本端封装地址为:12.1.2.1，端口4799。

<Spoke1-2> display sdwan tte connection

Destination SiteID/DevID/IfID/SysIP: 7/2/1/6.1.1.2 //对端：Site ID为7，Device ID为2，IfID：隧道ID同隧道编号，为1；

Destination IP/port: 12.1.1.1/4799 //对端封装地址和端口

Source SiteID/DevID/IfID/SysIP: 4/2/1/6.1.1.4 //本端：Site ID为4，Device ID为2，IfID：隧道ID同隧道编号，为1；

Source IP/port: 12.1.2.1/4799 //本端封装地址和端口

Created at: 2024/04/24 07:03:11

Status: Reachable

State changed at: 2024/05/31 05:46:41

3. 分支上执行Ping操作进行测试

分支设备上执行Ping操作，确认Underlay是否有丢包，相关命令：ping –c 100 –s 1500 –a <对端封装地址> <本端封装地址>，本例中执行如下命令：

<Spoke1-2> ping -c 100 -s 1500 -a 12.1.2.1 12.1.1.1

Ping 12.1.1.1 (12.1.1.1) from 12.1.2.1: 1500 data bytes, press CTRL_C to break

1500 bytes from 12.1.1.1: icmp_seq=8 ttl=254 time=0.710 ms

1500 bytes from 12.1.1.1: icmp_seq=9 ttl=254 time=0.556 ms

…略

--- Ping statistics for 12.1.1.1 ---

100 packet(s) transmitted, 35 packet(s) received, 65.0% packet loss //确认Underlay是否有丢包

round-trip min/avg/max/std-dev = 0.401/1.678/41.321/6.799 ms

此步骤仅作参考，ping公网地址只能证明icmp报文丢包情况，并不能完全排除运营商链路SDWAN封装的UDP报文不丢包。

7.2.4 Underlay和Overlay分别进行流量统计，确认是否有收到报文

报文经过运营商（互联网）时，报文的DSCP可能会被重置为0，因此只能基于隧道进行流量统计。

使用System IP地址进行Ping操作，在隧道和物理接口上进行流量统计，确认设备是否收到对方的报文，如果没有收到则可以认为是中间链路有丢包，需要排查中间链路。

为了区分BGP或者其它业务报文，可以设置特定的TOS值来区分探测报文进行测试。

探测命令：ping -a <本端SystemIP> -c 10 -s 1000 -i Tunnel <编号> -tos 160 <对端SystemIP>

其中：

· System IP可以直接在控制器设备列表页面查询；

· Tunnel编号就是本端TTE对应的Tunnel编号；

· tos 160：转换为DSCP就是40；

本例中对应的ping命令：

<Hub2> ping -c 10 -a 6.1.1.2 -s 1000 -i Tunnel 1 -tos 160 6.1.1.4

1. Overlay配置流量统计

配置对应ACL匹配对应的探测流量：

acl advanced 3777

rule 0 permit icmp source 6.1.1.2 0 destination 6.1.1.4 0 dscp cs5 //匹配ICMP报文，源为对端System IP，目的为本端System IP，dscp为40（cs5）

traffic classifier lt1 operator and

if-match acl 3777 //匹配对应的acl

traffic behavior lt1 //路由器不需要配置任何behavior

qos policy lt1

classifier lt1 behavior lt1 //流通的QoS Policy

interface Tunnel1 mode sdwan udp

qos apply policy lt1 inbound //隧道下配置入方向流通

执行Ping操作后确认流通结果：

[Spoke1-2-Tunnel1] display qos policy interface Tunnel 1

Interface: Tunnel1

Direction: Inbound

Policy: lt1

Classifier: default-class

Matched : 658 (Packets) 72314 (Bytes)

5-minute statistics:

Forwarded: 0/487 (pps/bps)

Dropped : 0/0 (pps/bps)

Operator: AND

Rule(s) :

If-match any

Behavior: be

-none-

Classifier: lt1

Matched : 6 (Packets) 6238 (Bytes) //只收到了6个报说明中间有丢包。

5-minute statistics:

Forwarded: 0/0 (pps/bps)

Dropped : 0/0 (pps/bps)

Operator: AND

Rule(s) :

If-match acl 3777

Behavior: lt1

-none-

2. Underlay配置流量统计

配置对应ACL匹配对应的探测流量：

acl advanced 3888

rule 0 permit udp source 12.1.1.1 0 destination 12.1.2.1 0 dscp cs5 source-port eq 4799 destination-port eq 4799 //匹配UDP报文，源地址和端口为对端封装地址和端口，目的地址和端口为本端地址和端口，dscp为40（cs5）

traffic classifier lt2 operator and

if-match acl 3888 //匹配对应的acl

traffic behavior lt2 //路由器不需要配置任何behavior

qos policy lt12

classifier lt1 behavior lt2 //流通的QoS Policy

interface GigabitEthernet0/1

qos apply policy lt1 inbound //WAN口下配置入方向流通

执行Ping操作后确认流通结果：

[Spoke1-2-GigabitEthernet0/1] display qos policy interface GigabitEthernet 0/1

Interface: GigabitEthernet0/1

Direction: Inbound

Policy: lt2

Classifier: default-class

Matched : 120 (Packets) 13913 (Bytes)

5-minute statistics:

Forwarded: 0/332 (pps/bps)

Dropped : 0/0 (pps/bps)

Operator: AND

Rule(s) :

If-match any

Behavior: be

-none-

Classifier: lt2

Matched : 6 (Packets) 6804 (Bytes) //只收到了6个报说明中间有丢包。

5-minute statistics:

Forwarded: 0/151 (pps/bps)

Dropped : 0/0 (pps/bps)

Operator: AND

Rule(s) :

If-match acl 3888

Behavior: lt2

-none-

7.2.5 协调抓包

用户如果不认可设备上流通的结果，可以协调用户进行抓包，确认设备是否正常接收到报文。

7.3 设备在线状态震荡

7.3.1 问题描述

设备注册成功后，经常离线然后状态恢复正常，在线状态出现震荡并产生大量告警。

7.3.2 问题排查思路

设备注册在线后，如果出现震荡，基本问题排查思路如图7-6所示。

图7-6 设备在线状态震荡排查思路

7.3.3 排查设备配置

1. 问题排查思路

如果设备是手工开局或者升级局点，需要确认设备上WebSocket注册保活时间是否配置为60秒。查询保活时间：

<Spoke1>display current-configuration | include cloud-management

cloud-management backup-server domain 120.1.1.1

cloud-management backup-server domain 120.1.2.1

cloud-management backup-server domain 192.168.40.23 source-ip 30.1.1.5

cloud-management keepalive 60 //保活时间60秒

2. 问题原因和解决方案

设备默认注册报文时间为180秒，设备间隔180秒发送保活报文。控制组件保活时间为200秒，如果200秒内没有收到保活报文，则认为设备离线。如果不修改设备默认配置，如果一个保活报文被丢掉，设备就会离线。

修改设备保活时间为60秒。

<Spoke1>system-view

[Spoke1]cloud-management keepalive 60

7.3.4 注册地址变化

1. 问题排查思路

查看控制组件告警，设备离线后很快又恢复上线（秒级恢复）。一般情况下是由于设备注册地址变化导致的设备在线状态震荡。

使用管理员登录控制组件，进入[自动化>广域分支网络>物理网络>设备管理]页面，单击设备前面的展开设备详细信息，可以查看设备注册地址，如图7-7所示。有注册状态变化是可以确认注册地址是否修改

图7-7 注册信息查询

2. 问题原因和解决方案

如果设备通过家用宽带注册上线，运营商会周期性回收设备的公网地址，替换为新的公网地址，导致设备使用新的地址注册，设备在线状态震荡。

设备使用新的地址注册，控制组件会认为设备离线并生成告警。用户通过配置优化告警生成，减少由于设备在线状态震荡导致的告警。

使用租户业务管理员登录统一数字底盘，进入[自动化>广域分支网络>网络规划>运维配置 >告警配置]页面，启用告警归类，打开设备下线告警容错功能，如图7-8所示。1分钟内设备上线状态震荡不会生成告警。

图7-8 告警容错

7.3.5 收集控制组件日志反馈研发

如果以上方式都无法排查或优化问题，则需要收集控制组件运行日志和对应的SN码，反馈控制组件日志给研发进行排查。需要收集的日志

(1) 底盘WebSocket日志，收集方法参考底盘WebSocket服务日志。

(2) SDWAN控制组件系统日志，收集方法参考SDWAN控制组件运行日志。

7.4 调度功能不生效

调度功能配置请参考《AD-WAN分支7.2 WAN业务配置指导》。

目前调度选路只能指定本地的出接口，应用流量未按照期望通过指定出接口转发。

7.4.1 控制组件配置排查

参考《AD-WAN分支7.2 WAN业务配置指导》排查一下控制组件相关配置。

7.4.2 设备配置排查

1. 流量入口着色是否成功

控制组件下发对应QoS策略，通过QoS策略进行应用着色，Remark为对应的Flow ID，确认LAN口着色是否成功。登录设备查询相关配置。

查看接口QoS统计：

<SPOKE2-1> display qos policy interface Vlan-interface 50

Interface: Vlan-interface50

Direction: Inbound

Policy: qos-lan

Classifier: default-class

Matched : 0 (Packets) 0 (Bytes)

5-minute statistics:

Forwarded: 0/0 (pps/bps)

Dropped : 0/0 (pps/bps)

Operator: AND

Rule(s) :

If-match any

Behavior: be

-none-

Classifier: sctc

Matched : 3413 (Packets) 4341336 (Bytes) //命中流分类

5-minute statistics:

Forwarded: 0/0 (pps/bps)

Dropped : 0/0 (pps/bps)

Operator: OR

Rule(s) :

If-match acl name shengchan //ACL名称

Behavior: sctb

Marking:

Remark dscp 57

Remark flow-id 123 //remark flow id

Classifier: bgtc

Matched : 0 (Packets) 0 (Bytes)

5-minute statistics:

Forwarded: 0/0 (pps/bps)

Dropped : 0/0 (pps/bps)

Operator: OR

Rule(s) :

If-match acl name bangong

Behavior: bgtb

Marking:

Remark flow-id 124

Remark dscp 58

确认入接口是否有对应的应用流量统计，是否匹配用户打入的流量。如果没有统计可以通过tracert 路径确认流量入口。

2. 确认调度配置

登录对应设备，使用如下命令，查询设备的调度配置是否下发成功。

[SPOKE2-1] display current-configuration configuration rir_sdwan

rir sdwan

link-quality probe interval 300

link-select suppress-period 1

load-balance per-session periodic-adjust enable

link-bandwidth ignore //关闭带宽选路策略后有此配置；开启后无此配置

sla 0

jitter threshold 50

delay threshold 1000

packet-loss threshold 1

sla 1

jitter threshold 10

delay threshold 500

packet-loss threshold 1

sla 2

jitter threshold 5

delay threshold 300

packet-loss threshold 1

sla 3

jitter threshold 5

delay threshold 150

packet-loss threshold 1

sla 4

jitter threshold 5

delay threshold 100

packet-loss threshold 1

sla 5

jitter threshold 3

delay threshold 50

packet-loss threshold 1

sla 6

jitter threshold 2

delay threshold 40

packet-loss threshold 1

sla 7

jitter threshold 1

delay threshold 30

packet-loss threshold 1

flow 123 //flow id

quality-policy sla 1

cqi-weight delay 1 jitter 1 packet-loss 2 //综合质量指标，配置为0的指标调度时不参考

path sdwan transport-network Default.1.ipv4 preference 10 //路径以及优先级

path sdwan transport-network Default.1.ipv6 preference 10

path sdwan transport-network Default.2.ipv4 preference 20

path sdwan transport-network Default.2.ipv6 preference 20

path sdwan transport-network Default.3.ipv4 preference 30

path sdwan transport-network Default.3.ipv6 preference 30

flow 124

cqi-weight delay 1 jitter 1 packet-loss 2

path sdwan transport-network Default.1.ipv4 preference 20

path sdwan transport-network Default.1.ipv6 preference 20

path sdwan transport-network Default.2.ipv4 preference 10

path sdwan transport-network Default.2.ipv6 preference 10

path sdwan transport-network Default.3.ipv4 preference 30

path sdwan transport-network Default.3.ipv6 preference 30

return

通过查询Tunnel配置，确认应用需要优选的Tunnel。

[SPOKE2-1] display current-configuration interface Tunnel

interface Tunnel1 mode sdwan udp

bandwidth 10000

ip address unnumbered interface GigabitEthernet0/1

source GigabitEthernet0/1

tunnel out-interface GigabitEthernet0/1

ipv6 address auto link-local

sdwan interface-id 1

sdwan routing-domain 1 id 1

sdwan transport-network Default.1.ipv4 id 1 //传输网标识，对应flow模板中的path路径

sdwan encapsulation udp-port 4799

sdwan collaboration peer-device-id 2

3. 选路结果排查

通过以下命令可以查询应用流量的转发路径，例如流量优选Tunnel1转发，确认转发路径是否符合预期。

[SPOKE2-1] display tunnel flow-statistics

Flow 0:

Interface Out pps Out bps

Tunnel1 0 72

Flow 123:

Interface Out pps Out bps

Tunnel1 100 1006400 //flow123 流量转发路径tunnel1

隧道综合质量评分排查

可以通过以下命令查询对应Flow的选路配置和CQI符合度，CQI为质量指标，CQI为100标识质量符合

[SPOKE2-1] display rir sdwan flow 123

Flow ID: 123

Session expected bandwidth: 0 kbps

Quality policy: Yes

Tunnels with different preference values:

Preference: 10

Tunnel: 1

SiteID DeviceID InterfaceID CQI

1 1 1 100

Preference: 20

Tunnel: 2

SiteID DeviceID InterfaceID CQI

1 2 2 100

Preference: 30

Tunnel: 4

SiteID DeviceID InterfaceID CQI

1 2 1 100

[SPOKE2-1]

检查设备质量结果

RIR配置了SLA级别支持基于质量的选路，如果隧道质量不符合预期，会导致路径调整，可以通过以下命令查询隧道的质量信息

[SPOKE2-1] display rir sdwan link-quality tunnel 1

Tunnel1:

Interface ID=1

Peer TTE: Site ID=1 Device ID=1 Interface ID=1

Connectivity : Connected

PktLoss (per mill): 0

Delay (msec) : 0

Jitter (msec) : 0

确认到目的设备的链路质量是否符合SLA要求，如果不符合要求可能触发调度。

隧道带宽排查

RIR未关闭带宽策略开关支持基于带宽的选路，如果带宽不符合预期，会导致路径调整，可以通过以下命令查询隧道/物理口带宽使用情况：

[SPOKE2-1] display rir sdwan bandwidth tunnel 1

Tunnel bandwidth info:

Interface Total bandwidth Remaining bandwidth Bandwidth usage

Tun1 10000 kbps 8962 kbps 10 %

Output interface bandwidth info:

PeerTTE: SiteID=1 DeviceID=1 IfID=1

Interface Total bandwidth Remaining bandwidth Bandwidth utilization

GE0/1 10000 kbps 8945 kbps 10 %

确认隧道带宽是否满足选路需求，如果带宽占用超过80%会触发路径调整。

如果以上方式都无法排查，需要收集设备日志反馈研发定位。

7.5 数据包超过路径MTU导致访问异常

站点间业务流量需要经过SDWAN隧道转发，SDWAN隧道封装会导致路径（隧道口）MTU小于实际物理接口的MTU。当转发的数据包大于路径MTU时，需要进行分片。某些业务流量设置不允许分片标志位，导致超过路由MTU的报文被丢弃。

7.5.1 TCP业务流量访问异常

1. 问题现象

业务流量引入SDWAN隧道转发后，WEB或某些TCP应用访问异常（例如FTP）。

2. 问题原因

通常TCP报文都会设置不允许分片标志位，当数据包大于路径MTU时会被丢弃。

抓包可以查询对应报文的不允许分片标志位（置1为不允许分片），如下图所示。

3. 解决方案

通过配置LAN口的TCP MSS值来指定经过LAN口协商的TCP报文最大长度。

方案最佳实践建议TCP MSS配置为1280，减小协商的TCP报文长度，保证TCP报文能正常通过SDWAN隧道转发。

两种修改方式（任选一种即可）：

(1) 进入[自动化>广域分支网络>虚拟网络>VPN管理>LAN网络]页面，选择对应的LAN网络，点击可以修改LAN网络的TCP MSS，如下图所示。

(2) 进入[自动化>广域分支网络>物理网络>设备管理>接口管理]页面，选择对应的设备，选择对应的接口，点击按钮可以修改接口的TCP MSS，如下图所示。

7.5.2 UDP业务流量访问异常

1. 问题现象

业务流量引入SDWAN隧道转发后，UDP应用（例如视频监控、网络认证等）访问异常。

2. 问题原因

某些特定UDP业务报文会设置不允许分片，当数据包大于路径MTU时会被丢弃。

抓包可以查询对应报文的不允许分片标志位（置1为不允许分片），如下图所示。

3. 解决方案

UDP报文没有三次握手协商过程，为了保证UDP报文不分片，只能手动修改隧道口MTU，将隧道口MTU调大，保证报文入隧道不分片。隧道封装后（UDP报文）不允许分片位会被置0，通过物理接口进行分片。

· 修改隧道MTU会影响设备转发性能，建议现网出现问题后再修改隧道MTU。

· 如果需要修改隧道MTU，SDWAN隧道和SDWAN协同隧道都需要修改。

进入[自动化>广域分支网络>物理网络>设备管理 >接口管理]页面，选择对应的设备，选择隧道接口，点击按钮可以修改隧道口的MTU，建议将MTU修改为1500，如下图所示。

接口列表展示的隧道口MTU为隧道口下配置的MTU，缺省情况下隧道口配置的MTU为最大值（和产品定制相关）。此值表示隧道MTU通过自动计算确认，可以通过如下命令查询隧道口的MTU。

<Spoke3> display interface Tunnel 1

Tunnel1

Current state: UP

Line protocol state: UP

Description: sdwan-v4-200-3-1

Bandwidth: 10000 kbps

Maximum transmission unit: 1408 //隧道口的MTU

Internet address: 110.1.5.2/32 (Unnumbered)

Tunnel source 110.1.5.2 (GigabitEthernet4/0), destination unknown

Tunnel TTL 255

Tunnel protocol/transport UDP_SDWAN/IP

Source port number is 12289

Output queue - Urgent queuing: Size/Length/Discards 0/1024/0

Output queue - Protocol queuing: Size/Length/Discards 0/500/0

Output queue - FIFO queuing: Size/Length/Discards 0/75/0

Last clearing of counters: Never

Last 5 seconds input rate: 188 bytes/sec, 1504 bits/sec, 3 packets/sec

Last 5 seconds output rate: 162 bytes/sec, 1296 bits/sec, 2 packets/sec

Input: 20110504 packets, 1221959262 bytes, 3 drops

Output: 19171327 packets, 1493588041 bytes, 23 drops

7.6 3G/4G/5G链路故障处理

7.6.1 故障描述

MSR路由器使用3G/4G/5G接口模块接入Internet，局域网用户无法上网，3G/4G/5G接口模块WWAN指示灯异常。

7.6.2 常见原因

· 3G/4G/5G接口模块或者USB 3G/4G Modem型号和主机型号不匹配。

· 主机软件版本不支持使用该3G/4G/5G接口模块。

· 3G/4G/5G接口模块安装的槽位不正确。

· 3G/4G/5G接口模块未安装到位。

· 3G/4G/5G接口模块热插拔操作不当。

· 3G/4G/5G接口模块或者USB 3G/4G Modem故障。

· 3G/4G/5G Modem未识别。

· SIM卡状态异常。

· 3G/4G/5G网络不稳定。

· 3G/4G/5G接口配置不正确。

7.6.3 故障分析

本类故障的诊断流程如图7-9所示。

图7-9 3G/4G/5G链路故障诊断流程图

7.6.4 处理步骤

1. 检查3G/4G/5G接口模块或者USB 3G/4G Modem状态

(1) ‍检查3G/4G/5G接口模块上的指示灯，如果所有指示灯均熄灭，则执行display device和display device manuinfo命令，查看Slot和电子标签信息。

<Sysname> display device

Slot No. Board Type Status Max Ports

--------------------------------------------------------------

0 RPU Normal 30

1 Unknown Abnormal Unknown

<Sysname>display device manuinfo

...

Slot 1:

DEVICE_NAME : NONE

DEVICE_SERIAL_NUMBER : NONE

MAC_ADDRESS : NONE

MANUFACTURING_DATE : NONE

VENDOR_NAME : NONE

(2) 如果Slot状态显示为Unknown，电子标签等相关信息显示为NONE。确认接口模块的型号是否和主机型号匹配，以及接口模块安装在主机的槽位是否正确，具体请参见《H3C MSR系列路由器接口模块手册》；如果是USB 3G/4G Modem，请联系技术支持确认主机是否支持该Modem。

(3) 确认接口模块是否安装到位。若未安装好，请重新拔插一下接口模块。重新插入前务必检查接口模块的连接器状态，看连接器是否变形、脏污。

(4) 将接口模块放到别的槽位，或者将主机上别的正常的接口模块放到这个槽位，进一步确认是不是接口模块故障。

(5) 仅部分带有REMOVE按钮接口模块支持热插拔，但是需要通过操作REMOVE按钮后再拔出接口模块，操作不当会导致设备或接口模块异常。如果已经带电拔插过接口模块，请尝试给主机断电重启恢复。

(6) 确认主机软件版本是否支持该接口模块。

a. ‍通过display version命令查看主机软件版本；

b. 联系技术支持，确认当前主机软件版本是否支持该接口模块；

c. 如果当前软件版本不支持该接口模块，请升级到正确版本。

(7) 如果是USB 3G/4G Modem，请把Modem插到PC上，待识别后查看以下信息，看PC是否能正常识别该Modem。

图7-10 计算机管理

图7-11 详细信息

2. 检查3G/4G/5G Modem状态

(1) ‍如果3G/4G/5G接口模块的信息可以正常显示，但是无法显示3G/4G/5G Modem的信息。

执行display cellular命令，无法显示Cellular接口信息。

<Sysname> display cellular 2/4/0

% Wrong parameter found at '^' position.

(2) 确认MSR路由器的款型和槽位是否正确。若不正确，请在支持的路由器的正确槽位上使用接口模块，具体请参见《H3C MSR系列路由器接口模块手册》。

(3) 确认接口模块是否外观有损伤、槽位的针脚是否有损伤。

(4) 确认是否已经通过remove命令或者“REMOVE”按钮将接口模块remove掉。部分带有REMOVE按钮的接口模块，若REMOVE指示灯熄灭，请重新拔插接口模块或者在用户视图下执行reboot命令重启接口模块。

(5) 确认接口模块是否在重启，接口模块完成初始化需要一定时间，请等待1-2分钟。

(6) 确认设备的版本是否正确。路由器版本需要升级到支持该Modem版本。若不正确，请升级版本。

(7) 部分CDMA制式的3G Modem不插SIM卡无法识别，请插入SIM卡后再测试。这些3G Modem也不支持4G SIM卡，所以插入4G SIM卡也无法识别。

(8) 仅部分带有REMOVE按钮接口模块支持热插拔，但是需要通过操作REMOVE按钮后再拔出接口模块，操作不当会导致设备或接口模块异常。如果已经带电拔插过接口模块，请尝试给主机断电重启恢复。

3. 检查SIM卡状态

(1) ‍3G/4G/5G接口模块和3G/4G/5G Modem的信息都可以正常显示，但无法拨号成功并获取IP地址。查看接口模块的WWAN指示灯，如果为常灭，表明无线广域网链路处于未连接状态。执行display ip interface brief，通道化以太网接口没有获取IP地址。

<Sysname> display ip interface brief

*down: administratively down

(s): spoofing (l): loopback

Interface Physical Protocol IP address/Mask VPN instance Description

E-Ch2/4/0:0 down down -- -- --

(2) 请确认SIM卡与Modem支持的制式是否匹配。比如WCDMA制式的Modem插中国电信（CDMA运营商）SIM卡就无法注册网络。

(3) 请确认SIM卡的状态是否正常，SIM卡有“OK、Not Inserted、Locked、Unknown、Network Reject”等状态，执行display cellular命令查看SIM卡状态。

<Sysname> display cellular 2/4/0

...

SIM Status: OK

...

¡ OK表示正常，无需处理。

¡ Not Inserted表示SIM安装异常，请检查SIM卡是否插好以及外观是否有损坏。

SIM卡的缺口方向一定要与卡槽的缺口方向对应上，SIM卡芯片面朝下，保证SIM卡接触良好；也可以再找一台设备或手机SIM卡，做SIM卡交叉测试；如果也没有问题，建议升级设备为最新的软件版本。

¡ Locked表示被锁定，请先解锁后再使用。若未完全锁定可以通过PUK码解锁，执行pin unlock命令进行解锁；若完全锁定则需要到营业厅解锁。

<Sysname> system-view

[Sysname] controller Cellular 2/4/0

[Sysname-Cellular2/4/0]pin unlock 87654321 1234

PIN will be unlocked and changed to “1234”. Continue? [Y/N]:y

PIN has been unlocked and changed successfully.

¡ Unknown表示状态未知。请尝试重新拔插SIM卡或执行modem reboot命令重启Modem。

<Sysname> system-view

[Sysname] controller cellular 2/4/0

[Sysname-Cellular2/4/0] modem reboot

¡ Network Reject表示SIM卡被拒绝接入网络。该状态处理方式同Locked和Unknown。

(4) 请确认SIM卡是否欠费。执行display cellular命令，查看Modem信息。如果“Current Service Status:Emergency”，打电话给营业厅确认。如果欠费再充值后，运营商开机了，重启一下Modem或者将该SIM卡插入手机看是否能上网。

<Sysname> display cellular 2/4/0

...

Network Information:

Current Service Status:Emergency

...

4. 检查3G/4G/5G网络信号状态

(1) ‍如果3G/4G/5G接口模块和3G/4G/5G Modem的信息都可以正常显示，SIM卡状态也是正常，请查看当前3G/4G/5G网络信号状态。3G/4G/5G接口模块都提供有网络信号强度的指示灯，例如5G接口模块提供有5G指示灯，如果5G指示灯常灭，表示无信号；如果5G指示灯慢闪，表示5G信号弱。不同接口模块指示灯情况有差异，具体请参见《H3C MSR系列路由器接口模块手册》。

(2) 如果不方便查看指示灯状态，也可以通过执行display cellular命令查看当前网络的信号强度。

¡ 3G Modem可以使用RSSI表示信号强度，其值在-90dBm以下表示信号非常差，可能会影响业务正常使用。

<Sysname> display cellular 2/4/0

...

Radio Information:

Current Band: ANY

Current RSSI: -51 dBm

¡ 4G Modem除了查看RSSI外，还要查看RSRP，RSRP在-100dBm以下表示信号非常差。

<Sysname> display cellular 2/4/0

...

LTE related info:

Current RSSI: -79 dBm

Current RSRQ: -9 dB

Current RSRP: -106 dBm

Current SNR: 5 dB

¡ 5G Modem查看5G NR的信号强度，RSRP在-89dBm以下表示信号较弱，－100dB左右就可能无法驻入5G。

<Sysname> display cellular 2/4/0

...

Radio Information:

Technology Preference: No preference specified (AUTO)

Technology Selected: NR && LTE

Configured LTE Band = 1,2,3,4,5,7,8,12,13,14,17,18,19,20,25,26,28,29,30,32,34,38,39,40,41,42,43

5G availability under LTE system info:

Current PCI: 537

Endc Available: 1

Restrict Dcnr: 0

R15Availabe: 1

NR related info:

Current RSRQ: -12 dB

Current RSRP: -93 dBm

Current SNR: 14 dB

LTE related info:

Current RSSI: -65 dBm

Current RSRQ: -13 dB

Current RSRP: -103 dBm

Current SNR: -2 dB

Tx Power: 10 dBm

(3) 如果确认3G/4G/5G无信号，请先检查天线是否正常连接。

a. ‍设备内置模块和SIC卡必须安装外置天线，USB Modem不需要。另外，3G Modem可以只安装一根天线，但是天线必须安装到“MAIN”天线接口，不能接到“DIV”天线接口；4G Modem必须安装2根天线；5G Modem建议使用4根天线。

b. 如果天线连接正常，请继续确认周围是否有3G/4G/5G网络覆盖。可以使用手机或其他终端插SIM卡尝试，看是否能拨号成功。如果不行，请联系运营商解决。

(4) 如果确认3G/4G/5G信号比较弱，建议调整天线位置来增强无线信号。请注意，天线的方向一般要竖直向上，棒状天线之间可以呈八字状或剪刀状错开。在室内信号比较弱的地方，也可以通过增加天线延长线方式来增强无线信号。

5. 检查3G/4G/5G接口的配置

(1) ‍如果3G/4G/5G接口模块的各项指示灯显示正常，但是3G/4G/5G链路仍然无法正常工作，此时，可以检查下3G/4G/5G Cellular接口的配置是否正确。3G/4G/5G Cellular接口的配置，请参见配套配置手册中“二层技术-广域网接入配置指导”内的“移动通信Modem管理配置”。一般建议配置永久在线模式，如果配置了按需拨号，需要流量才能触发拨号，ping几个包试试Eth-channel接口是否能够UP。

(2) 如果是USB 4G Modem，由于USB 4G Modem模块不支持通过配置命令来管理Modem模块，具体配置请参考对应主机的Web配置指导手册。

(3) 如果是连接VPDN网络，需要向运营商咨询正确的APN、用户名和密码。

¡ 对于3G Modem，可以通过profile create命令设置APN、用户名和密码。

<Sysname> system-view

[Sysname] controller cellular 2/4/0

[Sysname-Cellular2/4/0] profile create 1 static cmnet authentication-mode pap user abc password abc

¡ 对于4G/5G Modem，可以通过apn-profile命令设置APN、用户名和密码。

[Sysname] apn-profile test

[Sysname-apn-profile-test]apn static 3gnet

[Sysname-apn-profile-test]authentication-mode chap user card password simple card

(4) 请检查是否配置了当前运营商SIM卡不支持的band。band是用来配置模块工作的频段，各运营商SIM卡支持的band都不相同，一般缺省配置多个band来同时支持这些频段。如果该SIM卡支持的band不在这些缺省配置的band中或者配置限定到某些band，但是该SIM卡不支持，就会导致拨号失败。所以，如无必要，无需修改band配置，如果因为已配置了不支持的band而导致拨号失败，可以通过删除band配置来恢复。

(5) 如果Modem配置了IMSI绑定，但配置的IMSI号和实际使用的SIM卡IMSI不一致，会导致拨号失败。可以通过执行display cellular命令查看SIM卡的IMSI串号。

<sysname>display cellular 2/4/0

Cellular2/4/0:

Modem State:

Hardware Information:

Model: RM500QGL_VH

Manufacturer: QUALCOMM INCORPORATED

Modem Firmware Version: RM500QGLABR01A01M4G

International Mobile Equipment Identity (IMEI): 863305040121609

International Mobile Subscriber Identity (IMSI): 460028012255957

Hardware Version: 20000

Modem Status: Online

Modem Status: IPv4 Active.

...

(6) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息、告警信息。

8 安全接入与保障类故障处理

8.1 SSH故障处理

8.1.1 SSH客户端登录设备失败

1. 故障描述

设备作为SSH服务器，用户使用SSH客户端登录设备失败。

2. 常见原因

本类故障的常见原因主要包括：

· SSH客户端与设备之间路由不通，无法建立TCP连接。

· 设备未开启SSH服务器功能。

· 设备上配置了对SSH客户端的访问控制，且客户端的IP地址不在ACL定义的permit规则范围内。

· 客户端指定的服务端口号与服务器端不一致。

· 设备上的SSH版本与客户端不兼容。

· 设备上未生成本地密钥对。

· 服务器公钥与设备上缓存的公钥不一致。

· 用户线的认证方式或接入协议配置不正确。

· 设备上的本地用户视图下未配置SSH服务。

· SSH用户的服务类型或认证方式配置不正确。

· 设备上SSH2协议使用的算法与客户端不匹配。

· 设备上VTY用户线资源不足。

· 设备上SSH登录用户数达到上限。

3. 故障分析

本类故障的诊断流程如图8-1所示。

图8-1 SSH登录失败故障诊断流程图

4. 处理步骤

(1) ‍检查客户端能否Ping通设备。

使用ping命令检查网络连接情况。

¡ 如果Ping不通，请参见“Ping和Tracert故障处理”中的“Ping不通”继续定位，确保SSH客户端能Ping通服务器端。

¡ 如果可以Ping通，请执行步骤(2)。

(2) 检查SSH服务器功能是否开启。

当设备上出现如下日志时，表示SSH服务器功能未开启。

SSHS/6/SSHS_SRV_UNAVAILABLE: The SCP server is disabled or the SCP service type is not supported.

可以在设备上执行display ssh server status命令，检查Stelnet服务器功能、SFTP服务器功能、NETCONF over SSH服务器功能和SCP服务器功能是否按需开启。

<Sysname> display ssh server status

Stelnet server: Disable

SSH version : 2.0

SSH authentication-timeout : 60 second(s)

SSH server key generating interval : 0 hour(s)

SSH authentication retries : 3 time(s)

SFTP server: Disable

SFTP Server Idle-Timeout: 10 minute(s)

NETCONF server: Disable

SCP server: Disable

¡ 如果未开启，请在设备上执行如下命令，开启相关的SSH服务器功能。

<Sysname> system-view

[Sysname] ssh server enable

[Sysname] sftp server enable

[Sysname] scp server enable

[Sysname] netconf ssh server enable

¡ 如果已开启，请执行步骤(3)。

(3) 检查是否设置了对客户端的访问控制。

首先检查设备上是否通过ssh server acl命令设置了对客户端的访问控制。

¡ 如果已设置，请检查客户端的IP地址是否在ACL的permit规则中。

¡ 当设备上出现如下日志时，表示客户端的IP地址不在ACL的permit规则中。

SSHS/5/SSH_ACL_DENY: The SSH connection 181.1.1.10 request was denied according to ACL rules.

SSHS/5/SSH_ACL_DENY: The SSH connection 181.1.1.11 request was denied according to ACL rules.

- 如果不在，请修改ACL配置，使得客户端的IP地址在ACL的permit规则中。如果对所有SSH客户端都不需要进行访问控制，请删除对客户端的访问控制。

- 如果在，请执行步骤(4)。

¡ 如果未设置，请执行步骤(4)。

(4) 检查客户端指定的服务端口号是否与服务器端一致。

如果服务器端修改了SSH服务端口号，客户端仍然使用缺省端口号登录时，会出现登录失败。

以H3C设备作为客户端为例，会出现如下错误提示信息：Failed to connect to host 10.1.1.1 port 100.

¡ 如果客户端登录时指定的端口号与服务器端不一致，请在服务器端设备上执行display current-configuration | include ssh命令查看服务器端配置的端口号，将客户端登录时指定的端口修改为与服务器端一致。

¡ 如果客户端登录时指定的端口号与服务器端一致，请执行步骤(5)。

(5) 检查服务器的SSH版本与客户端版本是否兼容。

当设备上出现如下日志时，表示设备的SSH版本与客户端版本不兼容。

SSHS/6/SSHS_VERSION_MISMATCH: SSH client 192.168.30.117 failed to log in because of version mismatch.

如果使用SSH1版本的客户端登录设备，可以在设备上执行display ssh server status命令查看SSH version字段确认SSH版本。

¡ 如果SSH version显示为1.99，则表示设备可以兼容SSH1版本的客户端，请执行步骤(6)。

¡ 如果SSH version显示为2.0，请在设备上执行ssh server compatible-ssh1x enable命令设置设备兼容SSH1版本的客户端。

(6) 检查服务器上是否生成了本地密钥对。

设备作为SSH服务器时，必须配置本地非对称密钥对。虽然一个客户端只会采用DSA、ECDSA或RSA公钥算法中的一种来认证服务器，但是由于不同客户端支持的公钥算法不同，为了确保客户端能够成功登录服务器，建议在服务器上生成DSA、ECDSA和RSA三种密钥对。

在设备上执行display public-key local public命令查看当前设备上的密钥对信息。

¡ 如果DSA、ECDSA和RSA三种密钥对都不存在，请在系统视图下执行public-key local create命令依次进行配置。

¡ 如果已配置，请执行步骤(7)。

(7) 检查服务器公钥与客户端上缓存的服务器公钥是否一致。

如果客户端首次登录服务器设备时选择保存了服务器端公钥，当服务器设备更新本地密钥对后，将会导致客户端认证服务端失败。

以H3C设备作客户端为例，当客户端登录时，出现如下提示信息，则表示服务器公钥与客户端上本地缓存的服务器公钥不一致。

The server's host key does not match the local cached key. Either the server administrator has changed the host key, or you connected to another server pretending to be this server. Please remove the local cached key, before logging in!

¡ 如果不一致，请执行delete ssh client server-public-key命令，删除客户端保存的旧的服务端公钥。

¡ 如果一致，请执行步骤(8)。

(8) 查看VTY用户线下配置的认证方式及允许接入的协议是否正确。

当客户端为Stelnet客户端和NETCONF over SSH客户端时，需要在VTY用户线视图下，执行display this命令查看配置的认证方式是否为scheme、允许接入的协议是否包含SSH。

[Sysname] line vty 0 63

[Sysname-line-vty0-63] display this

line vty 0 63

authentication-mode scheme

user-role network-admin

idle-timeout 0 0

¡ 如果认证方式或者接入协议配置不正确，请将认证方式修改为scheme、将允许接入的协议修改为包含SSH。

¡ 如果均配置正确，请执行步骤(9)。

(9) 检查本地用户是否授权了SSH服务。（仅针对本地认证）

在本地用户视图下，执行display this命令查看用户可以使用的服务类型是否包含SSH。

[Sysname] local-user test

[Sysname-luser-manage-test] display this

local-user test class manage

service-type ssh

authorization-attribute user-role network-admin

authorization-attribute user-role network-operator

¡ 如果不包含，请在本地用户视图下通过service-type命令修改配置。

¡ 如果包含，请执行步骤(10)。

如果为远程认证方式，请参见“AAA故障处理”进行定位。

(10) 检查是否配置了SSH用户并指定正确的服务类型和认证方式。

SSH支持Stelnet、SFTP、NETCONF和SCP四种用户服务类型。

首先，根据服务器采用的认证类型，根据如下规则，查看设备上是否创建正确的SSH用户。

¡ 如果服务器采用了publickey认证，则必须在设备上创建相应的SSH用户，以及同名的本地用户（用于下发授权属性：工作目录、用户角色）。

¡ 如果服务器采用了password认证，则必须在设备上创建相应的本地用户（适用于本地认证），或在远程服务器（如RADIUS服务器，适用于远程认证）上创建相应的SSH用户。这种情况下，并不需要通过本配置创建相应的SSH用户，如果创建了SSH用户，则必须保证指定了正确的服务类型以及认证方式。

¡ 如果服务器采用了keyboard-interactive、password-publickey或any认证，则必须在设备上创建相应的SSH用户，以及在设备上创建同名的本地用户（适用于本地认证）或者在远程认证服务器上创建同名的SSH用户（如RADIUS服务器，适用于远程认证）。

接着，根据检查的结果，进行如下操作：

¡ 如果未创建且无需创建，请执行步骤(11)；如果未创建但有需求创建，请通过ssh user命令进行配置。

¡ 如果已创建，检查SSH用户的服务类型和认证方式。

- SSH用户指定的服务类型必须与客户端类型（Stelnet客户端、SFTP客户端、SCP客户端和NETCONF over SSH客户端）相匹配，否则将会因为服务类型不匹配而登录失败。SSH用户服务类型是否正确，通过如下方式来检查：

- 以SCP客户端为例，如果设备上出现如下日志，表示服务类型不匹配。SSHS/6/SSHS_SRV_UNAVAILABLE: The SCP server is disabled or the SCP service type is not supported.

- 请在设备系统视图下执行ssh user命令，修改SSH用户的服务类型。

- 请在设备上执行display ssh user-information命令，查看SSH服务器采用的认证方式，根据具体的认证方式检查设备上SSH用户的配置是否正确。

(11) 检查设备上SSH2协议使用的算法列表是否与客户端匹配。

通过display ssh2 algorithm命令查看当前SSH2协议使用的算法列表，检查客户端支持的算法是否包含在算法列表中。比如，设备上配置了不使用CBC相关的加密算法，但SSH客户端仅支持CBC相关加密算法，将导致该客户端无法登录服务器。

当设备上出现如下日志信息时，表示设备上SSH2协议使用的算法列表是否与客户端不匹配。

SSHS/6/SSHS_ALGORITHM_MISMATCH: SSH client 192.168.30.117 failed to log in because of encryption algorithm mismatch.

¡ 如果客户端使用的算法与设备上的算法不匹配，可通过如下两种方式进行修改：

- 设备可以通过执行ssh2 algorithm cipher、ssh2 algorithm key-exchange、ssh2 algorithm mac或ssh2 algorithm public-key命令修改相关算法列表，增加客户端支持的算法。

- 在客户端添加服务端支持的相关算法。

¡ 如果客户端使用的算法与设备上的算法能够匹配，请执行步骤(12)。

(12) 检查设备上VTY用户数是否达到允许用户数的上限。

SSH用户与Telnet用户登录均使用VTY用户线，但是VTY用户线是有限资源。若VTY类型用户线都已被占用，则后续使用Stelnet及NETCONF over SSH服务的客户端将无法登录，使用SFTP及SCP服务的客户端不占用用户线资源，不受影响，仍可登录。

当设备上出现如下日志时，表示设备上VTY用户数已达到允许用户数的上限。

SSHS/6/SSHS_REACH_USER_LIMIT: SSH client 192.168.30.117 failed to log in, because the number of users reached the upper limit.

通过display line命令查看VTY用户线资源是否充足。

¡ 如果VTY用户线资源不足，可将空闲且非scheme认证方式的VTY类型用户线认证方式修改为scheme认证方式；若所有VTY类型用户线都已是scheme认证方式且均处于active状态，可执行free ssh命令强制释放已建立的部分SSH连接或者执行free line vty命令强制释放VTY用户线，使得新的SSH用户能够上线。

¡ 如果VTY用户线资源充足，请执行步骤(13)。

(13) 检查登录服务器的SSH用户数是否达到允许用户数的上限。

通过display ssh server session命令查看服务器的会话信息，以及查看通过aaa session-limit ssh命令配置的SSH最大用户连接数。

当设备上出现如下日志时，表示登录服务器的SSH用户数已达到允许用户数的上限。

SSHS/6/SSHS_REACH_SESSION_LIMIT: SSH client 192.168.30.117 failed to log in. The number of SSH sessions is 10, and exceeded the limit (10).

¡ 如果SSH会话数已达到上限，可通过执行aaa session-limit ssh命令调大上限；如果配置的最大用户连接数已为可配置的最大值，可执行free ssh命令强制释放已建立的部分SSH连接或者在客户端下线空闲的SSH客户端，使得新的SSH用户能够上线。

¡ 如果未达上限，请执行步骤(14)。

(14) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息、告警信息。

5. 告警与日志

8.1.2 设备作为SSH服务器，用户使用password认证方式登录失败

1. 故障描述

设备作为SSH服务器，用户使用密码认证登录设备失败。

2. 常见原因

本类故障的常见原因主要包括：

· SSH客户端与设备之间路由不通，无法建立TCP连接。

· SSH客户端登录密码不正确。

· 设备未开启SSH服务器功能。

· SSH服务器上不存在该SSH登录用户。

· 设备上配置了对SSH客户端的访问控制，且客户端的IP地址不在ACL定义的permit规则范围内。

· 设备上SSH登录用户数达到上限。

· 设备上的SSH版本与客户端不兼容。

· SSH用户的服务类型或认证方式配置不正确。

· 设备上未生成本地密钥对。

· SCP/SFTP工作目录不正确。

3. 故障分析

本类故障的诊断流程如图8-2所示。

图8-2 SSH客户端使用password认证方式登录服务器失败（设备作为服务器）故障诊断流程图

4. 处理步骤

(1) ‍检查客户端能否Ping通设备。

使用ping命令查看网络连接情况。

¡ 如果Ping不通，请参见“Ping和Tracert故障处理”中的“Ping不通”继续定位，确保SSH客户端能Ping通服务器端。

¡ 如果可以Ping通，请执行步骤(2)。

(2) 检查登录密码是否正确。

a. ‍如果服务器采用本地认证，请确认当前用户登录的密码是否与设备上设备管理类本地用户视图下配置的密码一致：

- 如果不一致，请重新输入正确的密码。若忘记密码，可以进入设备管理类本地用户视图（用户名为当前登录的用户）下，执行password命令重新配置新的密码，确保登录密码与配置的密码一致。

- 如果一致，请执行步骤(3)。

b. 如果服务器采用远程认证，请确认当前用户登录的密码是否与认证服务器上配置的一致：

- 如果不一致，请重新输入正确的密码。若忘记密码，可以在服务器上为登录用户重新设置密码，确保登录密码与认证服务器上配置的一致。

- 如果一致，请执行步骤(3)。

(3) 检查SSH服务器功能是否开启。

当设备上出现如下日志时，表示SSH服务器功能未开启。

SSHS/6/SSHS_SRV_UNAVAILABLE: The SCP server is disabled or the SCP service type is not supported.

可以在设备上执行display ssh server status命令，检查Stelnet服务器功能、SFTP服务器功能、NETCONF over SSH服务器功能和SCP服务器功能是否按需开启。

<Sysname> display ssh server status

Stelnet server: Disable

SSH version : 2.0

SSH authentication-timeout : 60 second(s)

SSH server key generating interval : 0 hour(s)

SSH authentication retries : 3 time(s)

SFTP server: Disable

SFTP Server Idle-Timeout: 10 minute(s)

NETCONF server: Disable

SCP server: Disable

¡ 如果未开启，请在设备上执行如下命令，开启相关的SSH服务器功能。

<Sysname> system-view

[Sysname] ssh server enable

[Sysname] sftp server enable

[Sysname] scp server enable

[Sysname] netconf ssh server enable

¡ 如果已开启，请执行步骤(4)。

(4) 检查客户端指定的服务端口号是否与服务器端一致。

如果服务器端修改了SSH服务端口号，客户端仍然使用缺省端口号登录时，会出现登录失败。

以H3C设备作为客户端为例，会出现如下错误提示信息：Failed to connect to host 10.1.1.1 port 22.

¡ 如果客户端登录时指定的端口号与服务器端一致，请执行步骤(5)。

(5) 检查是否设置了对客户端的访问控制。

首先检查设备上是否通过ssh server acl命令设置了对客户端的访问控制。

¡ 如果已设置，请检查客户端的配置是否在ACL的permit规则中，请先在设备上通过ssh server acl-deny-log enable命令开启匹配ACL deny规则后打印日志信息功能。

¡ 当设备上出现如下日志时，表示客户端的IP地址不在ACL的permit规则中。

SSHS/5/SSH_ACL_DENY: The SSH Connection 181.1.1.10 request was denied according to ACL rules.

SSHS/5/SSH_ACL_DENY: The SSH Connection 181.1.1.11 request was denied according to ACL rules.

- 如果不在，请修改ACL配置，使得客户端的IP地址在ACL的permit规则中。如果对所有SSH客户端都不需要进行访问控制，请删除对客户端的访问控制。

- 如果在，请执行步骤(6)。

¡ 如果未设置，请执行步骤(6)。

(6) 检查服务器的SSH版本与客户端版本是否兼容。

当设备上出现如下日志时，表示设备的SSH版本与客户端版本不兼容。

SSHS/6/SSHS_VERSION_MISMATCH: SSH client 192.168.30.117 failed to log in because of version mismatch.

如果使用SSH1版本的客户端登录设备，可以在设备上执行display ssh server status命令查看SSH version字段确认SSH版本。

¡ 如果SSH version显示为1.99，则表示设备可以兼容SSH1版本的客户端，请执行步骤(7)。

¡ 如果SSH version显示为2.0，请在设备上执行ssh server compatible-ssh1x enable命令设置设备兼容SSH1版本的客户端。

(7) 查看VTY用户线下配置的认证方式及允许接入的协议是否正确。

当客户端为Stelnet客户端或NETCONF over SSH客户端时，需要在VTY用户线视图下，执行display this命令查看配置的认证方式是否为scheme、允许接入的协议是否包含SSH。

[Sysname] line vty 0 63

[Sysname-line-vty0-63] display this

line vty 0 63

authentication-mode scheme

user-role network-admin

idle-timeout 0 0

¡ 如果认证方式或者接入协议配置不正确，请通过authentication-mode scheme命令将认证方式修改为scheme、通过protocol inbound ssh命令将允许接入的协议修改为包含SSH。

¡ 如果均配置正确，请执行步骤(8)。

(8) 检查设备上VTY用户数是否达到允许用户数的上限。

当设备上出现如下日志时，表示设备上VTY用户数已达到允许用户数的上限。

SSHS/6/SSHS_REACH_USER_LIMIT: SSH client 192.168.30.117 failed to log in, because the number of users reached the upper limit.

通过display line命令查看VTY用户线资源是否充足。

¡ 如果VTY用户线资源充足，请执行步骤(9)。

(9) 检查登录服务器的SSH用户数是否达到允许用户数的上限。

通过display ssh server session命令查看服务器的会话信息，以及查看通过aaa session-limit ssh命令配置的SSH最大用户连接数。

当设备上出现如下日志时，表示登录服务器的SSH用户数已达到允许用户数的上限。

SSHS/6/SSHS_REACH_SESSION_LIMIT: SSH client 192.168.30.117 failed to log in. The number of SSH sessions is 10, and exceeded the limit (10).

¡ 如果未达上限，请执行步骤(10)。

(10) 检查服务器上是否生成了本地密钥对。

为了防止“伪服务器欺骗”，客户端验证服务器身份时，首先判断服务器发送的公钥与本地保存的服务器公钥是否一致，确认服务器公钥正确后，再使用该公钥对服务器发送的数字签名进行验证。如果客户端没有保存服务器的公钥或保存的服务器公钥不正确，则服务器身份验证将会失败，从而导致客户端无法登录服务器。因此，客户端登录服务器之前，需要先在服务器端创建密钥对，并将正确的服务器公钥保存在客户端。

虽然一个客户端只会采用DSA、ECDSA或RSA公钥算法中的一种来认证服务器，但是由于不同客户端支持的公钥算法不同，为了确保客户端能够成功登录服务器，建议在服务器上生成DSA、ECDSA和RSA三种密钥对。

在设备上执行display public-key local public命令查看当前设备上的密钥对信息。

¡ 如果DSA、ECDSA和RSA三种密钥对都不存在，请执行public-key local create命令依次进行配置，并确保将服务器上生成的公钥保存到客户端。

¡ 如果已配置，请执行步骤(11)。

(11) 检查是否配置了SSH用户并指定正确的服务类型和认证方式。

SSH支持Stelnet、SFTP、NETCONF和SCP四种用户服务类型。

首先，根据服务器采用的认证类型，查看设备上是否创建正确的SSH用户。

由于服务器采用了password认证，必须在设备上创建相应的本地用户（适用于本地认证），或在远程服务器（如RADIUS服务器，适用于远程认证）上创建相应的SSH用户。对于采用远程认证方式的情况，不需要通过本配置创建相应的SSH用户，如果创建了SSH用户，则必须保证指定了正确的服务类型以及认证方式。

接着，根据检查的结果，进行如下操作：

¡ 如果未创建且无需创建，请执行步骤(12)；如果未创建且需要创建，请通过ssh user命令进行配置。

¡ 如果已创建，检查SSH用户的服务类型和认证方式。

- 请在设备上执行display ssh user-information命令，分别通过“Service-type”和“Authentication-type”字段查看SSH用户的服务类型及认证方式。其中，服务类型必须与客户端类型（Stelnet客户端、SFTP客户端、SCP客户端或NETCONF over SSH客户端）相匹配，认证方式必须为password。

- 请在设备系统视图下执行ssh user命令，将SSH用户的服务类型和认证方式修改正确。

(12) 检查SCP/SFTP工作目录配置是否正确。

当SSH用户的服务方式为SCP/SFTP时，需要为用户设置授权目录。如果所配置的授权目录不存在，SCP/SFTP客户端通过该用户连接SCP/SFTP服务器就会失败。对于password认证方式的用户，请检查通过AAA授权的工作目录是否存在。

¡ 如果不存在，请通过本地用户视图下的authorization-attribute work-directory directory-name命令修改授权的工作目录。

¡ 如果存在，请执行步骤(13)。

(13) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息、告警信息。

5. 告警与日志

8.1.3 设备作为SSH服务器，用户使用publickey认证方式登录失败

1. 故障描述

设备作为SSH服务器，用户使用公钥认证登录失败。

2. 常见原因

本类故障的常见原因主要包括：

· SSH客户端与设备之间路由不通，无法建立TCP连接。

· 服务器端配置的用户公钥不正确。

· 设备未开启SSH服务器功能。

· SSH服务器上不存在该SSH登录用户。

· 设备上配置了对SSH客户端的访问控制，且客户端的IP地址不在ACL定义的permit规则范围内。

· 设备上SSH登录用户数达到上限。

· 设备上的SSH版本与客户端不兼容。

· SSH用户的服务类型或认证方式配置不正确。

· 设备上未生成本地密钥对。

· SCP/SFTP工作目录不正确。

3. 故障分析

本类故障的诊断流程如图8-3所示。

图8-3 SSH客户端使用publickey认证方式登录服务器失败（设备作为服务器）故障诊断流程图

4. 处理步骤

(1) ‍检查客户端能否Ping通设备。

使用ping命令查看网络连接情况。

¡ 如果Ping不通，请参见“Ping和Tracert故障处理”中的“Ping不通”继续定位，确保SSH客户端能Ping通服务器端。

¡ 如果可以Ping通，请执行步骤(2)。

(2) 检查服务器端配置的用户公钥和用户使用的私钥是否匹配。

SSH客户端可能支持多种公钥算法，每种公钥算法对应不同的非对称密钥对。只有服务器端保存的用户公钥类型与用户登录时使用的私钥类型一致时，用户认证才会成功。例如，服务器端为某用户指定了DSA类型的公钥，用户也持有与之相匹配的私钥，但是登录时用户使用的私钥类型为RSA，此时用户认证会失败。通过在设备上执行display public-key peer命令查看保存在设备上的客户端公钥信息，判断是否与正在登录用户使用的私钥类型一致：

¡ 如果不一致，请执行public-key local create命令在设备上生成相应类型的密钥对。

¡ 如果一致，请执行步骤(3)。

(3) 检查SSH服务器功能是否开启。

当设备上出现如下日志时，表示SSH服务器功能未开启。

SSHS/6/SSHS_SRV_UNAVAILABLE: The SCP server is disabled or the SCP service type is not supported.

可以在设备上执行display ssh server status命令，检查Stelnet服务器功能、SFTP服务器功能、NETCONF over SSH服务器功能和SCP服务器功能是否按需开启。

<Sysname> display ssh server status

Stelnet server: Disable

SSH version : 2.0

SSH authentication-timeout : 60 second(s)

SSH server key generating interval : 0 hour(s)

SSH authentication retries : 3 time(s)

SFTP server: Disable

SFTP Server Idle-Timeout: 10 minute(s)

NETCONF server: Disable

SCP server: Disable

¡ 如果未开启，请在设备上执行如下命令，开启相关的SSH服务器功能。

<Sysname> system-view

[Sysname] ssh server enable

[Sysname] sftp server enable

[Sysname] scp server enable

[Sysname] netconf ssh server enable

¡ 如果已开启，请执行步骤(4)。

(4) 检查客户端指定的服务端口号是否与服务器端一致。

如果服务器端修改了SSH服务端口号，客户端仍然使用缺省端口号登录时，会出现登录失败。

以我司设备作为客户端为例，会出现如下错误提示信息：Failed to connect to host 10.1.1.1 port 100.

¡ 如果客户端登录时指定的端口号与服务器端一致，请执行步骤(5)。

(5) 检查是否设置了对客户端的访问控制。

首先检查设备上是否通过ssh server acl命令设置了对客户端的访问控制。

¡ 如果已设置，请检查客户端配置是否在ACL的permit规则中，请先在设备上通过ssh server acl-deny-log enable命令开启匹配ACL deny规则后打印日志信息功能。

¡ 当设备上出现如下日志时，表示客户端的IP地址不在ACL的permit规则中。

SSHS/5/SSH_ACL_DENY: The SSH Connection 181.1.1.10 request was denied according to ACL rules.

SSHS/5/SSH_ACL_DENY: The SSH Connection 181.1.1.11 request was denied according to ACL rules.

- 如果不在，请修改ACL配置，使得客户端的IP地址在ACL的permit规则中。如果对所有SSH客户端都不需要进行访问控制，请删除对客户端的访问控制。

- 如果在，请执行步骤(6)。

¡ 如果未设置，请执行步骤(6)。

(6) 检查服务器的SSH版本与客户端版本是否兼容。

当设备上出现如下日志时，表示设备的SSH版本与客户端版本不兼容。

SSHS/6/SSHS_VERSION_MISMATCH: SSH client 192.168.30.117 failed to log in because of version mismatch.

如果使用SSH1版本的客户端登录设备，可以在设备上执行display ssh server status命令查看SSH version字段确认SSH版本。

¡ 如果SSH version显示为1.99，则表示设备可以兼容SSH1版本的客户端，请执行步骤(7)。

¡ 如果SSH version显示为2.0，请在设备上执行ssh server compatible-ssh1x enable命令设置设备兼容SSH1版本的客户端。

(7) 查看VTY用户线下配置的认证方式及允许接入的协议是否正确。

[Sysname] line vty 0 63

[Sysname-line-vty0-63] display this

line vty 0 63

authentication-mode scheme

user-role network-admin

idle-timeout 0 0

¡ 如果均配置正确，请执行步骤(8)。

(8) 检查设备上VTY用户数是否达到允许用户数的上限。

当设备上出现如下日志时，表示设备上VTY用户数已达到允许用户数的上限。

SSHS/6/SSHS_REACH_USER_LIMIT: SSH client 192.168.30.117 failed to log in, because the number of users reached the upper limit.

通过display line命令查看VTY用户线资源是否充足。

¡ 如果VTY用户线资源充足，请执行步骤(9)。

(9) 检查登录服务器的SSH用户数是否达到允许用户数的上限。

通过display ssh server session命令查看服务器的会话信息，以及查看通过aaa session-limit ssh命令配置的SSH最大用户连接数。

当设备上出现如下日志时，表示登录服务器的SSH用户数已达到允许用户数的上限。

SSHS/6/SSHS_REACH_SESSION_LIMIT: SSH client 192.168.30.117 failed to log in. The number of SSH sessions is 10, and exceeded the limit (10).

¡ 如果未达上限，请执行步骤(10)。

(10) 检查服务器上是否生成了本地密钥对。

在设备上执行display public-key local public命令查看当前设备上的密钥对信息。

¡ 如果DSA、ECDSA和RSA三种密钥对都不存在，请执行public-key local create命令依次进行配置。

¡ 如果已配置，请执行步骤(11)。

(11) 检查是否配置了SSH用户并指定正确的服务类型和认证方式。

SSH支持Stelnet、SFTP、NETCONF和SCP四种用户服务类型。

首先，根据服务器采用的认证类型，查看设备上是否创建正确的SSH用户。

由于服务器采用了publickey认证，则必须在设备上创建相应的SSH用户，以及同名的本地用户（用于下发授权属性：工作目录、用户角色）。

接着，根据检查的结果，进行如下操作：

¡ 如果未创建，请通过ssh user命令进行配置。

¡ 如果已创建，检查SSH用户的服务类型和认证方式。

- 请在设备系统视图下执行ssh user命令，将SSH用户的服务类型和认证方式修改正确。

(12) 检查SCP/SFTP工作目录配置是否正确。

当SSH用户的服务方式为SCP/SFTP时，需要为该用户设置授权目录。如果所配置的授权目录不存在，SCP/SFTP客户端通过该用户连接SCP/SFTP服务器就会失败。对于publickey认证方式的用户，请检查通过AAA授权的工作目录是否存在。

¡ 如果不存在，请通过本地用户视图下的authorization-attribute work-directory directory-name命令修改授权的工作目录。

¡ 如果存在，请执行步骤(13)。

(13) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息、告警信息。

5. 告警与日志

8.1.4 设备作为SSH客户端，用户使用password认证方式登录失败

1. 故障描述

设备作为SSH客户端，用户使用password认证方式登录SSH服务器失败。

2. 常见原因

本类故障的常见原因主要包括：

· SSH客户端与服务器端之间路由不通，无法建立TCP连接。

· SSH客户端登录密码不正确。

· 服务器上未生成本地密钥对。

· 服务器公钥与SSH客户端上缓存的公钥不匹配。

· 客户端的SSH版本与服务器端不兼容。

3. 故障分析

本类故障的诊断流程如图8-4所示。

图8-4 设备作为客户端采用password认证方式登录SSH服务器失败故障诊断流程图

4. 处理步骤

(1) ‍检查客户端能否Ping通服务器端。

使用ping命令查看网络连接情况。

¡ 如果Ping不通，请参见“Ping和Tracert故障处理”中的“Ping不通”继续定位，确保SSH客户端能Ping通服务器端。

¡ 如果可以Ping通，请执行步骤(2)。

(2) 检查登录密码是否正确。

a. ‍如果服务器采用本地认证，请确认当前用户登录的密码是否与设备上设备管理类本地用户视图下配置的密码一致：

- 如果不一致，请重新输入正确的密码。若忘记密码，可以在服务器上进入设备管理类本地用户视图（用户名为当前登录的用户）下，执行password命令重新配置新的密码，确保登录密码与配置的密码一致。（此处以H3C设备作为SSH服务器为例）

- 如果一致，请执行步骤(3)。

b. 如果服务器采用远程认证，请确认当前用户登录的密码是否与认证服务器上配置的一致：

- 如果不一致，请重新输入正确的密码。若忘记密码，可以在服务器上为登录用户重新设置密码，确保登录密码与认证服务器上配置的一致。

- 如果一致，请执行步骤(3)。

(3) 检查服务器上是否生成了本地密钥对。

请确保服务器上已生成本地密钥对。以H3C设备作为SSH服务器为例，在服务器上执行display public-key local public命令查看当前服务器上的密钥对信息。

¡ 如果DSA、ECDSA和RSA三种密钥对都不存在，请执行public-key local create命令依次进行配置，并确保将服务器上生成的公钥保存到客户端。

¡ 如果已配置，请执行步骤(4)。

(4) 检查服务器的SSH版本与客户端版本是否兼容。

请查看并确保服务器的SSH版本兼容客户端版本。以H3C设备作为SSH服务器为例，如果使用SSH1版本的客户端登录设备，可以在服务器上执行display ssh server status命令查看SSH version字段确认SSH版本。

¡ 如果SSH version显示为1.99，则表示服务器上可以兼容SSH1版本的客户端，请执行步骤(5)。

¡ 如果SSH version显示为2.0，请在服务器上执行ssh server compatible-ssh1x enable命令设置设备兼容SSH1版本的客户端。

(5) 检查服务器公钥与客户端上缓存的服务器公钥是否一致。

如果客户端首次登录服务器设备时选择保存了服务器端公钥，当服务器设备更新本地密钥对后，将会导致客户端认证服务端失败。

¡ 如果不一致，请在客户端上执行delete ssh client server-public-key命令，删除客户端保存的旧的服务端公钥。

¡ 如果一致，请执行步骤(6)。

(6) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息、告警信息。

5. 告警与日志

8.1.5 设备作为SSH客户端，用户使用publickey认证方式登录失败

1. 故障描述

设备作为SSH客户端，用户使用publickey认证方式登录SSH服务器失败。

2. 常见原因

本类故障的常见原因主要包括：

· SSH客户端与服务器端之间路由不通，无法建立TCP连接。

· 服务器上未生成本地密钥对。

· 服务器端配置的用户公钥不正确。

· 服务器公钥与SSH客户端上缓存的公钥不匹配。

· 客户端的SSH版本与服务器端不兼容。

3. 故障分析

本类故障的诊断流程如图8-5所示。

图8-5 设备作为客户端使用publickey认证方式登录SSH服务器失败故障诊断流程图

4. 处理步骤

(1) ‍检查客户端能否Ping通服务器端。

使用ping命令查看网络连接情况。

¡ 如果Ping不通，请参见“Ping和Tracert故障处理”中的“Ping不通”继续定位，确保SSH客户端能Ping通服务器端。

¡ 如果可以Ping通，请执行步骤(2)。

(2) 检查服务器端配置的用户公钥和用户使用的私钥是否匹配。

SSH客户端可能支持多种公钥算法，每种公钥算法对应不同的非对称密钥对。只有服务器端保存的用户公钥类型与用户登录时使用的私钥类型一致时，用户认证才会成功。例如，服务器端为某用户指定了DSA类型的公钥，用户也持有与之相匹配的私钥，但是登录时用户使用的私钥类型为RSA，此时用户认证会失败。

以H3C设备作为SSH服务器为例，通过在服务器上执行display public-key peer命令查看保存在设备上的客户端公钥信息，判断是否与正在登录用户使用的私钥类型一致：

¡ 如果不一致，请执行public-key local create命令在服务器上生成相应类型的密钥对。

¡ 如果一致，请执行步骤(3)。

(3) 检查服务器上是否生成了本地密钥对。

以H3C设备作为SSH服务器为例，在服务器上执行display public-key local public命令查看当前服务器上的密钥对信息。

¡ 如果DSA、ECDSA和RSA三种密钥对都不存在，请执行public-key local create命令依次进行配置。

¡ 如果已配置，请执行步骤(4)。

(4) 检查服务器的SSH版本与客户端版本是否兼容。

请查看并确保服务器上的SSH版本兼容客户端版本。以H3C设备作为SSH服务器为例，如果使用SSH1版本的客户端登录设备，可以在服务器上执行display ssh server status命令查看SSH version字段确认SSH版本。

¡ 如果SSH version显示为1.99，则表示服务器上可以兼容SSH1版本的客户端，请执行步骤(5)。

¡ 如果SSH version显示为2.0，请在服务器上执行ssh server compatible-ssh1x enable命令设置设备兼容SSH1版本的客户端。

(5) 检查服务器公钥与客户端上缓存的服务器公钥是否一致。

如果客户端首次登录服务器设备时选择保存了服务器端公钥，当服务器设备更新本地密钥对后，将会导致客户端认证服务端失败。

¡ 如果不一致，请在客户端上执行delete ssh client server-public-key命令，删除客户端保存的旧的服务端公钥。

¡ 如果一致，请执行步骤(6)。

(6) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息、告警信息。

5. 告警与日志

8.2 URL过滤故障处理

8.2.1 URL分类云端查询服务器连接失败

1. 故障描述

在图8-6所示的组网场景中，Device分别通过Trust安全域和Untrust安全域与局域网和Internet相连。内网Host在访问Internet时，Device需要对Host访问的URL进行过滤。在Device上完成URL分类云端查询功能配置后，Device无法连接URL分类云端查询服务器（Cloud Server）。此时可以执行display url-filter cache命令，查看云端查询功能状态显示为"Disabled"，如下面阴影处的显示信息所示。

<Sysname> display url-filter cache

Url-filter cache information:

Cloud-query status: Disabled

Total cached entries: 0

Min update interval: 0 seconds

Max update interval: 0 seconds

Last query message sent: 0 seconds ago

Last query result received: 0 seconds ago

图8-6 URL分类云端查询服务器连接失败组网图

‌

2. 常见原因

本类故障的常见原因主要包括：

· 物理链路等故障，导致Device与Cloud Server之间路由不通。

· 安全策略配置不正确，Device到Cloud Server间的报文被安全策略丢弃。

· URL过滤License失效。

· URL过滤云端查询功能配置错误。

3. 故障分析

本类故障的诊断思路如下：

(1) 查看Device与Cloud Server之间是否路由可达。

(2) 查看Device上的安全策略配置，判断其是否放行Device访问Cloud Server的报文。

(3) 查看Device上的URL过滤License是否有效。

(4) 查看Device上的URL过滤云端查询功能配置是否正确。

本类故障的诊断流程如图8-7所示。

图8-7 URL分类云端查询服务器连接失败故障诊断流程

4. 处理步骤

本故障处理的以下处理步骤，均以图8-6场景中的IP地址信息和安全域信息为例进行故障排除分析，实际组网环境中，请以设备的实际情况为准。

(1) 我司云端查询服务器（Cloud Server）的域名为sec.h3c.com，由于服务器部署于公网环境中，且关闭了Ping服务，无法通过在Device上执行Ping命令直接测试Device与服务器之间的连通性。用户可以通过Ping命令测试公网中的其他地址，例如www.h3c.com，确认Device可以正常访问Internet即可。

a. 在Device上使用ping命令检查与www.h3c.com的网络连接情况，方法如下所示：

<Sysname> ping www.h3c.com

C:\Users\usera>ping www.h3c.com

正在 Ping www.h3c.com [10.63.16.77] 具有 32 字节的数据:

来自 10.63.16.77 的回复: 字节=32 时间=25ms TTL=122

10.63.16.77 的 Ping 统计信息:

数据包: 已发送 = 4，已接收 = 4，丢失 = 0 (0% 丢失)，

往返行程的估计时间(以毫秒为单位):

最短 = 25ms，最长 = 25ms，平均 = 25ms

如果Device可以Ping通www.h3c.com，请执行步骤(2)。

如果Device仍不能Ping通www.h3c.com，请继续执行步骤b，排除Ping不通的问题。

b. 检查DNS服务器配置是否正确，方法如下所示：

<Sysname> display current-configuration | include dns

dns server 114.114.114.114

其中，114.114.114.114表示DNS服务器的IP地址。此处仅作为举例，具体请以实际情况为准。

如果未配置DNS服务器地址，或地址不正确，请重新配置，确保配置DNS服务器地址已正确配置后，故障仍不能排除，请继续执行步骤c。

c. Device不能Ping通www.h3.com故障的具体排查思路和方法，请参见“Ping和Tracert故障处理”中的“Ping不通”继续定位，确保Device可以Ping通www.h3c.com。Device可以Ping通www.h3c.com后，如果故障仍不能排除，请执行步骤(2)。

(2) 查看Device上的安全策略是否放行了Device访问Cloud Server的报文。

Device向Cloud Server发送URL分类云端查询的请求报文时，如果安全策略将此报文丢弃了，设备将不会将此报文发送Cloud Server进行处理。

a. 在Device上执行display security-policy verbose命令，显示所有安全策略的配置信息。

[Device] display security-policy verbose

Security-policy

rule 0 name trust-untrust

action pass

source-zone trust

destination-zone untrust

source-ip-host 192.168.1.3

rule 1 name local-untrust

action pass

source-zone local

destination-zone untrust

b. 按照从上到下的顺序依次查看处于生效状态的安全策略规则，寻找能够匹配Device访问Server报文的安全策略规则：

- 如果未能找到该规则，则需修改现有的安全策略规则，或补充一条安全策略规则，使其放行Device访问Server的报文。相关安全策略规则要求如下：

作为安全策略规则过滤条件的源安全域应为Local安全域；

作为安全策略规则过滤条件的目的安全域应为Untrust安全域；

作为安全策略规则的动作为Pass。

创建安全策略的相关命令如下：

[Device] security-policy

[Device-security-policy] rule name local-untrust

[Device-security-policy-2-local-untrust] source-zone local

[Device-security-policy-2-local-untrust] destination-zone untrust

[Device-security-policy-2-local-untrust] action pass

[Device-security-policy-2-local-untrust] quit

[Device-security-policy] quit

- 如果找到该规则，继续查看其动作（action）是否为pass；如果为drop，需要修改为pass。

c. 安全策略放行Device访问Cloud Server的报文后，如果故障仍得不到排除，请执行步骤（3）。

(3) 检查URL过滤License是否有效。

a. 在Device上执行display license feature命令，查看“UFLT”License的状态。

<Sysname> display license feature

Total: 32 Usage: 2

Feature Licensed State

ACG N -

AV Y Trial

IPRPT N -

IPS N -

SLB N -

SSLVPN Y Pre-licensed

UFLT Y Formal

WAF N -

WEB-CACHE N -

表8-1 display license feature命令显示信息描述表

字段	描述
Total	设备上一共可安装License的总数目
Usage	设备上已经安装的License总数
Feature	需要License授权才能使用的业务特性的名称
Licensed	是否已经授权，取值包括如下： · Y表示已授权 · N表示未授权
State	License的当前状态： · Formal表示当前已经为该特性安装了正式License，License处于有效状态 · Trial表示当前已经为该特性安装了临时License，License处于有效状态 · Pre-Licensed表示当前已经为该特性安装了预安装License，License处于有效状态 · -表示当前无有效License，用户如需使用该特性，请安装对应的License

b. 如果“State”字段显示为“-”，则表示License的状态无效，请重新激活或购买License，有关License的详细介绍，请参见“H3C 交换机及路由器产品通用License使用指南”；如果“State”字段显示为其他取值，请继续进入步骤（4）判断。

(4) 查看URL过滤策略中，云端查询功能相关配置是否正确。

a. 查看是否修改了云端服务器地址。

设备默认云端服务器地址为sec.h3c.com，无特殊情况，不建议修改。在Device上执行display current-configuration | include cloud-server命令，查看是否修改了云端服务器地址。

[Device] display current-configuration | include cloud-server

- 如果修改了默认地址，建议使用undo inspect cloud-server命令删除该配置。删除配置后，如果故障仍未排除，请执行步骤b继续判断。

- 如果未修改默认地址，请执行步骤b继续判断。

b. 查看URL过滤分类云端查询功能是否已开启。

在Device上执行如下命令，查看是否已开启URL过滤分类云端查询功能。

[Device] display current-configuration | include cloud

cloud-query enable

- 如果未配置该命令，请在指定的URL过滤策略视图中配置该命令。如果故障仍未排除，请执行步骤（5）

- 如果已配置该命令，请执行步骤（5）。

(5) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件。

5. 告警与日志

8.2.2 HTTP网站无法访问

1. 故障描述

在图8-8所示的组网场景中，Device分别通过Trust安全域和Untrust安全域与局域网和Internet相连。内网Host在访问Internet时，Device需要对Host访问的URL进行过滤。在Device上完成URL过滤功能配置后，存在部分网站无法正常访问的现象。

图8-8 HTTP网站无法正常访问故障组网图

‌

2. 常见原因

本类故障的常见原因主要包括：

· URL过滤功能配置错误。

· 安全策略配置错误。

3. 故障分析

本类故障的诊断思路如下：

(1) ‍‍‍查看浏览器响应页面信息或者设备打印的日志信息，并根据响应页面信息或日志信息进行处理。

(2) 查看URL过滤配置是否存在错误。

(3) 查看安全策略配置是否存在错误。

本类故障的诊断流程如图8-9所示。

图8-9 网站无法正常访问故障诊断流程图

4. 处理步骤

(1) ‍‍‍查看浏览器返回的响应页面提示信息，根据不同的提示信息执行相应的操作。

URL过滤业务在阻断了用户访问的网站后，会向用户浏览器返回提示页面，说明阻断访问的原因以及网站信息。用户可通过提示页面信息进行排查，具体内容如下：

Web Access Blocked

Your access to this website was denied. To access this webpage, contact Technical Support.

Reason：The URL of the website hit the URL blacklist.

Category：

URL：http://192.22.2.61/wnm/frame/index.php

如上使用灰色底纹标识了三类信息，分别为Reason、Category和URL。

¡ Reason：表示客户端访问的网站被阻断的原因。

¡ Category：表示客户端访问的URL所属的自定义分类、预定义分类或URL信誉的攻击分类。其中，当网站URL命中黑名单时，此字段显示为空。

¡ URL：表示客户端访问网站的URL。

用户可以根据Reason字段的取值，选择相应的处理方式：

¡ Reason显示为The URL of the website hit the URL blacklist.。

表示客户端访问的网站因命中URL过滤黑名单而被阻断。此时，用户可进入指定的URL过滤策略视图，执行display this命令，查看URL过滤策略下黑名单的相关配置，获取黑名单的ID，删除指定的黑名单。具体内容如下：

[Sysname] url-filter policy p1

[Sysname-url-filter-policy-p1] display this

category test action drop logging

add blacklist 1 host text 192.22.2.61

如上述灰色底纹标识内容所示，可获取到黑名单ID为1，用户可通过在指定的URL过滤策略视图下执行undo add blacklist 1命令，删除该黑名单表项。删除后，执行inspect activate命令，使配置生效。

完成上述操作后，如果故障仍不能排除，请执行步骤（3）。

¡ Reason显示为The URL of the website hit a user-defined URL category.。

表示客户端访问的网站因命中自定义URL分类而被阻断。此时，可以查看“Category”字段显示的具体分类名称，再选择如下任意一种方式进行处理。此处假设命中的自定义分类名称为test，命中的URL为http://192.22.2.61/wnm/frame/index.php。

在自定义分类中删除指定的URL，具体配置如下。

查看自定义分类test的相关配置。

[sysname] url-filter category test

[sysname-url-filter-category-test] display this

url-filter category test severity 2000

rule 1 host text 192.22.2.61

rule 2 host text *185*

由上述灰色底纹标识内容可知，指定URL所在规则的ID为1，用户可在自定义分类视图下执行undo rule 1命令，删除规则1。删除后，再退出到系统视图，执行inspect activate命令，使变更生效。

完成上述操作后，如果故障仍不能排除，请执行步骤（3）。

在指定的URL过滤策略视图下，修改自定义分类的动作，具体配置如下。

进入指定的URL过滤策略视图，配置自定义分类test的动作为permit。

[Sysname] url-filter policy p1

[Sysname-url-filter-policy-p1] category test action permit

完成上述操作后，如果故障仍不能排除，请执行步骤（3）。

¡ Reason显示为The URL of the website hit a predefined URL category.。

表示客户端访问的网站因命中预定义URL分类而被阻断。此时，如需放行网站的访问，可以采取如下任意一种方式：

在指定的URL过滤策略视图下，将需要放行的网站URL加入白名单，具体配置如下：

[Sysname] url-filter policy p1

[Sysname-url-filter-policy-p1] add whitelist 1 host text 192.22.2.61

再退出到系统视图，执行inspect activate命令，使变更生效。

完成上述操作后，如果故障仍不能排除，请执行步骤（4）。

在系统视图下创建自定义URL分类test，向分类中添加URL，并将分类的动作设置为permit，具体配置如下：

[sysname] url-filter category test severity 2000

[sysname-url-filter-category-test] rule 1 host text 192.22.2.61

[sysname-url-filter-category-test] quit

[Sysname] url-filter policy p1

[Sysname-url-filter-policy-p1] category test action permit

退出到系统视图，执行inspect activate命令，使变更生效。

完成上述操作后，如果故障仍不能排除，请执行步骤（4）。

¡ Reason显示为The URL of the website did not match any accessible URL category.。

表示客户端访问的网站因未匹配到任何允许访问的URL分类而被阻断，此时，URL过滤执行缺省动作。如需放行网站的访问，可以采取如下任意一种方式：

在指定的URL过滤策略视图下，将需要放行的网站URL加入白名单，具体配置如下：

[Sysname] url-filter policy p1

[Sysname-url-filter-policy-p1] add whitelist 1 host text 192.22.2.61

再退出到系统视图，执行inspect activate命令，使变更生效。

完成上述操作后，如果故障仍不能排除，请执行步骤（4）。

在系统视图下创建自定义URL分类test，向分类中添加URL，并将分类的动作设置为permit，具体配置如下：

[sysname] url-filter category test severity 2000

[sysname-url-filter-category-test] rule 1 host text 192.22.2.61

[sysname-url-filter-category-test] quit

[Sysname] url-filter policy p1

[Sysname-url-filter-policy-p1] category test action permit

退出到系统视图，执行inspect activate命令，使变更生效。

完成上述操作后，如果故障仍不能排除，请执行步骤（4）。

在指定的URL过滤策略视图下，将URL过滤缺省动作配置为permit，具体配置如下：

[Sysname] url-filter policy p1

[Sysname-url-filter-policy-p1] default-action permit

完成上述操作后，如果故障仍不能排除，请执行步骤（4）。

¡ Reason显示为No matching whitelist entry was found for the website in whitelist mode.表示客户端访问的网站因未命中白名单模式下的白名单而被阻断。

此时，表示URL过滤功能处于白名单模式，即开启了仅支持URL过滤白名单功能，设备仅允许用户访问白名单规则中定义的网站，不在白名单规则中的网站都会被阻断。用户可通过如下方式进行处理：

在指定的URL过滤策略视图下，将所访问网站的URL添加到白名单中，允许该URL的访问，具体配置如下：

[Sysname] url-filter policy p1

[Sysname-url-filter-policy-p1] add whitelist 1 host text 192.22.2.61

配置完成后，退出到系统视图，执行inspect activate命令，使配置生效。完成上述操作后，如果故障仍不能排除，请执行步骤（4）。

当用户访问的URL是某个网站下的内嵌网页时，执行如下操作：

由于内嵌网页URL与主页面URL不同，如果设备上只将主页面URL加入了白名单，内嵌网页URL没有加入白名单时，可能会导致内嵌网页无法访问。例如，用户访问的网页中内嵌了一个其他网站的视频链接，如果仅将该网页加入白名单，则用户无法访问内嵌的视频，还需要将该视频的链接网站加入白名单才可正常访问。

此时，用户可在指定的URL过滤策略视图下，执行display this命令，判断是否开启了内嵌白名单功能。该功能用于实现允许访问白名单网页下内嵌的其他网页链接。具体操作如下：

[Sysname] url-filter policy p1

[Sysname-url-filter-policy-p1] display this

url-filter policy p1

undo referer-whitelist enable

如上述灰色底纹内容所示，设备关闭了内嵌白名单功能。此时，用户可在指定URL过滤策略视图下，执行referer-whitelist enable命令，开启内嵌白名单功能。开启该功能后，只要主页面的URL加入到了白名单，内嵌网页也可以进行访问。

完成上述操作后，如果故障仍不能排除，请执行步骤（a）。

¡ Reason显示为The URL of the website hit the URL reputation signature library.。

表示客户端访问的网站因命中URL信誉特征库而被阻断。此时，如需放行网站的访问，可以采取如下任意一种方式：

在指定的URL过滤策略视图下，将需要放行的网站URL加入白名单，具体配置如下：

[Sysname] url-filter policy p1

[Sysname-url-filter-policy-p1] add whitelist 1 host text 192.22.2.61

再退出到系统视图，执行inspect activate命令，使变更生效。

完成上述操作后，如果故障仍不能排除，请执行步骤（4）。

在系统视图下创建自定义URL分类test，向分类中添加URL，并将分类的动作设置为permit，具体配置如下：

[sysname] url-filter category test severity 2000

[sysname-url-filter-category-test] rule 1 host text 192.22.2.61

[sysname-url-filter-category-test] quit

[Sysname] url-filter policy p1

[Sysname-url-filter-policy-p1] category test action permit

退出到系统视图，执行inspect activate命令，使变更生效。

完成上述操作后，如果故障仍不能排除，请执行步骤（4）。

(2) 查看URL过滤日志。

(3) 当用户开启了URL过滤日志记录功能后，设备会在报文匹配到URL过滤策略中的规则或者执行了缺省动作时记录日志信息。用户可以通过日志信息获取匹配的URL过滤策略名称、被阻断访问的网站URL以及URL所属的分类等信息。下面以日志主机接收到的快速日志为例，进行说明。

¡ UFLT_MATCH_IPV4_LOG日志

当报文匹配到URL过滤规则时，会记录该日志信息，具体内容如下：

UFLT/6/UFLT_MATCH_IPV4_LOG:Protocol(1001)=TCP;Application(1002)=SouhuNews;UserName(1113)=;SrcMacAddr(1021)=08-00-27-11-93-78;SrcIPAddr(1003)=112.1.1.2;SrcPort(1004)=3887;NATSrcIPAddr(1005)=112.1.1.2;NATSrcPort(1006)=3887;DstIPAddr(1007)=114.1.1.2;DstPort(1008)=80;NATDstIPAddr(1009)=114.1.1.2;NATDstPort(1010)=80;SrcZoneName(1025)=in;DstZoneName(1035)=out;PolicyName(1079)=p1;URLParentCategory(1128)=SearchEngines&Portals;URLCategory(1094)=SearchEngines&Portals;URL(1093)=news.sohu.com/upload/itoolbar/itoolbar.index.loader.20140923.js;VistTime(1114)=1480688515;Client(1110)=;Action(1053)=Drop;VlanID(1175)=400;VNI(1213)=--;SrcLocation(1209)=China Macao;DstLocation(1214)=SaintKittsandNevis;

上述灰色底纹内容标识了URL过滤策略名称、URL分类以及具体的URL。用户可根据URL分类的取值，即URLCategory(1094)字段的取值，选择相应的处理方式。

当字段取值为BlackList时，表示客户端访问的网站因命中URL过滤黑名单而被阻断。此时，可参考步骤（1）中，当Reason显示为“The URL of the website hit the URL blacklist.”时的操作步骤进行排查。

当字段取值为具体的分类名称时，例如category1，表示客户端访问的网站因命中自定义URL分类或预定义URL分类而被阻断。用户可以通过执行display url-filter category verbose命令，查看分类的“Type”字段取值，判断该分类属于自定义分类还是预定义分类，并根据判断结果执行相应的操作。具体内容如下：

<Sysname> display url-filter category verbose

URL category statistics:

Predefined categories: 53

Predefined rules: 2000

User-defined categories: 5

User-defined rules: 4

URL category details:

Name: category1

Type: User defined

Severity: 1001

Rules: 1

Description:

Name: Pre-AdvertisementsAndPop-Ups

Type: Predefined

Severity: 300

Rules: 32

Description: Sites that provide advertising graphics or other ad content fi

les such as banners and pop-ups.

如果“Type”字段显示为User defined，则表示自定义分类。此时，可参考步骤（1）中，当Reason显示为“The URL of the website hit a user-defined URL category.”时的操作步骤进行排查。

如果“Type”字段显示为Predefined，则表示预定义分类。此时，可参考步骤（1）中，当Reason显示为“The URL of the website hit a predefined URL category.”时的操作步骤进行排查。

¡ “UFLT_NOT_MATCH_IPV4_LOG”日志

设备会在如下情况记录该日志信息：

- 设备开启了仅支持URL过滤白名单功能，而用户访问的URL未添加到URL过滤白名单，使得访问被阻断。

- 报文因未匹配到任何URL过滤规则而被执行了URL过滤缺省动作。

用户可通过查看日志获取相应的信息，具体内容如下：

UFLT/6/UFLT_NOT_MATCH_IPV4_LOG:Protocol(1001)=TCP;Application(1002)=SouhuNews;UserName(1113)=;SrcMacAddr(1021)=08-00-27-11-93-78;SrcIPAddr(1003)=112.1.1.2;SrcPort(1004)=3887;NATSrcIPAddr(1005)=112.1.1.2;NATSrcPort(1006)=3887;DstIPAddr(1007)=114.1.1.2;DstPort(1008)=80;NATDstIPAddr(1009)=114.1.1.2;NATDstPort(1010)=80;SrcZoneName(1025)=in;DstZoneName(1035)=out;PolicyName(1079)=p1;URLParentCategory(1128)=-;URLCategory(1094)=Unknown;URL(1093)=news.sohu.com/upload/itoolbar/index/toolbar_bg_130315.gif;VistTime(1114)=1480691551;Client(1110)=;Action(1053)=Drop;VlanID(1175)=400;VNI(1213)=--;SrcLocation(1209)=China Macao;DstLocation(1214)=SaintKittsandNevis;

上述灰色底纹标识出了的URL过滤策略的名称以及具体的URL，用户可以通过如下方式进行处理：

在指定的URL过滤策略视图下，执行display this命令，查看是否开启了仅支持URL过滤白名单功能。具体配置如下：

[Sysname] url-filter policy p1

[Sysname-url-filter-policy-p1] display this

url-filter policy p1

whitelist-only enable

如上述灰色底纹标识内容所示，该命令用于开启URL过滤白名单功能，用户可以根据设备上是否配置了该功能进行如下处理：

- 如果设备上开启了仅支持URL过滤白名单功能。此时用户访问的URL是由于未匹配到URL过滤白名单而被阻断的。用户可以参考步骤（1）中，当Reason显示为“No matching whitelist entry was found for the website in whitelist mode.”时的操作步骤进行排查。

- 如果设备上未开启仅支持URL过滤白名单功能，则表示报文因未匹配到任何URL过滤规则而被执行了URL过滤缺省动作。用户可以参考步骤（1）中，当Reason显示为“The URL of the website did not match any accessible URL category.”时的操作步骤进行排查。

(4) 查看URL过滤配置是否存在错误。

自定义分类支持配置严重级别，当报文同时匹配到多条自定义分类规则时，设备将执行严重级别最高的分类指定的动作。

查看被阻断访问的网站URL是否被添加到了不同严重级别的自定义分类规则中。

a. ‍用户可以通过在指定的URL过滤策略视图下执行display this命令，查看是否存在多个自定义分类，具体内容如下：

[Sysname] url-filter policy p1

[Sysname-url-filter-policy-p1] display this

category test1 action permit logging

category test2 action drop logging

b. 分别进入不同的自定义分类视图，查看是否存在相同的规则。

在自定义分类test1视图下查看分类信息，具体内容如下：

[sysname] url-filter category test1

[sysname-url-filter-category-test] display this

url-filter category test1 severity 2000

rule 1 host text 192.22.2.61

rule 2 host text *185*

在自定义分类test2视图下查看分类信息，具体内容如下：

[sysname] url-filter category test2

[sysname-url-filter-category-test] display this

url-filter category test2 severity 3000

rule 1 host text 192.22.2.61

如上述灰色底纹标识内容所示，URL过滤策略下存在test1和test2两个自定义分类，且二者均包含相同内容的规则“192.22.2.61”。

其中，由于test2分类的严重级别“severity”为3000，高于test1的严重级别2000，所以URL过滤最终执行了test2分类的动作drop。

此时，如果需要放行报文，则可选择如下任意一种方式：

修改test1分类的严重级别，使其严重级别高于test2。具体内容如下：

[Sysname] url-filter category test1 severity 3001

修改test2分类的动作为permit，放行报文。具体内容如下：

[Sysname] url-filter policy p1

[Sysname-url-filter-policy-p1] category test2 action permit

在自定义分类test2视图下，删除192.22.2.61所在的规则。具体内容如下：

[Sysname] url-filter policy p1

[Sysname-url-filter-policy-p1] undo rule 1

在指定的URL过滤策略视图下，将192.22.2.61添加到白名单。具体内容如下：

[Sysname] url-filter policy p1

[Sysname-url-filter-policy-p1] add whitelist 1 host text 192.22.2.61

执行上述配置后，如果故障仍不能排除，请执行步骤（4）。

(5) 查看安全策略是否正确引用URL过滤策略。

在安全策略视图下执行display this命令，查看安全策略中是否引用了app-profile。具体内容如下：

[sysname] security-policy

[sysname-security-policy] display this

security-policy

rule 10 name abc

action pass

source-zone Trust

destination-zone Untrust

profile url-filter

return

如上述灰色底纹标识内容所示，查看到profile名称为url-filter。

在名称为url-filter的app-profile视图下，查看profile中引用的URL过滤策略是否正确。具体内容如下：

[sysname] app-profile url-filter

[sysname-app-profile-url-filter] display this

app-profile url-filter

url-filter apply policy p1

return

如上述灰色底纹标识内容所示，查看到URL过滤策略名称为p1。请判断策略名称是否正确。

¡ 如果不正确，请在指定的app-profile视图下执行url-filter apply policy命令，重新引用正确的URL过滤策略。完成引用后，如果故障仍不能排除，请执行步骤（5）。

如果正确，请执行步骤（5）。

(6) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件。

5. 告警与日志

8.2.3 HTTP网站无法阻断

1. 故障描述

在图8-10所示的组网场景中，Device分别通过Trust安全域和Untrust安全域与局域网和Internet相连。内网Host在访问Internet时，Device需要对Host访问的URL进行过滤。在Device上完成URL过滤功能配置后，存在部分网站无法阻断的现象。

图8-10 HTTP网站无法阻断故障组网图

‌

2. 常见原因

本类故障的常见原因主要包括：

· 应用层检测引擎工作状态异常，导致URL过滤业务无法正常处理。

· 安全策略配置错误，导致URL过滤业务无法正常处理。

· URL过滤功能配置错误，例如，将目标网站加入了白名单等，导致网站的访问无法阻断。

3. 故障分析

本类故障的诊断思路如下：

(1) 查看应用层检测引擎工作状态是否异常。

(2) 查看安全策略配置是否正确。

(3) 查看URL过滤功能配置是否正确。

本类故障的诊断流程如图8-11所示。

图8-11 网站无法正常阻断故障诊断流程图

‌

4. 处理步骤

(1) 检查应用层检测引擎工作状态是否异常。

在Device上执行命令display inspect status，查看应用层检测引擎运行状态“Running status”的取值是否为Normal。

<Sysname> display inspect status

Running status: Normal

¡ 如果取值为Normal：则表示应用层检测引擎工作状态正常，请继续执行步骤（3）。

¡ 如果取值为DPI administratively disabled：表示管理员手工关闭了应用层检测引擎。此时请在系统视图下执行undo inspect bypass命令，手工开启应用层检测引擎功能。完成配置后，如果故障仍得不到排除，请继续执行步骤（3)。

¡ 如果取值为DPI disabled due to high CPU usage：表示由于CPU使用率过高导致应用层检测引擎被关闭。此时，请降低CPU使用率后再通过执行undo inspect bypass命令开启应用层检测引擎功能。如果故障仍得不到排除，请执行步骤（3)。

(2) 查看安全策略是否正确引用URL过滤策略。

在安全策略视图下执行display this命令，查看安全策略中是否引用了app-profile。具体内容如下：

[sysname] security-policy

[sysname-security-policy] display this

security-policy

rule 10 name abc

action pass

source-zone Trust

destination-zone Untrust

profile url-filter

return

如上述灰色底纹标识内容所示，查看到profile名称为url-filter。

在名称为url-filter的app-profile视图下，查看profile中引用的URL过滤策略是否正确。具体内容如下：

[sysname] app-profile url-filter

[sysname-app-profile-url-filter] display this

app-profile url-filter

url-filter apply policy p1

return

如上述灰色底纹标识内容所示，查看到URL过滤策略名称为p1。请判断策略名称是否正确。

¡ 如果不正确，请在指定的app-profile视图下执行url-filter apply policy命令，重新引用正确的URL过滤策略。完成引用后，如果故障仍不能排除，请执行步骤（4）。

¡ 如果正确，请执行步骤（4）。

(3) 查看URL过滤配置是否存在错误。

URL过滤支持查看URL策略下详细的配置，如果用户配置了白名单、黑名单、自定义URL分类等规则，需要检查是否由于高优先级规则优先匹配，导致低优先级规则匹配失败的问题。URL过滤规则处理的优先级由高到低依次为：白名单>黑名单>自定义分类>预定义分类。

a. 查看是否存在白名单

用户可以通过在指定的URL过滤策略视图下执行display this命令，查看是否存在白名单配置。

[Sysname] url-filter policy p1

[Sysname-url-filter-policy-p1] display this

add whitelist 1 host text 192.22.2.61

如上述灰色底纹标识内容所示，URL过滤策略p1中添加了白名单192.22.2.61。用户可通过在指定的URL过滤策略视图下执行undo add whitelist 1命令，删除该白名单。

- 执行删除操作后，如果故障仍不能排除，请执行步骤（b）

- 如果不存在白名单，请执行步骤（b）。

b. 查看是否存在多个自定义分类，且多个分类下是否存在包含相同URL的规则

自定义分类支持配置严重级别，当报文同时匹配到多个自定义分类下的规则时，设备将执行严重级别最高的分类指定的动作。

用户可以通过在指定的URL过滤策略视图下执行display this命令，查看是否存在多个自定义分类，具体内容如下：

[Sysname] url-filter policy p1

[Sysname-url-filter-policy-p1] display this

category test1 action drop logging

category test2 action permit logging

分别进入不同的自定义分类视图，查看是否存在具有相同URL的规则。

在自定义分类test1视图下查看分类信息，具体内容如下：

[sysname] url-filter category test1

[sysname-url-filter-category-test] display this

url-filter category test1 severity 2000

rule 1 host text 192.22.2.61

rule 2 host text *185*

在自定义分类test2视图下查看分类信息，具体内容如下：

[sysname] url-filter category test2

[sysname-url-filter-category-test] display this

url-filter category test2 severity 3000

rule 1 host text 192.22.2.61

如上述灰色底纹标识内容所示，URL过滤策略下存在test1和test2两个自定义分类，且二者均包含相同URL（192.22.2.61）的规则。

其中，由于test2分类的严重级别“severity”为3000，高于test1的严重级别2000，所以URL过滤最终执行了test2分类的动作permit。

此时，如果需要阻断报文，则可选择如下任意一种方式：

修改test1分类的严重级别，使其严重级别高于test2。具体内容如下：

[Sysname] url-filter category test1 severity 3001

修改test2分类的动作为drop，阻断报文。具体内容如下：

[Sysname] url-filter policy p1

[Sysname-url-filter-policy-p1] category test2 action dorp

在自定义分类test2视图下，删除192.22.2.61所在的规则。具体内容如下：

[Sysname] url-filter policy p1

[Sysname-url-filter-policy-p1] undo rule 1

在指定的URL过滤策略视图下，将192.22.2.61添加到黑名单。具体内容如下：

[Sysname] url-filter policy p1

[Sysname-url-filter-policy-p1] add blacklist 1 host text 192.22.2.61

- 执行上述配置后，如果故障仍不能排除，请执行步骤（5）。

- 如果不存在多个自定义分类或多个自定义分类下不存在包含相同URL的自定义分类规则，请执行步骤（c）。

c. 查看自定义分类动作是否为permit

用户可以通过在指定的URL过滤策略视图下执行display this命令，查看是否存在自定义分类配置。

[Sysname-url-filter-policy-p1] display this

category test2 action permit logging

在自定义分类test2视图下查看分类信息，具体内容如下：

[sysname] url-filter category test2

[sysname-url-filter-category-test] display this

url-filter category test2 severity 3000

rule 1 host text 192.22.2.61

如上述灰色底纹标识内容所示，存在自定义URL分类test2，动作为permit。该分类下包含规则192.22.2.61。如需阻断该网站的访问，用户可通过在自定义分类test2视图下，执行undo rule 1命令，删除该规则。

- 执行上述配置后，如果故障仍不能排除，请执行步骤（5）。

- 如果不存在自定义分类或分类动作不是permit，请执行步骤（5）。

(4) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件。

5. 告警与日志

8.2.4 HTTPS网站无法访问或阻断

1. 故障描述

在图8-12所示的组网场景中，Device分别通过Trust安全域和Untrust安全域与局域网和Internet相连。内网Host在访问Internet时，Device需要对Host访问的URL进行过滤。在Device上完成URL过滤功能配置后，存在HTTPS网站无法正常放行或阻断的现象。

图8-12 HTTPS网站无法正常放行或阻断故障组网图

‌

2. 常见原因

对HTTPS流量进行URL过滤时，需要设备上配置如下功能：

· 开启HTTPS流量过滤功能：设备不对HTTPS流量进行解密，直接对客户端发送的HTTPS的Client HELLO报文中的SNI（Sever Name Indication extension）字段进行检测，从中获取用户访问的服务器域名，使用获取到的域名与URL过滤策略进行匹配。

本类故障具体处理步骤如下：

(1) 使用HTTPS流量过滤功能场景下，常见原因包括：

a. HTTPS流量过滤功能未开启，导致URL过滤业务无法对HTTPS流量进行检测。

b. 安全策略配置错误，导致URL过滤业务无法对HTTPS网站进行检测。

3. 故障分析

本类故障的诊断思路具体如下：

(1) 使用HTTPS流量过滤功能场景下，诊断思路如下：

a. 检查URL过滤配置文件中HTTPS过滤功能是否已开启，若未开启，请开启。

b. 检查安全策略配置是否正确。

本类故障的诊断流程如图8-13所示。

图8-13 使用HTTPS流量过滤功能场景下，HTTPS网站无法访问或阻断故障诊断流程图

4. 使用HTTPS流量过滤功能场景下的处理步骤

(1) 检查是否已开启HTTPS流量过滤功能

在指定的URL过滤策略视图下，执行display this命令，查看是否已开启HTTPS流量过滤功能。

[Sysname] url-filter policy p1

[Sysname-url-filter-policy-p1] display this

url-filter policy p12

https-filter enable

¡ 如上使用灰色底纹标识了HTTPS流量过滤功能已开启，请继续执行步骤（2）。

¡ 如果未出现上述取值，则表示未开启HTTPS流量过滤功能。如需使用该功能，可在指定的URL过滤策略视图下，执行https-filter enable命令，开启HTTPS流量过滤功能；如果开启此功能，故障仍不能排除，请执行步骤（2）。

(2) 查看安全策略是否正确引用URL过滤策略。

在安全策略视图下执行display this命令，查看安全策略中是否引用了app-profile。具体内容如下：

[sysname] security-policy

[sysname-security-policy-ip] display this

security-policy

rule 10 name abc

action pass

source-zone Trust

destination-zone Untrust

profile url-filter

return

如上述灰色底纹标识内容所示，查看到profile名称为url-filter。

在名称为url-filter的app-profile视图下，查看profile中引用的URL过滤策略是否正确。具体内容如下：

[sysname] app-profile url-filter

[sysname-app-profile-url-filter] display this

app-profile url-filter

url-filter apply policy p1

return

如上述灰色底纹标识内容所示，查看到URL过滤策略名称为p1。请判断此策略是否正确。

¡ 如果不正确，请在指定的app-profile视图下执行url-filter apply policy命令，重新引用正确的URL过滤策略。完成引用后，如果故障仍不能排除，请执行步骤（3）。

¡ 如果正确，请执行步骤（3）。

(3) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件。

5. 告警与日志

8.3 AAA故障处理

8.3.1 本地认证登录失败

1. 故障描述

管理员采用本地认证登录设备失败。

2. 常见原因

本类故障的常见原因主要包括：

· 用户线下的认证方式配置错误。

· VTY用户线下支持的协议类型不正确。

· ISP域下配置的认证、授权、计费方案错误。

· 本地用户不存在、用户密码错误，或服务类型错误。

· 本地用户接入数量达到上限。

· 登录设备的用户数量到达上限。

· 全局密码管理功能开启的情况下，设备本地的lauth.dat文件异常。

3. 故障分析

本类故障的诊断流程如图8-14所示。

图8-14 本地认证登录失败的故障诊断流程图

‌

4. 处理步骤

Web、NETCONF over SOAP、FTP类登录故障无需关心用户线（类）下的配置，其它排障步骤相同。

(1) ‍检查用户线下的配置。

执行line vty first-number [ last-number ]命令进入指定的VTY用户线视图，并通过display this命令查看如下配置是否准确：

¡ authentication-mode是否配置为scheme。

¡ 对于Telnet登录：protocol inbound是否配置为telnet或为缺省情况。

¡ 对于SSH登录：protocol inbound是否配置为ssh或为缺省情况。

(2) 检查用户线类下的配置。

用户线视图下的配置优先于用户线类视图下的配置。若用户线视图下未配置，则需要继续检查用户线类视图下的配置。

执行line class vty命令进入VTY用户线类视图，并通过display this命令查看如下配置是否准确：

¡ authentication-mode是否配置为scheme。

¡ 对于Telnet登录：protocol inbound是否配置为telnet或为缺省情况。

¡ 对于SSH登录：protocol inbound是否配置为ssh或为缺省情况。

如果用户线和用户线类下的配置均不准确，请按照需要在指定的用户线或用户线类下设置认证方案为scheme，并设置用户登录支持的协议类型。

(3) 检查ISP域下的认证、授权、计费方案配置是否准确。

执行display domain命令，查看显示信息：

¡ 如果用户的登录用户名中携带了域名（假设为test），则查看该域下的“Login authentication scheme:”字段取值是否为Local。如果该域下无“Login authentication scheme:”字段，再查看“Default authentication scheme:”字段取值是否为Local。

<Sysname> display domain test

Domain: test

State: Active

Default authentication scheme: Local

Default authorization scheme: Local

Default accounting scheme: Local

Accounting start failure action: Online

Accounting update failure action: Online

Accounting quota out action: Offline

Service type: HSI

Session time: Exclude idle time

NAS-ID: N/A

DHCPv6-follow-IPv6CP timeout: 60 seconds

Authorization attributes:

Idle cut: Disabled

Session timeout: Disabled

IGMP access limit: 4

MLD access limit: 4

¡ 如果用户的登录用户名中未携带域名，则在系统视图下执行display this命令查看是否存在domain default enable isp-name配置。（下例中缺省域名为system）。

domain default enable system

- 如果存在该配置，则执行display domain命令查看isp-name域下的“Login authentication scheme:”字段取值是否为“Local”。如果该域下无“Login authentication scheme:”字段，再查看“Default authentication scheme:”字段取值是否为“Local”。

- 如果不存在该配置，则执行display domain命令查看system域下的“Login authentication scheme:”字段取值是否为“Local”。如果system域下无“Login authentication scheme:”字段，再查看“Default authentication scheme:”字段取值是否为“Local”。

授权、计费配置确认方式与认证类似，不再赘述。如果以上配置不准确，请在相关ISP下配置Login用户的认证/授权/计费方案均为Local。

(4) 检查用户名和密码是否正确。

执行display local-user命令查看是否存在对应的本地用户配置。

¡ 如果本地用户存在，则执行local-user username class manage命令进入本地用户视图，然后通过display this命令查看该视图下是否配置了密码，以及service-type配置是否为所需的服务类型。

- 若需要用户密码，则尝试重置一次密码（下例中为123456TESTplat&!）。

<Sysname> system-view

[Sysname] local-user test class manage

[Sysname-luser-manage-test] password simple 123456TESTplat&!

- 若服务类型错误，则配置与登录方式匹配的服务类型（下例中为SSH）。

<Sysname> system-view

[Sysname] local-user test class manage

[Sysname-luser-manage-test] service-type ssh

¡ 如果本地用户不存在，则执行local-user username class manage命令创建一个设备管理类本地用户（下例中用户名为test），并按需配置密码和服务类型。

<Sysname> system-view

[Sysname] local-user test class manage

[Sysname-luser-manage-test]

(5) 检查使用该本地用户名接入的用户数是否达到上限。

在本地用户视图下执行display this命令查看是否存在access-limit配置。

¡ 如果access-limit配置存在，则执行display local-user username class manage命令查看“Current access number:”字段取值是否达到配置的上限值。如果达到上限值，则根据需要采取以下措施之一：

- 在该本地用户视图下执行access-limit命令扩大用户数上限（下例中为20）。

<Sysname> system-view

[Sysname] local-user test class manage

[Sysname-luser-manage-test] access-limit 20

- 在用户视图下执行free命令强制其它在线用户下线（下例中为强制释放VTY1上建立的所有连接）。

<Sysname> free line vty 1

Are you sure to free line vty1? [Y/N]:y

[OK]

¡ 如果access-limit配置不存在，或者用户数未达到上限值，则继续定位。

(6) 检查指定登录类型的在线用户数是否到达上限。

a. ‍在系统视图下执行display this命令查看是否存在aaa session-limit的配置，若无此配置，则说明采用了缺省值32。

aaa session-limit ftp 33

domain default enable system

b. 执行display users查看当前用户线的用户登录情况，确认是否已到用户数上限。

c. 如果在线用户数到达上限，则根据需要采取以下措施之一：

- 在系统视图下执行aaa session-limit命令扩大用户数上限。

- 在用户视图下执行free命令强制其它在线用户下线。

(7) 检查本地lauth.dat文件是否正常。

开启全局密码管理功能后，设备会自动生成lauth.dat文件记录本地用户的认证、登录信息。如果手工删除或修改该文件，会造成本地认证异常。因此，请首先执行display password-control命令查看设备上是否开启了全局密码管理功能。

¡ 如果该文件不存在、大小为0或者很小（若小于20B，则大概率发生了异常），请优先联系技术支持人员协助处理，若当前配置需求紧迫，可尝试重新开启全局密码管理功能来解决此问题。

<Sysname> dir

Directory of flash: (EXT4)

0 drw- - Aug 16 2021 11:45:37 core

1 drw- - Aug 16 2021 11:45:42 diagfile

2 drw- - Aug 16 2021 11:45:57 dlp

3 -rw- 713 Aug 16 2021 11:49:41 ifindex.dat

4 -rw- 12 Sep 01 2021 02:40:01 lauth.dat

...

<Sysname> system-view

[Sysname] undo password-control enable

[Sysname] password-control enable

¡ 若未开启，则忽略此步骤。

(8) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息、告警信息、诊断信息。

¡ 打开Local-Server调试信息开关（通过debugging local-server all命令），收集设备的调试信息。

5. 告警与日志

8.3.2 RADIUS认证登录失败

1. 故障描述

管理员采用RADIUS认证登录设备失败。

2. 常见原因

本类故障的常见原因主要包括：

· 用户线下的认证方式配置错误。

· VTY用户线下支持的协议类型不正确。

· ISP域下配置的认证、授权、计费方案错误。

· 与RADIUS服务器交互失败。

· RADIUS服务器下发的Login-Service属性值不正确。

· RADIUS服务器未下发用户角色权限。

3. 故障分析

本类故障的诊断流程如图8-15所示。

图8-15 RADIUS认证登录失败的故障诊断流程图

4. 处理步骤

Web、NETCONF over SOAP、FTP类登录故障无需关心用户线（类）下的配置，其它排障步骤相同。

(1) 检查用户线下的配置。

执行line vty first-number [ last-number ]命令进入指定的VTY用户线视图，并通过display this命令查看如下配置是否准确：

¡ authentication-mode是否配置为scheme。

¡ 对于Telnet登录：protocol inbound是否配置为telnet或为缺省情况。

¡ 对于SSH登录：protocol inbound是否配置为ssh或为缺省情况。

(2) 检查用户线类下的配置。

用户线视图下的配置优先于用户线类视图下的配置。若用户线视图下未配置，则需要继续检查用户线类视图下的配置。

执行line class vty命令进入VTY用户线类视图，并通过display this命令查看如下配置是否准确：

¡ authentication-mode是否配置为scheme。

¡ 对于Telnet登录：protocol inbound是否配置为telnet或为缺省情况。

¡ 对于SSH登录：protocol inbound是否配置为ssh或为缺省情况。

如果用户线和用户线类下的配置均不准确，请按照需要，在指定的用户线或用户线类下设置认证方案为scheme，并设置用户登录支持的协议类型。

(3) 检查ISP域下的认证、授权、计费方案配置是否准确。

执行display domain命令，查看显示信息：

¡ 如果用户的登录用户名中携带了域名（假设为test），则查看该域下的“Login authentication scheme:”字段取值是否为“RADIUS=xx”。如果该域下无“Login authentication scheme:”字段，再查看“Default authentication scheme:”字段取值是否为“RADIUS=xx”。

<Sysname> display domain test

Domain: test

State: Active

Default authentication scheme: Local

Default authorization scheme: Local

Default accounting scheme: Local

Accounting start failure action: Online

Accounting update failure action: Online

Accounting quota out action: Offline

Service type: HSI

Session time: Exclude idle time

NAS-ID: N/A

DHCPv6-follow-IPv6CP timeout: 60 seconds

Authorization attributes:

Idle cut: Disabled

Session timeout: Disabled

IGMP access limit: 4

MLD access limit: 4

¡ 如果用户的登录用户名中未携带域名，则在系统视图下执行display this命令查看是否存在domain default enable isp-name配置（下例中缺省域名为system）。

domain default enable system

- 如果存在该配置，则执行display domain命令查看isp-name域下的“Login authentication scheme:”字段取值是否为“RADIUS=xx”。如果该域下无“Login authentication scheme:”字段，再查看“Default authentication scheme:”字段取值是否为“RADIUS=xx”。

- 如果不存在该配置，则执行display domain命令查看system域下的“Login authentication scheme:”字段取值是否为“RADIUS=xx”。如果system域下无“Login authentication scheme:”字段，再查看“Default authentication scheme:”字段取值是否为“RADIUS=xx”。

授权、计费配置确认方式与认证类似，不再赘述。如果以上配置不准确，请在相关ISP域下配置Login用户采用RADIUS认证/授权/计费方案（下例中认证/授权/计费均采用RADIUS方案rd1）。

<Sysname> system-view

[Sysname] domain test

[Sysname-isp-test] authentication login radius-scheme rd1

[Sysname-isp-test] authorization login radius-scheme rd1

[Sysname-isp-test] accounting login radius-scheme rd1

(4) 通过RADIUS的调试信息辅助排查如下故障。

¡ 执行debugging radius packet命令打开RADIUS报文调试信息开关，如果系统打印Authentication reject类的报文调试信息，则表示用户的认证请求被服务器拒绝。因此，需要继续查看RADIUS服务器上记录的认证日志，并通过日志中描述的失败原因联系服务器管理员进行相应的处理。

¡ 执行debugging radius error命令打开RADIUS错误调试信息开关，如果系统打印错误调试信息“Invalid packet authenticator.”，则表示设备与服务器的共享密钥不匹配，可以尝试在RADIUS方案下设置与服务器匹配的共享密钥。

¡ 执行debugging radius event命令打开RADIUS事件调试信息开关，如果系统打印事件调试信息“Response timed out. ”，则表示设备与服务器之间不可达，可以尝试排查设备和服务器中间链路不通的问题。

(5) 检查RADIUS服务器下发的Login-Service属性值是否为设备支持的业务类型。

执行debugging radius packet命令打开RADIUS的报文调试信息开关后，查看RADIUS服务器下发的Login-Service属性情况，并采用“用户接入类型与RADIUS服务器下发的Login-Service属性值不匹配”介绍的方法解决故障。

(6) 检查RADIUS服务器是否下发了正确的用户角色权限。

执行debugging radius all命令打开所有RADIUS调试信息开关后，如果用户输入用户名和密码后连接直接断开，且没有异常的RADIUS事件调试信息以及RADIUS错误调试信息输出，则有可能是RADIUS服务器未给用户下发用户角色或下发的用户角色错误导致。此时，可以查看RADIUS报文调试信息中是否包含“shell:roles="xx"”或“Exec-Privilege=xx”字段。

¡ 如果不包含，则表示RADIUS服务器未给用户下发用户角色权限，则可以选用如下方法之一解决：

- 在设备侧，可以通过执行role default-role enable rolename命令使能缺省用户角色授权功能，使得用户在没有被服务器授权任何角色的情况下，具有一个缺省的用户角色。

<Sysname> system-view

[Sysname] role default-role enable

- 联系RADIUS服务器管理员，为用户下发合适的用户角色。

¡ 如果包含，但指定的用户角色在设备上不存在，则需要联系RADIUS服务器管理员修改用户角色设置或者在设备上通过user-role role-name命令创建对应的用户角色。

(7) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息、告警信息、诊断信息。

¡ 打开RADIUS调试信息开关（通过debugging radius all命令），收集设备的调试信息。

5. 告警与日志

8.3.3 HWTACACS认证登录失败

1. 故障描述

管理员采用HWTACACS认证登录设备失败。

2. 常见原因

本类故障的常见原因主要包括：

· 用户线下的认证方式配置错误。

· VTY用户线下支持的协议类型不正确。

· ISP域下配置的认证、授权、计费方案错误。

· 与HWTACACS服务器交互失败。

· HWTACACS服务器未下发用户角色权限。

3. 故障分析

本类故障的诊断流程如图8-16所示。

图8-16 HWTACACS认证登录失败的故障诊断流程图

4. 处理步骤

Web、NETCONF over SOAP、FTP类登录故障无需关心用户线（类）下的配置，其它排障步骤相同。

(1) 检查用户线下的配置。

执行line vty first-number [ last-number ]命令进入指定的VTY用户线视图，并通过display this命令查看如下配置是否准确：

¡ authentication-mode是否配置为scheme。

¡ 对于Telnet登录：protocol inbound是否配置为telnet或为缺省情况。

¡ 对于SSH登录：protocol inbound是否配置为ssh或为缺省情况。

(2) 检查用户线类下的配置。

用户线视图下的配置优先于用户线类视图下的配置。若用户线视图下未配置，则需要继续检查用户线类视图下的配置。

执行line class vty命令进入VTY用户线类视图，并通过display this命令查看如下配置是否准确：

¡ authentication-mode是否配置为scheme。

¡ 对于Telnet登录：protocol inbound是否配置为telnet或为缺省情况。

¡ 对于SSH登录：protocol inbound是否配置为ssh或为缺省情况。

¡ 如果用户线和用户线类下的配置均不准确，请按照需要，在指定的用户线或用户线类下设置认证方案为scheme，并设置用户登录支持的协议类型。

(3) 检查ISP域下的认证、授权、计费方案配置是否准确。

执行display domain命令，查看显示信息：

¡ 如果用户的登录用户名中携带了域名（假设为test），则查看该域下的“Login authentication scheme:”字段取值是否为“HWTACACS=xx”。如果该域下无“Login authentication scheme:”字段，再查看“Default authentication scheme:”字段取值是否为“HWTACACS=xx”。

<Sysname> display domain test

Domain: test

State: Active

Default authentication scheme: Local

Default authorization scheme: Local

Default accounting scheme: Local

Accounting start failure action: Online

Accounting update failure action: Online

Accounting quota out action: Offline

Service type: HSI

Session time: Exclude idle time

NAS-ID: N/A

DHCPv6-follow-IPv6CP timeout: 60 seconds

Authorization attributes:

Idle cut: Disabled

Session timeout: Disabled

IGMP access limit: 4

MLD access limit: 4

¡ 如果用户的登录用户名中未携带域名，则在系统视图下执行display this命令查看是否存在domain default enable isp-name配置。（下例中缺省域名为system）。

domain default enable system

- 如果存在该配置，则执行display domain命令查看isp-name域下的“Login authentication scheme:”字段取值是否为“HWTACACS=xx”。如果该域下无“Login authentication scheme:”字段，再查看“Default authentication scheme:”字段取值是否为“HWTACACS=xx”。

- 如果不存在该配置，则执行display domain命令查看system域下的“Login authentication scheme:”字段取值是否为“HWTACACS=xx”。如果system域下无“Login authentication scheme:”字段，再查看“Default authentication scheme:”字段取值是否为“HWTACACS=xx”。

授权、计费配置确认方式与认证类似，不再赘述。如果以上配置不准确，请在相关ISP域下配置Login用户采用HWTACACS认证/授权/计费方案（下例中认证/授权/计费均采用HWTACACS方案hwt1）。

<Sysname> system-view

[Sysname] domain test

[Sysname-isp-test] authentication login hwtacacs-scheme hwt1

[Sysname-isp-test] authorization login hwtacacs-scheme hwt1

[Sysname-isp-test] accounting login hwtacacs-scheme hwt1

(4) 通过HWTACACS的调试信息辅助排查如下故障。

¡ 执行debugging hwtacacs send-packet和debugging hwtacacs receive-packet命令打开HWTACACS报文发送/接收调试信息，如果系统打印应答报文调试信息中包含“status: STATUS_FAIL”，则表示用户的认证请求被服务器拒绝。因此，需要继续查看HWTACACS服务器认证日志中描述的失败原因，并根据具体的失败原因继续定位。

¡ 执行debugging hwtacacs error命令打开HWTACACS错误调试信息开关，如果系统打印错误调试信息“Failed to get available server.”，则通常表示设备与服务器的共享密钥不匹配，可以尝试在HWTACACS方案下设置与服务器匹配的共享密钥。

¡ 执行debugging hwtacacs event命令打开HWTACACS事件调试信息开关，如果系统打印事件调试信息“Connection timed out.”，则表示设备与服务器之间不可达，可以尝试排查设备和服务器中间链路不通的问题。

(5) 检查HWTACACS服务器是否下发了正确的用户角色权限。

执行debugging hwtacacs all命令打开所有HWTACACS调试信息开关后，如果发现客户端登录时直接断开连接，且没有异常的HWTACACS事件调试信息以及HWTACACS错误调试信息输出，则有可能是HWTACACS服务器未给用户下发用户角色权限导致。此时，可以查看HWTACACS的接收报文调试信息是否包含“priv-lvl=xx”或“roles=xx”字段。

¡ 如果不包含，则表示HWTACACS服务器未给用户下发用户角色权限，则可以选用如下方法之一解决：

<Sysname> system-view

[Sysname] role default-role enable

- 联系HWTACACS服务器管理员，为用户下发合适的用户角色。HWTACACS服务器上的授权角色配置必须满足格式：roles="name1 name2 namen"，其中name1、name2、namen为要授权下发给用户的用户角色，可为多个，并使用空格分隔。

(6) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息、告警信息、诊断信息。

¡ 打开HWTACACS调试信息开关（通过debugging hwtacacs all命令），收集设备的调试信息。

5. 告警与日志

8.3.4 用户接入类型与RADIUS服务器下发的Login-Service属性值不匹配

1. 故障描述

由于设备不支持RADIUS服务器下发的Login-Service属性值，导致用户认证失败。

打开设备上RADIUS的报文调试信息开关（通过执行debugging radius packet命令），在如下形式的调试信息中查看到服务器下发的Login-Service属性类型为设备不支持的类型：

*Aug 3 02:33:18:707 2021 Sysname RADIUS/7/PACKET:

Service-Type=Framed-User

Idle-Timeout=66666

Session-Timeout=6000

2. 常见原因

本类故障的主要原因为，用户登录的业务类型与服务器下发的Login-Service属性所指定的业务类型不一致。

· 0：Telnet（标准属性）

· 50：SSH（扩展属性）

· 51：FTP（扩展属性）

· 52：Terminal（扩展属性）

· 53：HTTP（扩展属性）

· 54：HTTPS（扩展属性）

可以通过命令行设置设备对Login-Service属性的检查方式，控制设备对用户进行业务类型一致性检查的方式。

3. 故障分析

本类故障的诊断流程如图8-17所示。

图8-17 用户接入类型与RADIUS服务器下发的Login-Service属性值不匹配的故障诊断流程图

4. 处理步骤

(1) 检查RADIUS服务器下发的Login-Service属性与接入类型是否匹配。

在接入设备上执行display radius scheme命令，查看RADIUS方案下的“Attribute 15 check-mode”字段取值：

¡ 取值为Loose，表示采用松散检查方式，即使用Login-Service的标准属性值对用户业务类型进行检查。对于SSH、FTP、Terminal用户，在RADIUS服务器下发的Login-Service属性值为0（表示用户业务类型为Telnet）时才，这类用户才能够通过认证。

¡ 取值为Strict，表示采用严格检查方式，即使用Login-Service的标准属性值以及扩展属性值对用户业务类型进行检查。对于SSH、FTP、Terminal用户，当RADIUS服务器下发的Login-Service属性值为对应的扩展取值时，这类用户才能够通过认。

如果RADIUS服务器下发给用户的Login-Service属性不属于设备支持的Login-Service属性范围，则可以选用如下方法之一解决：

¡ 在RADIUS服务器上，设置服务器不下发Login-Service属性或者修改下发的属性值为接入设备支持的取值。

¡ 在接入设备上，进入相应的RADIUS方案，通过执行attribute 15 check-mode命令修改对Login-Service属性的检查方式（下例中为松散检查方式）。

<Sysname> system-view

[Sysname] radius scheme radius1

[Sysname-radius-radius1] attribute 15 check-mode loose

(2) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息、调试信息、告警信息。

5. 告警与日志

9 运维与可视化类故障处理

9.1 NQA故障处理

9.1.1 ICMP-echo测试失败

1. 故障描述

(1) ‍在设备上执行display nqa { history | result | statistics }命令查看NQA测试结果，会看到测试失败。

¡ 如果执行display nqa history命令，且看到显示信息中Status字段的取值不是Succeeded，则表示NQA测试失败。

¡ 如果执行display nqa result或display nqa statistics命令，且看到显示信息中Extended results字段的取值不为0，则表示NQA测试失败。

(2) 如果业务模块（例如Track）引用了探测失败的NQA测试，会观察到业务模块采取相应措施（例如Track项的状态会从Positive变成Negative或NotReady）。

2. 常见原因

(1) ‍如果探测结果中Status字段的取值为Internal error或Unknown error，导致该类故障的常见原因主要包括：

¡ 设备上不存在测试目的地址的路由或ARP表项。

¡ 设备内存不足。

¡ 其他内部原因。

(2) 如果探测结果中Status字段的取值为Timeout，表示在测试超时前，未收到响应报文。导致该类故障的常见原因主要包括：

¡ 网络错误，例如：

- 探测报文途径安全设备时被误认为攻击报文而被丢弃。

- 网络时间频繁跳变。

- 探测报文出现传输错误，接口CRC校验报错。

- 探测报文传输路径上其他形式的报文丢失。

¡ 配置错误，例如：

- 组网复杂，探测源端到目的端途径的设备太多，NQA探测缺省TTL（20）无法满足需求。

- 探测报文过大，导致分片过多，处理超时。

- 配置了错误的出接口、下一跳。

- 配置了错误的源地址。

- 配置了过小的探测超时时间。

3. 故障分析

本类故障的诊断流程如图9-1所示。

图9-1 ICMP-echo测试失败故障诊断流程图

4. 处理步骤

(1) ‍执行display nqa { history | result | statistics }命令收集NQA探测结果，找到失败的NQA测试、测试执行的时间以及测试失败的类型。

¡ 如果display nqa history命令显示信息中Status字段的取值不是Succeeded，表示该条NQA测试失败。

<Sysname> display nqa history admin test

NQA entry (admin admin, tag test) history records:

Index Response Status Time

10 500 Timeout 2023-03-12 17:03:01.6

9 500 Timeout 2023-03-12 17:03:01.1

...

Status字段的取值包括：

- Succeeded：测试成功，接收到响应报文

- Internal error：内部错误导致NQA测试失败（如果配置了NQA与Track联动，则该状态不会触发Track状态切换）

- Unknown error：未知错误导致NQA测试失败（如果配置了NQA与Track联动，则该状态会触发Track状态切换）

- Timeout：请求超时导致NQA测试失败（如果配置了NQA与Track联动，则该状态会触发Track状态切换）

¡ 如果display nqa result命令显示信息中Extended results字段的取值不为0，则表示最近一次NQA测试失败。

<Sysname> display nqa result admin test

NQA entry (admin admin, tag test) test results:

Send operation times: 1 Receive response times: 1

Min/Max/Average round trip time: 35/35/35

Square-Sum of round trip time: 1225

Last succeeded probe time: 2023-03-12 10:50:33.2

Extended results:

Packet loss ratio: 0%

Failures due to timeout: 0

Failures due to disconnect: 0

Failures due to no connection: 0

Failures due to internal error: 0

Failures due to other errors: 0

¡ 如果display nqa statistics命令显示信息中Extended results字段的取值不为0，则表示曾经执行的某个测试失败。

<Sysname> display nqa statistics admin test

NQA entry (admin admin, tag test) test statistics:

NO. : 1

Start time: 2023-03-12 09:30:20.0

Life time: 2 seconds

Send operation times: 1 Receive response times: 1

Min/Max/Average round trip time: 13/13/13

Square-Sum of round trip time: 169

Extended results:

Packet loss ratio: 0%

Failures due to timeout: 0

Failures due to disconnect: 0

Failures due to no connection: 0

Failures due to internal error: 0

Failures due to other errors: 0

¡ 如果display nqa { history | result | statistics }命令显示信息中的时间不是您关注的时间，很可能您配置的NQA测试未启动，请执行nqa schedule命令来启动NQA测试。

(2) 对于失败类型为Internal error、Unknown error的NQA测试，请参照以下步骤进行处理。

a. ‍明确NQA测试的目的地址。

执行display current-configuration [ configuration nqa ]查看NQA配置信息，显示信息中destination ip、destination ipv6命令携带的IP地址即为NQA测试的目的地址。如果该地址配置错误，请在系统视图执行undo nqa schedule命令停止NQA测试，在NQA测试组视图下执行destination ip、destination ipv6命令修改后，再重新开始测试。

b. Ping NQA测试的目的地址，如果Ping不通，请先解决NQA测试的目的地址路由不可达问题。如果确定有去往NQA测试目的地址的数据链路，但是路由表无去往NQA测试的目的地址的路由，可在ICMP-echo测试类型视图下，配置out interface或者next-hop ip命令，NQA会跳过查路由表的环节，直接用指定的IP地址封装NQA测试报文。

c. 判断是否因为设备内存不足，导致NQA测试失败。

d. 执行display memory-threshold命令查看内存告警门限相关信息，如果Current free-memory state字段取值为Minor（一级告警门限状态）、Severe（二级告警门限状态）或Critical（三级告警门限状态），则说明设备内存不足，请先解决设备内存不足问题。

(3) 对于失败类型为Timeout的NQA测试，请参照以下步骤进行处理。

a. ‍明确NQA测试的目的地址。

c. 如果能Ping通，但是概率丢包，观察display nqa statistics时延结果最大值（Max round trip time）是否是接近ICMP-echo测试类型视图下probe timeout命令配置的值：

- 如果是，则说明链路时延较大，probe timeout配置值过小，请将probe timeout配置为大于Max round trip time的值。

- 如果否，则属于链路随机丢包，请重点关注是否存在接口CRC校验错误。针对测试响应报文的入接口执行display interface命令，显示信息中Input的CRC字段的取值即为CRC校验错误报文的数量。如果该数量持续较快增长，可能是传输链路中的元器件出现故障，需要进一步定位。

d. 使用和NQA测试完全相同的参数Ping NQA测试的目的地址，来帮助判断是否因为参数配置错误导致NQA测试失败。完全相同的参数包括：报文大小、出接口、下一跳、源地址、初始TTL。

- 如果可以Ping通，那么很有可能是探测路径上的安全设备过滤了NQA的探测报文。请进一步定位。

- 如果不可以Ping通，可进一步修改发包参数，观察是否可以Ping通。如果可以Ping通，则很有可能是因为参数配置错误导致NQA测试失败。

NQA探测缺省TTL取值为20，如果组网中测试报文的源到目的端的设备数量超过了20，请在ICMP-echo测试类型视图下执行ttl命令修改。

探测报文过大，导致分片过多，处理超时。可在ICMP-echo测试类型视图下执行data-size命令修改。

配置了错误的出接口、下一跳，可在ICMP-echo测试类型视图下执行out interface、nexthop命令修改。

配置了错误的源地址，可在ICMP-echo测试类型视图下执行source ip、source ipv6命令修改。（ICMP-echo测试不支持配置源端口，其它测试可能需要执行source port命令修改源端口）

配置了过小的探测超时时间，可在ICMP-echo测试类型视图下执行probe timeout命令修改。

- 如果始终无法ping通，则需要通过抓包、流量统计、查看调试信息等手段明确丢包原因。

(4) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息、告警信息。

5. 告警与日志

9.1.2 TWAMP-light探测失败

1. 故障描述

设备作为源端，向目的端发起TWAMP-light探测。当出现以下任一情况时，均可判定TWAMP-light探测失败：

· TWAMP-light探测状态异常

在设备上执行display nqa twamp-light client命令，显示信息中Status字段的取值为Inactive时，表明未启动TWAMP-light探测，TWAMP-light探测失败。

· TWAMP-light探测结果异常

在设备上执行display nqa twamp-light client statistics two-way-loss test-session命令，当Loss count字段取值不为0时，表示网络中出现了TWAMP-light探测报文丢失的情况；当Error count字段取值不为0时，表示设备收到了错误的TWAMP-light探测报文。如果丢包和错包个数超过用户业务允许范围，就可以认为TWAMP-light会话探测失败。

2. 常见原因

· 对于探测状态异常的情况，本类故障的常见原因主要包括：

¡ L3VPN场景下VPN被删除。

¡ L2VPN场景下源AC状态down。

¡ 如果配置了source interface命令，但接口板被拔出，接口不存在。

· 对于探测结果异常的情况，本类故障的常见原因主要包括：

¡ 丢包问题

- 配置错误，客户端与服务器侧的配置不匹配

- 与探测目的地址路由不可达，Ping不通或者Ping出现丢包

- 接口CRC校验错误

¡ 错包问题

- 配置错误，执行start命令启动TWAMP-light测试时，配置的timeout参数值过小，反射报文在timeout超时之后才到达设备，设备认为该报文为错包。

- 报文内容有不符合协议要求的字段

- 报文封装失败

3. 故障分析

本类故障的诊断流程如图图9-2所示：

图9-2 TWAMP-light探测失败的故障诊断流程图

4. 处理步骤

(1) 收集TWAMP-light探测状态及结果。

在设备上执行display nqa twamp-light client和display nqa twamp-light client statistics two-way-loss test-session命令，明确存在问题的探测，并收集探测状态及结果。

¡ 如果执行display nqa twamp-light client命令，显示信息中Status字段的取值为Inactive，则表示TWAMP-light探测状态异常。

<Sysname> display nqa twamp-light client

Brief information about all test sessions:

Total sessions: 1

Active sessions: 1

-----------------------------------------------------------------------------

ID Status Source IP/Port Destination IP/Port

1 Active 1.1.1.1/10000 1.1.1.2/20000

¡ 如果执行display nqa twamp-light client statistics two-way-loss test-session命令，显示信息中Loss count字段取值不为0，则表示TWAMP-light探测结果为丢包；显示信息中Error count字段取值不为0，则表示TWAMP-light探测结果为错包。

<Sysname> display nqa twamp-light client statistics two-way-delay test-session 1

Latest two-way loss statistics:

Index Loss count Loss ratio Error count Error ratio

1 200 100.0000% 0 0.0000%

2 200 100.0000% 0 0.0000%

3 200 100.0000% 0 0.0000%

4 200 100.0000% 0 0.0000%

5 200 100.0000% 0 0.0000%

--------------------------------------------------------------------------------

Average loss count : 200 Average loss ratio : 100.0000%

Maximum loss count : 200 Maximum loss ratio : 100.0000%

Minimum loss count : 200 Minimum loss ratio : 100.0000%

Average error count : 0 Average error ratio : 0.0000%

Maximum error count : 0 Maximum error ratio : 0.0000%

Minimum error count : 0 Minimum error ratio : 0.0000%

(2) 对于探测状态异常的情况，请参照以下步骤进行处理：

a. 如果设备刚启动、刚完成主备倒换或者配置的source interface所在接口板未完成启动时，请等待设备状态稳定后再观察探测状态是否恢复成Active。执行display system stable state命令，如果显示信息中System state字段的取值为Stable，则表示设备已经处于稳定状态。

- 如果恢复成Active，则无需继续处理。

- 如果未恢复成Active，请继续定位。

b. 如果设备已经稳定运行，请检查配置是否完整。

- 对于L3VPN场景，请执行display nqa twamp-light client verbose命令查看TWAMP-light探测绑定的VPN，并执行display ip vpn-instance命令查看该VPN是否存在。如果绑定的VPN不存在，请在系统视图下，执行ip vpn-instance命令来创建VPN实例。

- 对于L2VPN场景，请执行display nqa twamp-light client verbose命令查看Source interface字段的取值，如果取值为“-”，请在TWAMP-light测试的Client-session视图下执行source interface命令用来配置探测帧的源AC，且需要确保绑定的接口处于up状态。

c. 检查组网连接是否就绪。如果TWAMP-light探测绑定了源接口或者源AC，则要求源接口和源AC处于up状态。

- 执行display l2vpn pw xconnect-group或者display l2vpn forwarding ac命令，显示信息中State字段的取值表示AC的状态。如果AC状态为Down，请先解决AC故障问题。

- 执行display interface命令，显示信息中Current state、Line protocol state字段的取值表示接口的状态。如果接口状态为Down，请先保证接口UP。

(3) 针对探测结果丢包问题，请参照以下步骤进行处理：

a. 检查是否因为配置错误，导致丢包。

在设备上执行display nqa twamp-light client verbose命令，在探测目的端执行display nqa twamp-light responder命令，查看TWAMP-light探测参数。如果指定了以下参数，则要求源端和目的端的配置一致。

- 源IP地址。在源端，该参数可通过TWAMP-light测试的Client-session视图下的source ip、source ipv6命令修改。

- 源端口号。在源端，该参数可通过TWAMP-light测试的Client-session视图下的source port命令修改。

- 目的IP地址。在源端，该参数可通过TWAMP-light测试的Client-session视图下的destination ip、destination ipv6命令修改。

- 目的端口号。在源端，该参数可通过TWAMP-light测试的Client-session视图下的destination port命令修改。

- VPN实例名称。在源端，该参数可通过TWAMP-light测试的Client-session视图下的vpn-instance命令修改。

- VLAN ID。在源端，该参数可通过TWAMP-light测试的Client-session视图下的vlan命令修改。

- 源MAC地址。在源端，该参数可通过TWAMP-light测试的Client-session视图下的source mac命令修改。

- 目的MAC地址。在源端，该参数可通过TWAMP-light测试的Client-session视图下的destination mac命令修改。

以上参数，在探测目的端，均可通过TWAMP-light-responder视图下的test-session命令来修改。

TWAMP-light测试的其它配置要求如下：当源端（TWAMP-light sender）上时间戳类型配置为NTP，且测试报文的发包间隔配置为10ms或100ms时，设备会认为配置冲突，导致TWAMP_LIGHT测试启动失败。请在TWAMP-light-sender视图下通过start命令修改发包间隔，或者在TWAMP-light测试的Client-session视图下通过timestamp-format命令修改时间戳格式。

b. 在源端的用户视图依次执行terminal monitor、terminal debugging、debugging nqa error和debugging nqa event命令，打开NQA调试信息输出开关，让NQA调试信息通过登录终端的屏幕输出。然后在Probe视图下执行view /var/log/trace.log命令，可以查看NQA的Trace log信息。通过日志信息可以判断设备是否正常发送TWAMP-light探测报文、收到TWAMP-light响应报文、探测结果中的时间戳是否正常。

- 如果源端未正常发送TWAMP-light探测报文，请根据登录终端显示的NQA调试信息和Trace log信息来初步判定发包失败的原因，并根据发包失败的原因修改源端的TWAMP-light配置，并重新启动TWAMP-light探测。如果根据登录终端显示的NQA调试信息和Trace log信息无法解决源端未正常发送TWAMP-light探测报文的问题，可以执行以下命令收集显示信息，执行步骤（5）。

- display ip statistics

- display ipv6 statistics

- display ethernet statistics

- 如果源端未正常收到TWAMP-light响应报文，可在目的端的系统视图执行nqa agent enable命令开启NQA client功能，然后返回用户视图依次执行terminal monitor、terminal debugging、debugging nqa packet命令，打开NQA报文调试信息输出开关。查看目的端是否收到NQA报文，NQA报文的配置是否正确。如果目的端未收到NQA报文，大概率是网络出现了故障，请继续参照下面的步骤定位网络故障。如果NQA报文配置错误，请参考步骤9.1.2 4. (3)a修改NQA配置后再重新开启测试。目的端可查看到的NQA报文调试信息示例：

- 探测结果中的时间戳的关系应该为：CSendTime≤CRecvTime、SRecvTime≤SsendTime，且NQA server的处理时间SSendTime–SrecvTime值应该较小。如果未满足以上时间戳的要求，则表示时间戳异常。请收集时间戳信息及执行display device命令收集设备板卡信息，执行步骤（5）。

Trace log信息示例：

*May 6 00:36:24:900 2023 Sysname NQA/7/KDIAG: send packt, session 1, ucSampler 187.

// 以上调试信息表明设备发送了一个TWAMP-light探测报文

*May 6 00:36:24:901 2023 Sysname NQA/7/KDIAG: Twmap Recv Pakcet ucSampler=187

// 以上调试信息表明设备收到了一个TWAMP-light响应报文

*May 6 00:36:24:901 2023 Sysname NQA/7/KDIAG: cSendSec is 1683304584, cSendFrac is 900923500, sRecvSec is 1683304584, sRecvFrac is 835000000,cRecvSec is 1683304584, cRecvFrac is 901923500, sSendSec is 1683304584, sSendFrac is 835000000

*May 6 00:36:24:901 2023 Sysname NQA/7/KDIAG: nqa entry (twamplight?session-1) Sampler(187) client time:

CSendTime=1683304584900923 CRecvTime=1683304584901923 SRecvTime=1683304584835000 SSendTime=1683304584835000

// 以上调试信息表明设备进行一次TWAMP-light探测获取到的时间戳

c. 检查是否因为网络故障，导致丢包。对检测目的地址执行ping命令，如果Ping失败或者有丢包，请先解决网络故障。

d. 检查是否因为CRC校验错误，导致丢包。

e. 执行display counters命令，如果显示信息中Err (pkts)字段的取值随着探测的进行在不断增长，则表示链路层发包出现错误，请更换接口或者线缆来尝试解决该故障。

(4) 针对探测结果错包问题，请参照以下步骤进行处理：

a. 确认是否因为配置错误，导致设备将迟到的TWAMP-light响应报文误认为是错包。

- 在源端对探测目的端执行ping命令，探测源端到目的端的最大时延（对应Ping结果中round-trip min/avg/max/std-dev字段中max的取值，单位为ms）。

- 在设备上执行display nqa twamp-light client verbose命令，查看TWAMP-light响应报文的超时时间（对应显示信息中Timeout(sec)字段的值）。TWAMP-light响应报文的超时时间必须大于源端到目的端的最大时延，否则，请在TWAMP-light-sender视图下执行start命令重新指定time-out参数的值。

b. 在源端的用户视图依次执行terminal monitor、terminal debugging、debugging nqa error和debugging nqa event命令，打开NQA调试信息输出开关，让NQA调试信息通过登录终端的屏幕输出。然后在Probe视图下执行view /var/log/trace.log命令，查看NQA的Trace log信息。通过日志信息判断报文内容是否符合协议要求、报文封装是否正确。如果报文内容不符合协议要求、报文封装不正确，请参照TWAMP-light配置手册要求，重新配置TWAMP-light探测。

(5) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息、告警信息。

5. 告警与日志

9.2 NTP故障处理

9.2.1 NTP时钟未同步故障处理

1. 故障描述

设备作为NTP客户端，未能同步NTP服务器端的时钟。在设备上执行display ntp-service status命令，显示信息中Clock status字段的取值为unsynchronized，表示NTP时钟未同步。

2. 常见原因

本类故障的常见原因主要包括：

· NTP配置错误。

· NTP时间同步链路不通。

· 链路震荡，时延不稳定。

· NTP服务器端时间同步异常。

3. 故障分析

本类故障的诊断流程如图9-3所示。

图9-3 NTP时钟不同步的故障诊断流程图

4. 处理步骤

NTP支持以下几种工作模式：

· 客户端/服务器模式

· 对等体模式

· 广播模式

· 组播模式

其中客户端/服务器模式、广播模式和组播模式均基于C/S模型。以下处理步骤基于C/S模型，设备作为客户端、NTP时钟未同步的情况进行描述。如果采用对等体模式由本端同步对端的时间，也可使用下述处理步骤，此时本端相当于C/S模型中的客户端。

(1) 在设备上执行display ntp-service [ ipv6 ] sessions命令，如果没有显示信息，则表示未开启NTP功能，请参照配置手册先配置NTP功能。如果有显示信息，请按照以下步骤定位：

a. 查看source字段的取值是否为预期的NTP服务器端的IP地址。如果不是，请执行步骤（2）修改NTP的配置。

b. 对于IPv4 NTP功能，请查看stra字段的取值，对于IPv6 NTP功能，请查看Clock stratum字段的取值。设备作为NTP客户端时，要求NTP服务器的时钟层级必须大于等于0小于等于14。如果NTP服务器的时钟层级为15或16，则不同步NTP服务器的时钟，可登录NTP服务器并执行ntp-service refclock-master命令修改NTP服务器的NTP层级。

c. 对于IPv4 NTP功能，请查看reach字段的取值，对于IPv6 NTP功能，请查看Reachabilities字段的取值，如果取值为0，表示路由不可达，请执行步骤（3）来处理。

IPv4 NTP会话显示信息样例：

<Sysname> display ntp-service sessions

source reference stra reach poll now offset delay disper

********************************************************************************

[12345]LOCAL(0) LOCL 0 1 64 - 0.0000 0.0000 7937.9

[5]1.1.1.1 INIT 16 0 64 - 0.0000 0.0000 0.0000

Notes: 1 source(master), 2 source(peer), 3 selected, 4 candidate, 5 configured.

Total sessions: 1

IPv6 NTP会话显示信息样例：

<Sysname> display ntp-service ipv6 sessions

Notes: 1 source(master), 2 source(peer), 3 selected, 4 candidate, 5 configured.

Source: [12345]3000::32

Reference: 127.127.1.0 Clock stratum: 2

Reachabilities: 1 Poll interval: 64

Last receive time: 6 Offset: -0.0

Roundtrip delay: 0.0 Dispersion: 0.0

Total sessions: 1

(2) 检查NTP相关配置是否正确。

根据组网规划，确认设备使用的NTP工作模式。根据NTP使用的工作模式，在设备上执行display current-configuration | include ntp-service命令查看NTP相关配置，来进一步排查当前NTP相关配置是否正确。例如，当采用客户端/服务器模式，并且本端作为客户端进行时间同步时，要求：

¡ 服务器地址配置必须正确，对应的配置命令为系统视图下的ntp-service [ ipv6 ] unicast-server。

¡ 系统时间的获取方式为NTP，对应的配置命令为系统视图下的clock protocol ntp。

¡ 如果需要使用NTP验证功能，还要求在设备和NTP服务器端上均配置的认证密钥必须一致，且本设备上使用的认证密钥对应的秘钥ID在对端设备上是可信的。对应的配置命令为系统视图下的ntp-service authentication-keyid（配置的认证密钥）和ntp-service reliable authentication-keyid（配置认证密钥对应的秘钥ID是可信的）。

(3) 执行ping命令，检查设备和NTP服务器端之间是否路由可达。

¡ 如果可以Ping通，说明设备和NTP服务器端之间路由可达，请执行步骤（4）。

¡ 如果无法Ping通，请参见“Ping和Tracert故障处理”中的“Ping不通”先解决网络不通问题。待设备和网管之间可以Ping通后，再执行步骤（4）。

(4) 在用户视图配置debugging ntp-service all命令打开NTP调试信息开关，查看调试信息，出现以下两种情况时，本端不会同步NTP服务器端的时钟：

¡ 如果调试信息中出现“The packet from ip-address failed the validity tests result”，则表示设备从NTP服务器（IP地址为ip-address）接收到的报文未通过合法性检查，检查结果为result，设备不会同步该NTP服务器的时钟。

¡ NTP报文调试信息中，“rdel: delay”、“rdsp: disper”，如果delay>16000、disper>16000或delay/2+disper>16000，则表示NTP服务器提供的时钟偏差过大，设备不会同步该NTP服务器的时钟。

(5) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息、告警信息。

NTP报文交互较慢，使用debugging ntp-service all命令开启NTP调试信息开关后，请等待5～10分钟后再收集调试信息。

5. 告警与日志

9.3 Ping和Tracert故障处理

9.3.1 Ping不通

1. 故障描述

在源端执行Ping操作，在一定时间范围内没有收到目的端对该请求的回应。

2. 常见原因

存在三种故障情形：

· 源端没有发出请求报文。

· 目的端没有发出应答报文。

· 中间设备丢包或传输时间长。

本类故障的常见原因主要包括：

· 链路传输时延较长。由于传输时延长，虽然源端接收到了目的端的回应报文，但已经超过等待时限而造成Ping不通的现象。

· 配置不当。例如，当Ping报文过大时，报文的出接口MTU值较小，且设置了不可分片的功能等。

· FIB表或ARP表中缺少对应的表项。

· 存在防攻击配置。

· 硬件故障。

3. 故障分析

本类故障的诊断思路如下：

(1) 检查Ping操作是否得当，调整Ping操作参数。

(2) 查看Ping报文的统计信息，确认出问题的节点。

(3) 检查是否存在到达目的端的ARP以及FIB表项。

(4) 排查是否因为防攻击配置导致Ping报文被丢弃。

本类故障的诊断流程如图9-4所示。

图9-4 Ping不通故障诊断流程图

4. 处理步骤

(1) 检查Ping操作是否得当。

a. 检查是否因为实际链路传输时延较长导致Ping不通。

检查是否执行了ping -t timeout命令，如果执行了此操作，可通过增加-t参数的值（建议取值大于等于1000，达到秒级）或者去掉-t参数重新Ping。如果故障消除，则说明较大概率属于实际网络时延大导致的Ping不通；如果故障未消除，请继续定位。

-t参数用来指定ICMP回显应答（ECHO-REPLY）报文的超时时间，单位为毫秒，缺省值为2000。如果源端在timeout时间内未收到目的端的ICMP回显应答（ECHO-REPLY）报文，则会认为目的端不可达。

b. 检查是否因为Ping报文过大而被丢弃。

检查是否执行了ping -f –s packet-size命令，如果执行了此操作，且报文转发路径上存在出接口的MTU小于报文长度packet-size的情况，则会导致报文因为超大且不允许被分片而被丢弃。可以通过减小报文长度或者取消-f参数来解决这个问题。

· -f参数表示将长度大于出接口MTU的报文直接丢弃，即不允许对发送的ICMP回显请求报文进行分片。

· -s packet-size参数用来指定发送的ICMP回显请求报文的长度（不包括IP和ICMP报文头），单位为字节，缺省值为56。

以太网接口MTU的缺省值为1500字节，可以通过执行display interface命令来查看接口的MTU值：

<Sysname> display interface gigabitethernet 2/0/1

GigabitEthernet2/0/1

Current state: UP

Line protocol state: UP

Description: GigabitEthernet2/0/1 Interface

Bandwidth: 1000000 kbps

Maximum transmission unit: 1500

其它显示信息略……

c. 检查是否指定了错误的出接口。

检查是否执行了ping -i interface-type interface-number命令指定Ping报文的出接口。如果指定了出接口，请确保该接口和目的端之间的物理链路是否可达。否则，请换成其它接口或者去掉-i参数。

-i interface-type interface-number参数用来指定发送ICMP回显请求报文的接口的类型和编号。不指定该参数时，将根据目的IP查找路由表或者转发表来确定发送ICMP回显请求报文的接口。

d. 检查是否指定了源地址。

检查是否执行了ping –a source-ip命令指定Ping报文的源地址。如果执行了该命令，请确保中间设备和目的端有到达源地址source-ip的路由。

-a source-ip：指定ICMP回显请求（ECHO-REQUEST）报文的源IP地址。该地址必须是设备上已配置的IP地址。不指定该参数时，ICMP回显请求报文的源IP地址是该报文出接口的主IP地址。

e. 检查是否为目的端指定了准确的VPN。

根据网络规划和部署情况，确认目的端是否属于某个VPN。如果目的端属于某个VPN，则需要在执行ping命令时通过-vpn-instance参数指定目的端所属的VPN。

(2) 查看源端、目的端以及中间设备的收发包统计，确认Ping故障发生的方向。

¡ 检查源端是否发出了ICMP回显请求报文，并收到了ICMP回显应答报文。

源端执行Ping操作后，在源端和目的端分别使用display icmp statistics命令查看ICMP报文收发情况。可以根据统计信息中Input和Output区段报文的数量来确定Ping出现问题的方向：

- 如果源端Output区段的echo值正常增加，但Input区段的echo replies值没有增加，则说明源端发出了请求但是没有收到回应；与此同时，如果目的端Input区段和Output区段的计数都没有变化，则说明目的端没有收到请求也没有给予回应。这样，就可以确定Ping报文是在从源端到目的端的方向上出现了转发故障。

- 如果源端Output区段的echo值正常增加，但Input区段的echo replies值没有增加，则说明源端发出了请求但是没有收到回应；与此同时，如果目的端Input区段和Output区段的计数都正常增加，则说明目的端收到了请求，同时发出了回应。这样，就可以确定Ping报文是在从目的端到源端的方向上出现了转发故障。

display icmp statistics命令显示信息示例如下：

<Sysname> display icmp statistics

Input: bad formats 0 bad checksum 0

echo 1 destination unreachable 0

source quench 0 redirects 0

echo replies 0 parameter problem 0

timestamp 0 information requests 0

mask requests 0 mask replies 0

time exceeded 0 invalid type 0

router advert 0 router solicit 0

broadcast/multicast echo requests ignored 0

broadcast/multicast timestamp requests ignored 0

Output: echo 0 destination unreachable 0

source quench 0 redirects 0

echo replies 1 parameter problem 0
timestamp 0 information replies 0

mask requests 0 mask replies 0

time exceeded 0 bad address 0

packet error 0 router advert 0

其它显示信息略……

· 当目的端是框式设备或者IRF设备，且ICMP报文到达目的端未被分片时，请在目的端执行带slot参数的display icmp statistics命令来查看ICMP报文统计信息，slot为目的端接收该ICMP报文的接口所在的Slot。

· 当目的端是框式设备或者IRF设备，但ICMP报文到达目的端前被分片了，请在目的端执行display icmp statistics命令来查看ICMP报文统计信息即可。

(3) 确定出问题的节点。

确定了Ping故障的发生的方向后，请执行tracert命令确定该方向上报文丢失的位置。

¡ 如果源端到目的端方向出现了问题，请从源端开始排查。

¡ 如果目的端到源端方向出现问题，请从目的端开始排查。

如下例所示，可以通过tracert命令查看报文从源端到目的端（IP地址为1.1.3.2，属于vpn1）所经过的路径，并显示报文经过的私网中的三层设备的信息。

<Sysname> tracert –vpn-instance vpn1 –resolve-as vpn 1.1.3.2

traceroute to 1.1.3.2 (1.1.3.2), 30 hops at most, 40 bytes each packet, press CTRL+C to break

1 1.1.1.2 (1.1.1.2) 673 ms 425 ms 30 ms

2 1.1.2.2 (1.1.2.2) 580 ms 470 ms 80 ms

3 * * *

由以上信息可判断，Ping报文在1.1.2.2的下一跳设备上（即显示为“3 * * *”的节点）出现转发故障。

(4) 检查是否存在到达目的端和源端的FIB表项与ARP表项。

请在问题节点上执行以下操作：

¡ 执行display fib命令检查是否存在到达目的端和源端的路由。如果路由不存在，请检查OSPF、IS-IS、BGP等路由协议配置是否有误。

¡ 如果路由存在并且报文所经链路是以太链路，请执行display arp命令查看是否存在所需的ARP表项。如果ARP表项不存在，请首先排查ARP故障。

(5) 检查问题节点上是否配置ICMP防攻击功能。

如果设备上配置了ICMP攻击相关的防范策略，且设备检测到ICMP攻击，设备会将ICMP报文直接丢弃，从而导致Ping不通。

¡ 通过display attack-defense icmp-flood statistics ip命令查看统计信息的计数来判断设备是否受到了ICMP攻击。

¡ 通过display current-configuration | include icmp-flood、display current-configuration | include “signature detect”查看当前是否配置攻击防范策略。

如果设备受到了ICMP攻击，请先定位并解除ICMP攻击。

(6) 根据收发包统计，确认丢包位置和丢包原因。

在Ping报文途径的设备上：

a. 配置QoS策略，使用ACL源地址和目的地址过滤Ping报文，然后在Ping报文途径接口的入方向和出方向应用QoS策略。

b. 通过display qos policy interface命令查看应用QoS策略的接口上QoS策略匹配成功的报文个数。如果报文个数有增长，则说明设备收到了Ping报文；如果报文个数无增长，则说明设备没有收到Ping报文，此时，可以使用debugging ip packet命令打开IP报文调试信息开关，进一步排查设备没有收到Ping报文的原因并解决问题。

(7) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息、告警信息。

5. 告警与日志

9.3.2 Tracert不通

1. 故障描述

执行Tracert操作，显示信息中出现“* * *”行，说明某些节点之间路由不可达，Tracert不通。

2. 常见原因

本类故障的常见原因主要包括：

· 无对应的路由或者ARP表项。

· 中间设备未开启ICMP超时报文发送功能。

· 目的端未开启ICMP目的不可达报文发送功能。

3. 故障分析

本类故障的诊断思路如下：

(1) 检查中间设备是否开启了ICMP超时报文发送功能。

(2) 检查目的端是否开启了ICMP目的不可达报文发送功能。

(3) 检查是否存在达到目的端的ARP以及FIB表项。

本类故障的诊断流程如图9-5所示。

图9-5 Tracert不通故障诊断流程图

4. 处理步骤

(1) 检查中间设备是否开启了ICMP超时报文发送功能。

# 查看报文从源端到目的端所经过的路径（假设源端到目的端只有两跳，目的端的IP地址为1.1.2.2）。

<Sysname> tracert 1.1.2.2

traceroute to 1.1.2.2 (1.1.2.2), 30 hops at most, 40 bytes each packet, press CTRL+C to break

1 * * *

2 1.1.2.2 (1.1.2.2) [AS 100] 580 ms 470 ms 80 ms

出现以上显示信息时，请登录中间设备，在中间设备上执行ip ttl-expires enable命令开启ICMP超时报文发送功能。如果故障排除，则说明中间设备未开启ICMP超时报文发送功能导致Tracert不通；如果故障未排除，请继续执行下面的步骤。

(2) 检查目的端是否开启了ICMP目的不可达报文发送功能。

# 查看报文从源端到目的端所经过的路径（假设源端到目的端只有两跳，目的端的IP地址为1.1.2.2）。

<Sysname> tracert 1.1.2.2

traceroute to 1.1.2.2 (1.1.2.2), 30 hops at most, 40 bytes each packet, press CTRL+C to break

1 1.1.1.2 (1.1.1.2) [AS 99] 560 ms 430 ms 50 ms

2 * * *

出现以上显示信息时，请在目的端执行ip unreachables enable命令开启ICMP目的不可达报文发送功能。如果故障排除，则说明目的端未开启ICMP目的不可达报文发送功能；如果故障未排除，请继续执行下面的步骤。

(3) 在问题节点上检查是否存在对应的FIB表项和ARP表项。

在未回应ICMP差错报文的设备（tracert命令执行结果中显示为“* * *”的设备）上执行display fib命令，检查是否存在到目的地址的路由。

¡ 如果路由不存在，请检查OSPF、IS-IS、BGP等路由协议配置是否有误。

¡ 如果路由存在并且报文所经链路是以太链路，请执行display arp命令查看Tracert的下一跳地址对应的ARP表项是否存在。如果不存在，请检查ARP配置是否有误。

(4) 检查Tracert发起端是否收到ICMP差错报文。

发起Tracert后，在Tracert发起端上多次执行display icmp statistics命令查看发起端是否收到ICMP差错报文，显示信息示例如下：

<Sysname> display icmp statistics

Input: bad formats 0 bad checksum 0

echo 0 destination unreachable 9

source quench 0 redirects 0

echo replies 7 parameter problem 0

timestamp 0 information requests 0

mask requests 0 mask replies 0

time exceeded 3 invalid type 0

router advert 0 router solicit 0

broadcast/multicast echo requests ignored 0

broadcast/multicast timestamp requests ignored 0

其它显示信息略……

观察以上ICMP报文的统计信息的变化，判断Input区段内的time exceeded和destination unreachable值的增量是否与Tracert报文发送个数相等，如果不等则表明发起端未收到ICMP差错报文。

(5) 根据收发包统计，确认丢包位置和丢包原因。

在Tracert报文途径的设备上：

a. 配置QoS策略，使用ACL源地址和目的地址过滤Tracert报文，然后在Tracert报文途径接口的入方向和出方向应用QoS策略。

b. 通过display qos policy interface命令查看应用QoS策略的接口上QoS策略匹配成功的报文个数。如果报文个数有增长，则说明设备收到了Tracert报文；如果报文个数无增长，则说明设备没有收到Tracert报文，此时，可以使用debugging ip packet命令打开IP报文调试信息开关，进一步排查设备没有收到Tracert报文的原因并解决问题。

(6) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息、告警信息。

5. 告警与日志

9.3.3 IPv6 Ping不通

1. 故障描述

在源端执行IPv6 Ping操作，在一定时间范围内没有收到目的端对该请求的回应。

2. 常见原因

存在三种故障情形：

· 源端没有发出请求报文。

· 目的端没有发出应答报文。

· 中间设备丢包或传输时间长。

本类故障的常见原因主要包括：

· 链路传输时延较长。由于传输时延长，虽然源端接收到了目的端的回应报文，但已经超过等待时限而造成IPv6 Ping不通的现象。

· 配置不当，执行Ping操作时，指定的参数值和网络能力不匹配。例如当IPv6 Ping报文过大时，中间设备的IPv6 Ping报文出接口MTU值较小，导致IPv6 Ping报文被丢弃。

· IPv6 FIB表或ND表中缺少对应的表项。

· 存在防攻击配置。

· 硬件故障。

3. 故障分析

本类故障的诊断思路如下：

(1) 检查IPv6 Ping操作是否得当，调整IPv6 Ping操作参数。

(2) 查看IPv6 Ping报文的统计信息，确认出问题的节点。

(3) 检查是否存在到达目的端的ND以及IPv6 FIB表项。

(4) 排查是否因为防攻击配置导致IPv6 Ping报文被丢弃。

本类故障的诊断流程如图9-6所示。

图9-6 IPv6 Ping不通故障诊断流程图

4. 处理步骤

(1) 检查IPv6 Ping操作是否得当。

a. 检查是否因为实际链路传输时延较长导致IPv6 Ping不通。

检查是否执行了ping ipv6 -t timeout命令，如果执行了此操作，可通过增加-t参数的值（建议取值大于等于1000，达到秒级）或者去掉-t参数重新Ping。如果故障消除，则说明较大概率属于实际网络时延大导致的IPv6 Ping不通；如果故障未消除，请继续定位。

-t参数用来指定ICMPv6回显应答（ECHO-REPLY）报文的超时时间，单位为毫秒，缺省值为2000。如果源端在timeout时间内未收到目的端的ICMPv6回显应答（ECHO-REPLY）报文，则会认为目的端不可达。

b. 检查是否因为IPv6 Ping报文过大而被丢弃。

检查是否执行了ping ipv6 –s packet-size命令，如果执行了此操作，且报文转发路径上存在出接口的MTU小于报文长度packet-size的情况，则会导致报文因为超大且不允许被分片而被丢弃。可以通过减小报文长度来解决这个问题。

-s packet-size参数用来指定发送的ICMPv6回显请求报文的长度（不包括IPv6和ICMPv6报文头），单位为字节，缺省值为56。

以太网接口MTU的缺省值为1500字节，可以通过执行display interface命令来查看接口的MTU值：

<Sysname> display interface gigabitethernet 2/0/1

GigabitEthernet2/0/1

Current state: UP

Line protocol state: UP

Description: GigabitEthernet2/0/1 Interface

Bandwidth: 1000000 kbps

Maximum transmission unit: 1500

…

c. 检查是否指定了错误的出接口。

检查是否执行了ping ipv6 -i interface-type interface-number命令指定IPv6 Ping报文的出接口。如果指定了出接口，请确保该接口和目的端之间的物理链路是否可达。否则，请换成其它接口或者去掉-i参数。

-i interface-type interface-number参数用来指定发送ICMPv6回显请求报文的接口的类型和编号。不指定该参数时，将根据目的IP查找路由表或者转发表来确定发送ICMPv6回显请求报文的接口。

d. 检查是否指定了源地址。

检查是否执行了ping ipv6 –a source-ip命令指定IPv6 Ping报文的源地址。如果执行了该命令，请确保中间设备和目的端有到达源地址source-ip的路由。

-a source-ip：指定ICMPv6回显请求（ECHO-REQUEST）报文的源IPv6地址。该地址必须是设备上已配置的IPv6地址。不指定该参数时，ICMPv6回显请求报文的源IPv6地址是该报文出接口的主IPv6地址。

e. 检查是否为目的端指定了准确的VPN。

根据网络规划和部署情况，确认目的端是否属于某个VPN。如果目的端属于某个VPN，则需要在执行ping ipv6命令时通过-vpn-instance参数指定目的端所属的VPN。

(2) 查看源端、目的端以及中间设备的收发包统计，确认IPv6 Ping故障发生的方向。

¡ 检查源端是否发出了ICMPv6回显请求报文，并收到了ICMPv6回显应答报文。

源端执行IPv6 Ping操作后，在源端和目的端分别使用display ipv6 icmp statistics命令查看ICMPv6报文收发情况。可以根据统计信息中Input和Output区段报文的数量来确定IPv6 Ping出现问题的方向：

- 如果源端Output区段的echo request值正常增加，但Input区段的echo reply值没有增加，则说明源端发出了请求但是没有收到回应；与此同时，如果目的端Input区段和Output区段的计数都没有变化，则说明目的端没有收到请求也没有给予回应。这样，就可以确定IPv6 Ping报文是在从源端到目的端的方向上出现了转发故障。

- 如果源端Output区段的echo request值正常增加，但Input区段的echo reply值没有增加，则说明源端发出了请求但是没有收到回应；与此同时，如果目的端Input区段和Output区段的计数都正常增加，则说明目的端收到了请求，同时发出了回应。这样，就可以确定IPv6 Ping报文是在从目的端到源端的方向上出现了转发故障。

display ipv6 icmp statistics命令显示信息示例如下：

<Sysname> display ipv6 icmp statistics

Input: bad code 0 too short 0

checksum error 0 bad length 0

path MTU changed 0 destination unreachable 0

too big 0 parameter problem 0

echo request 1 echo reply 0

neighbor solicit 0 neighbor advertisement 0

router solicit 0 router advertisement 0

redirect 0 router renumbering 0

output: parameter problem 0 echo request 0

echo reply 1 unreachable no route 0

unreachable admin 0 unreachable beyond scope 0

unreachable address 0 unreachable no port 0

too big 0 time exceed transit 0

time exceed reassembly 0 redirect 0

ratelimited 0 other errors 0

· 当目的端是框式设备或者IRF设备，且ICMPv6报文到达目的端未被分片时，请在目的端执行带slot参数的display ipv6 icmp statistics命令来查看ICMPv6报文统计信息，slot为目的端接收该ICMPv6报文的接口所在的Slot。

· 当目的端是框式设备或者IRF设备，但ICMPv6报文到达目的端前被分片了，请在目的端执行display ipv6 icmp statistics命令来查看ICMPv6报文统计信息即可。

(3) 确定出问题的节点。

确定了IPv6 Ping故障的发生的方向后，请执行tracert ipv6命令确定该方向上报文丢失的位置。

¡ 如果源端到目的端方向出现了问题，请从源端开始排查。

¡ 如果目的端到源端方向出现问题，请从目的端开始排查。

如下例所示，可以通过IPv6 Tracert功能查看报文从源端到目的端（IP地址为2::2）所经过的路径，并显示报文经过的三层设备的信息。

<Sysname> tracert ipv6 2::2

traceroute to 2::2 (2::2), 30 hops at most, 104 byte packets, press CTRL_C to break

1 1::2 1.000 ms 0.000 ms 1.000 ms

2 * * *

由以上信息可判断，IPv6 Ping报文在1::2的下一跳设备上（即显示为“2 * * *”的节点）出现转发故障。

使用IPv6 Tracert功能：

· 需要在中间设备（源端与目的端之间的设备）的系统视图下执行ipv6 hoplimit-expires enable命令开启设备的ICMPv6超时报文的发送功能。

· 需要在目的端设备系统视图下执行ipv6 unreachables enable命令开启设备的ICMPv6目的不可达报文的发送功能。

(4) 检查是否存在到达目的端和源端的IPv6 FIB表项与ND表项。

请在问题节点上执行以下操作：

¡ 执行display ipv6 fib命令检查是否存在到达目的端和源端的路由。如果路由不存在，请检查IGP和BGP等路由协议配置是否有误。

¡ 如果路由存在并且报文所经链路是以太链路，请执行display ipv6 neighbors命令查看是否存在所需的ND表项。如果ND表项不存在，请首先排查ND故障。

(5) 检查问题节点上是否配置ICMPv6防攻击功能。

如果设备上配置了ICMPv6攻击相关的防范策略，且设备检测到ICMPv6攻击，设备会将ICMPv6报文直接丢弃，从而导致IPv6 Ping不通。

¡ 通过display attack-defense icmpv6-flood statistics ipv6命令查看统计信息的计数来判断设备是否受到了ICMPv6攻击。

¡ 通过display current-configuration | include icmpv6-flood、display current-configuration | include “signature detect”查看当前是否配置攻击防范策略。

如果设备受到了ICMPv6攻击，请先定位并解除ICMPv6攻击。

(6) 根据收发包统计，确认丢包位置和丢包原因。

在IPv6 Ping报文途径的设备上：

a. 配置QoS策略，使用IPv6 ACL源地址和目的地址过滤IPv6 Ping报文，然后在IPv6 Ping报文途径接口的入方向和出方向应用QoS策略。

b. 通过display qos policy interface命令查看应用QoS策略的接口上QoS策略匹配成功的报文个数。如果报文个数有增长，则说明设备收到了IPv6 Ping报文；如果报文个数无增长，则说明设备没有收到IPv6 Ping报文，此时，可以使用debugging ipv6 packet命令打开IPv6报文调试信息开关，进一步排查设备没有收到IPv6 Ping报文的原因并解决问题。

(7) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息、告警信息。

5. 告警与日志

9.4 SNMP故障处理

9.4.1 SNMP连接失败

1. 故障描述

网管（NMS）通过SNMP协议无法成功连接设备。

2. 常见原因

本类故障的常见原因主要包括：

· 网络异常导致报文不可达。

· 配置错误导致认证失败。

· 设备受到SNMP报文攻击，进入SNMP静默模式。

3. 故障分析

本类故障的诊断流程如图9-7所示。

图9-7 SNMP无法连接的故障诊断流程图

4. 处理步骤

(1) 执行ping命令，检查设备和网管之间是否路由可达。

¡ 如果可以Ping通，说明设备和网管之间路由可达，请执行步骤（2）。

¡ 如果无法Ping通，请参见“Ping和Tracert故障处理”中的“Ping不通”先解决网络不通问题。待设备和网管之间可以Ping通后，重新建立SNMP连接。如果重新建立SNMP连接后，SNMP连接仍不能成功建立，请执行步骤（2）。

(2) 检查SNMP配置是否正确。

a. 执行display snmp-agent sys-info version命令，查看设备当前使用的SNMP版本号。设备和网管使用的SNMP版本号必须相同。如果不同，需使用snmp-agent sys-info version命令修改配置。

b. 如果当前使用的是SNMPv1或SNMPv2c版本，则执行display snmp-agent community命令查看设备上配置的团体信息（包括团体名和使用的ACL等信息）。设备和网管使用的团体名必须相同，且设备上配置的ACL必须允许网管访问设备。否则，需使用snmp-agent community和acl命令修改配置。

c. 如果当前使用的是SNMPv3版本，则执行display snmp-agent usm-user命令查看SNMPv3用户信息（包括用户名和使用的ACL等信息），并执行display snmp-agent group命令查看SNMP组信息（包括认证/加密模式和使用的ACL等信息）。设备和网管使用的用户名必须相同，认证/加密参数必须一致，且设备上配置的ACL必须允许网管访问设备。否则，需使用snmp-agent group、snmp-agent usm-user v3和acl命令修改配置。

(3) 检查设备是否进入SNMP静默状态。

如果1个统计周期内（时长为1分钟）设备收到的SNMP认证失败报文的个数大于等于100，则设备认为受到了SNMP攻击，SNMP模块会进入静默状态（设备会打印日志SNMP agent is now silent），设备将在4～5分钟内不再响应收到的任何SNMP报文。请等待SNMP静默状态解除后，重新建立SNMP连接。

(4) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息、告警信息。

5. 告警与日志

9.4.2 SNMP操作超时

1. 故障描述

网管（NMS）对设备执行SNMP Get和Set操作，网管侧提示操作超时，导致操作失败。

2. 常见原因

本类故障的常见原因主要包括：

· SNMP连接中断，导致网管无法访问设备。

· 网络丢包，导致设备没有收到SNMP请求。

· 设备存储介质上的存储空间不足，导致设备无法处理SNMP请求。

· 设备繁忙，正在处理其它业务，导致无法处理SNMP请求。

· SNMP（作为SNMP agent）进程忙，正在处理其它SNMP请求，导致无法对当前SNMP请求做出应答。

· SNMP进程处理当前SNMP请求时发生异常。

3. 故障分析

本类故障的诊断流程如图9-8所示。

图9-8 SNMP操作超时的故障诊断流程图

4. 处理步骤

(1) 定位并处理SNMP连接问题。

在网管上查看SNMP连接，如果显示连接超时或者失败，请参照“SNMP连接失败”故障处理章节先定位并处理SNMP连接问题。

(2) 检查网络是否存在丢包。

在网管设备上使用ping –c count host命令，例如将conut参数设置为100，host参数取值为设备的IP地址，查看ping命令执行结果中的packet loss字段取值，判断网络是否存在丢包。

¡ 如果无丢包，请参照步骤（3）继续定位；

¡ 如果有丢包，请参见“Ping和Tracert故障处理”中的“Ping不通”先解决网络不通问题。

-c count：指定ICMP回显请求报文的发送次数，取值范围为1～4294967295，缺省值为5。

(3) 定位并处理设备存储介质上的存储空间不足问题。

在任意视图下执行display memory-threshold命令，如果显示信息中的“Current free-memory state”字段取值中包含Normal字样，表示设备存储介质上的存储空间充足，否则，表示设备存储介质上的存储空间不足，请使用以下方法清理内存。

¡ 使用reset recycle-bin命令清除回收站中的文件。（回收站中的文件也会占用存储介质上的存储空间。）

¡ 使用delete /unreserved file命令一次性彻底删除文件。如果未使用/unreserved参数，删除的文件会保存在回收站中。

根据设备型号不同，设备支持的存储介质可能为Flash、CF卡等。

(4) 定位并处理设备繁忙问题。

a. 在任意视图下多次重复执行display cpu-usage命令，查看设备CPU利用率是否持续在较高水平。

b. 在任意视图下执行monitor process命令，检查是否存在占用较多CPU的进程。如果某个业务进程占用CPU较多，可以根据业务需要以及设备支持情况，通过重启服务来降低CPU利用率。

(5) 定位SNMP进程问题。

对于支持display system internal snmp-agent operation in-progress命令的设备，在系统视图下执行probe命令，进入Probe视图，然后多次重复执行display system internal snmp-agent operation in-progress命令查看设备正在处理的SNMP操作的相关信息。

¡ 如果显示信息中的Request ID取值一直在变化，则说明SNMP进程一直在处理不同的请求，当前SNMP进程业务较忙。请降低网管对设备的SNMP操作频率。

¡ 如果显示信息中的Request ID取值一直不变，则说明SNMP进程一直在处理同一请求，SNMP进程处理该请求时超时。可通过以下方法排除故障：

- 依次执行undo snmp-agent命令和snmp-agent命令重启SNMP进程，来尝试排除故障。

- 执行display system internal snmp-agent operation timed-out和display system internal snmp-agent packet timed-out命令确认耗时较多的SNMP操作以及该操作涉及的MIB节点，减少或不要执行类似操作。

display system internal snmp-agent operation in-progress命令的支持情况与设备的型号有关，请以设备的实际情况为准。

‌

对于不支持display system internal snmp-agent operation in-progress命令的设备，可通过以下方法排除故障：

¡ 执行debugging snmp agent命令打开SNMP调试信息开关，再次执行SNMP Get或Set操作来复现问题，然后根据调试信息进一步定位。

¡ 如果SNMP进程挂死，无法继续执行SNMP操作来复现问题，可在Probe视图下执行follow命令查看SNMP进程挂死的原因。然后依次执行undo snmp-agent命令和snmp-agent命令重启SNMP进程，来尝试排除故障。

(6) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息、告警信息。

5. 告警与日志

9.4.3 网管无法管理设备

1. 故障描述

网管对设备执行SNMP Set或Get等操作，设备无响应或者提示操作失败。

2. 常见原因

本类故障的常见原因主要包括：

· 网管通过SNMP协议无法成功连接设备。

· 网管使用的SNMP版本和MIB节点不匹配。

· 网管没有访问设备的权限。

· 设备上的SNMP进程忙，无法对当前SNMP请求做出应答。

3. 故障分析

本类故障的诊断流程如图9-9所示。

图9-9 网管无法管理设备的故障诊断流程图

4. 处理步骤

(1) 检查网管是否可以通过SNMP协议连接设备。

如果网管通过SNMP协议无法成功连接设备，请参照SNMP连接失败故障处理流程进行处理。

(2) 检查网管当前使用的SNMP协议版本是否支持访问该MIB节点。

例如snmpUsmMIB只支持通过SNMPv3协议访问；Integer32、Unsigned32和Counter64数据类型仅SNMPv2c和SNMPv3版本支持。如果网管使用SNMPv1版本和设备相连，网管将无法访问Integer32、Unsigned32和Counter64数据类型的MIB节点。MIB节点的数据类型可通过MIB文件中节点的SYNTAX字段查看。

hh3cDhcpServer2BadNum OBJECT-TYPE

SYNTAX Counter64

MAX-ACCESS read-only

STATUS current

DESCRIPTION

"The total number of the bad packets received."

::= { hh3cDhcpServer2StatGroup 1 }

如果因为版本原因导致网管无法访问MIB节点，请将网管切换到SNMPv2c或SNMPv3版本后，与设备重新建立连接，再执行Get和Set操作。

(3) 检查MIB节点是否支持当前的访问操作。

请根据MIB节点支持的操作类型来访问设备。MIB节点支持的操作类型可通过MIB文件中节点的MAX-ACCESS字段查看。

hh3cDhcpServer2BadNum OBJECT-TYPE

SYNTAX Counter64

MAX-ACCESS read-only

STATUS current

DESCRIPTION

"The total number of the bad packets received."

::= { hh3cDhcpServer2StatGroup 1 }

(4) 检查网管的访问权限。如果访问权限不够，请在设备上修改对应配置，给网管授权。

SNMP支持的访问控制方式包括：

¡ VACM（View-based Access Control Model，基于视图的访问控制模型）：将团体名/用户名与指定的MIB视图进行绑定，可以限制NMS能够访问哪些MIB对象，以及对MIB对象不同的操作权限。通过display current-configuration | include view命令可查看MIB视图相关配置，通过display snmp-agent mib-view命令可查看MIB视图的详细信息。如果配置错误，请修改MIB的相关配置。

¡ 设备支持三种MIB视图：

- Read-view：网管只能读取该视图中节点的值。

- Write-view：网管可读和写该视图中节点的值。

- Notify-view：当该视图中包含的Trap节点到达触发条件，网管会收到对应的Trap/Inform报文。

¡ RBAC（Role Based Access Control，基于角色的访问控制）：我司设备通过RBAC进行用户访问权限控制。RBAC的基本思想就是给用户指定角色，这些角色中定义了允许用户操作哪些系统功能以及资源对象。创建SNMPv3用户名时，可以绑定对应的用户角色，通过用户角色下制定的规则，来限制NMS能够访问哪些MIB对象，以及对MIB对象不同的操作权限。如果RBAC权限配置错误，可以通过role name命令进入用户角色视图修改用户角色的规则。

- 拥有network-admin或level-15用户角色的SNMP团体/用户，可以对所有的MIB对象进行读写操作；

- 拥有network-operator用户角色的SNMP团体/用户，可以对所有的MIB对象进行读操作；

- 拥有自定义用户角色的SNMP团体/用户，可以对角色规则中指定的MIB对象进行操作。

为了安全起见，只有具有network-admin或者level-15用户角色的用户登录设备后才能配置SNMP团体、用户或组。请确保登录用户具有network-admin或者level-15用户角色，以免配置失败。

(5) 检查SNMP进程是否繁忙。

网管对设备执行SNMP Set或Get等操作，设备无响应或者提示操作失败，还可能因为SNMP进程忙，无法对当前SNMP请求做出应答，请参照SNMP操作超时故障处理流程进行处理。

(6) 其它建议

建议网管通过业务接口访问设备，因为业务接口的报文处理能力优于网管口，以便SNMP报文能尽快得到处理。

当有多个NMS同时访问设备，且设备反应缓慢时，建议降低访问频率来减轻设备分担，例如将访问频率设置成大于等于5分钟。

(7) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息、告警信息。

5. 告警与日志

9.4.4 网管无法收到设备发送的Trap

1. 故障描述

网管无法收到设备发送的Trap报文。

2. 常见原因

本类故障的常见原因主要包括：

· 设备和网管之间路由不可达，或者SNMP功能异常，导致无法建立SNMP连接。

· 设备侧和网管侧配置错误，导致网管无法收到设备发送的告警。

· 设备侧业务模块没有产生告警。

· 告警报文丢失，导致网管未收到设备发送的告警。

· SNMP Trap报文过大，超过SNMP模块对Trap报文大小的限制。

3. 故障分析

本类故障的诊断流程如图9-10所示。

图9-10 网管无法收到设备发送的Trap的故障诊断流程图

4. 处理步骤

(1) 在系统视图下通过snmp-agent trap log命令开启SNMP告警日志功能。当设备向网管发送告警时，会同时在设备上生成一条日志来记录该Trap。

(2) 通过display logbuffer | include SNMP_NOTIFY命令可以查看设备上是否生成Trap以及生成的Trap详情。

¡ 如果有显示信息，说明设备有Trap生成。请执行步骤(3)。

¡ 如果没有显示信息，说明SNMP模块未向外发送Trap。请执行步骤(4)。

(3) 如果设备生成了Trap，但网管未收到Trap，请参照以下步骤定位。

a. 检查设备是否可以和网管建立SNMP连接。如果连接建立失败，请参见“SNMP连接失败”解决SNMP连接建立失败问题。

b. 通过display current-configuration | include snmp命令查看snmp-agent target-host trap命令配置是否正确。如果不正确，请修改配置，保证指定的IP地址（VPN参数）和端口号与网管用来接收Trap报文的IP地址（网管所属VPN）和端口号一致，以及设备和网管使用的SNMP协议、安全字一致。

- 如果使用SNMPv1或SNMPv2c版本，则安全字为团体名，请在设备上使用snmp-agent community命令创建SNMP团体。

- 如果使用SNMPv3版本，则安全字为用户名，且设备和网管使用的认证和加密级别必须相同。您需要在设备上使用snmp-agent group和snmp-agent usm-user v3命令创建SNMPv3用户，创建用户时配置的认证和加密模式、认证密码和加密密码（如果用到）必须和网管侧一致，且创建用户时配置的认证和加密级别必须比snmp-agent target-host trap命令中指定的认证和加密级别高。安全级别分为：不认证不加密、认证不加密和认证加密，安全级别依次升高。

- 团体名和用户名可访问的MIB view必须包含对应的MIB告警节点，否则，会因为权限问题导致备不会将Trap报文发送给网管。

c. 执行debugging udp packet命令打开UDP报文的调试信息开关，查看设备发送的Trap报文是否过大。如果业务模块封装的数据较多，可能会导致Trap报文大于设备能发送的SNMP报文的最大长度，这样的Trap报文会被丢弃。此时可结合网络的MTU值以及是否支持分片情况，通过snmp-agent packet max-size命令修改设备能发送的SNMP报文的最大长度。

*Dec 27 22:35:41:203 2021 Sysname SOCKET/7/UDP: -MDC=1;

UDP Output:

UDP Packet: vrf = 0, src = 192.168.56.121/30912, dst = 192.168.56.1/162

len = 79, checksum = 0xd98f

d. 检查网络中是否存在防火墙过滤Trap报文。

如果网络中设置了防火墙，可采用以下措施来解决问题：

- 如果防火墙对报文的源IP进行了过滤，可使用snmp-agent trap source命令修改Trap报文的源IP地址。

- 修改防火墙的规则，放行Trap报文。

e. 检查网络是否不稳定，存在丢包。

如果网络中存在丢包，可采用以下措施来解决问题：

- 检查网络，解决网络丢包问题。

- 配置使用Inform报文发送告警信息。Inform有确认机制，比Trap更可靠。Inform仅SNMPv2c和SNMPv3支持。

(4) SNMP模块未向外发送Trap，请参照以下步骤定位。

a. 通过display snmp-agent trap-list查看业务模块的告警功能是否开启。如未开启，可通过snmp-agent trap enable命令开启。

b. 检查是否达到告警条件。例如接口状态告警会在接口状态发生变化时产生，CPU和内存告警会在CPU、内存的利用率超过阈值时产生等。

- 如未达到告警条件，未产生Trap，属正常现象，无需处理。

- 如果达到告警条件，设备未向外发送Trap，请执行步骤(c)。

c. 使用display snmp-agent trap queue命令查看Trap缓冲区是否被占满。如果Message number大于Queue size，表示Trap缓冲区可能被占满，新生成的Trap报文可能被丢弃。此时，可在系统视图下使用snmp-agent trap queue-size和snmp-agent trap life命令来调整Trap缓冲区性能参数。

(5) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息、告警信息。

5. 告警与日志

9.5 gRPC故障处理

9.5.1 gRPC采样周期不准确

1. 故障描述

gRPC Dial-out模式向采集器上送的订阅报文中，某些数据源的采样周期与用户配置的采样周期不一致。

2. 常见原因

本类故障的常见原因主要包括：

· 部分采样路径无法达到配置的采样周期精度，以自身的最小采样周期进行采样。

· 设备CPU繁忙。

· 数据源对应的采样路径为ifmgr/interfaces、路由类或统计类路径，由于采样数据量庞大，设备在用户配置的采样周期内无法完成采样。

例如route/ipv4routes，当路由表项达到100k时，采样数据量大，设备无法在一个较小的采样周期完成采集工作。

3. 故障分析

本类故障的诊断流程如图9-11所示。

图9-11 gRPC采样周期不准确的故障诊断流程图

4. 处理步骤

(1) 通过display system internal telemetry命令查看采样路径是否使用最小采样周期。

例如，以下显示结果中，采样路径route/ipv4routes配置的采样周期（Sampling interval，100毫秒）小于生效的采样周期（Effective sampling interval，5秒），说明该采样路径实际使用最小采样周期（5秒）。为了使命令行配置与生效情况一致，建议扩大采样周期，使其不低于最小采样周期。

<Sysname> system-view

[Sysname] probe

[Sysname-probe] display system internal telemetry

Current-time: 2021-12-25T15:51:45.530

--------------------Subscription s----------------------

Subscription mode: non-gNMI

DSCP value: 0

Source address or interface: Not configured

Telemetry data model: 2-layer

Encoding: JSON

Protocol: GRPC

Sensor group: s

Sampling interval: 100 milliseconds

Sampling type Effective sampling interval Sensor path

Periodic 5 seconds route/ipv4routes

Destination group: d

...

[Sysname-probe] quit

(2) 确认设备是否处于CPU繁忙状态。

通过display cpu-usage命令查看CPU利用率。

[Sysname] display cpu-usage

Slot 0 CPU 0 CPU usage:

70% in last 5 seconds

62% in last 1 minute

60% in last 5 minutes

...

如果主设备/全局主用主控板的CPU利用率超过60%，将会影响Telemetry功能的采样效率，导致设备不能在配置的采样周期内完成数据采样。用户可以选择：

¡ 等待CPU利用率降到60%以下。

¡ 减少配置的采样路径数量，以降低CPU利用率。

(3) 确认是否存在大数据量上报的采样路径。

进入Telemetry视图，通过display this命令查看配置。

[Sysname] telemetry

[Sysname-telemetry] display this

telemetry

sensor-group s

sensor path route/ipv4routes

destination-group d

ipv4-address 192.168.79.155 port 50051

subscription s

sensor-group s sample-interval 5

destination-group d

当存在ifmgr/interfaces、路由类或统计类采样路径时，在网管侧查看设备上送给采集器的相邻的两个订阅报文之间的时间差是否为命令行配置的采样周期的整数倍。

· 统计类采样路径通常会包含statistics节点，例如ifmgr/statistics。

· 路由类采样路径通常会包含route节点，例如route/ipv4routes。

假设，设备上为采样路径route/ipv4routes配置的采样周期为5秒，上送给采集器的两个订阅报文之间的时间差为两个Timestamp（单位为毫秒）字段的差 = ( 1641482427751 – 1641482417751 ) / 1000 = 10秒，是5秒的整数倍。

Producer-Name: H3C

...

Sensor-Path: route/ipv4routes

Json-Data: {"Notification":{"Timestamp":"1641482417751",...

Producer-Name: H3C

...

Sensor-Path: route/ipv4routes

Json-Data: {"Notification":{"Timestamp":"1641482427751",...

这就说明，该采样路径的采集数据量过大，需要使用多个采样周期才能上送数据。为了使命令行配置与生效情况一致，建议扩大采样周期，使其不低于数据上报所需时间。

(4) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息、告警信息。

5. 告警与日志

10 附录

10.1 非root用户使用指导

如需使用非root用户管理和配置后台操作系统，可参考本章节进行设置。

10.1.1 创建非root用户并添加操作权限

(1) 创建用户组，用户组名称以usergroup为例。

[root@node1 ~]# groupadd -g 500 usergroup

(2) 创建一个用户并指定主目录，用户名以user1为例。

[root@node1 ~]# useradd -u 1000 -d /home/user1 -g usergroup -s /bin/bash user1

(3) 配置用户的sudo权限。

[root@node1 ~]# chmod 640 /etc/sudoers

[root@node1 ~]# echo "test ALL=(ALL) NOPASSWD:ALL" >> /etc/sudoers

[root@node1 ~]# chmod 440 /etc/sudoers

(4) 确认权限是否添加成功。

[root@node1 ~]# cat /etc/sudoers

(5) 设置初始密码，输入密码后回车，然后按Ctrl + d保存并退出。

[root@node1 ~]# chpasswd

user1:Pwd@22001010

(6) 使用user1登录操作系统控制台，执行以下命令，使用户可执行kubectl相关命令。

[user1@node1 ~]$ mkdir -p $HOME/.kube

[user1@node1 ~]$ sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config

[user1@node1 ~]$ sudo chown user1:usergroup $HOME/.kube/config

[user1@node1 ~]$ echo "export KUBECONFIG=/home/user1/.kube/config" >> ~/.bash_profile

(7) 退出控制台，重新登录可生效。

10.1.2 删除非root用户及权限

如需删除非root用户，可执行以下命令：

(1) 删除用户组和用户。

[root@node1 ~]# /sbin/userdel -rf user1

[root@node1 ~]# groupdel usergroup

(2) 编辑 sudoers 文件，找到用户的sudo配置并删除。

[root@node1 ~]# sudo visudo

user1 ALL=(ALL) NOPASSWD:ALL //删除本内容

(3) 保存并退出编辑器。

10.2 SDWAN常用维护功能

10.2.1 修改设备WAN口地址

1. 总部设备修改WAN口地址

分支设备需要主动和总部设备（站点角色包含RR）的WAN接口地址建立TLS连接，分支建立TLS连接的相关配置（指定总部RR站点的WAN口地址）为控制器自动下发。如果总部设备（站点角色包含RR）需要修改WAN口地址，必须在控制器上按照开局方式执行如下操作，控制器可以根据新的WAN口地址自动更新分支设备配置。

手动开局方式修改WAN口地址

添加WAN详情时开局配置部署方式选择手工时，修改WAN口地址步骤如下：

(1) 删除对应的WAN网络详情；

(2) 手动在设备上修改对应的WAN口地址；

(3) 进入控制器设备管理列表页面，单击操作列中的信息同步按钮，同步设备信息，如图10-1所示。

图10-1 设备信息同步

(4) 在接口管理页面，确认控制器上设备接口地址已经更新为新的地址，如图10-2所示

图10-2 接口管理

(5) 重新添加WAN详情。

接口地址修改后还要修改对应的路由配置，保证对应的网络连接和业务互通。

U盘/邮件开局修改WAN口地址

添加WAN详情时开局配置部署方式选择U盘/邮件方式，修改WAN口地址步骤如下：

(6) 删除对应的WAN网络详情；

(7) 手动在设备上修改对应的WAN口地址和路由配置。

(8) 重新添加WAN详情，开局方式选择U盘/邮件，设备接口地址使用新的地址，添加对应的路由配置。

WebSocket开局修改WAN口地址

添加WAN详情时开局配置部署方式选择WebSocket方式，修改WAN口地址步骤如下：

(9) 删除对应的WAN网络详情；

(10) 重新添加WAN详情，开局方式选择WebSocket，设备接口地址使用新的地址，添加对应的路由配置，控制器通过WebSocket自动下发接口地址和对应路由。

选择WebSocket部署方式则由控制组件下发接口IP，后续删除此WAN业务网络详情时，控制组件将删除接口IP，如果设备使用此接口通过WebSocket上线，删除接口地址将导致设备失联，可能会出现删除失败等问题，请谨慎选择。

2. 分支设备修改WAN口地址

分支站点（站点角色只有CPE）的WAN接口联网方式是PPPoE、DHCP或者4/5G拨号时，接口地址变换并不会影响业务功能，不需要手动干预。

如果分支的WAN接口联网方式是静态地址，修改分支的IP地址：

(1) 确认分支对应接口是否有业务配置，例如站点上网，需要删除上网配置重新添加。

(2) 手动修改设备接口IP。

(3) 进入控制器设备管理列表页面，单击操作列中的信息同步按钮，同步设备信息，如图10-3所示。

图10-3 设备信息同步

(4) 在接口管理页面，确认控制器上设备接口地址已经更新为新的地址，如图10-4所示

图10-4 接口管理

10.2.2 设备板卡操作

控制器会自动监控设备板卡状态，当设备板卡进行替换或拔出时，控制器会产生对应告警。用户需要手动在控制器上进行操作，确认当前板卡状态。板卡异常后控制器会认为设备硬件状态异常，不会自动保存配置（配置文件和设备硬件板卡/接口相关），并且新的业务功能也可能部署下发失败，需要根据故障原因进行相应处理。

1. 设备板卡替换

设备替换版本后，控制器会识别到SN有变换，会产生板卡替换告警。因为控制器无法确认替换动作是否正确，会认为设备硬件状态异常，不会自动保存配置（配置文件和设备硬件板卡/接口相关），并且新的业务功能也可能部署下发失败。因此需要尽快处理。

进入[监控>告警管理>活动告警]页面可以查询到对应的告警信息，告警不建议手动删除，需要通过确认板卡状态后自动恢复。

(1) 替换设备板卡告警如图10-5所示。

图10-5 板卡替换告警

(2) 替换设备子卡告警如图10-6所示。

图10-6 子卡替换告警

板卡替换操作

控制器识别到设备板卡替换后，需要手动进行确认，通知控制器此替换为正常操作，后续相关业务功能可以正常下发，设备配置可以正常保存。

手动确认方式：

进入[自动化>广域分支网络>物理网络>设备管理>板卡管理]页面，通过下拉菜单选择对应的设备。如果是替换了板卡，对应板卡的状态会变为“板卡替换”，单击后面的<确认>按钮，完成替换确认。如果替换了子卡，需要展开对应的母板，对应子卡的状态会变为“子卡替换”，单击后面的<确认>按钮，完成替换确认。如图10-7所示。

图10-7 确认板卡替换

确认完成后对应告警也会自动恢复。

2. 设备板卡异常/拔出

控制器监控到设备板卡异常后，会生成板卡异常告警。板卡异常后控制器会认为设备硬件状态异常，不会自动保存配置（配置文件和设备硬件板卡/接口相关），并且新的业务功能也可能部署下发失败，需要根据故障原因进行相应处理。

堆叠分裂也是设备板卡异常，即一个框上对应的所有板卡都异常。

进入[监控>告警管理>活动告警]页面可以查询到对应的告警信息，告警不建议手动删除，需要通过后续操作来恢复告警。板卡异常告警如图10-8所示。

图10-8 板卡异常告警

板卡异常可以分为三种场景：

(2) 设备板卡故障导致的异常；

(3) 板卡重启或者堆叠中一台设备重启导致的异常；

(4) 板卡不再使用，拔出后产生的异常；

下面基于三层异常场景分别说明一下处理方式。

设备板卡故障导致的异常

设备板卡损坏导致的板卡异常，需要尽快协调新的板卡进行替换。板卡替换前由于控制器认为设备状态异常，不会保存设备配置，新业务可能也无法部署下发。进入[自动化>物理网络>设备管理>板卡管理]页面，通过下拉菜单选择对应的设备，可以看到设备板卡如图10-9所示，板卡状态可能显示为损坏或者拔出。需要尽快协调板卡进行替换，板卡替换后，控制器的操作可以参考设备板卡替换。

千万不要单击“确认拔出”或“确认损坏”，单击后控制器会认为对应板卡已经不再使用，会自动删除对应板卡上的所有业务，导致配置丢失，需要尽快协调板卡进行更换。

图10-9 板卡故障

设备板卡重启导致的异常

设备板卡重启或者堆叠设备整框重启导致的板卡异常，这种异常不需要进行手动操作，板卡重启完成后可以自动恢复。板卡恢复前由于控制器认为设备状态异常，不会保存设备配置，新业务可能也无法部署下发，需要等到板卡恢复后再部署新业务。进入[自动化>物理网络>设备管理>板卡管理]页面，通过下拉菜单选择对应的设备，可以看到设备板卡如图10-10所示。

千万不要单击“确认拔出”，单击后控制器会认为对应板卡已经不再使用，会自动删除对应板卡上的所有业务，导致配置丢失，只需要等待板卡或设备重启完成即可。

图10-10 板卡拔出

设备板卡不需要再使用

设备板卡不需要再使用，正常拔出后，控制器也会监控到板卡异常，控制器认为设备状态异常，不会保存设备配置，新业务可能也无法部署下发。需要尽快手动进行确认，通知控制器此次拔出为正常操作，控制器会自动删除对应板卡相关的业务，后续相关业务功能可以正常下发，设备配置可以正常保存。

高危操作：一定要确认板卡已经不再使用再单击确认拔出，控制器会自动删除板卡对应的业务配置。建议先删除完板卡相关业务后再拔出板卡，然后在控制器上进行确认。

进入[自动化>物理网络>设备管理>板卡管理]页面，通过下拉菜单选择对应的设备，可以看到设备板卡如图10-11所示，单击<确认拔出>，对板卡拔出的操作进行确认。

图10-11 板卡拔出

10.2.3 站点扩容双网关

当前只有非RR角色的站点才能单机扩容成双网关。

(1) 在控制器中添加新的设备，设备不要加入任何站点；

(2) 登录控制器进入[自动化>广域分支网络>物理网络>站点管理]页面，选择需要扩容的站点，单击站点后面的编辑按钮，切换为“双网关”，选择新的设备接入站点，配置站点间互联接口和互联地址，如图10-12所示，单击确定完成双网关扩容。

图10-12 扩容双网关

10.3 业务流量统计配置

业务访问异常时，需要对业务流量进行流统，确认丢包的位置。由于业务流量在WAN链路转发时会进行隧道封装，因此物理接口下无法识别到原始报文。我们需要将报文Remark为特定的DSCP，通过统计携带此DSCP的报文来进行流通。

下面介绍通过两边终端互Ping来模拟业务流量的情况下如果进行流通，组网如下图所示。

组网和预制条件说明：

· PC1地址：172.16.1.1；PC2地址17.1.1.14。

· 特定的DSCP：40（cs5）。

· 要和用户确认哪个DSCP没有使用或者通过display current-configuration | in dscp命令查询设备上是否有remark过对应的DSCP，如果有使用需要更换一个没有使用的DSCP。

下面说明PC1 ping PC2单向报文流量的配置方法，如果需要双向流通参考此配置方案反向配置即可。

10.3.1 Hub设备LAN口入方向流通配置

Hub设备LAN口是流量入口，需要对业务流量进行着色并且在入方向统计报文数量。配置如下：

(1) 创建ACL匹配对应流量：流量匹配ping报文，需要加对应的业务VPN。

acl advanced 3456

rule 0 permit icmp vpn-instance VPN1 source 172.16.1.1 0 destination 17.1.1.14 0

(2) 创建TC匹配对应的ACL。

traffic classifier lt operator and

if-match acl 3456

创建TB，Remark DSCP为40 (CS5)

traffic behavior lt

remark dscp cs5

(3) 创建QoS Policy，关联TC和TB，并将对应策略应用在HUB设备的LAN口的入方向。如果LAN口入方向已经有对应的QoS Policy，也可以修改QoS Policy，将对应的TC，TB对插入到最前面。

qos policy app

classifier lt behavior lt //LAN口已经有QoS Policy，将流通的TC/TB对插到最前面

classifier app1 behavior app1

interface GigabitEthernet2/0.2

qos apply policy app inbound //接口入方向应用对应的QoS Policy

10.3.2 Hub设备隧道口出方向流通配置

隧道口还是可以识别原始报文，可以继续使用同样的TC，TB对进行流通。

由于流量已经被Remark DSCP，也可以直接匹配DSCP进行流通，下面介绍使用DSCP进行流通。隧道口下没有QoS Policy，可以单独创建一个QoS Policy，并应用在隧道出方向：

(1) 创建TC匹配对应的DSCP 40。

traffic classifier lt1 operator and

if-match dscp cs5

(2) 创建空的TB即可。

traffic behavior lt1

(3) 创建QoS Policy，关联TC和TB，并将对应策略应用在HUB设备的隧道出方向。如果已经有对应的QoS Policy，也可以修改QoS Policy，将对应的TC，TB对插入到最前面。

qos policy lt1

classifier lt behavior lt1

interface Tunnel3 mode sdwan udp

qos apply policy lt1 outbound //隧道出方向应用

10.3.3 Hub设备WAN口出方向流通配置

流量已经被Remark DSCP，可以直接匹配DSCP进行流通，复用上面的QoS Policy，如果隧道口入方向已经有对应的QoS Policy，也可以修改QoS Policy，将对应的TC，TB对插入到最前面。

interface GigabitEthernet5/0

qos apply policy lt1 outbound

10.3.4 CPE设备WAN口入方向流通配置

设备WAN口转发的报文经过隧道封装因此无法识别到原始报文，可以通过匹配DSCP进行流通：

(1) 创建TC匹配对应的DSCP 40。

traffic classifier lt1 operator and

if-match dscp cs5

(2) 创建空的TB即可。

traffic behavior lt1

(3) 创建QoS Policy，关联TC和TB，并将对应策略应用在设备的WAN口的入方向。如果WAN口入方向已经有对应的QoS Policy，也可以修改QoS Policy，将对应的TC，TB对插入到最前面。

qos policy lt1

classifier lt1 behavior lt1

interface GigabitEthernet3/0

qos apply policy lt1 inbound

10.3.5 CPE设备隧道口入方向流通配置

interface Tunnel1 mode sdwan udp

qos apply policy lt1 inbound //应用流通QoS策略

10.3.6 CPE设备LAN口出方向流通配置

流量已经被Remark DSCP，可以直接匹配DSCP进行流通，复用上面的QoS Policy，如果LAN口出入方向已经有对应的QoS Policy，也可以修改QoS Policy，将对应的TC，TB对插入到最前面。

interface GigabitEthernet2/0

qos apply policy lt1 outbound

10.3.7 测试流通效果

使用PC1 ping PC2 10个报文，测试流通效果。

<LAN1>ping -c 10 -a 172.16.1.1 17.1.1.14

Ping 17.1.1.14 (17.1.1.14) from 172.16.1.1: 56 data bytes, press CTRL_C to break

56 bytes from 17.1.1.14: icmp_seq=0 ttl=254 time=0.395 ms

56 bytes from 17.1.1.14: icmp_seq=1 ttl=254 time=1.550 ms

56 bytes from 17.1.1.14: icmp_seq=2 ttl=254 time=0.340 ms

56 bytes from 17.1.1.14: icmp_seq=3 ttl=254 time=0.346 ms

56 bytes from 17.1.1.14: icmp_seq=4 ttl=254 time=3.830 ms

56 bytes from 17.1.1.14: icmp_seq=5 ttl=254 time=0.234 ms

56 bytes from 17.1.1.14: icmp_seq=6 ttl=254 time=0.375 ms

56 bytes from 17.1.1.14: icmp_seq=7 ttl=254 time=0.338 ms

56 bytes from 17.1.1.14: icmp_seq=8 ttl=254 time=0.231 ms

56 bytes from 17.1.1.14: icmp_seq=9 ttl=254 time=3.018 ms

--- Ping statistics for 17.1.1.14 ---

10 packet(s) transmitted, 10 packet(s) received, 0.0% packet loss

round-trip min/avg/max/std-dev = 0.231/1.066/3.830/1.248 ms

<LAN1>

1. Hub设备LAN口入方向查询结果

通过display qos policy interface XXXX命令查询流量结果：

<Hub1-1> display qos policy interface GigabitEthernet 2/0.2

Interface: GigabitEthernet2/0.2

Direction: Inbound //入方向

Policy: app

Classifier: default-class

Matched : 3236 (Packets) 381768 (Bytes)

5-minute statistics:

Forwarded: 2/2005 (pps/bps)

Dropped : 0/0 (pps/bps)

Operator: AND

Rule(s) :

If-match any

Behavior: be

-none-

Classifier: lt

Matched : 10 (Packets) 1020 (Bytes) //classifier是lt，确认收到10个报

5-minute statistics:

Forwarded: 0/27 (pps/bps)

Dropped : 0/0 (pps/bps)

Operator: AND

Rule(s) :

If-match acl 3456

Behavior: lt

Marking:

Remark dscp cs5

2. Hub设备隧道口出方向查询结果

通过display qos policy interface XXXX命令查询流量结果：

<Hub1-1> display qos policy interface Tunnel 3

Interface: Tunnel3

Direction: Outbound //出方向

Policy: lt1

Classifier: default-class

Matched : 1578 (Packets) 153449 (Bytes)

5-minute statistics:

Forwarded: 1/1215 (pps/bps)

Dropped : 0/0 (pps/bps)

Operator: AND

Rule(s) :

If-match any

Behavior: be

-none-

Classifier: lt1

Matched : 10 (Packets) 1240 (Bytes) //发出去了10个报文

5-minute statistics:

Forwarded: 0/32 (pps/bps)

Dropped : 0/0 (pps/bps)

Operator: AND

Rule(s) :

If-match dscp cs5

Behavior: lt1

-none-

3. Hub设备WAN出方向查询结果

通过display qos policy interface XXXX命令查询流量结果：

<Hub1-1>display qos policy interface GigabitEthernet 5/0

Interface: GigabitEthernet5/0

Direction: Outbound //出方向

Policy: lt1

Classifier: default-class

Matched : 12308 (Packets) 1275739 (Bytes)

5-minute statistics:

Forwarded: 16/13338 (pps/bps)

Dropped : 0/0 (pps/bps)

Operator: AND

Rule(s) :

If-match any

Behavior: be

-none-

Classifier: lt1

Matched : 10 (Packets) 1380 (Bytes) //发出去了10个报文

5-minute statistics:

Forwarded: 0/36 (pps/bps)

Dropped : 0/0 (pps/bps)

Operator: AND

Rule(s) :

If-match dscp cs5

Behavior: lt1

-none-

4. CPE设备WAN口入方向查询结果

通过display qos policy interface XXXX命令查询流量结果：

[Spoke1-1]display qos policy interface GigabitEthernet 3/0

Interface: GigabitEthernet3/0

Direction: Inbound //入方向

Policy: lt1

Classifier: default-class

Matched : 10363 (Packets) 1069016 (Bytes)

5-minute statistics:

Forwarded: 15/12868 (pps/bps)

Dropped : 0/0 (pps/bps)

Operator: AND

Rule(s) :

If-match any

Behavior: be

-none-

Classifier: lt1

Matched : 10 (Packets) 1380 (Bytes) //收到10个报文

5-minute statistics:

Forwarded: 0/36 (pps/bps)

Dropped : 0/0 (pps/bps)

Operator: AND

Rule(s) :

If-match dscp cs5

Behavior: lt1

-none-

5. CPE设备隧道口入方向查询结果

通过display qos policy interface XXXX命令查询流量结果：

[Spoke1-1]display qos policy interface Tunnel 1

Interface: Tunnel1

Direction: Inbound //入方向

Policy: lt1

Classifier: default-class

Matched : 870 (Packets) 62736 (Bytes)

5-minute statistics:

Forwarded: 1/886 (pps/bps)

Dropped : 0/0 (pps/bps)

Operator: AND

Rule(s) :

If-match any

Behavior: be

-none-

Classifier: lt1

Matched : 10 (Packets) 966 (Bytes) //收到10个报文

5-minute statistics:

Forwarded: 0/0 (pps/bps)

Dropped : 0/0 (pps/bps)

Operator: AND

Rule(s) :

If-match dscp cs5

Behavior: lt1

-none-

6. CPE设备LAN口出方向查询结果

通过display qos policy interface XXXX命令查询流量结果：

[Spoke1-1]display qos policy interface GigabitEthernet 2/0

Interface: GigabitEthernet2/0

Direction: Outbound //出方向

Policy: lt1

Classifier: default-class

Matched : 1054 (Packets) 81158 (Bytes)

5-minute statistics:

Forwarded: 2/1232 (pps/bps)

Dropped : 0/0 (pps/bps)

Operator: AND

Rule(s) :

If-match any

Behavior: be

-none- Classifier: lt1

Matched : 10 (Packets) 966 (Bytes) //发出10个报文

5-minute statistics:

Forwarded: 0/0 (pps/bps)

Dropped : 0/0 (pps/bps)

Operator: AND

Rule(s) :

If-match dscp cs5

Behavior: lt1

-none-

热门推荐

热门推荐

H3C服务器

HPE服务器

热门推荐

H3C存储

HPE存储

热门推荐

商用台式机

商用笔记本

商用显示器

配件

热门推荐

热门推荐

智能终端

技术解决方案

热门推荐

热门推荐

热门推荐

热门推荐

热门推荐

热门推荐

热门推荐

专业安全服务

安全运营服务

热门推荐

热门推荐

热门推荐

热门推荐

热门推荐

技术支持

自助服务

热门推荐

热门推荐

热门推荐

热门推荐

合作伙伴培训与认证

热门推荐

热门推荐

公司刊物

加入我们

国家/地区

H3C AD-WAN分支方案故障处理手册-6W101

目录

1.3 典型组网架构

1.3.1 总部+分支（Hub-Spoke组网）

1.3.2 分支入云（Hub-Spoke组网）

1.3.3 总部+分支（多总部组网）

1.3.4 总部+分支（Full-mesh组网）

1.3.5 总部+汇聚+分支（三级分层组网）

1.3.6 多租户POP组网（MSP运营组网）

2.2 故障定位分层分域原则与排查顺序建议

1. 分层排查

2. 分域排查

1. 单台设备/单分支上线或业务异常（如新分支上线失败、单站点业务不通等）

2. 多分支批量上线/全网策略统一下发失败或大面积业务同步异常

3. 发现设备与控制器通信中断、注册失败、策略下发失败、业务编排失败等特有告警

4. 复杂或无法归因的问题

3 AD-WAN控制器故障处理

3.1.1 SDWAN控制组件运行日志

3.1.2 WVAS组件运行日志

3.1.3 SDWAN控制组件操作日志

3.1.4 底盘WebSocket服务日志

3.1.5 收集Matrix诊断信息

1. 故障描述

2. 故障处理步骤

1. 故障描述

2. 故障处理步骤

3.3.4 Pod运行状态CrashLoopBackOff

3.3.5 Flink流任务OOM问题

3.3.6 系统断电或重启后Seamq实例状态异常

4 自动化开局与设备上线类故障处理

2. U盘/邮件开局