1 Introduction
As a network engineer, it is very important to locate and resolve the fault in time when there is a failure in the network environment. Based on CISCO routing network, this article introduces the method of using diagnostic tools to troubleshoot Cisco routers. Due to space limitations, the content and examples we introduced are mainly based on IP packets, and diagnostic technologies based on protocols such as IPX and Appletalk are similar.
2 Functional features and architecture of routers
Before learning the various troubleshooting and diagnostic tools available on Cisco routers, it is important to understand the basic architecture of a router. Network engineers should understand the role of diagnostic commands when they are executed and the impact on router performance.
Exchange and routing are terms that we often encounter in network interconnection. The switching mentioned here is a completely different concept from the frame-level switching in a local area network. The switching process refers to how a router transmits messages between two different interfaces.
For example, the router receives a message on Ethernet interface 0. The router first obtains the MAC header information from the message, and then checks the network layer message header. The router checks whether there are entries that match the destination address of the packet. Suppose the routing table contains matching terms and the next hop address is another router, which can be reached via Ethernet interface 1. The router then needs to check the second layer address of the next hop. If it does not have this address, it needs to send an ARP broadcast message on Ethernet interface 1. If no ARP response is received, the router will discard the message. If there is response information, the router establishes an Ethernet frame to the next hop router. In this example, the entire process of a router from receiving an Ethernet frame to establishing and sending an Ethernet frame is called a switching process. It should be noted that the ARP parsing process is not usually considered as part of the exchange process. In the above process, performing a routing table query to find the address of the next hop indicates that the exchange process is adopted. This is the simplest method of message exchange, so its overhead and delay are relatively large. All routing protocols ultimately rely on the establishment of routing tables. The router updates the corresponding routing tables by receiving routing update messages sent by adjacent routers running the same protocol. We call it the routing process, which is mainly completed by the routing processor.
Cisco routers that are currently widely used in China include the 2500 series, 4000 series, 7000 series and 7500 series. The routing process of these routers is basically similar, but the switching process varies according to their system structure.
The 7000 series supports process exchange, fast exchange, autonomous exchange and silicon exchange. The Cisco 7500 Series routers have many architectural improvements over the 7000 Series. The functions of the routing processor and the switching processor are integrated into the router switching processor (RSP). This new architecture reduces the load on the system bus during fast switching. The integrated functions optimize both the routing processor and the switching processor in terms of performance, stability, scalability and security. The 7500 series routers do not support autonomous switching or silicon switching, and it supports more flexible optimized switching.
The hardware structure of the Cisco 4000/2500 series routers is simpler than that of the 7000/7500 series routers. These devices share memory only during the exchange process. All message caches and cache are located in shared memory, so only fast exchange or process exchange is supported.
It is necessary to know that process exchange requires routing selection by querying routing tables, and other switching technologies are used to improve switching speed through caches. Because of the different cache locations, they are called different technologies.
3 Troubleshooting and troubleshooting commands
Cisco ISO operating system software provides a set of feature-rich commands that can be used to troubleshoot and troubleshoot, problem diagnosis, and performance detection. Commands can be roughly divided into two categories: show command and debug command. At the same time, it also contains a set of clear commands used to connect these two types of commands. Let's explain each command below
3.1 show command （）
In this section, we will talk about the most commonly used show commands, explaining the output of these commands and the types of failures that these commands are suitable for solving. For clarity, these commands are divided into global system commands, interface-related commands, and protocol-related commands. We only discuss the most commonly used commands.
Global system commands
This section lists output commands related to router software and hardware, including memory areas and power supplies. The show version command is one of the most basic commands, which displays basic information about the router itself and the software and hardware it uses. The function of the show hardware command is similar to the show version command.
The output information of the command includes: the version of the IOS, the router's continuous operation time of about 23 weeks, the reason for the last restart, the size of the router's main memory, the size of the shared memory, the size of the flash memory, the file name of the IOS image, and where the router starts. The show version command displays a lot of very useful information about the router. When solving a problem, you should usually start collecting data from this command.
If multiple interfaces of the router lose messages at the same time, it may be due to insufficient router memory or CPU overload. Users can use the show memory command to check memory utilization (as shown below). CPU utilization can be checked using the show process command.
YH-Router#show memory
Head Total(b) Used(b) Free(b) Lowest(b) Largest(b)
Processor 60DB19C0 19195456 6162924 13032532 11615164 11250780
Fast 60DB19C0 131072 128344 2728 2728 2684
The first two lines of show memory show general information, which indicates that the system has enough memory available. It also shows that there is no fragmentation in memory, as the largest available block in 13.03 megabytes of available memory is close to 11.25 megabytes. Memory fragmentation indicates that memory is divided into many discontinuous blocks. It will cause memory utilization to be reduced, and in severe cases, memory errors may occur, which will also seriously affect the performance of the router.（）
Now let’s take a look at the situation where there are many memory fragments in the router (as shown below). At this point we have enough memory available (8.4 megabytes), but the largest block of them is only 0.5 megabytes. There are not enough available blocks in continuous memory, which can lead to serious memory allocation problems. These problems sometimes manifest as intermittent missing messages from one or more interfaces. At this time, the router generates a memory fragmentation error message.
HX-Router#sh mem
Head Total(b) Used(b) Free(b) Lowest(b) Largest(b)
Processor 60DB19C0 19195456 10713712 8481744 192680 586748
Fast 60DB19C0 131072 90936 40136 40136 40092
Using the command show memory free, users can see that the available memory is divided into many small fragments. It should be noted that it is normal to have a certain amount of memory fragments in the router. Although there is no strict boundary to divide the acceptable level of memory fragmentation, the size of available blocks should be at least not less than half of available memory. Users can solve this problem by restarting the router. On restart, the system reallocates memory and cache space. At this point, the user should monitor the memory allocation process. If a similar situation occurs again, you should consult Cisco TAC.
Users can use the show process cpu command to check whether the router's CPU is overloaded. This command will give the utilization of the router's CPU and also display the CPU usage of different processes in the router. In the following example, the router's CPU is working fine. In general, it is acceptable that the average CPU utilization rate is less than 60% in 5 minutes. If you suspect that there is a problem with CPU utilization, you need to constantly monitor this parameter because it may change in a short period of time. It is best to use this command every 10 seconds. Through this method, the fluctuations in CPU utilization can be clearly understood.
YH-Router#sh process cpu
CPU utilization for five seconds:15%/4%;one minute:175;five minutes:19%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
1 460184 5380085 85 0.00% 0.00% 0.00% 0 NTP
2 252749536 2384205 106010 0.00% 2.35% 2.65% 0 Check Heaps
......
13 26155236 9135958 2862 0.32% 0.25% 0.22% 0 IP Background
14 317720 150150 2116 0.00% 0.00% 0.00% 0 IP Cache ager
......
23 51598380 135094851 381 0.32% 0.24% 0.28% 0 IPX Input
24 86792124 23662071 3667 0.98% 0.87% 0.89% 0 IPX RIP
25 438480948 123384161 3553 7.94% 3.31% 3.91% 0 IPX SAP
......
If the average CPU utilization rate exceeds 80%, it means that the router is overloaded. The next step is to detect which processes are causing excessive CPU utilization. In the above display, we can see that the process IPX SAP occupies most of the CPU processing power, but it is still within an acceptable range. Sometimes, if the SRB background parameter continues to be too high, a routing bridge storm has occurred.（）
[1][2] [3] [4] [5] [6] [7] [8] Next page
Article entry: csh Editor in charge: csh
The show process memory command can be used to give general information about the available memory of the router, and then display the detailed information of the memory space occupied by each process.
If the router completely crashes due to temporary restart, the corresponding error message will be included in the output of the show version command. The show stack command is used to track the router's stack and provides the reason for the router to restart temporarily. If restarted due to an error, the stack record will be displayed at the end of the output. In order to extract information related to the failure, the stack record needs to be decoded. This work is usually done by Cisco TAC engineers. In addition, users with the corresponding CCO login ID can obtain decoded information by sending the output of the show stack command to the CCO. The result of stack record decoding is sometimes related to bugs in Cisco routers.
When a user reports a failure to Cisco TAC, support technicians usually ask the user to send the output result of the show tech_support command. This command will cause the following commands to be executed in order: Show version, Show controllers, Show buffers, Show interface, Show stack, Show process cpu, Show process memory, and Show running-config. A combination of these commands will give details on the router configuration as well as most critical performance parameters. The output of the show tech_support command is very useful for Cisco TAC technicians to solve complex network problems.
Below we will explain some commands directly related to the active router interface. The show ip interface brief will display the IP address information of each router interface and the status information of the second layer (as shown below). The relevance information of other protocols corresponding to IP can be obtained through the corresponding command attributes, such as show ipx interface brief.
YH-Router#sh ip in brief
Interface IP-Address OK? Method Status Protocol
TokenRing0/0 172.26.12.3 YES NVRAM up up
TokenRing0/1 172.27.12.3 YES NVRAM up up
TokenRing0/2 172.28.12.3 YES NVRAM up up
TokenRing0/3 unassigned YES NVRAM administratively down down
Ethernet1/0 172.30.12.3 YES NVRAM up up
Ethernet1/0 172.31.12.3 YES NVRAM up up
Ethernet1/0 172.32.12.3 YES NVRAM up up
Ethernet1/0 172.33.12.3 YES NVRAM up up
The show interface command can get more information. Let's discuss these common interface parameters using Ethernet as an example.
YH-Router#sh int e1/0
Ethernet1/0 is up,line protcol is up
Hardware is cxBus Ethernet,address is 00e0.f78a.6d40(bia 00e0.f78a.6d40)
Deion:seg=E2 LAB SRV1
Internet address is 172.30.12.3/16
MTU 1500bytes,BW 10000Kbit,DLY 1000usec,rely 255/255,load 1/255
Encapsulation ARPA, loopback not set, keepalive set(10sec)
ARP type:ARPA,ARP Timeout 04:00:00
Last input 00:00:00,output 00:00:00,output hang never
Queueing strategy:fifo
Output queue 0/40,44 drops;input queue 0/75,66114 drops
5 minute input rate 181000 bits/sec,23 packets/sec
5 minute output rate 43000 bits/sec,26 packets/sec
525599659 packets input,2042735431 bytes, 0 no buffer
Received 4004547 broadcasts,10 runts,0 giants
139 input errors, 0 CRC, 129 frame, 0 overrun, 0 ignored, 0 abort
0 input packets with dribble condition detected
481020335 packets output, 1069273018 bytes, 47 underruns
20 output errors, 95880485 collisions, 0 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out
in:
Ethernet 1/0 is up Indicates that the first layer of the OSI model is successfully launched.
Line protocol up indicates that the second layer is successfully started.
Deion User-defined description. It is very important to use this function to give an accurate description of the interface. In a large organization, it is difficult for engineers of a local network to locate a failed router.
Previous page [1][2][3] [4] [5] [6] [7] [8] Next page
Article entry: csh Editor in charge: csh
MTU specifies the maximum transmission unit, which can be configured by the user.（）
BW, Dly, rely, load (bandwidth, latency, reliability and load): These parameters are related to the IGRP/EIGRP standard. The configuration of bandwidth and latency can affect routing. In a working interface, the value of reliability is 255. The load should not usually exceed 150/255 unless under very busy conditions.
Encapsulation It refers to the second layer of the interface. In Ethernet, for IP, Cisco is set to ARPA by default, while for IPX is Novell-Ether by default.
What other information can be obtained from the output? Readers can see that the value of ARP cache timeout is 4 hours (this value is the default setting). The time it takes less than 1 second to input from the router interface to output. The output is never suspended. The last time the interface counter was cleared 0 was 5 weeks ago. These data are very useful when evaluating the statistics of the interface. In general, the counter can be cleared for further monitoring.
The interface uses FIFO queuing rules. The default lengths of the output queue and the input queue are 40 and 75, respectively. No packets are included in the queue. After the counter was cleared for the last time, many messages were lost in the input queue. However, as we said earlier, the counter has not been cleared by 0 for 5 weeks; therefore, this value does not indicate that a network failure must have occurred. In this case, the counter should be cleared first, and then the number of missing messages in the output queue should be monitored.
At the same time, the output of the command also displays the average amount of information (in bytes) and the number of messages passing through the router interface every 1 second. The total amount of these parameters and the number of all broadcast messages observed by the router interface are also displayed in the output of the command. If the number of broadcast messages grows very rapidly, especially if the number of input messages is very high, it indicates that there is a broadcast storm in the LAN segment. Since certain specific applications require frequent use of broadcast messages, it is difficult to determine the threshold of the number of broadcast messages. However, if the number of broadcast messages exceeds 30% of the entire input message, you need to use a LAN protocol analyzer to further detect the network.
We can also obtain the following error detection information of the interface:
Runts refers to messages with a size smaller than the minimum value. In the example Ethernet, the value is 64. The minimum packet size specified in Ethernet is because the workstation in this transmission mode needs to detect collisions. If the Ethernet segment contains an Ethernet repeater and its distance meets specified criteria, the minimum message size can cause the workstation in this transmission mode to detect any collisions in the line.
Giants refers to messages whose size exceeds the maximum packet size that the line can bear. The MTU of Ethernet is usually 1500 bytes, or the maximum encapsulation data is 1500 bytes.
Input errors refers to an error detected in the arrival message, which may also indicate an error occurred in the network segment itself.
Output errors refers to an error in the output message, which may indicate that a failure in the router interface itself.
CRCs cyclic redundancy check errors detected by the incorrect Ethernet checksum of the packet. It may be caused by noise in the network segment, or due to network card failure or packet conflict. The frequency of the CRC should occur once every 100,000 input messages.
Frame errors refers to the type of the received frame that does not match the router Ethernet frame type (IP protocol frame type is ARPA).
Problems caused by excessive retransmission in collision detection. In Ethernet, the maximum number of retransmissions should not exceed 15 times.
Dribble condition refers to the received frames larger than MTU, but do not belong to Giants.
Babble refers to the continuous reception of suspicious frames.
Deferred If the line is busy, the message will be delayed during transmission.
Interface resets When too many errors are detected, the router will reset the interface. These errors may exist in the LAN segment or may be errors in the interface itself. It is not possible to determine where a failure occurs, but if a large number of output errors are accompanied, it means that the router interface itself has failed.
Collisions In Ethernet, conflicts are divided into two categories: early and late. early collision detected by the sender before the first 64 bytes of the frame enter the line. Early collision is an integral part of the Ethernet CSMA/CD access method. Early collision usually results in small interrupted frames or runts. Late collision occurs when multiple bytes (greater than 64) of a frame are sent to the line. In theory, Ethernet will not create such conflicts. The reasons for late collision include:
;; The cable violates the distance rule.
;; The faulty NIC card monitors the line incorrectly.
Lost carrier indicates the failure of the carrier and line protocol after the counter is cleared for the last time. Such failures are usually not related to the router. For example, carrier loss may be due to interrupted cable connection between the router and the hub.
The Buffer parameters show interface command also provides failure information related to buffer allocation, including no buffer, overruns, ignored, underruns, buffer failures, swapped out buffers, etc.
Above, we discussed in detail the usage of the show interface command. The output of these commands provides valuable information such as parameters related to the router interface and to the transmission medium.
The show controller command provides detailed information about the physical line and transmission media connected to the router interface. And provide historical information about the status. Some of these details are rarely used, and they are generally only used by TAC technicians to solve very complex problems.（）
Agreement-related commands
This section discusses how to use display commands related to different protocols.
The show protocol command gives the protocol information that the router runs and the address information of each interface that routes these protocols (as shown below).（）
YH-Router#sh protocol
Global values:
Internet Protocol routing is enabled
Novell routing is enabled
Serial0 is up, line protocol is up
Internet address is 171.137.8.130/25
Novell address is AB890880.0000.30e8.b7c8
Serial1 is administratively down, line protocol is down
TokenRing0 is up, line protocol is up
Internet address is 171.137.6.1/25
Novell address is AB890600.0000.30e8.b7c8
......
Previous page [1] [2][3][4] [5] [6] [7] [8] Next page
Article entry: csh Editor in charge: csh
3.2 Debug command
Cisco IOS software contains a large number of debugging commands. These commands can obtain detailed information about packets and frames exchanged in the router when the router is working properly or when a network failure occurs. The special function of debugging commands in troubleshooting network failures can reduce users' demand for protocol analyzers. When using debugging commands, you need to pay attention to the following points:
Do not use debug commands when you do not fully understand the working process of debug commands and the information it provides.（）
The debug command can only capture messages exchanged through the process. Debugging commands will significantly increase the load on the processor. Some commands have very little load, but others are very sensitive to the processor. It is recommended that readers use the command show process cpu to check the CPU load before using the debug command. Even if the CPU load is small, you still need to be very careful when using processor-sensitive commands. In cases where it is not certain, you can query the Cisco debug command reference manual. Commands that are very sensitive to the CPU will generate warning messages. Normally, a large amount of output from debug commands will add to the burden on the processor.
Debugging commands are for troubleshooting, and it is best not to use these commands during monitoring. After obtaining sufficient information, the execution of the debug command should be immediately aborted.
Below we will explain the various debugging commands that can be used in Cisco IOS. To clarify, we divide all debugging commands into three categories: global (system) debugging commands, interface debugging commands, and protocol debugging commands. Similar to the show command, there is no strict boundary between these commands.
First of all, what you need to know is what debugging commands are available. Using debug-related help, enter "debug ?", we will get a list of commands, each containing several properties that provide a variety of different functions when troubleshooting.
Global debugging
When configuring a Cisco router, the boundaries between global and interface commands are very obvious. In this case, we use "global" to identify commands that cannot be used for interface debugging or for specific transmission media types and protocol debugging. For example, in a 2500 series router, you can use debug commands to analyze the Cisco Discovery Protocol (CDP). We log in to the router remotely via telnet. By default, the output of the debug command is sent to the console. If it is in a telnet session, we can use the terminal monitor command to view the output.
Interface debugging
The debug serial interface command is a debug command that is directly related to the router interface and transmission media type. In the following example, the serial interface is in an HDLC package. End-to-end HDLC keeps active packets exchanged every 10 seconds. This indicates that the link is operating properly and the second layer is working properly. The show interface serial0 command indicates that the line protocol is started normally. Use the undebug all command to close all debugging.
YH-Router#debug serial interface
Serial network interface debugging is on
YH-Router#
Jun 1 21:54:55 PDT:Serial0: HDLC myseq 171093, mineseen 171093*, yourseen 1256540,line up
Jun 1 21:55:05 PDT:Serial0: HDLC myseq 171094, mineseen 171094*, yourseen 1256541,line up
Jun 1 21:54:15 PDT:Serial0: HDLC myseq 171095, mineseen 171095*, yourseen 1256542,line up
YH-Router#undebug all
All possible debugging has been turned off
Protocol debugging
Below we give two examples of protocol debugging. Both examples are related to IP protocol. Of course, debug commands apply to all other protocols.
The first example (shown below) shows ARP debugging. ARP debugging starts, then clears the ARP cache, and generates both ARP requests and responses. First, we use the command to clear all ARP caches on the router, so every LAN segment connected to the router will generate ARP packets. Because we do not need to generate too many ARP packets, the selected router is only connected to one Ethernet segment.（）
YH-Router#debug arp
ARP packet debugging is on
YH-Router#clear arp
YH-Router#
*Jun 1 21:57:36 PDT: IP ARP: sent req src 171.136.10.1 00e0.
dst 171.136.10.34 00a0.24d1.5823 Ethernet0
*Jun 1 21:57:36 PDT: IP ARP: sent req src 171.136.10.1 00e0.
dst 171.136.10.10 0080.5f06.ca3d Ethernet0
......
*Jun 1 21:57:36 PDT: IP ARP: rcvd req src 171.136.10.10 0080.5f06.ca3d, dst 171.136.10.1 Ethernet0
*Jun 1 21:57:36 PDT: IP ARP: creating entry for IP address:171.136.10.10,hw: 0080.5f06.ca3d
......
The second example (shown below) shows IP RIP debugging. At the beginning of debugging, the router table was not cleared because the router automatically updates RIP every 30 seconds, so there is no need for forced updates. Similar to the first example, all debugging should be turned off after sufficient information is obtained.（）
YH-Router#debug ip rip events
RIP event debugging is on
YH-Router#
NOV 27 13:55:45 PST: RIP: sending v1 update to 255.255.255.255 via TokenRing1/0 (165.48.65.136)
NOV 27 13:55:45 PST: RIP: Update contains 25 routes
NOV 27 13:55:45 PST: RIP: Update queued
NOV 27 13:55:45 PST: RIP: Update contains 6 routes
NOV 27 13:55:45 PST: RIP: Update queued
NOV 27 13:55:45 PST: RIP: Update sent via TokenRing1/0
......
YH-Router#undeb all
All possible debugging has been turned off
Previous page [1] [2] [3][4][5] [6] [7] [8] Next page
Article entry: csh Editor in charge: csh
3.3 Ping command
Ping is the most commonly used troubleshooting and troubleshooting command. It consists of a set of ICMP response request messages, and if the network is running normally, a set of response response messages will be returned. ICMP messages are transmitted as IP packets, so receiving an ICMP response response message can indicate that connections below the third layer are working properly.
Cisco's ping command not only supports IP protocol, but also supports most other desktop protocols, such as the ping commands of IPX and AppleTalk protocols. Let's first look at the situation where ping commands that support IP protocol are executed in user EXEC mode, and then discuss the many powerful features that extended ping commands contain in privileged mode.（）
User execution mode
IP PING Simple IP ping can be executed in user mode or in privileged mode. Under normal circumstances, the command will send back 5 response requests, and 5 exclamation marks indicate that all requests have successfully received the response. The output also includes information such as maximum, minimum and average round trip time.
Each “!” indicates that an echo response was successfully accepted. If it is not the “!” sign, it indicates that the reason why the echo response was not received:
! Response successfully received
· Request timeout
U Unreachable Purpose
P protocol is unreachable
N Network unreachable
Q Source Suppression
M cannot be segmented
? Agnostic message type
IPX PING The IPX ping command can only be executed on routers running IOS v 8.2 and above. IPX ping in user mode is usually only used to test the Cisco router interface. In privileged mode, users can ping a specific NOVELL workstation, and the command format is "ping ipx IPX address".
APPLETALE PING This command uses Apple Echo Protocol (AEP) to confirm connectivity between AppleTalk nodes. It should be noted that the current Cisco router only supports Apple Echo Protocol for Ethernet interfaces. The format of the command is "ping apple Appletalk address".
Privileged execution mode
In privileged execution mode, the extended ping command is applicable to any desktop protocol. It contains more functional properties, so more detailed information can be obtained. Through this information, we can analyze the reasons for network performance degradation, not just for service loss. The execution method of the extended ping command is also to type in the ping. The router then prompts for various different properties.
EXTENDED IP PING The usage method is as follows:（）
YH-Router#ping
Protocol :
Target IP address: 165.48.183.12
Repeat count <5>: 10
Datagram size <100>: 1600
Timeout in seconds <2>:
Extended commands : y
Source address or interface: 165.48.48.3
Type of service <0>:
Set DF bit in IP header? :
Data pattern <0xABCD>:
Loose, Srict, Record, Timestamp, Verbose:
Sweep range of sizes :
Type escape sequence to abort.
Sending 10, 1600-byte ICMP Echoes to 165.58.183.12, timeout is 2 seconds:
!!!!!!!!!!
Success rate is 100 percent (10/10), round-trip min/avg/max = 36/39/48 ms
First we discuss the various available properties of ping in privileged mode. The default values for each attribute are displayed in parentheses.
Protocol The protocol that needs to be tested.
Target address The target address of the test.
Repeat count If there is an intermittent failure or the response time is too slow, the number of pings will be repeated.
Datagram size If you suspect that the message is lost due to too long delay or segmentation failure, the size of the message can be increased. For example, we can use 1600 byte packets to force segmentation.
Timeout If the timeout is suspected to be due to a slow response rather than a packet loss, this value can be increased.
Extended commands Answer OK to obtain the extended attribute.
Source address must be the address of the router interface.
Type of service According to the attributes specified by RFC 791 TOS, the default value is usually 0.
Set DF bit in IP header? By setting the DF bit to prohibit segmentation, even if the packet exceeds the router-defined MTU.
Data pattern <0xABCD> The noise of the line can be tested by changing the data mode.
Loose, Strict, Record, Timestamp, Verbose are all attributes of IP packet headers. Generally, only Record attributes and Verbose are used, and other attributes are rarely used. Record can be used to record the address of each hop of the message, and the Verbose attribute gives the response time of each response. .
Sweep range of sizes This property is mainly used to test failures such as large packets being lost, processing speed is too slow or segmentation failure.（）
Previous page [1] [2] [3] [4][5][6] [7] [8] Next page
Article entry: csh Editor in charge: csh
EXTEND IPX PING The extended IPX ping also allows users to modify parameters, such as packet size and number of repetitions. Another enhanced attribute for ping in user mode is the use of the Novell Standard echo attribute. Using this property, users can ping the workstation that loads IPX. If this property is disabled, Novell IPX devices will not respond to pings because they do not support the Cisco proprietary IPX ping protocol. Users can modify the properties of devices to support this feature
EXTENDED APPLETALK PING The extended AppleTalk ping command is an enhancement to ping in user mode, which is similar to the extended IPX ping. Like IP and IPX extension ping, users can also choose attributes such as Verbose.
3.4 trace command
The trace command provides information about each hop from the router to the destination address. It is implemented by controlling the lifetime (TTL) field of IP packets. ICMP response request packets with TTL equal to 1 will be sent first. The first router on the path will discard the message and send back the message that identifies the error message. The error message is usually an ICMP timeout message, indicating that the message has successfully reached the next hop of the path, or the port is unreachable message, indicating that the message has been received by the destination address but cannot be uploaded to the IP protocol stack.（）
In order to obtain information on the round trip delay time, trace sends three messages and displays the average delay time. Then add 1 to the TTL field of the message and send 3 messages. These messages will arrive on the second router of the path and return a timeout error or port unreachable message. Repeat this method, continuously increasing the value of the TTL field of the message until a response message of the destination address is received.
In some cases, using the trace command may cause a failure. Because there are bugs related to the trace command in the IOS. Information about these bugs can be obtained from the CCO. Another problem is that some target sites do not respond to ICMP port unreachable messages. When the output of the command displays a series of asterisks (*), you may encounter such sites. Users can use Ctrl-Shift-6 to interrupt the execution of the command.
User Execution Mode The following shows the output of a simple trace command executed in user execution mode. The distance to reach the destination is 3 hops. The response messages of 3 packets with TTL value of 1 are ICMP timeout errors, and there are two IP addresses of the returned packets. Because router 1 and router 2 are in the same network segment, and their distance to router 3 is one hop, these routers all respond to packets.
Router3#trace 171.144.1.39
Type escape sequence to abort.
Tracing the route to Router9 (171.144.1.39)
1 Router2 (165.48.48.2) 0 msec
Router2 (165.48.48.2) 0 msec
Router1 (165.48.48.1) 0 msec
2 165.48.48.129 12 msec
Router6 (165.48.49.129) 12 msec 12 msec
3 Router4 (171.133.1.2) 12 msec 12 msec
Router9 (171.144.1.39) 12 msec 12 msec
Router3
The following lists the different characters appearing in the output of the IP trace command and their meanings:（）
XY msec round trip delay (in milliseconds) before receiving the response message
* Message timeout
? Message type cannot be recognized
U port is unreachable
P protocol is unreachable
N Network unreachable
H Host Unreachable
Q ICMP source suppression
Privileged mode Extend Trace Many properties used to extend the ping command can be used to extend the functionality of the trace command. The special properties of the extended trace command are:
Numeric display By default, the output of the trace command includes both the IP address and its corresponding DNS domain name. This property can be used if the user does not need to display the DNS domain name.
Probe count The default value is 3, and users can adjust it as needed.
TTL This value can vary between the maximum and minimum TTL values.
Port number This is a very useful property that allows engineers to track specific transport layer ports. Therefore, it is possible to confirm not only the IP connectivity between the source and destination, but also to confirm whether the high-level service is accessible.
Previous page [1] [2] [3] [4] [5][6][7] [8] Next page
Article entry: csh Editor in charge: csh
Another problem related to the trace command is that if there are multiple paths to the destination, the source address of the return message may be different. In this case, the user needs to carefully compare the delay times of different return messages. If you still cannot get a clear result, you can remotely access one or more routers on the path and use the trace command to access the source and destination addresses.
4 Understanding Cisco Error Messages
4.1 Error message format
The system error message format is as follows:
úcility - subfacility - Severity - Mnemonic ： Message Text
Facility It indicates the device name involved in the error message. This value can be a protocol, hardware device, or system software module.
Subfacility It is only related to Channel Interface Processor (CIP) cards. For detailed information, please refer to the relevant sections of the Cisco documentation.
Severity It is a number with a range of 0 to 7. The smaller the value of the number, the higher the severity.
Mnemonic Single-value code that uniquely identifies the error message. This code can usually imply the wrong type.
Message Text It is a short description of the error message, including the router hardware and software information involved.
Here are some examples of error messages. Users can consult the System Error Messages section of the CCO ISO documentation for instructions on these error messages.
%DUAL-3-SIA：Route 171.155.148.192/26 stuck-in-active state in IP-EIGP 211. Cleaning up
%LANCE-3-OWNERR: Unit 0, buffer ownership error
It should be noted that not all messages involve failures or problems. Some messages display status information. For example, the following message only indicates that the ISDN BRI 0 interface is connected to a specific remote data.
%ISDN-6-CONNECT: Interface BRI0 is now connected to 95551212 （）
4.2 Traceback Report
Some error messages related to internal router errors contain traceback information. When reporting errors to Cisco TAC, add this information to the error description.
5 Logs of error messages and event information
Depending on the importance and validity of the error message, Cisco error messages can be logged to the following locations:
;; Console
;; Virtual terminal
;; Syslog server
;; Internal buffer
The logging on command enables the output of log messages to the above location. For Syslog servers, the IP address of the server must be specified using the following global configuration command:
logging ip-address
By repeatedly using this command, a list of servers can be created. When managing large networks, it is often necessary to set up redundant servers.
The logging buffered command is used to send log information to the internal buffer. The size of the buffer must be above 4096 bytes. The default value varies according to the system platform. The user needs to select the buffer size suitable for the environment. If the buffer is too small, the new message will overwrite the old message. This may cause problems. However, if the buffer size is too large, the system cache will be wasted. The no logging buffered command will prohibit messages from being written to the internal cache.
Users can use the show logging command to display the contents of the internal buffer. If the user needs information for a certain time period, first use NTP or manually set the clock. The specific operation is:
YH-Router#clock set 11:37:00 December 2000
YH-Router#sh clock
11:37:03.596 PST Fri Dec 11 2000
The timestamps and debugging information of log messages can be used using the following global configuration commands:
YH-Router (config)#service timestamps log datetime
YH-Router (config)#service timestamps debug datetime
The terminal monitor command will display the log information during debugging on the current terminal. This command is not a configuration command. Instead, it can be used in the command line mode when telnet to the router.（）
In most cases, users may need to display a certain level of log information. Therefore, log information is divided into eight different levels, arranged from high to low according to the degree of importance as follows:
;; Emergencies
;; Alerts
;; Critical
;; Errors
;; Warnings
;; Notifications
;; Informational
Previous page [1] [2] [3] [4] [5] [6][7][8] Next page
Article entry: csh Editor in charge: csh;; Debugging
For example, if you need to display all log information on the console with a severity equal to or greater than Warning, you can use the following global configuration command:
logging console warning
Similarly, when sending a certain type of log information to the current terminal, use
logging monitor level
Or use when sending information to the Syslog server
logging trap level
Unlike the terminal monitor command, the logging monitor command is part of the router configuration. The former command is not allowed to be executed at different security levels.
It should be noted that when logging logs to different locations, the system overhead varies greatly. The overhead of recording logs to the console is relatively high, but the overhead of recording logs to the virtual terminal is relatively low. Less overhead when using Syslog servers. The log writing method with the least system overhead is to write to the internal buffer.
5 To be sorted out (bbs.) （）
6 Core Dump
In order to find the cause of the router crash, we can use many commands to get valid information. We have explained the usage of the show stacks command. A core dump is a copy of the system memory image that can be written to the TFTP server. From this binary file, we can obtain information related to router crashes or serious misoperations, through which possible failures can be eliminated.
The following configuration command writes the core dump to the TFTP server corresponding to the IP address in the command:
exception dump ip-address
The write core command is usually used to save the core image when a router has serious errors but does not completely crash.
Core dumps are available only on servers running IOS v 9.0 or later. However, it is important to note that when using core dumps, it is best to get support from experienced engineers or Cisco TAC.
7 Conclusion
To successfully diagnose and troubleshoot network failures, network engineering and technicians must master two basic skills. First of all, we must have a clear understanding of network technology and protocols, which is the basis for diagnosing and troubleshooting network failures. Without proper knowledge and experience, troubleshooting and troubleshooting tools such as router diagnostic commands and network analyzers cannot play their role.
The second skill that network engineering technicians must master is to apply the knowledge they have in a organized manner to diagnose and troubleshoot network failures. Although this article only explains some diagnostic commands, it should be emphasized that troubleshooting and troubleshooting are a structured method. Many engineering and technicians believe that troubleshooting and troubleshooting planning is less important than research and application of technology itself. In fact, correct planning often plays a decisive role in the process of troubleshooting and troubleshooting. During the troubleshooting process, an accidental behavior may allow the failure to be solved smoothly, but it cannot replace structured troubleshooting and troubleshooting methods.
The troubleshooting of network failures is a systematic project that should go through steps such as defining problems, collecting facts, considering possibilities based on facts, establishing an action plan, implementing plans, observation results and cycling processes. This process is like a waterfall model of the software development process, and its importance is self-evident.
Previous page [1] [2] [3] [4] [5] [6] [7][8]
Article entry: csh Editor in charge: csh