Purpose
By applying the standard four-step process illustrated in Figure 5, you can isolate a failed node in the network.
Figure 5: Process for Diagnosing Problems in Your Network
Before you embark on the four-step process, however, it is important that you are prepared for the inevitable problems that occur on all networks. While you might find a solution to a problem by simply trying a variety of actions, you can reach an appropriate solution more quickly if you are systematic in your approach to the maintenance and monitoring of your network. To prepare for problems on your network, understand how the network functions under normal conditions, have records of baseline network activity, and carefully observe the behavior of your network during a problem situation.
Figure 6 shows the network topology used in this topic to illustrate the process of diagnosing problems in a network.
Figure 6: Network with a Problem
The network in Figure 6 consists of two autonomous systems (ASs). AS 65001 includes two routers, and AS 65002 includes three routers. The border router (R1) in AS 65001 announces aggregated prefixes 100.100/24 to the AS 65002 network. The problem in this network is that R6 does not have access to R5 because of a loop between R2 and R6.
To isolate a failed connection in your network, follow these steps:
The symptoms of a problem in your network are usually quite obvious, such as the failure to reach a remote host.
To identify the symptoms of a problem on your network, start at one end of your network and follow the routes to the other end, entering all or one of the following JUNOS command-line interfaces (CLI) operational mode commands:
- user@host> ping (ip-address | host-name)
- user@host> show route (ip-address | host-name)
- user@host> traceroute (ip-address | host-name)
Sample Output
user@R6> ping 10.0.0.5
PING 10.0.0.5 (10.0.0.5): 56 data bytes
36 bytes from 10.1.26.1: Time to live exceeded
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 0054 e2db 0 0000 01 01 a8c6 10.1.26.2 10.0.0.5
36 bytes from 10.1.26.1: Time to live exceeded
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 0054 e2de 0 0000 01 01 a8c3 10.1.26.2 10.0.0.5
36 bytes from 10.1.26.1: Time to live exceeded
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 0054 e2e2 0 0000 01 01 a8bf 10.1.26.2 10.0.0.5
^C
--- 10.0.0.5 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss
user@R6> show route 10.0.0.5
inet.0: 20 destinations, 20 routes (20 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.0.5/32 *[IS-IS/165] 00:02:39, metric 10
> to 10.1.26.1 via so-0/0/2.0
user@R6> traceroute 10.0.0.5
traceroute to 10.0.0.5 (10.0.0.5), 30 hops max, 40 byte packets
1 10.1.26.1 (10.1.26.1) 0.649 ms 0.521 ms 0.490 ms
2 10.1.26.2 (10.1.26.2) 0.521 ms 0.537 ms 0.507 ms
3 10.1.26.1 (10.1.26.1) 0.523 ms 0.536 ms 0.514 ms
4 10.1.26.2 (10.1.26.2) 0.528 ms 0.551 ms 0.523 ms
5 10.1.26.1 (10.1.26.1) 0.531 ms 0.550 ms 0.524 ms
Meaning
The sample output shows an unsuccessful ping command in which the packets are being rejected because the time to live is exceeded. The output for the show route command shows the interface (10.1.26.1) that you can examine further for possible problems. The traceroute command shows the loop between 10.1.26.1 (R2) and 10.1.26.2 (R6), as indicated by the continuous repetition of the two interface addresses.
A particular symptom can be the result of one or more causes. Narrow down the focus of your search to find each individual cause of the unwanted behavior.
To isolate the cause of a particular problem, enter one or all of the following JUNOS CLI operational mode command:
To isolate the cause of a particular problem, enter one or all of the following JUNOS CLI operational mode command:
Your particular problem may require the use of more than just the commands listed above. See the appropriate command reference for a more exhaustive list of commonly used operational mode commands.
Sample Output
user@R6> show interfaces terse
Interface Admin Link Proto Local Remote
so-0/0/0 up up
so-0/0/0.0 up up inet 10.1.56.2/30
iso
so-0/0/2 up up
so-0/0/2.0 up up inet 10.1.26.2/30
iso
so-0/0/3 up up
so-0/0/3.0 up up inet 10.1.36.2/30
iso
[...Output truncated...]
user@R2> show route 10.0.0.5
inet.0: 22 destinations, 25 routes (22 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.0.5/32 *[Static/5] 00:16:21
> to 10.1.26.2 via so-0/0/2.0
[BGP/170] 3d 20:23:35, MED 5, localpref 100
AS path: 65001 I
> to 10.1.12.1 via so-0/0/0.0
Meaning
The sample output shows that all interfaces on R6 are up. The output from R2 shows that a static route [Static/5] configured on R2 points to R6 (10.1.26.2) and is the preferred route to R5 because of its low preference value. However, the route is looping from R2 to R6, as indicated by the missing reference to R5 (10.1.15.2).
The appropriate action depends on the type of problem you have isolated. In this example, a static route configured on R2 is deleted from the [routing-options] hierarchy level. Other appropriate actions might include the following:
To resolve the problem in this example, enter the following JUNOS CLI commands:
- [edit]
-
user@R2# delete routing-options static
route destination-prefix
- user@R2# commit and-quit
- user@R2# show route destination-prefix
Sample Output
[edit]
user@R2# delete routing-options static route 10.0.0.5/32
[edit]
user@R2# commit and-quit
commit complete
Exiting configuration mode
user@R2> show route 10.0.0.5
inet.0: 22 destinations, 24 routes (22 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.0.5/32 *[BGP/170] 3d 20:26:17, MED 5, localpref 100
AS path: 65001 I
> to 10.1.12.1 via so-0/0/0.0
Meaning
The sample output shows the static route deleted from the [routing-options] hierarchy and the new configuration committed. The output for the show route command now shows the BGP route as the preferred route, as indicated by the asterisk (*).
If the problem is solved, you are finished. If the problem remains or a new problem is identified, start the process over again.
You can address possible causes in any order. In relation to the network in Figure 6, we chose to work from the local router toward the remote router, but you might start at a different point, particularly if you have reason to believe that the problem is related to a known issue, such as a recent change in configuration.
To evaluate the solution, enter the following JUNOS CLI commands:
- user@host> show route (ip-address |host-name)
- user@host> ping (ip-address | host-name)
- user@host> traceroute (ip-address | host-name)
Sample Output
user@R6> show route 10.0.0.5
inet.0: 20 destinations, 20 routes (20 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.0.5/32 *[BGP/170] 00:01:35, MED 5, localpref 100, from 10.0.0.2
AS path: 65001 I
> to 10.1.26.1 via so-0/0/2.0
user@R6> ping 10.0.0.5
PING 10.0.0.5 (10.0.0.5): 56 data bytes
64 bytes from 10.0.0.5: icmp_seq=0 ttl=253 time=0.866 ms
64 bytes from 10.0.0.5: icmp_seq=1 ttl=253 time=0.837 ms
64 bytes from 10.0.0.5: icmp_seq=2 ttl=253 time=0.796 ms
^C
--- 10.0.0.5 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.796/0.833/0.866/0.029 ms
user@R6> traceroute 10.0.0.5
traceroute to 10.0.0.5 (10.0.0.5), 30 hops max, 40 byte packets
1 10.1.26.1 (10.1.26.1) 0.629 ms 0.538 ms 0.497 ms
2 10.1.12.1 (10.1.12.1) 0.534 ms 0.538 ms 0.510 ms
3 10.0.0.5 (10.0.0.5) 0.776 ms 0.705 ms 0.672 ms
Meaning
The sample output shows that there is now a connection between R6 and R5. The show route command shows that the BGP route to R5 is preferred, as indicated by the asterisk (*). The ping command is successful and the traceroute command shows that the path from R6 to R5 is through R2 (10.1.26.1), and then through R1 (10.1.12.1).