OSPF排错报告
故障点一：PPP链路故障
故障现象：
R2和R4之间的PPP链路一会down一会UP
故障分析：
1) ppp 认证类型是否一致
2) ppp chap认证用户是否配置正确
3) pppp chap认证密码是否配置正确
4) 进行chap认证的用户是否包含ppp的服务类型
故障解决：
1) 在RT2 上使用“display current-configuration int s0/1/0”查看接口下的认证配置，发现本端的认证类型为chap，且配置了认证用户和密码，在RT4上同样执行上述命令查看接口下的认证配置，发现配置的认证用户名和密码均为rt2。
2) 在RT4上使用“display current-configuration conf luser”查看RT2上配置的认证用户rt4密码是否正确，是否包含服务类型ppp。
3) 在RT2上使用“display current-configuration conf luser”发现RT4上配置的chap认证用户不存在，在系统视图下输入“local-user rt2”，创建本地用户rt2，在该模式下输入“password simple rt2 “设置rt2的密码为rt2，使用” service-type ppp “命令设置服务类型为ppp。
4) 在RT2上进入s0/1/0接口，执行shudown和 undo shutdown命令，关闭接口并激活接口，使接口ppp认证重新进行协商。
5) 在RT2、RT4上使用“display ip interface brief “命令查看ppp链路的接口状态，发现物理和协议双up，此故障排除。
故障点二：MSTP故障
故障现象：
在SW1、SW2、SW3上使用“display stp brief “命令查看mstp 实例的接口的角色状态，发现阻塞接口不符合题目要求，且SW2和SW3出现master角色的接口。
故障分析：
1) 是否创建mstp实例对应的vlan
2) 设备互联接口是否封装类型为trunk
3) 设备互联接口是否放行了业务vlan
4) 设备的mstp域配信息的域名是否一致
5) 设备的mstp域配信息的vlan和实例的映射关系是否一致
6) 是否手工指定实例的主备根
故障解决：
1) 在SW1、SW2、SW3上使用“display stp brief “查看VLAN信息，发现三台设备都有题目要求的业务VLAN10和VLAN20
2) 在SW1、SW2、SW3上使用“display port trunk “查看三台设备的trunk接口和接口放行的vlan,发现所有的设备互联接口封装均为trunk且都放行了题目要求的业务VLAN。
3) 在SW1、SW2、SW3上使用“display stp region-configuration “发现三台设备都没有手动配置域名，在SW1、SW2、SW3的系统视图下使用” stp region-configuration “进入mstp域配视图，使用” region-name h3c “，设置相同的域名，并执行” active region-configuration “重新激活域配信息。
4) 在SW1、SW2、SW3上使用“display stp brief “查看实例对应的接口角色，发现SW3对应的实例1阻塞了e0/4/1接口，而实例2阻塞了e0/4/0接口，而题目要求实例一阻塞e0/4/0 接口，而实例二阻塞e0/4/1接口，不符合题目要求。
5) 在SW1和SW2的系统视图下使用“display current-configuration configuration | include root “查看实例的主备根设置，发现实例1的主根为SW2，备根为SW1。实例2的主根为SW1，备根为SW2，不符合题目要求，在SW1的系统视图下输入：
stp instance 1 root primary
stp instance 2 root secondary
使SW1为实例1的主根，实例2的备根
在SW2的系统视图下输入：
stp instance 2 root primary
stp instance 1 root secondary
使SW2为实例2的主根，实例1 的备根
6)在SW3上使用“display stp brief”查看接口的角色信息，发现实例一阻塞e0/4/0，实例二阻塞e0/4/1。此故障排除。
故障点三：VRRP故障
故障现象：
在SW1上使用“display vrrp”发现vlan 10为backup角色，在SW2上使用“display vrrp”查看，发现vlan 10为master角色，而vlan 20为int状态。
故障分析：
1) 是否配置了合理的优先级
2) 虚拟IP地址是否正确
故障解决：
1) 在SW1上使用“display current-configuration int Vlan-interface 10”查看vlan10 的vrrp的配置信息，发现没有配置优先级，在SW2上执行同样的命令查看VLAN 10的vrrp配置信息，发现vlan 10在sw2的vlan接口的IP地址为192.168.0.253 24 ，由于sw1上vlan 10没有配置优先级，因此两端默认的优先级为100，则master和backup角色的确定依赖于接口IP地址数值的大小，因为SW2的VLAN10的接口IP地址大，故为IP地址拥有者。
在SW1上使用“int Vlan-interface 10”进入vlan 10的接口视图，使用“vrrp vrid 1 priority 110”修改优先级为110，在sw1上使用“display vrrp”查看vrrp信息，发现vlan 10的角色已经变为master。
2)在SW1上使用“display current-configuration int Vlan-interface 20”查看vlan 20的 vrrp配置，没有发现问题，在SW2上使用该命令查看vlan 20的vrrp配置，发现vlan 20的虚拟机地址错误，和接口的地址不在同一网段，在SW2上使用“int Vlan-interface 20”进入vlan 20的接口，使用“undo vrrp vrid 2 virtual-ip 10.1.1.254”删除vlan 20的虚拟地址，使用“vrrp vrid 2 virtual-ip 10.1.0.254”修改vlan 20的地址为题目要求的10.1.0.254。在SW2上使用“display vrrp”查看vrrp信息，发现SW2的vlan 20已经成为master角色，此故障排除。
故障点四：OSPF故障
故障现象：在SW1上使用“display ospf peer”查看OSPF邻居时，发现没有SW2
故障分析：
1) 是否使用OSPF验证
2) 使用将直连接口宣告
3) 是否将接口地址宣告进正确的区域
4) 直连接口的MTU值是否一致，且使能ospf的mtu检测
5) 接口是否使用了acl过滤了ospf协议报文
6) 接口是否被设置为静默接口
7) Ospf的router id是否冲突
故障解决：
1) 在SW1、SW2的系统视图下上使用“display current-configuration conf ospf”查看OSPF配置，发现没有使用开启OSPF验证。
2) 在SW1、SW2的协议视图下使用“display ospf interface”查看宣告的OSPF接口，发现SW1和SW2的直连接口vlan 30 接口正确宣告。
3) 在SW1、SW2上使用“display int Vlan-interface 30”查看vlan 30接口配置，发现并没有使能接口的mtu 检测，且接口的mtu为默认值。
4) 在SW1、SW2上使用“display current-configuration interface Vlan-interface 30”查看接口是否调用包过滤防火墙，发现没有，其接口也没有手工设置为静默接口。
5) 在SW1和SW2上使用“display ospf brief”查看ospf router id，发现SW1和SW2的ospf的router id都为192.168.1.12，题目要求使用loopback的接口地址作为设备的ospf router id，router id 冲突，不符合题意。
在SW2的系统视图下使用“ospf 1 router-id 192.168.255.12”为SW2设置ospf的router-id，设置成功后，在SW2的用户视图下使用“reset ospf process”重启OSPF协议进程，发现SW1和SW2通过VLAN30的接口建立OSPF邻居关系，此故障排除。
故障点五：GRE over IPsec 故障
故障现象：
在RT1上不断提示隧道接口一会up一会down
故障分析：
隧道的源地址被宣告进了RIP协议进程
故障解决：
由于RT1、RT3、RT4通过GRE隧道运行RIP协议，IPsec VPN触发建立隧道后，GRE的隧道源和目的可达，通过RIP协议学习路由，由于RIP协议错误的将隧道的源地址宣告进了协议进程，当路由器通过RIP协议学习到隧道的源地址时，载荷变负载，此时隧道主动down，当隧道down之后，由于本地配置了默认路由，隧道接口的源为本地的loopback地址，目标为对端的loopback接口地址，匹配默认路由，隧道口up，隧道口up后由于RIP协议宣告了隧道口地址，RIP协议报文触发ipsec vpn的建立，当ipsec vpn 隧道建立后，隧道的源和目标可达，通过RIP学习路由，当学习到对端的隧道源地址时，GRE隧道的载荷变负载，如此反复，故RT1和RT3不断提示隧道口一会up，一会down 。
在RT1上使用“display current-configuration conf rip”查看RIP配置，在RT1上的系统视图下输入“rip 1”进入RIP协议视图，使用“undo network 192.168.255.0”，删除错误宣告的隧道源地址。
在RT3、RT4上执行同样的操作，发现RT1 GRE隧道正常。
在RT1上使用“display ike sa”查看ipsec vpn的两个阶段是否正常建立，发现仅存在和RT5的关系，没有和RT3的关系。
在RT1上使用ping 命令，测试RT3的公网接口64.67.1.1是否可达，发现RT1 公网接口和RT3的公网接口不可达。
在RT3上使用“display ip interface brief”查看隧道口的状态，发现gre隧道物理和协议均为down状态，在RT3上使用“display ip routing-table”命令查看路由表，发现没有缺省路由，在RT3的系统视图下：
[RT3]ip route-static 0.0.0.0 0 64.67.1.2
配置默认路由后发现隧道口up。此时从RT3ping 测试RT1的公网地址61.67.1.1，网络可达。
在RT3上使用“display ike sa”发现ipsec vpn两个阶段都已成功建立，此故障排除。
故障点六：NAT故障
故障现象：
在SW1上使用源为vlan 10的网关地址192.168.0.254 ，目标为61.67.1.2 ，发现不通。在RT3 ping 100.0.0.100发现不通。
故障分析：
1) 是否做了NAT
2) NAT调用的acl是否匹配
3) 本地是否有默认路由
故障解决：
1) 在RT1上使用“display nat bound”，发现在g0/0/1上做了easy ip。
2) 使用“display acl 2000”查看是否匹配A流，发现匹配。
3) 在SW1上使用“display ip routing-table”发现没有缺省。
4) 在RT1的OSPF协议视图下为SW1下发缺省路由
[RT1-ospf-1]default-route-advertise
在SW1上进行测试，发现可以ping通61.67.1.2
<SW1>ping -a 192.168.0.254 61.67.1.2
在RT1上使用[RT1]display nat session，发现已经有了NAT转换条目。
5) 在RT1上使用“display nat static”查看静态NAT配置，发现为空，题目要求将本地B流动10.1.0.100 和公网64.67.1.100 做静态NAT，在RT1上创建静态NAT映射
[RT1]nat static 10.1.0.100 64.67.1.100，然后在公网接口执行[RT1-GigabitEthernet0/0/1]nat outbound static。
此故障排除。
故障点七：路由过滤故障
故障现象：
在RT3上使用“display ip routing-table | include RIP”查看IP路由表中的RIP路由条目发现存在:
192.168.111.1/32
192.168.120.1/32
故障分析：
题目要求二级分部的B流之间不可以互访，且要求在RT1上进行过滤，在RT1上使用“display current-configuration conf rip”查看RIP配置，发现使用了filter-policy，调用的ip ip-prefix 为filter，使用“display ip ip-prefix filter”查看该前缀列表：
[RT1]display ip ip-prefix filter
发现前缀列表中匹配B流的后缀为19，仅匹配192.168.96.0 19 ，而RT3上的B流都是使用loopback口的地址进行模拟的，故无法匹配/32的B流。
故障解决：
在RT1的系统视图下删除index 为10的名为filter 的前缀列表
undo ip ip-prefix filter index 10
然后重新写一条index 为10的前缀列表替换掉原来的 /19的前缀列表。
[RT1]ip ip-prefix filter index 10 deny 192.168.96.0 19 less-equal 32
等待RiP路由收敛后，在RT5使用“display ip routing-table | include RIP”查看RT5上的IP路由表中的RIP路由条目，发现RT3的B流已经消失，此故障排除。
故障点八：QOS故障
故障现象：
在RT2上使用“<RT2>display qos policy interface”发现QOS策略没有应用在接口上
故障分析：
在RT2上使用<RT2>display qos policy user-defined查看用户定义的qos 策略，发现定义了一个AF带宽为1.5 M，使用“[RT2]display int s0/1/0”查看接口的带宽，发现v.35线缆使用了默认的64kbps，且本端为DCE端。
故障解决：
在RT2上进入s0/1/0接口，修改带宽
[RT2-Serial0/1/0]qos max-bandwidth 2048
然后将定义的qos 策略应用到该接口的出方向
[RT2-Serial0/1/0]qos apply policy h3c outbound
在RT4执行同样的操作，此故障排除。
来源：https://www.cnblogs.com/networking/p/3841170.html