If the interface is not up, use the no shutdown command to bring the interface up. Ensure that encapsulation is PPP. If the interface is not using PPP then use the encapsulation ppp command in the interface configuration mode to correct it. Check to see if loopback is set. Loopback should be set only for testing purposes. Use the no loopback command to remove loopbacks. Whenever troubleshooting a PRI, you need to check to see if the T1 is running cleanly on both ends.
If Layer 1 problems have been resolved, as described above, consider Layer 2 and Layer 3 problems. The show isdn status command is used to display a snapshot of all ISDN interfaces. It displays the status of Layers 1, 2 and 3. Also verify that the T1 is not administratively down. Use the no shutdown command to bring the T1 controller up. Refer to the Troubleshooting using the show controller t1 Command section in this chapter. Use debug isdn q to verify that layer 2 is stable.
The debug isdn q command displays data link layer layer 2 access procedures that are taking place at the router on the D-channel. Ensure that you are configured to view debug messages by using the logging console or terminal monitor command as necessary.
Note: In a production environment, verify that console logging is disabled. Enter the show logging command. If logging is enabled, the access server may intermittently freeze up as soon as the console port gets overloaded with log messages. Enter the no logging console command. Note: If debug isdn q is turned on and you do not receive any debug outputs, place a call or reset the controller to get debug outputs.
You should observe the debug outputs for messages indicating that the service is not bouncing up and down. If you see the following types of debug outputs, the line is not stable. If Layer 2 does not appear to be stable, see "Troubleshooting T1 Error Events," earlier in this chapter.
This is usually seen when we are transmitting poll requests RRp and not getting a response from the switch RRf or vice-versa. Check to see if encapsulation is PPP. If not, use the encapsulation ppp command to set encapsulation. Check to see if the interface is in loopback mode. For normal operation, the interface should not be in loopback mode.
The Hardware loopback plug test can be used to test whether the router has any faults. If a router passes a hardware loopback plug test, then the problem exists elsewhere on the line. Use wire cutters to cut a working RJ or RJ cable so that there are five inches of cable and the connector is attached to it.
Pin 1 is the left-most pin when looking at the jack with the metal pins facing you. If the interface does not have an IP address, obtain a unique address and assign it to the interface with a subnet mask of Perform the extended ping test as described in the "Using Extended ping Tests," section earlier in this chapter. This section describes the techniques and procedures for troubleshooting E1 circuits for dial-in customers. Issue a show controller e1 command to display statistics about the E1 link.
If you specify a slot and port number, statistics for each 15 minute period will be displayed. The show controller e1 EXEC command provides information to logically troubleshoot physical layer and data link layer problems.
This section describes how to logically troubleshoot using the show controller e1 command. Most E1 errors are caused by misconfigured lines.
Ensure that linecoding, framing, clock source and line termination balanced or unbalanced are configured according to what the service provider recommends. If the E1 line is not up, check to see that the line configuration is correct and matches the settings of the remote end. Check the framing of the line and the remote end. Consult your service provider for more information regarding the correct settings.
Make any changes as necessary to both local or remote end-devices. If the E1 controller and line are not up, check to see if one of the following messages appears in the show controller e1 EXEC output:.
You can check the framing format of the controller from the running configuration or the show controller e1 command output.
Make sure that the cable between the interface port and the E1 service provider's equipment or E1 terminal equipment is connected correctly. Refer to the following figure for more information. Check to see if there are far-end block errors. If so, the problem exists with the receive lead on the local end. Contact the TAC for more assistance. Run the show controller e1 EXEC command after each step to check if the controller exhibits any errors.
Check to see if the line is in loopback mode from the show controller e1 output. A received remote alarm means there is an alarm occurring on the line upstream of the equipment connected to the port. Check the linecoding setting on the remote-end equipment. Contact your service provider for the correct settings. Correct any misconfigurations as necessary. To create a loopback plug, see the section "Performing Hardware Loopback Plug Test," earlier in the chapter. Connect the E1 line to a different port.
Perform a hardware loop test as described in the section "Performing Hardware loopback Plug Test". If the problem does not persist, then the fault lies with the one port. The show controller e1 EXEC command provides error messages that can be used to troubleshoot problems. To see if the error counters are increasing, execute the show controller e1 command repeatedly.
The presence of slips on E1 lines indicates a clocking problem. Note: If there are multiple E1s in an access server, only one can be the primary, while the other E1s derive the clock from the primary. In that case, verify that the E1 line designated as the primary clock source is configured correctly.
If the interface is not using PPP, then use the encapsulation ppp command in the interface configuration mode to correct it. When troubleshooting a PRI, you need to determine if the E1 is running cleanly on both ends. If Layer 1 problems have been resolved as described above, consider Layer 2 and Layer 3 problems. Also verify that the E1 is not administratively down. Use the no shutdown command to bring the E1 controller up. Use the debug isdn q command to verify that Layer 2 is stable. The debug isdn q command displays data link layer Layer 2 access procedures that are taking place at the router on the D-channel.
Verify that Layer 2 is stable. If Layer 2 does not appear to be stable, see "Troubleshooting E1 Error Events," earlier in this chapter.
If not use the encapsulation ppp command to set encapsulation. Contents Introduction. Troubleshooting Using the show interfaces serial Command. Serial Lines: show interfaces serial Status Line Conditions. Detailed Information on the show interfaces serial Command.
Troubleshooting Using the show controller t1 Command. Troubleshooting Using the show controller e1 Command. Serial x is up, line protocol is up. This is the proper status line condition. No action required. Serial x is down, line protocol is down DTE mode. Typically indicates that the router is not sensing a CD signal that is, CD is not active. Verify that you are using the proper cable and interface see your hardware installation documentation. Insert a breakout box and check all control leads.
Contact your leased-line or other carrier service to see if there is a problem. Swap faulty parts. If you suspect faulty router hardware, change the serial line to another port. If the connection comes up, the previously connected interface has a problem. Serial x is up, line protocol is down DTE mode. Put the modem, CSU, or DSU in local loopback mode and use the show interfaces serial command to see if the line protocol comes up.
If the line protocol comes up, a telephone company problem or a failed remote router is the likely problem. Verify all cabling. Use the show controllers EXEC command to determine which cable is attached to which interface. Enable the debug serial interface EXEC command. If the line protocol does not come up in local loopback mode and if the output of the debug serial interface EXEC command shows that the keepalive counter is not incrementing, a router hardware problem is likely.
Swap router interface hardware. If the line protocol comes up and the keepalive counter increments, the problem is not in the local router. If you suspect faulty router hardware, change the serial line to an unused port. Serial x is up, line protocol is down DCE mode. Add the clockrate interface configuration command on the serial interface.
Syntax: clock rate bps Syntax Description: bps -Desired clock rate in bits per second: , , , , , , , , , , , , , , , , , , or See the section "Inverting the Transmit Clock," later in this chapter.
Verify that the correct cable is being used. If the line protocol is still down, there is a possible hardware failure or cabling problem. Insert a breakout box and observe leads. Replace faulty parts as necessary. Serial x is up, line protocol is up looped. A loop exists in the circuit. The sequence number in the keepalive packet changes to a random number when a loop is initially detected.
If the same random number is returned over the link, a loop exists. Use the show running-config privileged EXEC command to look for any loopback interface configuration command entries.
If you find a loopback interface configuration command entry, use the no loopback interface configuration command to remove the loop. If they are, disable manual loopback. If the line protocol comes up, no other action is needed. If the CSU or DSU is not configured in manual loopback mode, contact the leased-line or other carrier service for line troubleshooting assistance.
Serial x is up, line protocol is down disabled. Troubleshoot the line with a serial analyzer and breakout box. If the problem continues, it is likely that there is a hardware problem. If the problem does not continue, it is likely that there is a telephone company problem. Serial x is administratively down, line protocol is down. Router configuration includes the shutdown interface configuration command Duplicate IP address.
Check the router configuration for the shutdown command. Use the no shutdown interface configuration command to remove the shutdown command. If there are duplicate addresses, resolve the conflict by changing one of the IP addresses. Input rate to serial interface exceeds bandwidth available on serial link.
Minimize periodic broadcast traffic such as routing and SAP updates by using access lists or by other means. For example, to increase the delay between SAP updates, use the ipx sap-interval interface configuration command. Increase the output hold queue size in small increments for instance, 25 percent , using the hold-queue out interface configuration command.
On affected interfaces, turn off fast switching for heavily used protocols. For example, to turn off IP fast switching, enter the no ip route-cache interface configuration command. For the command syntax for other protocols, consult the Cisco IOS configuration guides and command references.
Implement priority queuing on slower serial links by configuring priority lists. For information on configuring priority lists, see the Cisco IOS configuration guides and command references. Input rate exceeds the capacity of the router or input queues exceed the size of output queues. Increase the output queue size on common destination interfaces for the interface that is dropping packets.
Use the hold-queue out interface configuration command. Increase these queues by small increments for instance, 25percent until you no longer see drops in the show interfaces output.
Reduce the input queue size, using the hold-queue in interface configuration command, to force input drops to become output drops. Output drops have less impact on the performance of the router than do input drops.
The default input hold queue is 75 packets. Use a serial analyzer to isolate the source of the input errors. If you detect errors, it is likely that there is a hardware problem or a clock mismatch in a device that is external to the router. Use the loopback and ping tests to isolate the specific problem source. Look for patterns. For example, if errors occur at a consistent interval, they could be related to a periodic function such as the sending of routing updates. Ensure that the line is clean enough for transmission requirements.
Shield the cable if necessary. Make sure the cable is within the recommended length-no more than 50 feet Ensure that all devices are properly configured for a common line clock. Contact your leased-line or other carrier service and have it perform integrity tests on the line.
A framing error occurs when a packet does not end on an 8-bit byte boundary for one of the following reasons: Noisy serial line Improperly designed cable; serial cable is too long; the cable from the CSU or DSU to the router is not shielded SCTE mode is not enabled on the DSU; the CSU line clock is incorrectly configured; one of the clocks is configured for local clocking Ones density problem on T1 link incorrect framing or coding specification.
Make certain you are using the correct cable. Ensure that all devices are properly configured to use a common line clock.
Aborts indicate an illegal sequence of one bits more than seven in a row. Make certain the cable is within the recommended length-no more than 50 feet Ensure that all connections are good.
Check the hardware at both ends of the link. Lower data rates and see if aborts decrease. Use local and remote loopback tests to determine where aborts are occurring. See the section "Special Serial Line Tests," later in this chapter. When interface resets are occurring, examine other fields of the show interfaces serial command output to determine the source of the problem. Step 3 Use the show interfaces serial exec command, and determine whether input errors counts are increasing and where they are accumulating.
If input errors are accumulating on both ends of the connection, clocking of the CSU is the most likely problem. If only one end is experiencing input errors, there is probably a DSU clocking or cabling problem. Aborts on one end suggest that the other end is sending bad information or that there is a line problem.
Note Always refer to the show interfaces serial command output see Figure Log any changes in error counts, or note if the error count does not change. Table outlines suggested remedies for clocking problems, based on the source of the problem. Determine whether the CSUs at both ends agree on the clock source local or line.
If the CSUs do not agree, configure them so that they do agree usually the line is the source. If SCTE is not enabled on both ends of the connection, enable it. For any interface that is connected to a line of kbps or faster, SCTE must be enabled. Make sure that ones density is maintained. Check with your leased-line provider for information on its framing and coding schemes. If your carrier service uses AMI coding, either invert the transmit clock on both sides of the link, or run the DSU in bit-stuff mode.
Inverting the transmit clock compensates for phase shifts between the data and clock signals. The specific command used to invert the transmit clock varies between platforms. On a Cisco series router, enter the invert-transmit-clock interface configuration command.
For Cisco series routers, use the dte-invert-txc interface configuration command. To ensure that you are using the correct command syntax for your router, refer to the user guide for your router or access server and to the Cisco IOS configuration guides and command references.
Note On older platforms, inverting the transmit clock might require that you move a physical jumper. Excessively high bandwidth utilization greater than 70 percent results in reduced overall performance and can cause intermittent failures.
For example, DECnet file transmissions might be failing because of packets being dropped somewhere in the network. If the situation is bad enough, you must increase the bandwidth of the link. However, increasing the bandwidth might not be necessary or immediately practical. One way to resolve marginal serial line overutilization problems is to control how the router uses data buffers.
The configuration commands associated with these options are described in the Cisco IOS configuration guides and command references. There are two general buffer types on Cisco routers: hardware buffers and system buffers. Only the system buffers are directly configurable by system administrators. The hardware buffers are specifically used as the receive and transmit buffers associated with each interface and in the absence of any special configuration are dynamically managed by the system software itself.
The system buffers are associated with the main system memory and are allocated to different-size memory blocks. A useful command for determining the status of your system buffers is the show buffers exec command. Figure shows the output from the show buffers command.
In the show buffers output, the following is true:. These buffers are always in the pool and cannot be trimmed away. The hits counter provides a mechanism for determining which pool must meet the highest demand for buffers. In other words, the number of buffers in the free list has dropped below min. The misses counter represents the number of times that the RP has been forced to create additional buffers. The RP creates buffers when demand for buffers has increased until the number of buffers in the free list is less than min buffers or a miss occurs because of zero buffers in the free list.
The number of failures represents the number of packets that have been dropped due to buffer shortage. The show buffers command output in Figure indicates high numbers in the Trims and Created fields for large buffers. If you are receiving high numbers in these fields, you can increase your serial link performance by increasing the max free value configured for your system buffers.
Use the buffers max free number global configuration command to increase the number of free system buffers. The value that you configure should be approximately percent of the figure indicated in the total field of the show buffers command output. Repeat this process until the show buffers output no longer indicates trims and created buffers.
If the show buffers command output shows a large number of failures in the no memory field see the last line of output in Figure , you must reduce the usage of the system buffers or increase the amount of shared or main memory physical RAM on the router. Call your technical support representative for assistance.
Hold queues are buffers used by each router interface to store outgoing or incoming packets. Use the hold-queue interface configuration command to increase the number of data packets queued before the router will drop packets. Note The hold-queue command is used for process-switched packets and periodic updates generated by the router.
Use the hold-queue command to prevent packets from being dropped and to improve serial link performance under the following conditions:. DECnet is an example of a protocol that meets both criteria.
Local-area transport LAT does not meet this criteria because it does not tolerate delays. Note When you increase the number specified for an output hold queue, you might need to increase the number of system buffers.
The value used depends on the size of the packets associated with the traffic anticipated for the network. Priority queuing is a list-based control mechanism that allows traffic to be prioritized on an interface-by-interface basis. Priority queuing involves two steps:. Step 1 Create a priority list by protocol type and level of priority. Step 2 Assign the priority list to a specific interface. Both of these steps use versions of the priority-list global configuration command.
In addition, further traffic control can be applied by referencing access-list global configuration commands from priority-list specifications. For examples of defining priority lists and for details about command syntax associated with priority queuing, refer to the Cisco IOS configuration guides and command references. Note Priority queuing automatically creates four hold queues of varying size.
This overrides any hold queue specification included in your configuration. Use priority queuing to prevent packets from being dropped and to improve serial link performance under the following conditions:. In general, start with the default number of queues when implementing priority queues. After enabling priority queuing, monitor output drops with the show interfaces serial exec command.
If you notice that output drops are occurring in the traffic queue that you have specified to be high priority, increase the number of packets that can be queued using the queue-limit keyword option of the priority-list global configuration command. The default queue-limit arguments are 20 packets for the high-priority queue, 40 for medium, 60 for normal, and 80 for low.
A high-priority queue depth of about specified with the queue-limit keyword is a typical working value when your router is dropping output packets and the serial lines are subjected to about 50 percent bandwidth utilization. If the router is dropping packets and is at percent utilization, you need another line. You can implement LAT compression with the interface configuration command bridge-group group lat-compression. In addition to the basic diagnostic capabilities available on routers, a variety of supplemental tools and techniques can be used to determine the conditions of cables, switching equipment, modems, hosts, and remote internetworking hardware.
Perform the local loop test first, and then perform the remote test. Because there is no concept of a loopback in X. Following is a general procedure for performing loopback tests in conjunction with built-in system diagnostic capabilities:.
In local loop mode, the use of the line clock from the T1 service is terminated, and the DSU is forced to use the local clock. Step 2 Use the show interfaces serial exec command to determine whether the line status changes from "line protocol is down" to "line protocol is up looped ," or whether it remains down. Step 3 If the line protocol comes up when the CSU or DSU is in local loopback mode, this suggests that the problem is occurring on the remote end of the serial connection.
Step 4 If the problem appears to be local, use the debug serial interface privileged exec command. When the line protocol is down, the debug serial interface command output will indicate that keepalive counters are not incrementing. This should cause the keepalive packets to begin to increment.
Specifically, the values for mineseen and yourseen keepalives will increment every 10 seconds. This information will appear in the debug serial interface output. If the keepalives do not increment, there may be a timing problem on the interface card or on the network.
For information on correcting timing problems, refer to the section "Troubleshooting Clocking Problems," earlier in this chapter. Make certain that the cables are within the recommended lengths no more than 50 feet [ Make certain that the cables are attached to the proper ports. Figure shows the output from the debug serial interface command for an HDLC serial connection, with missed keepalives causing the line to go down and the interface to reset.
If you determine that the local hardware is functioning properly, but you still encounter problems when attempting to establish connections over the serial link, try using the remote loopback test to isolate the problem's cause. Note This remote loopback test assumes that HDLC encapsulation is being used and that the preceding local loop test was performed immediately before this test. Step 2 Using the show interfaces serial exec command, determine whether the line protocol remains up, with the status line indicating "Serial x is up, line protocol is up looped ," or goes down, with the status line indicating "line protocol is down.
Perform both local and remote tests at the remote end to isolate the problem source. Step 4 If the line status changes to "line protocol is down" when remote loopback mode is activated, make certain that ones density is being properly maintained. This section covers the show interfaces serial command's parameters, syntax description, sample output display, and field descriptions.
To display information about a serial interface, use the show interfaces serial privileged exec command:. T1 channels on the CT3IP are numbered 1 to 28 rather than the more traditional zero-based scheme 0 to 27 used with other Cisco products.
This is to ensure consistency with telco numbering schemes for T1 channels within channelized T3 equipment. The following is sample output from the show interfaces command for a synchronous serial interface:.
Table describes significant fields shown in the output. Indicates whether the interface hardware is currently active whether carrier detect is present or whether it has been taken down by an administrator.
Indicates whether the software processes that handle the line protocol consider the line usable that is, whether keepalives are successful , or whether it has been taken down by an administrator. Indicates the value of the bandwidth parameter that has been configured for the interface in kilobits per second. The bandwidth parameter is used to compute IGRP metrics only. If the interface is attached to a serial line with a line speed that does not match the default or for T1, and 56 for a standard synchronous serial line , use the bandwidth command to specify the correct line speed for this serial line.
Gives the number of hours, minutes, and seconds since the last packet was successfully received by an interface. Useful for knowing when a dead interface failed.
Gives the number of hours, minutes, and seconds since the last packet was successfully transmitted by an interface. Gives the number of hours, minutes, and seconds or never since the interface was last reset because of a transmission that took too long. When the number of hours in any of the last fields exceeds 24, the number of days and hours is printed.
If that field overflows, asterisks are printed. Gives the number of packets in output and input queues. Each number is followed by a slash, the maximum size of the queue, and the number of packets because the queue is full. Gives the average number of bits and packets transmitted per second in the past 5 minutes. The 5-minute input and output rates should be used only as an approximation of traffic per second during a given 5-minute period.
These rates are exponentially weighted averages with a time constant of 5 minutes. A period of four time constants must pass before the average will be within 2 percent of the instantaneous rate of a uniform stream of traffic over that period.
Gives the total number of bytes, including data and MAC encapsulation, in the error-free packets received by the system. Gives the number of received packets discarded because there was no buffer space in the main system. Compare with ignored count. Broadcast storms on Ethernet networks and bursts of noise on serial lines are often responsible for no input buffer events. Gives the total number of broadcast or multicast packets received by the interface.
Gives the number of packets that are discarded because they are smaller than the medium's minimum packet size. Gives the number of packets that are discarded because they exceed the medium's maximum packet size.
Gives the total number of no buffer, runts, giants, CRCs, frame, overrun, ignored, and abort counts. Other input-related errors can also increment the count, so this sum might not balance with the other counts. The Cyclic Redundancy Check CRC counter is incremented by the originating station or far-end device when the checksum calculated from the data received does not match the checksum from the transmitted data. On a serial link, CRCs usually indicate noise, gain hits, or other transmission problems on the data link.
Gives the number of packets received incorrectly, having a CRC error and a noninteger number of octets. On a serial line, this is usually the result of noise or other transmission problems.
Gives the number of times that the serial receiver hardware was incapable of handing received data to a hardware buffer because the input rate exceeded the receiver's capability to handle the data. Gives the number of received packets ignored by the interface because the interface hardware ran low on internal buffers. Broadcast storms and bursts of noise can cause the ignored count to be increased.
Indicates an illegal sequence of 1 bit on a serial interface. This usually indicates a clocking problem between the serial interface and the data link equipment. Gives the number of times that the carrier detect signal of a serial interface has changed state. For example, if data carrier detect DCD goes down and comes up, the carrier transition counter will increment two times. This indicates modem or line problems if the carrier detect line is changing state often.
Gives the total number of bytes, including data and MAC encapsulation, transmitted by the system. Gives the number of times that the transmitter has been running faster than the router can handle. This might never be reported on some interfaces. Gives the sum of all errors that prevented the final transmission of datagrams out of the interface being examined.
Note that this might not balance with the sum of the enumerated output errors because some datagrams can have more than one error, and others can have errors that do not fall into any of the specifically tabulated categories. Gives the number of messages retransmitted because of an Ethernet collision. This usually is the result of an overextended LAN Ethernet or transceiver cable too long, more than two repeaters between stations, or too many cascaded multiport transceivers.
Some collisions are normal. However, if your collision rate climbs to around 4 percent or 5 percent, you should consider verifying that there is no faulty equipment on the segment, or moving some existing stations to a new segment. A packet that collides is counted only once in output packets. Gives the number of times that an interface has been completely reset. This can happen if packets queued for transmission were not sent within several seconds. On a serial line, this can be caused by a malfunctioning modem that is not supplying the transmit clock signal, or by a cable problem.
If the system notices that the carrier detect line of a serial interface is up but the line protocol is down, it periodically resets the interface in an effort to restart it. Interface resets can also occur when an interface is looped back or shut down. Gives the number of times that the controller was restarted because of errors. Shows the status of G. This section describes the techniques and procedures to troubleshoot T1 circuits for dial-in customers.
The show controller t1 exec command provides information to logically troubleshoot physical layer and data link layer problems. This section describes how to logically troubleshoot using the show controller t1 command.
This command displays the controller status that is specific to the controller hardware. The information displayed is generally useful for diagnostic tasks performed by technical support personnel. Issue a show controller t1 command to display statistics about the T1 link. If you specify a slot and port number, statistics for each minute period will be displayed.
Most T1 errors are caused by misconfigured lines. Ensure that linecoding, framing, and clock source are configured according to what the service provider recommends.
The controller is administratively down when it has been manually shut down. You should restart the controller to correct this error. Step 1 Enter enable mode. Step 2 Enter global configuration mode. Step 3 Enter controller configuration mode. Step 4 Restart the controller. If the T1 controller and line are not up, check to see if you are seeing one of the following messages in the show controller t1 exec output:.
Step 1 Check to see whether the framing format configured on the port matches the framing format of the line. You can check the framing format of the controller from the running configuration or the show controller t1 command output. Step 2 Try the other framing format to see if the alarm clears. Line build out LBO compensates for the loss in decibels based on the distance from the device to the first repeater in the circuit.
A longer distance from the device to the repeater requires that the signal strength on the circuit be boosted to compensate for loss over that distance. To configure transmit and receive levels for a cable length line build out longer than feet for a T1 trunk with a channel service unit CSU interface, use the cablelength long controller configuration command.
To configure transmit attenuation for a cable length line build out of feet or shorter for a T1 trunk with a DSX-1 interface, use the cablelength short controller configuration command. Consult your service provider and the Cisco IOS command reference for details on buildout settings.
Step 1 Make sure that the cable between the interface port and the T1 service provider's equipment or T1 terminal equipment is connected correctly. Check to see if the cable is hooked up to the correct ports. Correct the cable connections, if necessary. Step 2 Check cable integrity. Look for breaks or other physical abnormalities in the cable.
Ensure that the pinouts are set correctly. If necessary, replace the cable. Step 3 Check the cable connectors. A reversal of the transmit and receive pairs or an open receive pair can cause errors. Set the receive pair to lines 1 and 2; the transmit pair should be lines 4 and 5. The pins on an RJ jack are numbered from 1 through 8. Pin 1 is the leftmost pin when looking at the jack with the metal pins facing you. Refer to Figure Step 4 Try using a rollover cable.
Run the show controller t1 exec command after each step to see whether the controller exhibits any errors. Check to see whether the line is in loopback mode from the show controller t1 output.
A line should be in loopback mode only for testing purposes. SPD is a mechanism that quickly drops low priority packets when the CPU is overloaded in order to save some processing capacity for high priority packets. The flushes counter in the show interface command output increments as part of selective packet discard SPD , which implements a selective packet drop policy on the IP process queue of the router.
Therefore, it applies to only process switched traffic. The purpose of SPD is to ensure that important control packets, such as routing updates and keepalives, are not dropped when the IP input queue is full. When the size of the IP input queue is between the minimum and maximum thresholds, normal IP packets are dropped based on a certain drop probability.
These random drops are called SPD flushes. Total output drops is the number of packets dropped because the output queue is full. A common cause of this might be traffic from a high bandwidth link being switched to a lower bandwidth link or traffic from multiple inbound links being switched to a single outbound link. For example, if a large amount of bursty traffic comes in on a gigabit interface and is switched out to a Mbps interface, this might cause output drops to increment on the Mbps interface.
This is because the output queue on that interface is overwhelmed by the excess traffic due to the speed mismatch between the inbound and outbound bandwidths. First-in, first-out FIFO queuing is the default queuing strategy that applies to all interfaces with more than 2 Mbps, or, in other words, E1 size or greater interfaces. With the FIFO Queuing strategy, packets are forwarded through the interface in the order that they are received.
The number of packets in the output queue. The average input and output rate seen by the interface in the last five minutes. Packets input: Total number of error-free packets received by the system. Bytes: Total number of bytes, including data and MAC encapsulation, in the error-free packets received by the system.
No buffers: Number of received packets discarded because there was no buffer space in the main system. Compare with ignored count.
Broadcast storms on Ethernet networks and bursts of noise on serial lines are often responsible for no input buffer events. Runts: Number of packets that are discarded because they are smaller than the minimum packet size of the medium. For instance, any Ethernet packet that is less than 64 bytes is considered a runt. Giants: Number of packets that are discarded because they exceed the maximum packet size of the medium.
For example, any Ethernet packet that is greater than bytes is considered a giant. Throttles: the number of times the receiver on the port is disabled , possibly because of buffer or processor overload. Input error: Includes runts, giants, no buffer, CRC, frame, overrun, and ignored counts.
Other input-related errors can also cause the input errors count to be increased, and some datagrams may have more than one error; therefore, this sum may not balance with the sum of enumerated input error counts. CRC: Cyclic redundancy checksum generated by the originating LAN station or far-end device does not match the checksum calculated from the data received. A high number of CRCs is usually the result of collisions or a station transmitting bad data.
Frame: Number of packets received incorrectly having a CRC error and a noninteger number of octets. On a LAN, this is usually the result of collisions or a malfunctioning Ethernet device. Ignored: Number of received packets ignored by the interface because the interface hardware ran low on internal buffers. These buffers are different than the system buffers mentioned previously in the buffer description.
Broadcast storms and bursts of noise can cause the ignored count to be increased. Watchdog: Number of times watchdog receive timer expired. It happens when receiving a packet with length greater than Pause input: Counter incrementing means that the port is receving pause frame. It could be caused by a oversubscription of bandwidth, or a burst traffic pattern.
Dribble bit error indicates that a frame is slightly too long. This frame error counter is incremented just for informational purposes; the router accepts the frame. Packets output: Total number of messages transmitted by the system. Bytes: Total number of bytes, including data and MAC encapsulation, transmitted by the system. Underruns: Number of times that the transmitter has been running faster than the router can handle.
0コメント