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执行同样的操作,此故障排除。