Error point restore:
#AR30:
acl 2000
rule 5 deny 10.5.1.32 0
int g0/0/0
traffic-filter outbound acl 2000
1, Fault root cause judgment
The loopback 0 of AR32 cannot access the loopback 0 and g0/0/0 interface addresses of AR34. The root cause is that the traffic filtering strategy for the address of AR32loopback 0 interface is made in the outgoing direction of g0/0/0 interface of AR30.
2, Fault analysis
2.1. The fault phenomenon reappears. Execute ping -a 10.5.1.32 x.x.x.x (where x.x.x.x is all addresses of ISIS area) command on AR32. It is found that some addresses are inaccessible. The inaccessible addresses are as follows:
<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 ...... Omit can ping Address of communication
According to the output results, the address that cannot be ping ed is loopback0 and g0/0/0 interfaces of AR34, and the IP addresses are 10.5.1.34 and 10.5.34.34 respectively. It is necessary to check whether there is corresponding routing information in the routing table of AR32.
2.2. Execute the display IP routing table command on AR32 to view the routing table information of AR32. The output results are as follows:
<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
According to the output results, there are all routes in the ISIS area in the routing table of AR32, indicating that AR28 introduces the ISIS process into the OSPF process. You need to check whether there is a route in OSPF area in the routing table of ISIS area equipment, so as to judge whether the OSPF process on AR28 is introduced into the ISIS process.
2.3. Execute the display IP routing table command on AR31 and AR34 to view the routing table information of AR31 and AR34. The output results are as follows:
<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
According to the output results, there are all routes in the OSPF area in the routing table of AR31, and there are two default routes on AR34. The next hop points to AR30 and AR31 respectively, indicating that AR28 introduces the OSPF process into the ISIS process. Both processes have all routes in each other's area, indicating that the routes of the whole network can be reached, and there is no route filtering strategy. It is preliminarily judged that there may be traffic filtering policies on AR28, AR30, AR31, AR32 and AR34. Since AR28 and AR30 have login permissions and cannot be accessed, check whether there are traffic filtering policies on AR31, AR32 and AR34 first.
2.4. Execute display acl all, display traffic filter applied record and display traffic policy applied record commands on AR31, AR32 and AR34 respectively to check whether there are any filtering strategies that can cause faults. The output results are as follows:
......
Omit output results
According to the output results, there is no flow filtering strategy on AR31, AR32 and AR34 that can lead to this fault phenomenon. It is judged that there may be a traffic filtering strategy on AR28 or AR31. Due to the problem of login permission, you need to use tracert command on AR32 to test indirectly.
2.5. Execute tracert -a 10.5.1.32 10.5.1.34 and tracert 10.5.1.34 commands on AR32 to test whether there is a traffic filtering strategy on the transmission path of traffic. The output results are as follows:
<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
According to the output results, when the tracert test is conducted with the loopback0 interface address as the source address on AR32, the traffic can pass AR28 normally, but there is packet loss after passing AR30, and the traffic cannot reach AR34 smoothly. When the tracert test is carried out directly on AR32 without carrying the source address, the traffic can reach AR34 smoothly without packet loss. It shows that there is a traffic filtering strategy on the g 0/0/0 interface of AR30, but the direction of policy application cannot be determined. It is necessary to use the tracert command in the opposite direction to determine the direction of policy application.
2.6. Execute tracert -a 10.5.1.34 10.5.1.32 and tracert - a 10.5.34 10.5.1.32 commands on AR34 to determine the direction of policy application. The output results are as follows:
<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
According to the output results, when the loopbck0 and g0/0/0 interface addresses are used as the source addresses for reverse tracert test on AR34, the traffic can reach AR32 smoothly without packet loss, indicating that there is no traffic filtering strategy in the direction from AR34 to AR32.
To sum up: during the tracert test with loopback0 as the source on AR32, the data packet can successfully pass AR28, but there is packet loss after passing AR30, indicating that there is a traffic filtering strategy for the address of AR32loopback0 interface on AR30. When the reverse tracert test is conducted on AR34 with loopback0 and g0/0/0 interface addresses as sources respectively, the data packet can successfully reach AR32, indicating that there is no traffic filtering on the path from AR34 to AR32.
Conclusion: the fundamental reason why the AR32loopback 0 interface address cannot access the AR34 loopback 0 interface address is that there is a traffic filtering strategy for the AR32 loopback 0 interface address in the outgoing direction of the g0/0/0 interface of AR30.
3, Fault handling
3.1. There is a flow filtering strategy in the outgoing direction of g0/0/0 interface of AR30. The following commands need to be executed:
display traffic-filter applied-record #View flow filtering display traffic-policy applied-record #View traffic policy system-view #Enter system view int g0/0/0 #Enter interface view undo traffic-filter outbound #Delete flow filter undo traffic-policy outbound #Delete traffic policy After executing the above command AR32 Execute the following command on to test if the fault has been resolved: ping -a 10.51.32 10.5.1.34 #Test the connectivity of AR32 and AR34 loopback0 interfaces ping -a 10.1.32 10.5.34.34 #Test the connectivity of AR32 loopback0 and AR34 g0/0/0 interfaces
3.2. Other high possibilities - Advanced ACL filtering is done on AR30, and the following commands need to be executed on AR30:
display acll all #View all ACL S
system-view #Enter system view
undo acl {senior ACL serial number} #Delete ACL
After executing the above command AR32 Execute the following command on to test if the fault has been resolved:
ping -a 10.51.32 10.5.1.34 #Test the connectivity of AR32 and AR34 loopback0 interfaces
ping -a 10.1.32 10.5.34.34 #Test the connectivity of AR32 loopback0 and AR34 g0/0/0 interfaces
3.3. quit # push to system view
save # saves the configuration
If the fault still cannot be solved after executing the above command, it is necessary to send front-line engineers to the site for troubleshooting, or provide complete equipment configuration, call Huawei 400 hotline and ask Huawei experts for remote assistance.