TAC-4----思维导图

这是一篇关于TAC-4----思维导图，包括了故障磁力、故障分析和故障原因这几个部分，感兴趣的小伙伴可以收藏起来。

TAC-4

• 问题
  • AR32的loopback0无法访问isis区域内的任何设备
• 故障根因
  • AR28的G0/0/2接口使用了filter-lsa-out命令添加了针对5类lsa执行路由过滤策略
• 故障分析
  • 2.1 故障重现
    • 在AR32上以loopback0为源地址，使用ping命令测试是否能够访问isis区域内AR30、AR31、AR34的loopback0地址，输出结果如下：
    • 由以上输出结果可知，确实存在此故障。AR32的loopback0与isis区域内的AR30、AR31、AR34的loopback0地址无法互访。首先要做的就是查看AR32的路由表信息，确认是否存在相关路由条目。
  • 2.2 查看AR32的路由表信息
    • 在AR32上使用命令display iprouting-table查看路由表信息，输出结果如下：
    • 由以上输出结果可知，AR32的路由表信息中不存在isis区域内的任何路由条目。由于当前运行ospf协议，所以进一步查看AR32的ospf邻居关系建立情况，确认是否与AR28正常建立ospf邻居关系。
  • 2.3 查看AR32的ospf邻居关系
    • 在AR32上使用命令display ospf peer brief 查看ospf邻居建立情况，输出结果如下：
    • 由以上输出结果可知，AR32在区域1下与AR28正常建立ospf邻居关系，因此可以排除AR32--AR28之间数据链路层和物理层故障。由于ospf计算路由的前提是存在相应的lsa，所以进一步查看AR32的ospf lsdb，确认是否存在相应的5类lsa。
  • 2.4 查看AR32的ospf lsdb
    • 在AR32上使用命令display ospf lsdb查看ospf lsdb相关信息，输出结果如下：
    • 由以上输出结果可知，AR32的ospf lsdb中不存在isis区域引入进来的相应的5类lsa。由于AR28没有登录权限，而5类lsa整个区域内泛洪，所以可以在AR27上查看ospf lsdb，确认是否存在引入isis区域的路由形成的5类lsa。
  • 2.5 查看AR27的ospf lsdb和路由表信息
    • 在AR27上使用命令display ospf lsdb和display ip routing-table | include ASE查看ospf lsdb相关信息和路由表信息，输出结果如下：
    • 由以上输出信息可知，AR27的ospf lsdb中存在引入isis区域内相应的5类lsa，并且路由表信息中存在全部源自于isis区域内的ospf外部路由（O_ASE）。因此可以判断AR28（ASBR）的ospf成功引入了isis区域的路由。接下来需要进一步查看AR31与AR34的路由表信息，确认是否存在ospf区域的路由条目。
  • 2.6 查看AR31和AR34的路由表信息
    • 分别在AR31和AR34上使用命令display ip routing-table查看路由表信息，输出结果如下：
    • 由以上输出结果可知，AR31的路由表信息中存在所有ospf区域的路由条目，AR34的路由表信息中虽然没有ospf区域内的路由条目，但是存在两条指向AR30与AR31的等价缺省路由。因此可以证明AR28（ASBR）的isis进程下引入ospf正常。由于AR30没有登录权限，所以无法判断AR30的路由表信息是否有条目缺失。
  • 2.7 综合分析
    • 通过以上测试可知，AR27与AR31的路由表信息中都可以看到对方路由协议的路由条目，因此可以判断AR28的路由表正常，并且单点双向引入不存在路由过滤。因为5类lsa是整个区域内泛洪，但是当前只是在AR32上没有5类lsa，表明AR32的上游路由器没有将5类lsa发送给AR32，针对5类lsa的发送做了过滤。5类LSA传递过程中实现过滤只有接口下使用ospf filter-lsa-out命令后加上ase关键词可以实现。由于AR32只有AR28一个OSPF邻居，所以可以肯定AR28连接AR32的G0/0/2接口下，使用了ospf filter-lsa-out加ase针对了5类LSA的发送执行了过滤动作。
  • 2.8 排查后续影响访问失败的流量和路由过滤策略
    • 2.8.1 在AR32上使用命令display acl all和display ip ip-prefix检查控制平面路由信息，输出结果如下：
    • 由以上输出结果可知，AR32上无相关acl和前缀列表，可以排除AR32上做了路由过滤的可能。在之前的排查结果中，AR31、AR34、AR28已经检查并不缺失路由，由于AR30没有登录权限，所以不能排除配置了路由过滤的可能。
    • 2.8.2 分别在AR31、AR32、AR34上使用命令display acl all检查数据转发平面问题，输出结果如下：
    • 由以上输出结果可知，AR31、AR32、AR34上都没有相关acl，所以可以排除做了流量过滤的可能，由于AR28与AR30没有登录权限，所以不能排除配置了流量过滤。
• 故障处理
  • 3.1 在AR28的G0/0/2接口执行以下命令，删除针对5类lsa的过滤
    • system-view //进入系统视图 interface G0/0/2 //进入接口视图 undo ospf filter-lsa-out //删除针对5类LSA发送的过滤行为。
  • 3.2 执行完以上命令后逐一执行以下命令验证，排查后续可能出现的问题
    • 验证1：在AR30上执行：display ip routing-table //查看路由表中是否存在AR32 loopback0地址路由，有则执行验证2，否则参考高可能1
    • 验证2：在AR32上执行：ping -a 10.5.1.32 10.5.1.31(30)(34) //测试是否能与ISIS内部设备的地址互通，能则故障解决，否则参考高可能2
  • 3.3 其他可能存在的高可能性故障
    • 高可能性1：AR30的ISIS进程下存在路由过滤，则在AR30上执行以下命令
      • isis 1 //进入ISIS进程 display this //查看ISIS进程下配置，确认是否存在路由过滤 undo filter-policy xxx import //删除进程下的路由过滤策略
    • 高可能性2：AR30和AR28的接口下存在流量过滤，则在AR28和AR30上执行以下命令
      • interface GigabitEthernet 0/0/X //进入接口视图 display this //查看接口配置，确认是否存在流量过滤 undo traffic-filter inbound/outbound //删除流量过滤策略 undo traffic-policy inbound/outbound //删除流量过滤策略
  • 3.4 最后在所有设备上保存配置
    • quit //退到<HUAWEI>模式 save //保存配置，防止断电之后故障重现
  • 3.5 若执行以上操作仍不能解决问题，需要用户提供完整的设备配置信息或者派遣一线工程师到达现场进行现场排障，同时拨打华为400服务热线请求华为TAC专家协助处理。