【HCIE备考笔记】TAC报告总结
所有的TAC题目拓扑图均一致。据目前考生反馈，有6份TAC试卷，出去第一份为HUAWEI官方刊登的范文。其他5份试卷为常考题目。下文对TAC报告进行整理，帮助大家进行考前准备。
目录
TAC题目汇总：
-
诊断 1:AR29 的的 loopback0 无法访问 AR28 的 loopback0 口;请诊断其问题的原因;
- LSW 10上VLAN划分错误
-
诊断 2:AR29 的 loopback0 无法访问 AR33 的 loopback0;请诊断其问题的原因;
- 29和33之间，Hello timer不匹配
- 29和33之间，区域类型不匹配
- 29和33之间，Hello timer不匹配，区域类型也不匹配
-
诊断 3:AR32 的 loopback0 无法访问 AR28 的 loopback0 口;请诊断其问题的原因:
- 3类LSA过滤
-
诊断 4:AR32 的 loopback0 无法访问 ISIS 区域里的任何设备;请诊断其问题的原因
- 5类LSA过滤
-
诊断 5:AR34 没有学习到两条等价默认路由，只从 AR30 学习到了一条
- R31区域号错误
- R31 Level类型错误
-
诊断 6:AR32 的 loopback0 无法访问 ISIS 区域里的部分设备;请诊断其问题的原因
- R28 G0/0/2流量过滤
- R30 G0/0/0流量过滤
TAC报告评分标准
TAC报告写作要求
在记事本上作答，要求分:故障根因，故障分析和解决方案这三部分写。
1、整体要求
- a.语句通顺，没有错别字:
- b:逻辑清晰，达到给客户编写正式的"故障分析报告及处理方案"的质量标准
2、网络故障点的根因判断:
要求:
- a.准确得出网络故障点的根因结论
- b.要求准备描述故障点的根因，而不是描述由于该原因带来的现象
3、分析思路:
要求:
- a.从全局着眼，并考虑协议间的相关性，一步步推断出问题所在
- b.依照故障分析的典型方法论，进行符合逻辑的分析，并体现出方法分析过程
- c.对于故障判断及定位，需要有明确判断依据
4、解决方法:
要求:
- a.清晰，明确
- b.具有明确的可操作性，有清晰步骤，有能快速高效地指导一线的初级工程师进行排除故障所 需的执行指令指导，对执行指令后的输出内容有明确的查看关键点指导和判读
- c.有遇到主要几种高可能性变化情况下的应对方案
TAC报告范文
TAC1–LSW 10上VLAN划分错误
题目:AR29 的的 loopback0 无法访问 AR28 的 loopback0 口;请诊断其问题的原因
故障根因：
LSW6上E0/0/3口VLAN划分错误，与E0/0/2口不在同一VLAN内
分析过程:
第一步，检查路由表，用于查看目标网络是否存在
AR29要访问AR28的loop0，首先需要有对方的路由，所以首先在路由器AR29上，通过display ip routing查看路由表，显示信息如下：
------------------------------------------------------------------------------
Routing Tables: Public
Destinations : 12 Routes : 12
Destination/Mask Proto Pre Cost Flags NextHop Interface
10.5.1.29/32 Direct 0 0 D 127.0.0.1 LoopBack0
------------------------------------------------------------------------------
结果显示当前在AR29上没有AR28的loop0的路由，由于当前运行的路由协议是OSPF，所以下一步先检查OSPF邻居关系
第二步，检查ospf 邻居关系
在路由器AR29上，通过display ospf peer brief，查看OSPF邻居表,显示信息如下：
----------------------------------------------------------------------------
Area Id Interface Neighbor id State
----------------------------------------------------------------------------
结果表明当前在AR29上无AR28/AR27的OSPF邻居关系
同时在AR27上，通过display ospf peer （brief），查看OSPF邻居表
显示信息如下：
----------------------------------------------------------------------------
Router ID: 10.5.1.28 Address: 10.5.128.28 State: Full Mode: Nbr is Master Priority: 1
----------------------------------------------------------------------------
结果表明当前在AR27上存在AR28的FULL的邻居关系，同时获得了AR28的接口IP是：10.5.128.28。
由于邻居关系建立依赖于底层的连通性，所以下一步检查路由器之间的网络连通性。
第三步，通过ping 测试3层连通性
在AR29上分别对AR27和AR28做PING测试: ping 10.5.128.27/ping 10.5.128.28
显示信息如下：
----------------------------------------------------------------------------
Request time out
----------------------------------------------------------------------------
结果表明：AR29无法PING通AR27和AR28的互联接口
在AR27上分别对AR28做PING测试: ping 10.5.128.28/PING 10.5.1.28
显示信息如下：
----------------------------------------------------------------------------
Reply from 10.5.128.28: bytes=56 Sequence=1 ttl=255 time=30 ms
----------------------------------------------------------------------------
结果表明AR27可以PING通AR28的互联接口及loop0接口，说明AR27和AR28之间无连通性故障及无OSPF协议故障
由于3层互通需要2层的支持，所以下一步检查2层之间的连通性。
第四步，排查2层连通性
在路由器AR29/AR27上arp-ping mac xxxx.xxxx.xxxx //xxxx是对方的G0/0/0口MAC地址
显示信息如下：
-----------------------------------------------------------------------------
OutInterface: GigabitEthernet0/0/0 MAC[00-E0-FC-D1-6B-19], press CTRL_C to break
Error: Request timed out.
-----------------------------------------------------------------------------
结果表明：AR29/AR27都无法学习到对方的MAC地址
在路由器AR29/AR27上通过 display arp 命令查看本机的ARP表，结果显示无对方的ARP表项,所以下一步需检查物理层故障
第五步：检查物理层故障
在AR29上通过display interface g0/0/0命令检查物理层的连接。
显示信息如下：
------------------------------------------------------------------------------
GigabitEthernet0/0/0 current state : UP
Line protocol current state : UP
Input: 1245 packets, 148155 bytes
Unicast: 0, Multicast: 1245
Broadcast: 0, Jumbo: 0
--------------------------------------------------------------------------------
结果表明物理层连接正常，且端口上单播和广播包始终为0,但组播包非0且数量持续增加（组播包应该是LSW6的生成树的BPDG）说明物理连接无故障。
第六步，对上述现象的综合分析和解读，推出故障点的根因
综上所述，由于AR27和AR28之间互访正常，所以可以判定AR27/AR28之间不存在任何故障。
由于ARP请求是广播形式，AR29和AR28/27互联地址PING不通并收不到对方发出的广播包以及ARP列表中都无对方的ARP表项得出结论：
双方处于不同的广播域。因为AR27/28/29的G0/0/0口都接在同一台LSW6上，所以可以推断出E0/0/1和E0/0/2处于同一VLAN内，但E0/0/3口处于其他VLAN内。
解决方案
到sw10下
interface Ethernet0/0/3
display this
port link-type access
port default vlan xx //这里vlan号和接口e0/0/2 、e0/0/1 保持一致
验证命令: 在AR29上执行命令：
ping -a 10.5.1.29 10.5.1.28
PING通表示故障已全部排除，否则请参考高可能性
高可能性1： LSW6 AR28 AR29 接口下存在流量过滤策略
interface GigabitEthernet0/0/x
display this //查看当前接口下配置，确认是否存在流量过滤行为
undo traffic-filter inbound(outbound) //删除接口下的流量过滤行为
undo traffic-policy inbound(outbound） //删除接口下的流量过滤行为
高可能性2： sw10 e0/0/2和e0/0/3 接口处于相同的隔离组
int e 0/0/x
dis this //查看接口下是否有隔离组配置
undo port-isolate enable //删除隔离组配置
TAC2–Hello时间、区域类型错误
题目：AR29的的loopback0无法访问AR33的loopback0口；请诊断其问题的原因
故障原因：
AR33 接口配置ospf hello时间为15s,AR29 接口的ospf hello时间 10 s 两者时间不一致，导致两台路由器无法建立ospf邻居，路由无法学习。
分析过程:
2.1 故障验证
<AR29>ping -a 10.5.1.29 10.5.1.33
PING 10.5.1.33: 56 data bytes, press CTRL_C to break
Request time out
Request time out
在AR29 上确实无法ping 通AR33 环回接口，故障确实存在
2.2 查看路由表
在AR29 上面查看路由表
<AR29>dis ip routing-table | include 10.5.1.33
Route Flags: R - relay, D - download to fib
------------------------------------------------------------------------------
Routing Tables: Public
Destinations : 13 Routes : 13
Destination/Mask Proto Pre Cost Flags NextHop Interface
想要双方通信成功，双方需要能够学到对端路由。以上结果表明AR29 上没有学习到AR33 环回接口路由。想要学习到路由，双方需建立ospf邻居。接下来进一步查看ospf邻居关系。
2.3 查看ospf 邻居关系
在AR29 上查看ospf邻居关系
<AR29>dis ospf pee brief
OSPF Process 1 with Router ID 10.5.1.29
Peer Statistic Information
----------------------------------------------------------------------------
Area Id Interface Neighbor id State
0.0.0.0 GigabitEthernet0/0/0 10.5.1.27 Full
0.0.0.0 GigabitEthernet0/0/0 10.5.1.28 Full
----------------------------------------------------------------------------
结果表明，AR29和AR33 并没有建立邻居关系。想要建立邻居需要满足很多条件，例如：直连接口要发布到ospf进程，ospf参数需匹配，直连链路确保可达等。接下来首先查看AR29 是否将接口gi 0/0/1 发布进ospf。
2.4 查看AR29 相关接口是否发布进ospf
<AR29>display ospf interface all
OSPF Process 1 with Router ID 10.5.1.29
Interfaces
Area: 0.0.0.0 (MPLS TE not enabled)
Interface: 10.5.128.30 (GigabitEthernet0/0/0)
Cost: 1 State: BDR Type: Broadcast MTU: 1500
Priority: 1
Designated Router: 10.5.128.28
Backup Designated Router: 10.5.128.30
Timers: Hello 10 , Dead 40 , Poll 120 , Retransmit 5 , Transmit Delay 1
Area: 0.0.0.2 (MPLS TE not enabled)
Interface: 10.5.40.30 (GigabitEthernet0/0/1)
Cost: 1 State: DR Type: Broadcast MTU: 1500
Priority: 1
Designated Router: 10.5.40.30
Backup Designated Router: 0.0.0.0
Timers: Hello 10 , Dead 40 , Poll 120 , Retransmit 5 , Transmit Delay 1
Interface: 10.5.1.29 (LoopBack0)
Cost: 0 State: P-2-P Type: P2P MTU: 1500
Timers: Hello 10 , Dead 40 , Poll 120 , Retransmit 5 , Transmit Delay 1
结果表明，AR29已经将gi 0/0/1 和loopback 0 口发布进ospf。且可以看到gi 0/0/1 接口ospf网络类型为broadcast 、hello时间10s、dead时间40s、MTU值1500、Router id为10.5.1.29 。接下来进一步检查直连链路连通性。
2.5 直连链路连通性检查
在AR29 上ping AR33 物理接口
<AR29>ping 10.5.40.34
PING 10.5.40.34: 56 data bytes, press CTRL_C to break
Reply from 10.5.40.34: bytes=56 Sequence=1 ttl=255 time=80 ms
Reply from 10.5.40.34: bytes=56 Sequence=2 ttl=255 time=20 ms
结果表明，直连链路网络层连通性正常。接下来进一步检查ospf 参数。
2.6 查看ospf 错误参数统计信息
<AR29>dis ospf error int gi 0/0/1
OSPF Process 1 with Router ID 10.5.1.29
OSPF error statistics
Interface: GigabitEthernet0/0/1 (10.5.40.30)
General packet errors:
0 : Bad version 0 : Bad checksum
0 : Bad area id 0 : Bad authentication type
0 : Bad authentication key 0 : Unknown neighbor
0 : Bad net segment 0 : Extern option mismatch
0 : Router id confusion
HELLO packet errors:
0 : Netmask mismatch 89 : Hello timer mismatch
0 : Dead timer mismatch 0 : Invalid Source Address
DD packet errors:
0 : MTU option mismatch
LS REQ packet errors:
0 : Bad request
LS UPD packet errors:
0 : LSA checksum bad
Receive Grace LSA errors:
0 : Number of invalid LSAs 0 : Number of policy failed LSAs
0 : Number of wrong period LSAs
结果表明，hello 时间不匹配。接下来通过调试命令，进一步检查ospf hello 时间具体信息。
2.7 通过debugging 调试命令 检查ospf 报文中的hello 时间参数
在AR29 上执行如下调试命令
<AR29>debugging ospf packet int gi 0/0/1
<AR29>terminal debugging
Dec 29 2019 23:36:29.290.2-08:00 AR29 RM/6/RMDEBUG: Source Address: 10.5.40.34
Dec 29 2019 23:36:29.290.3-08:00 AR29 RM/6/RMDEBUG: Destination Address: 224.0.0.5
Dec 29 2019 23:36:29.290.4-08:00 AR29 RM/6/RMDEBUG: Ver# 2, Type: 1 (Hello)
Dec 29 2019 23:36:29.290.5-08:00 AR29 RM/6/RMDEBUG: Length: 44, Router: 10.5.1.33
Dec 29 2019 23:36:29.290.6-08:00 AR29 RM/6/RMDEBUG: Area: 0.0.0.2, Chksum: 0
Dec 29 2019 23:36:29.290.7-08:00 AR29 RM/6/RMDEBUG: AuType: 02
Dec 29 2019 23:36:29.290.8-08:00 AR29 RM/6/RMDEBUG: Key(ascii): * * * * * * * *
Dec 29 2019 23:36:29.290.9-08:00 AR29 RM/6/RMDEBUG: Net Mask: 255.255.255.0
Dec 29 2019 23:36:29.290.10-08:00 AR29 RM/6/RMDEBUG: Hello Int: 15, Option: _E_
Dec 29 2019 23:36:29.290.11-08:00 AR29 RM/6/RMDEBUG: Rtr Priority: 1, Dead Int:60
Dec 29 2019 23:36:29.290.12-08:00 AR29 RM/6/RMDEBUG: DR: 0.0.0.0
Dec 29 2019 23:36:29.290.13-08:00 AR29 RM/6/RMDEBUG: BDR: 0.0.0.0
Dec 29 2019 23:36:29.290.14-08:00 AR29 RM/6/RMDEBUG: # Attached Neighbors: 0
Dec 29 2019 23:36:29.290.15-08:00 AR29 RM/6/RMDEBUG:
Dec 29 2019 23:36:38.80.2-08:00 AR29 RM/6/RMDEBUG: Source Address: 10.5.40.30
Dec 29 2019 23:36:38.80.3-08:00 AR29 RM/6/RMDEBUG: Destination Address: 224.0.0.5
Dec 29 2019 23:36:38.80.4-08:00 AR29 RM/6/RMDEBUG: Ver# 2, Type: 1 (Hello)
Dec 29 2019 23:36:38.80.5-08:00 AR29 RM/6/RMDEBUG: Length: 44, Router: 10.5.1.29
Dec 29 2019 23:36:38.80.6-08:00 AR29 RM/6/RMDEBUG: Area: 0.0.0.2, Chksum: 0
Dec 29 2019 23:36:38.80.7-08:00 AR29 RM/6/RMDEBUG: AuType: 02
Dec 29 2019 23:36:38.80.8-08:00 AR29 RM/6/RMDEBUG: Key(ascii): * * * * * * * *
Dec 29 2019 23:36:38.80.9-08:00 AR29 RM/6/RMDEBUG: Net Mask: 255.255.255.0
Dec 29 2019 23:36:38.80.10-08:00 AR29 RM/6/RMDEBUG: Hello Int: 10, Option: _E_
Dec 29 2019 23:36:38.80.11-08:00 AR29 RM/6/RMDEBUG: Rtr Priority: 1, Dead Int: 40
Dec 29 2019 23:36:38.80.12-08:00 AR29 RM/6/RMDEBUG: DR: 10.5.40.30
Dec 29 2019 23:36:38.80.13-08:00 AR29 RM/6/RMDEBUG: BDR: 0.0.0.0
Dec 29 2019 23:36:38.80.14-08:00 AR29 RM/6/RMDEBUG: # Attached Neighbors: 0
Dec 29 2019 23:36:38.80.15-08:00 AR29 RM/6/RMDEBUG:
显示一段时间后可以通过 undo terminal debugging 关闭显示
由以上两组信息对比可以看出AR33 和AR29 ospf hello 时间确实不一致，结果表明AR33 和AR29 ospf邻居无法建立的原因是hello时间不匹配造成。
AR33 hello时间是15s AR29 hello时间是10s。
且可以看到影响ospf邻居建立的其他参数：区域id、区域类型、掩码都是匹配的。
同时看到router id 也不冲突。因此可以排除由区域id、区域类型、掩码、router id 参数引起的故障。
由于AR29已经检测到hello报文中的时间不匹配，所以也排除了认证失败的可能性。即使经过修改hello时间，使得ospf邻居正常建立，但也不排除双方存在流量过滤和路由过滤（这两者都有可能影响后续通信）。
接下来在AR29 上进一步查看是否有流量过滤和路由过滤。
2.8 查看AR29是否存在流量过滤或路由过滤
在AR29 上查看用于流量过滤和路由过滤调用的ACL和前缀列表
<AR29>dis acl all
Total quantity of nonempty ACL number is 0
<AR29>dis ip ip-prefix
结果表明，AR29 上无相关ACL和前缀列表。所以可以排除后续在AR29上做流量过滤和路由过滤的可能性。由于AR33 无法登陆，因此不能排除AR33存在流量过滤和路由过滤的可能性。
解决方案：
将AR33 gi 0/0/1 接口ospf hello时间改为10s
AR33:
system-view
int gi 0/0/1
dis this //查看接口下配置
ospf timer hello 10 //修改ospf hello时间为10s,确保AR29 和AR33 的hello时间一致。
验证命令：
在AR29 上执行，验证命令1：
display ospf peer
查看ospf邻居是否存在，如果存在则执行验证命令2，否则参考下面高可能性1
在AR33 和AR29 上执行，验证命令2 ：
display ip routing-table
查看路由表，查看是否有对端环回口路由。有则执行验证命令3，否则参考高可能性2 、3、4
在AR29 上执行验证命令3：
ping -a 10.5.1.29 10.5.1.33
验证故障是否消除。如果故障仍未消除，则考虑高可能性5
高可能性1： AR33 和AR29 接口MTU不匹配，且都开启了MTU检查。(现象为双方仍无法建立full的邻居关系）
在AR33 上执行以下命令：
system-view
int gi 0/0/1
dis this //查看接口mtu是否修改
mtu 1500 //修改接口MTU为1500
高可能性2： AR33上没有将环回接口发布进ospf （现象为ospf邻居可以建立，但AR29 上没有AR33 环回接口路由）
在AR33 上执行以下命令：
system-view
ospf x (x为AR33 ospf 进程）
area 2 //进入区域2
network 10.5.1.33 0.0.0.0 //将AR33 环回口发布进ospf
**高可能性3：**AR33上存在路由过滤的命令 （现象为AR33 上没有AR29 环回接口路由）
在AR33上执行以下命令：
system-view
ospf x（ x为AR33 进程）
dis this //查看是否有流量过滤命令
undo filter-policy xx import //删除ospf进程下路由过滤行为
高可能性4： AR33 接口ospf网络类型不是广播型和AR29 不一致（现象为AR33 和AR29 同时无对方环回口路由）
在AR33 上执行以下命令：
system-view
int gi 0/0/1
dis this //查看是否修改了ospf 网络类型
ospf network-type broadcast //将ospf 网络类型修改为广播型
高可能性5： AR33 接口下存在流量过滤行为（现象为双方都可以学到路由，但是ping 不成功）
在AR33 上执行以下命令：
system-view
int gi 0/0/1
undo traffic-filter inbound //删除流量过滤命令
undo traffic-policy inbound //删除流量过滤命令
最后在所有设备上保存配置
quit
save
经过以上操作发现故障依然存在，可以拨打华为400热线或向华为工程师申请现场支持。
TAC3–LSA3类过滤
题目：AR32(或者AR32环回口）无法访问AR28的loopback0口；请诊断其问题的原因
故障根因
- 1、AR28在area 0 下存在针对自身loop0接口的路由汇总（带not-advertise关键字）。
- 2、AR28 ospf 区域下有针对自身loop0口的filter 路由过滤行为（在area0里面是filter ** export 在area1 里面是filter ** import）
- 3、AR28 gi2/0/0口存在针对自身loop0口3型lsa过滤命令：ospf filter-lsa-out （后面带summary关键字）
分析过程
2.1 故障验证
<AR32>ping 10.5.1.28
PING 10.5.1.28: 56 data bytes, press CTRL_C to break
Request time out
Request time out
Request time out
Request time out
Request time out
--- 10.5.1.28 ping statistics ---
5 packet(s) transmitted
0 packet(s) received
100.00% packet loss
结果表明 AR32 无法ping 通AR28，故障确实存在。
2.2 AR32 查看路由表
<AR32>dis ip routing-table | include 10.5.1.28
Route Flags: R - relay, D - download to fib
------------------------------------------------------------------------------
Routing Tables: Public
Destinations : 20 Routes : 20
Destination/Mask Proto Pre Cost Flags NextHop Interface
可以看到AR32 没有学习到AR28 的环回口路由，这是导致AR32无法访问AR28 环回口的原因。想要学习到路由必须要有ospf邻居。
2.3 AR32上查看ospf 邻居
<AR32>dis ospf peer brief
OSPF Process 1 with Router ID 10.5.1.32
Peer Statistic Information
----------------------------------------------------------------------------
Area Id Interface Neighbor id State
0.0.0.1 GigabitEthernet0/0/0 10.5.1.28 Full
----------------------------------------------------------------------------
结果表明AR32和AR28 ospf邻居关系正常，且为full状态。由此可以排除直连链路故障。既然邻居关系正常，接下来查看ospf LSDB。
2.4 AR32上查看ospf 链路状态数据库（1类LSA）
<AR32>dis ospf lsdb router 10.5.1.28
OSPF Process 1 with Router ID 10.5.1.32
Area: 0.0.0.1
Link State Database
Type : Router
Ls id : 10.5.1.28
Adv rtr : 10.5.1.28
Ls age : 696
Len : 36
Options : ASBR ABR E
seq# : 80000028
chksum : 0xf5a0
Link count: 1
* Link ID: 10.5.239.32
Data : 10.5.239.28
Link Type: TransNet
Metric : 1
可以看到AR32 仅收到了AR28 发来的Gi2/0/0口对应的TransNet的链路状态描述，并未收到loop 0 口对应的StubNet 的链路状态描述。因此可以判定AR28 没有将环回接口发布在area 1 中。如果发布在area 0 中则会以3型LSA形式出现在area 1 中的数据库中。
2.5 AR32 上查看ospf 3型LSA
<AR32>dis ospf lsdb
OSPF Process 1 with Router ID 10.5.1.32
Link State Database
Area: 0.0.0.1
Type LinkState ID AdvRouter Age Len Sequence Metric
Router 10.5.1.32 10.5.1.32 1247 48 80000047 1
Router 10.5.1.28 10.5.1.28 1251 36 80000028 1
Network 10.5.239.32 10.5.1.32 1247 32 8000000A 0
Sum-Net 10.5.128.0 10.5.1.28 1859 28 80000001 1
Sum-Net 10.5.1.33 10.5.1.28 1659 28 80000001 2
Sum-Net 10.5.1.29 10.5.1.28 1659 28 80000001 1
Sum-Net 10.5.1.27 10.5.1.28 1659 28 80000001 1
Sum-Net 10.5.40.0 10.5.1.28 1659 28 80000001 2
Sum-Asbr 10.5.1.29 10.5.1.28 1659 28 80000001 1
Sum-Asbr 10.5.1.27 10.5.1.28 1659 28 80000001 1
结果显示AR32 area 1的 3型lsa （Sum-Net）中并没有10.5.1.28。由于无法判定AR28 是否已经将环回接口发布到area 0 中，所以需要到AR27 上查看area 0 的LSDB。
2.6 AR27 上查看ospf lsdb
<AR27>dis ospf lsdb router 10.5.1.28
OSPF Process 1 with Router ID 10.5.1.27
Area: 0.0.0.0
Link State Database
Type : Router
Ls id : 10.5.1.28
Adv rtr : 10.5.1.28
Ls age : 174
Len : 48
Options : ASBR ABR E
seq# : 80000012
chksum : 0x8cc4
Link count: 2
* Link ID: 10.5.128.30
Data : 10.5.128.28
Link Type: TransNet
Metric : 1
* Link ID: 10.5.1.28
Data : 255.255.255.255
Link Type: StubNet
Metric : 0
Priority : Medium
结果表明在AR27 area 0 的lsdb中，存在AR28通告的1类LSA，且该lsa包含环回口所对应的 StubNet 类型的链路状态描述。由此可以判定AR28 已经将环回接口发布到了area 0 中。同时也排除了AR28 将环回口发布在isis区域再引入ospf的可能。
2.7 综合分析
由于AR28 已经将loop 0 口发布到area 0 中，且AR28 和AR32 邻居关系正常，但AR32 LSDB中并未发现相关LSA。因此可以推断AR28上存在针对环回口的3类LSA的路由过滤行为。针对环回口的路由过滤方式有如下三种：
- 1、AR28在area 0 下存在针对自身loop0接口的路由汇总（带not-advertise关键字）。
- 2、AR28 ospf 区域下有针对自身loop0口的filter 路由过滤行为（在area0里面是filter ** export 在area1 里面是filter ** import）
- 3、AR28 gi2/0/0口存在针对自身loop0口3型lsa过滤命令：ospf filter-lsa-out （后面带summary关键字）
2.8 到AR32查看其是否有数据转发层面过滤或路由控制层面过滤
AR32：
<AR32>dis acl all
Total quantity of nonempty ACL number is 0
<AR32>dis ip ip-prefix
结果表明AR32 上并没有路由控制层面过滤（路由控制层面过滤需要调用acl或前缀列表）和数据转发层面过滤（数据转发层面过滤需要调用acl）。因此可以排除后续由AR32上数据转发层面过滤或路由控制层面过滤以引发访问失败的可能性。
(注释：如果题目要求AR32带loop无法访问AR28的loop0，则在排除AR28上是否有针对AR32 loop0口的过滤，需要考虑AR28是否有回包路由问题，测试方法：AR32带loop0为源PING AR28的G2/0/0口，通说明AR28上有AR32的loop0路由)
解决方案
在AR28上查看OSPF进程下的相关配置，查找具体故障点
system-view
OSPF 1
dis this
area 0 //进入区域0下
undo abr-summary 10.5.1.28 255.255.255.255 //如果有路由汇总命令并最后有not-advertise关键字请删除之
undo filter export //如果有针对3类LSA的出方向过滤行为请删除之
area 1 //进入区域1下
undo filter import //如果有针对3类LSA的入方向过滤行为请删除之
在AR28上查看G0/0/0接口下的相关配置，查找具体故障点
interface GigabitEthernet2/0/0
display this //查看当前接口下配置，确认是否存在3类LSA的过滤命令
undo ospf filter-lsa-out //如果有针对3类LSA的过滤命令请删除之
验证命令：
修改完成后AR32上执行验证命令
<AR32>ping 10.5.1.28
如果能ping 通表示故障已全部排除。否则请参考以下高可能性1。
高可能性1：
AR28 gi 2/0/0 口上存在流量过滤行为
int gi 2/0/0
dis this //如果有流量过滤行为，请删除之
undo traffic-filter inbound //删除入向流量过滤命令
undo traffic-policy inbound //删除入向流量过滤命令
最后保存配置防止重启后故障重现
quit
save
如果经过以上操作仍未解除故障，则可以拨打华为400热线或向华为工程师申请现场技术支持
TAC4–LSA5类过滤
题目：AR32的Loopback 0无法访问ISIS区域里的任何设备；请诊断其问题的原因
故障根因
AR28 Gi2/0/0 接口下配置了ospf filter-lsa-out 命令加ase 关键字来对出方向5类LSA进行过滤。
分析过程
2.1 故障验证
AR32：
ping -a 10.5.1.32 10.5.30 （31,34)
结果显示均为 Request time out
证明故障确实存在。
2.2 AR32查看路由表
想要访问ISIS区域，AR32必须要有对方的路由。
<AR32>dis ip routing-table
Route Flags: R - relay, D - download to fib
------------------------------------------------------------------------------
Routing Tables: Public
Destinations : 14 Routes : 14
Destination/Mask Proto Pre Cost Flags NextHop Interface
10.5.1.27/32 OSPF 10 2 D 10.5.239.28 GigabitEthernet0/0/0
10.5.1.28/32 OSPF 10 1 D 10.5.239.28 GigabitEthernet0/0/0
10.5.1.29/32 OSPF 10 2 D 10.5.239.28 GigabitEthernet0/0/0
10.5.1.32/32 Direct 0 0 D 127.0.0.1 LoopBack0
10.5.1.33/32 OSPF 10 3 D 10.5.239.28 GigabitEthernet0/0/0
10.5.40.0/24 OSPF 10 3 D 10.5.239.28 GigabitEthernet0/0/0
10.5.128.0/24 OSPF 10 2 D 10.5.239.28 GigabitEthernet0/0/0
10.5.239.0/24 Direct 0 0 D 10.5.239.32 GigabitEthernet0/0/0
10.5.239.32/32 Direct 0 0 D 127.0.0.1 GigabitEthernet0/0/0
10.5.239.255/32 Direct 0 0 D 127.0.0.1 GigabitEthernet0/0/0
127.0.0.0/8 Direct 0 0 D 127.0.0.1 InLoopBack0
127.0.0.1/32 Direct 0 0 D 127.0.0.1 InLoopBack0
127.255.255.255/32 Direct 0 0 D 127.0.0.1 InLoopBack0
255.255.255.255/32 Direct 0 0 D 127.0.0.1 InLoopBack0
结果显示AR32没有任何域外路由（O_ASE）。
2.3 AR32上查看ospf邻居关系
<AR32>dis ospf peer b
OSPF Process 1 with Router ID 10.5.1.32
Peer Statistic Information
----------------------------------------------------------------------------
Area Id Interface Neighbor id State
0.0.0.1 GigabitEthernet0/0/0 10.5.1.28 Full
----------------------------------------------------------------------------
结果表明AR32于AR28 邻居关系正常，且为full状态。进而证明两者的互联链路正常。
2.4 AR32上查看ospf LSDB，查看是否有5类LSA
<AR32>
dis ospf lsdb
OSPF Process 1 with Router ID 10.5.1.32
Link State Database
Area: 0.0.0.1
Type LinkState ID AdvRouter Age Len Sequence Metric
Router 10.5.1.32 10.5.1.32 1240 48 80000006 1
Router 10.5.1.28 10.5.1.28 1250 36 80000004 1
Network 10.5.239.32 10.5.1.32 1240 32 80000002 0
Sum-Net 10.5.128.0 10.5.1.28 1289 28 80000001 1
Sum-Net 10.5.1.33 10.5.1.28 1154 28 80000001 2
Sum-Net 10.5.1.29 10.5.1.28 1250 28 80000001 1
Sum-Net 10.5.1.28 10.5.1.28 1289 28 80000001 0
Sum-Net 10.5.1.27 10.5.1.28 1243 28 80000001 1
Sum-Net 10.5.40.0 10.5.1.28 1250 28 80000001 2
Sum-Asbr 10.5.1.29 10.5.1.28 1250 28 80000001 1
Sum-Asbr 10.5.1.27 10.5.1.28 1243 28 80000001 1
结果表明AR32 上只收到1 、2、3、4类lsa，没有5类LSA，由于5类lsa需要在整个ospf区域内泛洪。因此到AR27上做进一步查看。
2.5 AR27上查看ospf lsdb和路由表
<AR27>dis ospf lsdb
OSPF Process 1 with Router ID 10.5.1.27
Link State Database
Area: 0.0.0.0
Type LinkState ID AdvRouter Age Len Sequence Metric
Router 10.5.1.27 10.5.1.27 1645 48 80000006 1
Router 10.5.1.29 10.5.1.29 1642 36 80000007 1
Router 10.5.1.28 10.5.1.28 1646 48 80000008 1
Network 10.5.128.30 10.5.1.29 1646 36 80000002 0
Sum-Net 10.5.1.33 10.5.1.29 1551 28 80000001 1
Sum-Net 10.5.1.32 10.5.1.28 1646 28 80000001 1
Sum-Net 10.5.1.29 10.5.1.29 1694 28 80000001 0
Sum-Net 10.5.239.0 10.5.1.28 1685 28 80000001 1
Sum-Net 10.5.40.0 10.5.1.29 1694 28 80000001 1
AS External Database
Type LinkState ID AdvRouter Age Len Sequence Metric
External 10.5.1.31 10.5.1.28 1663 36 80000001 1
External 10.5.1.30 10.5.1.28 1656 36 80000001 1
External 10.5.1.34 10.5.1.28 1656 36 80000001 1
External 10.5.14.0 10.5.1.28 1663 36 80000001 1
External 10.5.34.0 10.5.1.28 1656 36 80000001 1
External 10.5.130.0 10.5.1.28 1683 36 80000001 1
External 10.5.129.0 10.5.1.28 1677 36 80000001 1
<AR27>dis ip routing-table protocol ospf
Route Flags: R - relay, D - download to fib
------------------------------------------------------------------------------
Public routing table : OSPF
Destinations : 13 Routes : 13
OSPF routing table status : <Active>
Destinations : 13 Routes : 13
Destination/Mask Proto Pre Cost Flags NextHop Interface
10.5.1.28/32 OSPF 10 1 D 10.5.128.28 GigabitEthernet0/0/0
10.5.1.29/32 OSPF 10 1 D 10.5.128.30 GigabitEthernet0/0/0
10.5.1.30/32 O_ASE 150 1 D 10.5.128.28 GigabitEthernet0/0/0
10.5.1.31/32 O_ASE 150 1 D 10.5.128.28 GigabitEthernet0/0/0
10.5.1.32/32 OSPF 10 2 D 10.5.128.28 GigabitEthernet0/0/0
10.5.1.33/32 OSPF 10 2 D 10.5.128.30 GigabitEthernet0/0/0
10.5.1.34/32 O_ASE 150 1 D 10.5.128.28 GigabitEthernet0/0/0
10.5.14.0/24 O_ASE 150 1 D 10.5.128.28 GigabitEthernet0/0/0
10.5.34.0/24 O_ASE 150 1 D 10.5.128.28 GigabitEthernet0/0/0
10.5.40.0/24 OSPF 10 2 D 10.5.128.30 GigabitEthernet0/0/0
10.5.129.0/24 O_ASE 150 1 D 10.5.128.28 GigabitEthernet0/0/0
10.5.130.0/24 O_ASE 150 1 D 10.5.128.28 GigabitEthernet0/0/0
10.5.239.0/24 OSPF 10 2 D 10.5.128.28 GigabitEthernet0/0/0
结果显示AR27数据库中有AR28发来的5类LSA，路由表中有所有源自ISIS区域内的ospf 外部路由（O_ASE）。由此可以判定（ASBR）AR28 ospf 进程下成功引入ISIS路由。
2.6 在AR31和AR34 上查看路由表（确认ospf到isis的引入是否正常）
<AR31>dis ip routing-table protocol isis
Route Flags: R - relay, D - download to fib
------------------------------------------------------------------------------
Public routing table : ISIS
Destinations : 12 Routes : 12
ISIS routing table status : <Active>
Destinations : 12 Routes : 12
Destination/Mask Proto Pre Cost Flags NextHop Interface
10.5.1.27/32 ISIS-L2 15 74 D 10.5.130.28 GigabitEthernet0/0/2
10.5.1.28/32 ISIS-L2 15 74 D 10.5.130.28 GigabitEthernet0/0/2
10.5.1.29/32 ISIS-L2 15 74 D 10.5.130.28 GigabitEthernet0/0/2
10.5.1.30/32 ISIS-L1 15 20 D 10.5.14.34 GigabitEthernet0/0/1
10.5.1.32/32 ISIS-L2 15 74 D 10.5.130.28 GigabitEthernet0/0/2
10.5.1.33/32 ISIS-L2 15 74 D 10.5.130.28 GigabitEthernet0/0/2
10.5.1.34/32 ISIS-L1 15 10 D 10.5.14.34 GigabitEthernet0/0/1
10.5.34.0/24 ISIS-L1 15 20 D 10.5.14.34 GigabitEthernet0/0/1
10.5.40.0/24 ISIS-L2 15 74 D 10.5.130.28 GigabitEthernet0/0/2
10.5.128.0/24 ISIS-L2 15 74 D 10.5.130.28 GigabitEthernet0/0/2
10.5.129.0/24 ISIS-L1 15 30 D 10.5.14.34 GigabitEthernet0/0/1
10.5.239.0/24 ISIS-L2 15 74 D 10.5.130.28 GigabitEthernet0/0/2
<AR34>dis ip routing-table protocol isis
Route Flags: R - relay, D - download to fib
------------------------------------------------------------------------------
Public routing table : ISIS
Destinations : 5 Routes : 6
ISIS routing table status : <Active>
Destinations : 5 Routes : 6
Destination/Mask Proto Pre Cost Flags NextHop Interface
0.0.0.0/0 ISIS-L1 15 10 D 10.5.14.31 GigabitEthernet0/0/1
ISIS-L1 15 10 D 10.5.34.30 GigabitEthernet0/0/0
10.5.1.30/32 ISIS-L1 15 10 D 10.5.34.30 GigabitEthernet0/0/0
10.5.1.31/32 ISIS-L1 15 10 D 10.5.14.31 GigabitEthernet0/0/1
10.5.129.0/24 ISIS-L1 15 20 D 10.5.34.30 GigabitEthernet0/0/0
10.5.130.0/24 ISIS-L1 15 20 D 10.5.14.31 GigabitEthernet0/0/1
结果显示AR34上存在两条等价的默认路由。AR31路由表中存在源自OSPF区域的所有路由条目。由此可以判定AR28 ISIS进程下成功引入了ospf 路由。由于AR30无法登陆，不能判断AR30上的路由表是否有路由缺失。
2.7 综合分析
由于AR27和AR31上都能够看到对方路由域中的路由条目，由此可以判定AR28上的路由表是完整的。且可以确定ASBR （AR28）上的单点双向路由引入是正确的（路由引入无过滤）。
由于5类LSA会通告到整个OSPF域，但仅仅AR32上没有相应的5类LSA。
由此可以判定AR28 Gi2/0/0 接口下配置了ospf filter-lsa-out ase 命令来对出方向5类LSA进行过滤。
2.8 进一步排查后续引起访问失败的路由过滤和流量过滤的可能性
<AR32>dis ip ip-prefix
<AR32>
<AR32>dis acl all
Total quantity of nonempty ACL number is 0
<AR31>dis acl all
Total quantity of nonempty ACL number is 0
<AR34>dis acl all
Total quantity of nonempty ACL number is 0
结果表明AR32、AR31、AR34上没有流量过滤行为（流量过滤需要调用acl）。
同时可以判定AR32上没有路由控制层面的过滤行为（路由控制过滤需要调用acl或前缀列表）。
结合步骤2.6可以排除后续AR32 AR31 AR34 存在流量过滤或路由过滤的可能性。
由于AR28无法登陆，暂时不能排除是否做了流量过滤，同时AR30也无法排除是否做了流量过滤和路由过滤。
解决方案
到AR28 Gi2/0/0接口下将路由过滤的命令删除即可
system-view
int gi 2/0/0
dis this //查看接口下配置
undo ospf filter-lsa-out //删除路由过滤命令
验证命令1：
在AR30 上执行
dis ip routing-table
查看是否可以学习到AR32环回口路由，可以学到则执行验证命令2.否则请参考高可能性1
验证命令2：
在AR32上执行
ping -a 10.5.1.32 10.5.1.30 (31,34)
能ping通表明故障已解除，否则请参考高可能性2
高可能性1：
AR30 ISIS进程下存在针对AR32 环回口路由过滤
AR30：
system-view
isis 1 //进入isis进程下
dis this //查看isis进程下配置
undo filter-policy import //删除路由过滤行为
高可能性2：
AR28和AR30 接口下存在流量过滤行为
到AR28 AR30 接口下检查 并删除相应流量过滤行为
system-view
int gi 0/0/x
dis this //查看接口下配置
undo traffice-filter inbound(outbound） //删除接口下流量过滤行为
undo traffice-policy inbound(outbound） //删除接口下流量过滤行为
最后在所有设备上保存配置,防止设备掉电重启导致故障重现
quit
save
如果经过以上操作故障仍未解除，请拨打华为400热线或向华为工程师申请现场支持
TAC5_1–ISIS level配置错误
题目：AR34 没有收到两条等价缺省路由AR34没有学习到两条等价默认路由，只从AR30学习到了一条
故障根因
AR31 isis级别错误的配置为level-1
分析过程
2.1 故障验证
<AR34>dis ip routing-table
Route Flags: R - relay, D - download to fib
------------------------------------------------------------------------------
Routing Tables: Public
Destinations : 14 Routes : 14
Destination/Mask Proto Pre Cost Flags NextHop Interface
0.0.0.0/0 ISIS-L1 15 10 D 10.5.34.30 GigabitEthernet
0/0/0
10.5.1.30/32 ISIS-L1 15 10 D 10.5.34.30 GigabitEthernet
0/0/0
结果表明AR34 路由表中只有一条isis缺省路由，下一跳指向AR30，缺少一条指向AR31的缺省路由。故障的确存在。
2.2 检查ISIS邻居关系
<AR34>dis isis peer
Peer information for ISIS(1)
System Id Interface Circuit Id State HoldTime Type PRI
-------------------------------------------------------------------------------
0000.0000.0030 GE0/0/0 0000.0000.0034.01 Up 27s L1 64
0000.0000.0031 GE0/0/1 0000.0000.0031.01 Up 9s L1 64
可以看到AR34 和AR30、AR31都形成了Level 1 类型的邻居关系，邻居正常。
2.3 查看两条链路cost开销
<AR34>dis isis brief
ISIS Protocol Information for ISIS(1)
-------------------------------------
SystemId: 0000.0000.0034 System Level: L1
Area-Authentication-mode: NULL
Domain-Authentication-mode: NULL
Ipv6 is not enabled
ISIS is in invalid restart status
ISIS is in protocol hot standby state: Real-Time Backup
Interface: 10.5.34.34(GE0/0/0)
Cost: L1 10 L2 10 Ipv6 Cost: L1 10 L2 10
State: IPV4 Up IPV6 Down
Type: BROADCAST MTU: 1497
Priority: L1 64 L2 64
Timers: Csnp: L1 10 L2 10 ,Retransmit: L12 5 , Hello: L1 10 L2 10 ,
Hello Multiplier: L1 3 L2 3 , LSP-Throttle Timer: L12 50
Interface: 10.5.14.34(GE0/0/1)
Cost: L1 10 L2 10 Ipv6 Cost: L1 10 L2 10
State: IPV4 Up IPV6 Down
Type: BROADCAST MTU: 1497
Priority: L1 64 L2 64
Timers: Csnp: L1 10 L2 10 ,Retransmit: L12 5 , Hello: L1 10 L2 10 ,
Hello Multiplier: L1 3 L2 3 , LSP-Throttle Timer: L12 50
结果表明AR34 isis 类型为Level 1 ，接口gi 0/0/0和gi0/0/1 都已经发布到isis中，接口isis cost值相同都为10。由于形成默认路由需要AR34收到来自AR30和AR31 ATT位置1 的LSP，所以需要查看LSDB。
2.4 检查AR34 LSDB
<AR34>dis isis lsdb
Database information for ISIS(1)
--------------------------------
Level-1 Link State Database
LSPID Seq Num Checksum Holdtime Length ATT/P/OL
-------------------------------------------------------------------------------
0000.0000.0030.00-00 0x0000000b 0x6af0 1150 102 1/0/0
0000.0000.0031.00-00 0x00000009 0xe2a8 1077 102 0/0/0
结果显示AR31产生的LSP中的ATT位没有置1，所以AR34无法形成指向AR31的缺省路由。下一步需要到AR31上检查ISIS相关信息。
2.5 检查AR31上 isis相关信息
<AR31>dis isis peer
Peer information for ISIS(1)
System Id Interface Circuit Id State HoldTime Type PRI
-------------------------------------------------------------------------------
0000.0000.0034 GE0/0/1 0000.0000.0031.01 Up 24s L1 64
结果显示AR31当前只有AR34的level-1的邻居关系，没有和AR28形成level-2的邻居关系，所以AR31产生的LSP中ATT位不置1。由此可以将故障原因缩小到AR28和AR31 isis邻居关系故障。接下来检查邻居故障的原因。
2.6 首先检查直连链路联通性
<AR31>ping 10.5.130.28
PING 10.5.130.28: 56 data bytes, press CTRL_C to break
Reply from 10.5.130.28: bytes=56 Sequence=1 ttl=255 time=10 ms
Reply from 10.5.130.28: bytes=56 Sequence=2 ttl=255 time=1 ms
测试结果发现AR31可以PING通AR28，直连链路可达。
2.7 查看AR31 isis相关信息
<AR31>dis isis brief
ISIS Protocol Information for ISIS(1)
-------------------------------------
SystemId: 0000.0000.0031 System Level: L1
Area-Authentication-mode: NULL
Domain-Authentication-mode: NULL
Ipv6 is not enabled
ISIS is in invalid restart status
ISIS is in protocol hot standby state: Real-Time Backup
Interface: 10.5.14.31(GE0/0/1)
Cost: L1 10 L2 10 Ipv6 Cost: L1 10 L2 10
State: IPV4 Up IPV6 Down
Type: BROADCAST MTU: 1497
Priority: L1 64 L2 64
Timers: Csnp: L1 10 L2 10 ,Retransmit: L12 5 , Hello: L1 10 L2 10 ,
Hello Multiplier: L1 3 L2 3 , LSP-Throttle Timer: L12 50
Interface: 10.5.130.31(GE0/0/2)
Cost: L1 10 L2 10 Ipv6 Cost: L1 10 L2 10
State: IPV4 Up IPV6 Down
Type: BROADCAST MTU: 1497
Priority: L1 64 L2 64
Timers: Csnp: L1 10 L2 10 ,Retransmit: L12 5 , Hello: L1 10 L2 10 ,
Hello Multiplier: L1 3 L2 3 , LSP-Throttle Timer: L12 50
可以看到AR31 isis类型为Level-1 ，这是导致其无法与AR28建立邻居的根本原因，而且可以看到AR31已经将gi 0/0/2口发布进isis中,且网络类型为broadcast。
检查AR31接口isis配置
<AR31>dis isis interface
Interface information for ISIS(1)
---------------------------------
Interface Id IPV4.State IPV6.State MTU Type DIS
GE0/0/1 001 Up Down 1497 L1/L2 Yes/No
GE0/0/2 002 Up Down 1497 L1/L2 No/No
Loop0 001 Up Down 1500 L1/L2 --
结果表明AR31 gi 0/0/2 口类型为Level-1-2 ，并没有强制指定为level 1 。
综合分析
通过在AR31上采集信息，发现AR31的ISIS进程下设置了ISIS类型为level-1，导致无法与AR28建立level-2的邻居关系。
由于AR31还需要和AR34保持level-1的邻居关系，所以需要将AR31 ISIS类型改为level-1-2。
解决方案
在AR31上将isis 级别改为level-1-2。
AR31：
system-view
isis 1 //进入isis进程
is-level level-1-2 //将isis级别改为level-1-2
验证命令1：AR31 上查看isis邻居
dis isis peer
如果能够和AR28建立Level 2邻居关系则执行验证命令2，否则请参考高可能性1
验证命令2：AR34 上查看路由表
dis ip routing-table
如果有两条负载分担的默认路由说明故障已全部排除，否则请参考高可能性2和3
高可能性1：
AR28 Gi0/0/2 口启用了isis认证且认证失败，或者AR28没有将Gi0/0/2口发布进isis ，或者双方isis接口网络类型不匹配。
AR28:
system-view //进入配置修改模式
interface g0/0/2 //进入接口模式模式
dis this //查看接口相关配置，确认是否有ISIS验证
isis enable 1 //将AR28接口发布在isis进程中
undo isis circuit-type //把接口模式恢复为BROADCAST
undo isis authentication-mode //如有验证，请删除ISIS相关验证
高可能性2：
AR31上开启了命令attached-bit advertise never，强制ATT位不置1。
在AR31上
system-view //进入配置修改模式
isis 1 //进入isis进程下
dis this //查看进程下相关配置
undo attached-bit advertise //如有相关命令请删除
高可能性3：
AR34 针对不同下一跳（nexthop）设置了不同的weight 值。
AR34：
system-view
isis 1
dis this //查看isis进程下配置
undo nexthop 10.5.x.x //如果针对不同下一跳设置了不同weight值请删除
最后到所有设备上
quit
save
保存配置防止设备掉电重启后故障重现
如果经过以上操作发现故障仍未解决，请拨打华为400热线或者向华为工程师申请现场技术支持
TAC 5_2-ISIS区域ID配置错误
题目：AR34 没有收到两条等价缺省路由AR34没有学习到两条等价默认路由，只从AR30学习到了一条
故障根因
AR31 ISIS区域ID配置错误（非49.0005）
分析过程
2.1 故障验证
<AR34>dis ip routing-table
Route Flags: R - relay, D - download to fib
------------------------------------------------------------------------------
Routing Tables: Public
Destinations : 14 Routes : 14
Destination/Mask Proto Pre Cost Flags NextHop Interface
0.0.0.0/0 ISIS-L1 15 10 D 10.5.34.30 GigabitEthernet
0/0/0
10.5.1.30/32 ISIS-L1 15 10 D 10.5.34.30 GigabitEthernet
0/0/0
结果表明AR34 路由表中只有一条isis默认路由，下一跳指向AR30，缺少一条指向AR31的默认路由。故障的确存在。
2.2 检查ISIS邻居关系
<AR34>dis isis peer
Peer information for ISIS(1)
System Id Interface Circuit Id State HoldTime Type PRI
-------------------------------------------------------------------------------
0000.0000.0030 GE0/0/0 0000.0000.0034.01 Up 25s L1 64
可以看到AR34只和AR30 形成了邻居关系，并未和AR31形成邻居关系。由此可以推断AR34没有形成指向AR31默认路由的原因是ISIS邻居关系故障。
2.3 检查AR34 直连链路以及ISIS配置
1、检查直连链路连通性
<AR34>ping 10.5.14.31
PING 10.5.14.31: 56 data bytes, press CTRL_C to break
Reply from 10.5.14.31: bytes=56 Sequence=1 ttl=255 time=70 ms
Reply from 10.5.14.31: bytes=56 Sequence=2 ttl=255 time=30 ms
结果表明AR34和AR31直连链路三层可达。
2、检查AR34 isis 相关参数
<AR34>dis isis brief
ISIS Protocol Information for ISIS(1)
-------------------------------------
SystemId: 0000.0000.0034 System Level: L1
Area-Authentication-mode: NULL
Domain-Authentication-mode: NULL
Ipv6 is not enabled
ISIS is in invalid restart status
ISIS is in protocol hot standby state: Real-Time Backup
Interface: 10.5.34.34(GE0/0/0)
Cost: L1 10 L2 10 Ipv6 Cost: L1 10 L2 10
State: IPV4 Up IPV6 Down
Type: BROADCAST MTU: 1497
Priority: L1 64 L2 64
Timers: Csnp: L1 10 L2 10 ,Retransmit: L12 5 , Hello: L1 10 L2 10 ,
Hello Multiplier: L1 3 L2 3 , LSP-Throttle Timer: L12 50
Interface: 10.5.14.34(GE0/0/1)
Cost: L1 10 L2 10 Ipv6 Cost: L1 10 L2 10
State: IPV4 Up IPV6 Down
Type: BROADCAST MTU: 1497
Priority: L1 64 L2 64
Timers: Csnp: L1 10 L2 10 ,Retransmit: L12 5 , Hello: L1 10 L2 10 ,
Hello Multiplier: L1 3 L2 3 , LSP-Throttle Timer: L12 50
结果表明AR34 isis 类型为Level 1 接口gi 0/0/0和gi0/0/1 都已经发布到isis中，网络类型为broadcast，且接口isis cost值相同都为10。
2.4 检查AR31 isis 配置
1、 检查邻居
<AR31>dis isis peer
Peer information for ISIS(1)
System Id Interface Circuit Id State HoldTime Type PRI
-------------------------------------------------------------------------------
0000.0000.0028 GE0/0/2 0000.0000.0031.02 Up 26s L2 64
可以看到AR31 已经和其他区域的AR28建立了Level 2 的邻居关系。满足自身LSP ATT位置1的条件。且在LSDB中可以看到自己产生的ATT 位置1的LSP。因此问题可以定位在AR31-AR34 之间（没有level 1邻居关系）。
2、检查isis配置
<AR31>dis isis brief
ISIS Protocol Information for ISIS(1)
-------------------------------------
SystemId: 0000.0000.0031 System Level: L12
Area-Authentication-mode: NULL
Domain-Authentication-mode: NULL
Ipv6 is not enabled
ISIS is in invalid restart status
ISIS is in protocol hot standby state: Real-Time Backup
Interface: 10.5.14.31(GE0/0/1)
Cost: L1 10 L2 10 Ipv6 Cost: L1 10 L2 10
State: IPV4 Up IPV6 Down
Type: BROADCAST MTU: 1497
Priority: L1 64 L2 64
Timers: Csnp: L1 10 L2 10 ,Retransmit: L12 5 , Hello: L1 10 L2 10 ,
Hello Multiplier: L1 3 L2 3 , LSP-Throttle Timer: L12 50
Interface: 10.5.130.31(GE0/0/2)
Cost: L1 10 L2 10 Ipv6 Cost: L1 10 L2 10
State: IPV4 Up IPV6 Down
Type: BROADCAST MTU: 1497
Priority: L1 64 L2 64
Timers: Csnp: L1 10 L2 10 ,Retransmit: L12 5 , Hello: L1 10 L2 10 ,
Hello Multiplier: L1 3 L2 3 , LSP-Throttle Timer: L12 50
可以看到AR31 isis类型为Level-1-2 ，且已经将gi 0/0/1口发布进isis中,且网络类型也为broadcast和AR34接口一致。
3、检查AR31接口isis配置
<AR31>dis isis interface
Interface information for ISIS(1)
---------------------------------
Interface Id IPV4.State IPV6.State MTU Type DIS
GE0/0/1 001 Up Down 1497 L1/L2 No/No
GE0/0/2 002 Up Down 1497 L1/L2 No/Yes
Loop0 001 Up Down 1500 L1/L2 --
结果表明AR31 gi 0/0/1 口类型为Level-1-2 ，并没有强制指定为level 2 。
2.5 检查AR31 isis 接口错误统计信息
<AR31>dis isis error int gi 0/0/1
Statistics of errored packets for GE0/0/1:
--------------------------------------------------------------------
LSP packet errors:
Longer LSP : 0 Smaller LSP : 0
Mismatched Level : 0 Invalid Sysid : 0
Zero Sequence Number : 0 Illegal IS Type : 0
Zero Checksum : 0 Incorrect Checksum : 0
Bad Authentication : 0 Bad Auth Count : 0
More Protocol TLV : 0 Bad Nbr TLV : 0
Bad Extended IS TLV : 0 Bad IF Addr TLV : 0
Bad Reach TLV : 0 Bad Inter Domain TLV : 0
Mismatched Area Id(L1) : 0 Bad TLV Length : 0
Bad Alias TLV : 0 Bad Area TLV : 0
Bad SRLG TLV : 0 Unknown Adjacency : 0
Bad Protocol ID : 0 Bad Version : 0
Zero Lifetime : 0 Bad Ext Reach TLV : 0
Bad TE Router ID TLV : 0 Bad TE Sub TLV : 0
Hello packet errors:
Bad Packet Length : 0 Reserved CircType : 0
Repeated System ID : 0 Bad Circuit Type : 0
Longer packet : 0 More Area Addr : 0
Longer Area Addr : 0 Bad Area Addr TLV : 0
More IF Addr : 0 Bad Formatted IF TLV : 0
More Nbr SNPA(LAN) : 0 Invalid Sysid : 0
Bad TLV Length : 0 Zero HoldingTime : 0
Unusable IP Addr : 0 Repeated IPv4 Addr : 0
Mismatched Area Addr(L1): 624 Mismatched Proto : 0
SNPA Conflicted(LAN) : 0 Mismatched Level : 0
Mismatched Max Area Addr: 0 Bad Authentication : 0
More Auth TLV : 0 3-Way Option Error(P2P) : 0
No Area Addr TLV : 0 Bad Protocol ID : 0
Bad Version : 0 Invalid IPv6 Addr : 0
More IPv6 IF Addr : 0 Duplicate IPv6 Addr : 0
More Optional Checksum : 0 Bad Optional Checksum : 0
--------------------------------------------------------------------
结果表明 AR31因为区域id 不匹配才没有和AR34 建立邻居。（Mismatched Area Addr(L1): 624 ，建立Level 1 邻居两台路由器必须处于相同区域。）。由于已经检测到hello报文中的区域id 错误参数，可以排除认证失败导致邻居无法建立的可能性。
2.6 查看AR31和AR34 区域ID
<AR31>dis isis lsdb local verbose
Database information for ISIS(1)
--------------------------------
Level-1 Link State Database
LSPID Seq Num Checksum Holdtime Length ATT/P/OL
-------------------------------------------------------------------------------
0000.0000.0031.00-00* 0x0000000c 0xed5b 473 88 1/0/0
SOURCE 0000.0000.0031.00
NLPID IPV4
AREA ADDR 49.0006
<AR34>dis isis lsdb local verbose
Database information for ISIS(1)
--------------------------------
Level-1 Link State Database
LSPID Seq Num Checksum Holdtime Length ATT/P/OL
-------------------------------------------------------------------------------
0000.0000.0034.00-00* 0x0000000c 0xe353 602 102 0/0/0
SOURCE 0000.0000.0034.00
NLPID IPV4
AREA ADDR 49.0005
结果表明AR31 区域id 是：49.0006 而AR34 区域id 是49.0005 ，两者不匹配，无法建立Level 1 的邻居关系。
2.7 进一步检查后续引起不形成缺省路由的其他可能原因
<AR31>dis isis lsdb
Database information for ISIS(1)
--------------------------------
Level-1 Link State Database
LSPID Seq Num Checksum Holdtime Length ATT/P/OL
-------------------------------------------------------------------------------
0000.0000.0031.00-00* 0x00000009 0xf358 1138 88 1/0/0
可以看到AR31 自身已经产生ATT位置1 的LSP。
由此可以判定AR31 isis 进程下没有配置attached-bit advertise never 指令。（该指令会强制AR31 LSP ATT位不置1）
2.8 综上分析
经过排查发现AR31和AR34 的区域ID不匹配导致两者无法建立Level 1 的邻居关系。
如果更改AR34的区域ID将会影响其和AR30的邻居关系。
因此需要更改AR31的区域id，使其和AR34一致（AR28和AR31属于Level 2 邻居关系，区域ID可以不一致）。
根据AR31上的其他输出信息显示，双方的system id不冲突,且无其他故障点存在。
并且双方已经检测到hello中的参数不匹配，所以也可以排除验证失败的可能性。
由于AR31 LSDB中已经有自身产生的ATT bit 置1的LSP，因此可以说明AR31 isis进程下没有attached-bit advertise never 的命令。
解决方案
在AR31上将区域id改为49.0005。
AR31：
system-view
isis 1
dis this //查看isis进程下的配置
undo network-entity 49.0006.0000.0000.0031.00 //删除错误的区域id
netw并rk-entity 49.0005.0000.0000.0031.00 //配置新的区域id，使其保持和AR34一致（注意系统id不要一致）
修改完成后，使用以下命令进行验证
验证命令1：AR34上查看isis邻居
dis isis peer
确保AR34上有两个isis邻居关系
验证命令2：AR34 上查看路由表
dis ip routing-table
如果有两条负载分担的缺省路由说明故障已全部排除，否则请参考高可能性1
高可能性1：
AR34 针对不同下一跳（nexthop）设置了不同的weight 值。
AR34：
system-view
isis 1
dis this //查看isis进程下配置
undo nexthop 10.5.x.x //如果针对不同下一跳设置了不同weight值请删除
最后到所有设备上
quit
save
保持配置防止设备掉电重启后故障重现
如果经过以上操作发现故障仍未解决，请拨打华为400热线或者向华为工程师申请现场技术支持
TAC6_1-流量过滤
题目：AR32的loopback0无法访问ISIS区域里的部分设备；请诊断其问题的原因
故障根因
AR28 Gi0/0/2接口出方向做了针对AR32 loop 0口流量过滤行为
分析过程
根据故障现象先排查控制层面再排查转发层面，步骤如下：
2.1 故障定位
先在AR31上进行路由信息查询，确定ISIS区域网络信息
<AR31>dis isis lsdb verbose
......
SOURCE 0000.0000.0030.00
NLPID IPV4
AREA ADDR 49.0005
INTF ADDR 10.5.1.30
INTF ADDR 10.5.34.30
INTF ADDR 10.5.129.30
......
SOURCE 0000.0000.0031.00
NLPID IPV4
AREA ADDR 49.0005
INTF ADDR 10.5.1.31
INTF ADDR 10.5.14.31
INTF ADDR 10.5.130.31
......
SOURCE 0000.0000.0034.00
NLPID IPV4
AREA ADDR 49.0005
INTF ADDR 10.5.1.34
INTF ADDR 10.5.34.34
INTF ADDR 10.5.14.34
......
SOURCE 0000.0000.0028.00
NLPID IPV4
AREA ADDR 49.0006
INTF ADDR 10.5.129.28
INTF ADDR 10.5.130.28
在AR32上以loop0口为源地址对上面的IP逐个进行ping 测试。
<AR32>ping -a 10.5.1.32 10.5.x.x （目标地址是上面INTF ADDR 地址）
经过ping 可以发现AR32 无法访问AR31上面的所有接口地址，同时无法访问AR34 gi0/0/1以及环回接口。其余ISIS区域地址都可以访问。
总结：由上面测试可以发现AR32 环回口不能访问的区域集中在AR28-AR31-AR34 这几段链路。故障的确存在。接下来查看各路由器的路由信息。
2.2 首先对控制层面进行排查，先查询AR32上面路由信息
<AR32>dis ip routing-table protocol ospf
Route Flags: R - relay, D - download to fib
------------------------------------------------------------------------------
Public routing table : OSPF
Destinations : 13 Routes : 13
OSPF routing table status : <Active>
Destinations : 13 Routes : 13
Destination/Mask Proto Pre Cost Flags NextHop Interface
10.5.1.27/32 OSPF 10 2 D 10.5.239.28 GigabitEthernet
0/0/0
10.5.1.28/32 OSPF 10 1 D 10.5.239.28 GigabitEthernet
0/0/0
10.5.1.29/32 OSPF 10 2 D 10.5.239.28 GigabitEthernet
0/0/0
10.5.1.30/32 O_ASE 150 1 D 10.5.239.28 GigabitEthernet
0/0/0
10.5.1.31/32 O_ASE 150 1 D 10.5.239.28 GigabitEthernet
0/0/0
10.5.1.33/32 OSPF 10 3 D 10.5.239.28 GigabitEthernet
0/0/0
10.5.1.34/32 O_ASE 150 1 D 10.5.239.28 GigabitEthernet
0/0/0
10.5.14.0/24 O_ASE 150 1 D 10.5.239.28 GigabitEthernet
0/0/0
10.5.34.0/24 O_ASE 150 1 D 10.5.239.28 GigabitEthernet
0/0/0
10.5.40.0/24 OSPF 10 3 D 10.5.239.28 GigabitEthernet
0/0/0
10.5.128.0/24 OSPF 10 2 D 10.5.239.28 GigabitEthernet
0/0/0
10.5.129.0/24 O_ASE 150 1 D 10.5.239.28 GigabitEthernet
0/0/0
10.5.130.0/24 O_ASE 150 1 D 10.5.239.28 GigabitEthernet
0/0/0
OSPF routing table status : <Inactive>
可以看到AR32上面的路由信息完整，并无缺失。由此可以判定AR32控制层面没有问题。
2.3 检查AR31 AR34 AR30 AR28 的路由表是否有AR32 环回口路由
<AR31>dis ip routing-table 10.5.1.32
Route Flags: R - relay, D - download to fib
------------------------------------------------------------------------------
Routing Table : Public
Summary Count : 1
Destination/Mask Proto Pre Cost Flags NextHop Interface
10.5.1.32/32 ISIS-L2 15 74 D 10.5.130.28 GigabitEthernet0/0/2
结果表明AR31上有10.5.1.32 路由信息(回包路由正常），控制层面没有问题。
<AR34>dis ip routing-table 10.5.1.32
Route Flags: R - relay, D - download to fib
------------------------------------------------------------------------------
Routing Table : Public
Summary Count : 2
Destination/Mask Proto Pre Cost Flags NextHop Interface
0.0.0.0/0 ISIS-L1 15 10 D 10.5.34.30 GigabitEthernet0/0/0
ISIS-L1 15 10 D 10.5.14.31 GigabitEthernet0/0/1
结果表明AR34上面有两条等价缺省路由。（AR34 是Level 1 级别路由器）路由信息正常。
由于AR30 无法登陆，因此可以在AR32上面使用环回口对其进行ping 测试。
<AR32>ping -a 10.5.1.32 10.5.1.30
PING 10.5.1.30: 56 data bytes, press CTRL_C to break
Reply from 10.5.1.30: bytes=56 Sequence=1 ttl=254 time=60 ms
Reply from 10.5.1.30: bytes=56 Sequence=2 ttl=254 time=40 ms
Reply from 10.5.1.30: bytes=56 Sequence=3 ttl=254 time=20 ms
Reply from 10.5.1.30: bytes=56 Sequence=4 ttl=254 time=30 ms
Reply from 10.5.1.30: bytes=56 Sequence=5 ttl=254 time=20 ms
能够ping 通，表明AR30 上存在10.5.1.32 的路由。（回包需要相应路由）
由于AR32和AR31上都能够学到对端路由，因此可以判定ASBR（AR28）单点双向路由引入正确，即AR28上也会有双方路由。
小结：经过以上排查发现路由条目正常，控制层面没有问题。由此可以推断通信故障是由数据转发层面引起。初步怀疑AR28-AR31-AR34 链路上存在流量控制策略。下面排查流量控制策略的具体位置。
2.4 在AR32上直接tracert AR31 和AR34 接口地址
<AR32>tracert 10.5.1.31
traceroute to 10.5.1.31(10.5.1.31), max hops: 30 ,packet length: 40,press CTRL
_C to break
1 10.5.239.28 10 ms 1 ms 10 ms
2 10.5.130.31 10 ms 20 ms 20 ms
<AR32>tracert 10.5.14.34
traceroute to 10.5.14.34(10.5.14.34), max hops: 30 ,packet length: 40,press CT
RL_C to break
1 10.5.239.28 30 ms 10 ms 20 ms
2 10.5.130.31 20 ms 20 ms 30 ms
3 10.5.14.34 30 ms 30 ms 30 ms
可以看到AR32 访问AR31和AR34 接口经过的路径是：AR28-AR31和AR28-AR31-AR34 。
2.5 首先检查AR31 和AR34 上是否存在流量控制策略
<AR31>dis acl all
Total quantity of nonempty ACL number is 0
<AR34>dis acl all
Total quantity of nonempty ACL number is 0
可以看到AR31 和AR34 上没有流量控制策略（流量控制策略需要调用acl）。
2.6 查询AR28-AR31这段链路是否有流量控制策略
在AR32 上以loop0 为源对之前ping 不通的地址进行tracert 测试
<AR32>tracert -a 10.5.1.32 10.5.130.31
traceroute to 10.5.130.31(10.5.130.31),
max hops: 30 ,packet length: 40,press CTRL_C to break
1 10.5.239.28 30 ms 10 ms 30 ms
2 * * *
<AR32>tracert -a 10.5.1.32 10.5.14.34
traceroute to 10.5.14.34(10.5.14.34),
max hops: 30 ,packet length: 40,press CT
RL_C to break
1 10.5.239.28 20 ms 20 ms 20 ms
2 * * *
结果显示AR32去往AR31 和AR34 的报文全部在第二跳终止。由此可以判断流量过滤发生在AR28-AR31之间，由2.4可知AR31上没有流量过滤。
因此可以判定：流量过滤发生在AR28 的Gi0/0/2口。可以是inbound方向（针对目的地址为10.5.1.32)也可以是outbound 方向（针对源地址是10.5.1.32）。
2.6 进一步判定过滤方向
到AR32上使用loop0 口做为源ping 10.5.130.31.然后到AR31上查看gi 0/0/2 接口input 方向收到的unicast 单播报文情况 ：
<AR32>ping -a 10.5.1.32 10.5.130.31
<AR31>dis int gi 0/0/2
GigabitEthernet0/0/2 current state : UP
Line protocol current state : UP
Last line protocol up time : 2020-01-05 15:05:35 UTC-08:00
Description:HUAWEI, AR Series, GigabitEthernet0/0/2 Interface
Route Port,The Maximum Transmit Unit is 1500
Internet Address is 10.5.130.31/24
IP Sending Frames' Format is PKTFMT_ETHNT_2, Hardware address is 00e0-fcf8-32af
Last physical up time : 2020-01-05 15:05:35 UTC-08:00
Last physical down time : 2020-01-05 15:05:26 UTC-08:00
Current system time: 2020-01-05 15:18:48-08:00
Port Mode: COMMON COPPER
Speed : 1000, Loopback: NONE
Duplex: FULL, Negotiation: ENABLE
Mdi : AUTO
Last 300 seconds input rate 1232 bits/sec, 0 packets/sec
Last 300 seconds output rate 7528 bits/sec, 0 packets/sec
Input peak rate 7896 bits/sec,Record time: 2020-01-05 15:05:42
Output peak rate 10392 bits/sec,Record time: 2020-01-05 15:13:47
Input: 110 packets, 127828 bytes
Unicast: 15, Multicast: 93
Broadcast: 2, Jumbo: 0
Discard: 0, Total Error: 0
重复多次测试发现AR31 gi0/0/2 Input 入方向 unicast 报文没有增长，始终是15，由此可以判定AR28 没有将报文从接口gi 0/0/2 发送给AR31.因此可以判定：AR28 Gi0/0/2接口出方向做了针对AR32 loop 0口流量过滤行为。（注意：如果没有出方向流量过滤，即使AR32 ping 不通AR31也可以收到报文）。
2.7 综上分析
由以上步骤可以发现AR32和AR31 都有对方路由信息，可以判定控制层面没有问题。经过2.5 和2.6 可以发现问题出在AR28 gi 0/0/2口出方向。AR28 在gi 0/0/2口出方向做了流量过滤行为。
解决方案
在AR28 gi 0/0/2 口删除流量过滤命令
AR28：
system-view
int gi 0/0/2
dis this //查看接口配置
undo traffic-filter outbound //删除流量过滤命令
undo traffic-policy outbound
验证命令：
在AR32上以环回口为源对isis区域地址逐个ping 测试
ping -a 10.5.1.32 10.5.130.31
ping -a 10.5.1.32 10.5.1.31
ping -a 10.5.1.32 10.5.14.31
ping -a 10.5.1.32 10.5.14.34
ping -a 10.5.1.32 10.5.1.34
如果能够全部ping 通说明故障已全部排除。否则请参考高可能性1 、2
高可能性1：
AR28 gi 0/0/2 口存在入向流量过滤行为
AR28:
int gi 0/0/2
dis this //查看是否有入向流量过滤
undo traffic-filter inbound //删除入向流量过滤
undo traffic-policy inbound //删除入向流量过滤
高可能性2：
如果经过以上操作仍无法访问，则考虑AR28 上使用了高级acl。高级acl对基于端口的流量进行了相应过滤。请一线工程师登陆设备查看。
最后：
quit
save
所有设备上保存配置，防止设备掉电重启导致故障重现
如果经过以上操作发现故障仍未解决，可以拨打华为400电话或向华为工程师申请现场技术支持
TAC6_2–流量过滤
题目：AR32的loopback0无法访问ISIS区域里的部分设备；请诊断其问题的原因
故障根因
AR30的G0/0/0接口的出方向有针对AR32的loop0流量过滤行为。
分析过程
根据故障现象先排查控制层面再排查转发层面，步骤如下：
2.1 故障定位
先在AR31上进行路由信息查询，确定ISIS区域网络信息
<AR31>dis isis lsdb verbose
......
SOURCE 0000.0000.0030.00
NLPID IPV4
AREA ADDR 49.0005
INTF ADDR 10.5.1.30
INTF ADDR 10.5.34.30
INTF ADDR 10.5.129.30
......
SOURCE 0000.0000.0031.00
NLPID IPV4
AREA ADDR 49.0005
INTF ADDR 10.5.1.31
INTF ADDR 10.5.14.31
INTF ADDR 10.5.130.31
......
SOURCE 0000.0000.0034.00
NLPID IPV4
AREA ADDR 49.0005
INTF ADDR 10.5.1.34
INTF ADDR 10.5.34.34
INTF ADDR 10.5.14.34
......
SOURCE 0000.0000.0028.00
NLPID IPV4
AREA ADDR 49.0006
INTF ADDR 10.5.129.28
INTF ADDR 10.5.130.28
在AR32上以loop0口为源地址对上面的IP逐个进行ping 测试。
<AR32>ping -a 10.5.1.32 10.5.x.x （目标地址是上面INTF ADDR 地址）
测试结果发现不能PING通AR34的G0/0/0口(10.5.34.34) 和 AR34的loop0接口，其余ISIS区域地址都可以访问。
2.2 首先针对控制层面进行排查，先查询AR32上面路由信息
<AR32>dis ip routing-table protocol ospf
Route Flags: R - relay, D - download to fib
------------------------------------------------------------------------------
Public routing table : OSPF
Destinations : 13 Routes : 13
OSPF routing table status : <Active>
Destinations : 13 Routes : 13
Destination/Mask Proto Pre Cost Flags NextHop Interface
10.5.1.27/32 OSPF 10 2 D 10.5.239.28 GigabitEthernet
0/0/0
10.5.1.28/32 OSPF 10 1 D 10.5.239.28 GigabitEthernet
0/0/0
10.5.1.29/32 OSPF 10 2 D 10.5.239.28 GigabitEthernet
0/0/0
10.5.1.30/32 O_ASE 150 1 D 10.5.239.28 GigabitEthernet
0/0/0
10.5.1.31/32 O_ASE 150 1 D 10.5.239.28 GigabitEthernet
0/0/0
10.5.1.33/32 OSPF 10 3 D 10.5.239.28 GigabitEthernet
0/0/0
10.5.1.34/32 O_ASE 150 1 D 10.5.239.28 GigabitEthernet
0/0/0
10.5.14.0/24 O_ASE 150 1 D 10.5.239.28 GigabitEthernet
0/0/0
10.5.34.0/24 O_ASE 150 1 D 10.5.239.28 GigabitEthernet
0/0/0
10.5.40.0/24 OSPF 10 3 D 10.5.239.28 GigabitEthernet
0/0/0
10.5.128.0/24 OSPF 10 2 D 10.5.239.28 GigabitEthernet
0/0/0
10.5.129.0/24 O_ASE 150 1 D 10.5.239.28 GigabitEthernet
0/0/0
10.5.130.0/24 O_ASE 150 1 D 10.5.239.28 GigabitEthernet
0/0/0
OSPF routing table status : <Inactive>
可以看到AR32上面有去往ISIS域所有路由信息。由此可以判定AR32控制层面没有问题。
2.3 检查AR31 AR34 AR30 AR28 的路由表是否有AR32 环回口路由
<AR31>dis ip routing-table 10.5.1.32
Route Flags: R - relay, D - download to fib
------------------------------------------------------------------------------
Routing Table : Public
Summary Count : 1
Destination/Mask Proto Pre Cost Flags NextHop Interface
10.5.1.32/32 ISIS-L2 15 74 D 10.5.130.28 GigabitEthernet0/0/2
结果表明AR31上有10.5.1.32 路由信息（回包路由正常），AR31控制层面没有问题。
<AR34>dis ip routing-table 10.5.1.32
Route Flags: R - relay, D - download to fib
------------------------------------------------------------------------------
Routing Table : Public
Summary Count : 2
Destination/Mask Proto Pre Cost Flags NextHop Interface
0.0.0.0/0 ISIS-L1 15 10 D 10.5.34.30 GigabitEthernet0/0/0
ISIS-L1 15 10 D 10.5.14.31 GigabitEthernet0/0/1
结果表明AR34上面有两条等价缺省路由（回包路由正常）。AR34 作为Level 1 级别路由器，路由信息正常。
由于AR30 无法登陆，因此可以在AR32上面使用环回口对其进行ping 测试。
<AR32>ping -a 10.5.1.32 10.5.1.30
PING 10.5.1.30: 56 data bytes, press CTRL_C to break
Reply from 10.5.1.30: bytes=56 Sequence=1 ttl=254 time=60 ms
Reply from 10.5.1.30: bytes=56 Sequence=2 ttl=254 time=40 ms
Reply from 10.5.1.30: bytes=56 Sequence=3 ttl=254 time=20 ms
Reply from 10.5.1.30: bytes=56 Sequence=4 ttl=254 time=30 ms
Reply from 10.5.1.30: bytes=56 Sequence=5 ttl=254 time=20 ms
能够ping 通，表明AR30 上存在10.5.1.32 的路由。（回包需要相应路由）
由于AR32和AR31上都能够学到对端路由，因此可以判定ASBR（AR28）单点双向路由引入正确，即AR28上也会有双方路由。
小结：经过以上排查发现路由条目正常，控制层面没有问题。接下来检查数据转发层面。
2.4 在AR32上直接tracert AR30和AR34接口地址
<AR32>tracert 10.5.1.30
traceroute to 10.5.1.30(10.5.1.30), max hops: 30 ,packet length: 40,press CTRL
_C to break
1 10.5.239.28 20 ms 10 ms 20 ms
2 10.5.129.30 20 ms 30 ms 30 ms
<AR32>tracert 10.5.34.34
traceroute to 10.5.34.34(10.5.34.34), max hops: 30 ,packet length: 40,press CT
RL_C to break
1 10.5.239.28 20 ms 20 ms 20 ms
2 10.5.129.30 20 ms 20 ms 20 ms
3 10.5.34.34 40 ms 30 ms 30 ms
可以看到AR32 访问AR30和AR34（10.5.34.34）经过的路径是：AR28-AR30和AR28-AR30-AR34
2.5 在AR32 上以loop0 为源tracert AR30和AR34接口地址
<AR32>tracert -a 10.5.1.32 10.5.1.30
traceroute to 10.5.1.30(10.5.1.30),
max hops: 30 ,packet length: 40,press CTRL_C to break
1 10.5.239.28 30 ms 20 ms 20 ms
2 10.5.129.30 20 ms 10 ms 30 ms
<AR32>tracert -a 10.5.1.32 10.5.34.34
traceroute to 10.5.34.34(10.5.34.34),
max hops: 30 ,packet length: 40,press CTRL_C to break
1 10.5.239.28 40 ms 20 ms 20 ms
2 10.5.129.30 20 ms 20 ms 20 ms
3 * * *
<AR32>tracert -a 10.5.1.32 10.5.1.34
traceroute to 10.5.1.34(10.5.1.34),
max hops: 30 ,packet length: 40,press CTRL_C to break
1 10.5.239.28 20 ms 10 ms 10 ms
2 10.5.129.30 10 ms 10 ms 20 ms
3 * * *
结果显示AR32去往AR31（10.5.1.31）可达。访问AR34gi0/0/0口和环回口报文全部在第三跳终止。由于目的地址相同，结合步骤2.4 可以判定丢包行为发生在AR30-AR34之间。接下来检查到底在哪台设备上出现的丢包。
2.6 查询AR34上是否存在流量过滤行为
<AR34>dis acl all
Total quantity of nonempty ACL number is 0
结果表明AR34没有流量过滤行为（流量过滤需要调用acl）。结合步骤2.5和2.6 可以判定：流量过滤发生在AR30的gi0/0/0口。可以是inbound方向（针对目的地址是10.5.1.32）也可以是outbound 方向（针对源地址是10.5.1.32）。
2.7 进一步判定过滤方向
到AR34上开启针对icmp 报文的debugging 调试，同时在AR32上以loop0为源ping 10.5.34.34 ，然后查看AR34上是否有icmp报文：
<AR34>terminal debugging
Info: Current terminal debugging is on.
<AR34>debugging ip icmp
<AR34>terminal monitor
Info: Current terminal monitor is on.
<AR32>ping -a 10.5.1.32 10.5.34.34
PING 10.5.130.31: 56 data bytes, press CTRL_C to break
Request time out
Request time out
结果显示AR34上并未收到icmp报文，由此可以判定AR30 没有将报文从接口gi 0/0/0 发送给AR34.因此可以判定：AR30 Gi0/0/0接口出方向做了针对AR32 loop 0口流量过滤行为。
2.8 综上分析
由以上步骤可以发现AR32和isis域路由器都有对端路由信息，控制层面没有问题。经过前面步骤逐步排查可以发现问题出在AR30 gi 0/0/0口出方向。由此得出故障根因：AR30 在gi 0/0/0口出方向做了针对AR32环回口的流量过滤行为。
解决方案
在AR30 gi 0/0/0 口删除流量过滤命令
AR30：
system-view
int gi 0/0/2
dis this //查看接口配置
undo traffic-filter outbound //删除流量过滤命令
undo traffic-policy outbound
验证命令：
在AR32上以环回口为源进行ping 测试
ping -a 10.5.1.32 10.5.34.34
ping -a 10.5.1.32 10.5.1.34
如果能够全部ping 通说明故障已全部排除。否则请参考高可能性1 、2
高可能性1：
AR30 gi 0/0/0 口存在入向流量过滤行为
AR30:
int gi 0/0/0
dis this //查看是否有入向流量过滤
undo traffic-filter inbound //删除入向流量过滤
undo traffic-policy inbound //删除入向流量过滤
高可能性2：
在ping 通的情况下，某些访问仍出现问题，则考虑使用了高级acl基于端口的流量过滤方法。请一线工程师登陆设备查看接口下是否存在过滤命令。
最后：
quit
save
所有设备上保存配置，防止设备掉电重启导致故障重现
如果经过以上操作发现故障仍未解决，可以拨打华为400电话或向华为工程师申请现场技术支持