错点还原:
#AR30:
acl 2000
rule 5 deny 10.5.1.32 0
int g0/0/0
traffic-filter outbound acl 2000
一、故障根因判断
AR32的 loopback0 无法访问AR34 的 loopback 0 和 g0/0/0 接口地址,根本原因是因为在AR30的 g0/0/0 接口的出方向上做了针对AR32loopback 0 接口地址的流量过滤策略。
二、故障分析
2.1、故障现象重现,在AR32上执行 ping -a 10.5.1.32 x.x.x.x (其中x.x.x.x 是ISIS区域的所有地址)命令,发现确实存在部分地址无法访问的现象,无法访问的的地址如下:
<AR32>ping -a 10.5.1.32 10.5.1.34
PING 10.5.1.34: 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.34 ping statistics ---
5 packet(s) transmitted
0 packet(s) received
100.00% packet loss
------------------------------------------------------------------------------------
<AR32>ping -a 10.5.1.32 10.5.34.34
PING 10.5.34.34: 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.34.34 ping statistics ---
5 packet(s) transmitted
0 packet(s) received
100.00% packet loss
……
省略可以ping 通的地址
由输出结果得知,无法ping 通的地址为AR34的 loopback0 和 g0/0/0 接口,IP地址分别为 10.5.1.34、10.5.34.34,需要查看AR32的路由表中是否存在对应的路由信息。
2.2、在AR32上执行display ip routing-table 命令,查看AR32的路由表信息,输出结果如下:
<AR32>display ip routing-table
Route Flags: R - relay, D - download to fib
------------------------------------------------------------------------------
Routing Tables: Public
Destinations : 21 Routes : 21
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.30/32 O_ASE 150 1 D 10.5.239.28 GigabitEthernet0/0/0
10.5.1.31/32 O_ASE 150 1 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.1.34/32 O_ASE 150 1 D 10.5.239.28 GigabitEthernet0/0/0
10.5.14.0/24 O_ASE 150 1 D 10.5.239.28 GigabitEthernet0/0/0
10.5.34.0/24 O_ASE 150 1 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.129.0/24 O_ASE 150 1 D 10.5.239.28 GigabitEthernet0/0/0
10.5.130.0/24 O_ASE 150 1 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
由输出结果得知,AR32的路由表中存在ISIS区域的所有路由,说明AR28上将ISIS进程引入到了OSPF进程中。需要查看ISIS区域设备的路由表是否存在OSPF区域的路由,以此判断AR28上OSPF进程是否引入到了ISIS进程中。
2.3、在AR31和AR34上执行display ip routing-table 命令,查看AR31和AR34的路由表信息,输出结果如下:
<AR31>dis ip routing-table
Route Flags: R - relay, D - download to fib
------------------------------------------------------------------------------
Routing Tables: Public
Destinations : 23 Routes : 23
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.31/32 Direct 0 0 D 127.0.0.1 LoopBack0
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.14.0/24 Direct 0 0 D 10.5.14.31 GigabitEthernet0/0/1
10.5.14.31/32 Direct 0 0 D 127.0.0.1 GigabitEthernet0/0/1
10.5.14.255/32 Direct 0 0 D 127.0.0.1 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.130.0/24 Direct 0 0 D 10.5.130.31 GigabitEthernet0/0/2
10.5.130.31/32 Direct 0 0 D 127.0.0.1 GigabitEthernet0/0/2
10.5.130.255/32 Direct 0 0 D 127.0.0.1 GigabitEthernet0/0/2
10.5.239.0/24 ISIS-L2 15 74 D 10.5.130.28 GigabitEthernet0/0/2
=====================================================================
<AR34>display ip routing-table
Route Flags: R - relay, D - download to fib
------------------------------------------------------------------------------
Routing Tables: Public
Destinations : 16 Routes : 17
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.1.34/32 Direct 0 0 D 127.0.0.1 LoopBack0
10.5.14.0/24 Direct 0 0 D 10.5.14.34 GigabitEthernet0/0/1
10.5.14.34/32 Direct 0 0 D 127.0.0.1 GigabitEthernet0/0/1
10.5.14.255/32 Direct 0 0 D 127.0.0.1 GigabitEthernet0/0/1
10.5.34.0/24 Direct 0 0 D 10.5.34.34 GigabitEthernet0/0/0
10.5.34.34/32 Direct 0 0 D 127.0.0.1 GigabitEthernet0/0/0
10.5.34.255/32 Direct 0 0 D 127.0.0.1 GigabitEthernet0/0/0
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
由输出结果得知,AR31的路由表中存在OSPF区域的所有路由,AR34上存在两条缺省路由,下一跳分别指向AR30 和 AR31 ,说明AR28上将OSPF进程引入到了ISIS进程中。两个进程都存在对方区域的所有所有路由,说明全网路由可达,不存在路由过滤策略。初步判断可能是AR28、AR30、AR31、AR32、AR34上存在流量过滤策略,由于AR28 和 AR30 存在登陆权限无法访问,所以先查看AR31、AR32、AR34上是否存在流量过滤策略。
2.4、在AR31、AR32、AR34上分别执行 display acl all、display traffic-filter applied-record、display traffic-policy applied-record 命令,查看是否存在可以导致故障现象的过滤策略,输出结果如下
……
省略输出结果
由输出结果得知,AR31、AR32、AR34上均无任何能够导致该故障现象的流量过滤策略。判断可能是AR28或AR31上存在流量过滤策略。由于登陆权限问题,所以需要在AR32上使用tracert 命令间接进行测试。
2.5、在AR32上执行 tracert -a 10.5.1.32 10.5.1.34 和 tracert 10.5.1.34 命令,测试流量在传递路径上是否存在流量过滤策略,输出结果如下:
<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 30 ms 20 ms 10 ms
2 10.5.130.31 40 ms 10.5.129.30 30 ms 10.5.130.31 30 ms
3 * 10.5.14.34 70 ms *
============================================================================================
<AR32>tracert 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 30 ms 20 ms 10 ms
2 10.5.130.31 50 ms 10.5.129.30 20 ms 10.5.130.31 1 ms
3 10.5.34.34 40 ms 10.5.14.34 20 ms 10.5.34.34 20 ms
由输出结果得知,在AR32上以loopback0 接口地址为源地址进行tracert 测试时,流量可以正常通过AR28,但在经过AR30后出现丢包现象,流量无法顺利到达AR34。在AR32上不携带源地址直接进行tracert 测试时,流量可以顺利到达AR34,无丢包现象。说明AR30的g 0/0/0 接口上存在流量过滤策略,但无法判断策略应用的方向,需要在反方向上使用tracert 命令来确定策略应用的方向。
2.6、在AR34上执行tracert -a 10.5.1.34 10.5.1.32 和 tracert -a 10.5.34.34 10.5.1.32 命令,确定策略应用方向,输出结果如下:
<AR34>tracert -a 10.5.1.34 10.5.1.32
traceroute to 10.5.1.32(10.5.1.32), max hops: 30 ,packet length: 40,press CTRL_C to break
1 10.5.34.30 60 ms 20 ms 20 ms
2 10.5.129.28 10 ms 30 ms 10.5.130.28 20 ms
3 10.5.239.32 40 ms 20 ms 20 ms
=====================================================================
<AR34>tracert -a 10.5.34.34 10.5.1.32
traceroute to 10.5.1.32(10.5.1.32), max hops: 30 ,packet length: 40,press CTRL_C to break
1 10.5.34.30 60 ms 20 ms 20 ms
2 10.5.129.28 10 ms 30 ms 10.5.130.28 20 ms
3 10.5.239.32 40 ms 20 ms 20 ms
由输出结果得知,AR34上分别以loopbck0 和g0/0/0 接口地址为源地址进行反向 tracert 测试时,流量可以顺利到达AR32,无丢包现象,说明AR34到AR32的方向上没有流量过滤策略。
综上所述:AR32上以loopback0 为源进行tracert 测试时,数据包可以顺利通过AR28但在经过AR30后出现丢包现象,说明AR30上存在针对AR32loopback0 接口地址的流量过滤策略。在AR34上分别以loopback0 和 g0/0/0 接口地址为源进行反向tracert 测试时,数据包可以顺利到达AR32,说明在AR34到AR32的路径上不存在流量过滤。
结论:AR32loopback 0 接口地址无法访问AR34 loopback 0接口地址的 根本原因是因为在AR30的 g0/0/0接口的出方向上存在针对AR32 loopback 0 接口地址的流量过滤策略。
三、故障处理
3.1、AR30的g0/0/0 接口的出方向上存在流量过滤策略,需要执行以下命令:
display traffic-filter applied-record #查看流量过滤
display traffic-policy applied-record #查看流量策略
system-view #进入系统视图
int g0/0/0 #进入接口视图
undo traffic-filter outbound #删除流量过滤
undo traffic-policy outbound #删除流量策略
执行完上述命令后在AR32上执行以下命令以测试故障是否已解决:
ping -a 10.51.32 10.5.1.34 #测试AR32和AR34 loopback0接口的连通性
ping -a 10.1.32 10.5.34.34 #测试AR32 loopback0 和 AR34 g0/0/0 接口的连通性
3.2、其他高可能性——AR30上做了高级ACL过滤,需要在AR30上执行以下命令:
display acll all #查看所有ACL
system-view #进入系统视图
undo acl {高级ACL序列号} #删除ACL
执行完上述命令后在AR32上执行以下命令以测试故障是否已解决:
ping -a 10.51.32 10.5.1.34 #测试AR32和AR34 loopback0接口的连通性
ping -a 10.1.32 10.5.34.34 #测试AR32 loopback0 和 AR34 g0/0/0 接口的连通性
3.3、quit #推出到系统视图
save #保存配置
若执行完上述命令后,故障仍无法解决,需要派遣一线工程师前往现场进行排障,或提供完整的设备配置,并拨打华为400热线,请华为专家进行远程协助。