Pete's Packet

Limitless

Archive for the ‘Other’ Category

« Previous Entries
Next Entries »

Serial lines: Increasing Carrier Transitions Count on Serial Link

Posted by Peter Kurdziel on March 22, 2009

Increasing Carrier Transitions Count on Serial Link

 

Possible Problem

Solution

The following problems can result in this symptom:

•Line interruptions due to an external source (such as physical separation of cabling, red or yellow T1 alarms, or lightning striking somewhere along the network)

•Faulty switch, DSU, or router hardware

1. Check hardware at both ends of the link (attach a breakout box or a serial analyzer, and test to determine the source of problems).

2. If an analyzer or breakout box is incapable of identifying any external problems, check the router hardware.

3. Swap faulty equipment, as necessary.

 

Posted in Other, Troubleshooting | Leave a Comment »

Debug commands that are useful when troubleshooting serial and WAN problems.

Posted by Peter Kurdziel on March 22, 2009

 Following are some debug commands that are useful when troubleshooting serial and WAN problems. More information about the function and output of each of these commands is provided in the Debug Command Reference publication:

•debug serial interface—Verifies whether HDLC keepalive packets are incrementing. If they are not, a possible timing problem exists on the interface card or in the network.

•debug x25 events—Detects X.25 events, such as the opening and closing of switched virtual circuits (SVCs). The resulting cause and diagnostic information is included with the event report.

•debug lapb—Outputs Link Access Procedure, Balanced (LAPB) or Level 2 X.25 information.

•debug arp—Indicates whether the router is sending information about or learning about routers (with ARP packets) on the other side of the WAN cloud. Use this command when some nodes on a TCP/IP network are responding, but others are not.

•debug frame-relay lmi—Obtains Local Management Interface (LMI) information useful for determining whether a Frame Relay switch and a router are sending and receiving LMI packets.

•debug frame-relay events—Determines whether exchanges are occurring between a router and a Frame Relay switch.

•debug ppp negotiation—Shows Point-to-Point Protocol (PPP) packets transmitted during PPP startup, where PPP options are negotiated.

•debug ppp packet—Shows PPP packets being sent and received. This command displays low-level packet dumps.

•debug ppp errors—Shows PPP errors (such as illegal or malformed frames) associated with PPP connection negotiation and operation.

•debug ppp chap—Shows PPP Challenge Handshake Authentication Protocol (CHAP) and Password Authentication Protocol (PAP) packet exchanges.

•debug serial packet—Shows Switched Multimegabit Data Service (SMDS) packets being sent and received. This display also prints error messages to indicate why a packet was not sent or was received erroneously. For SMDS, the command dumps the entire SMDS header and some payload data when an SMDS packet is transmitted or received. 

Posted in Other, Troubleshooting | Leave a Comment »

Serial Lines: Increasing Interface Resets on Serial Link

Posted by Peter Kurdziel on March 22, 2009

Serial Lines: Increasing Interface Resets on Serial Link

 

Possible Problem

Solution

The following problems can result in this symptom:

•Congestion on link (typically associated with output drops)

•Bad line causing CD transitions

•Possible hardware problem at the CSU, DSU, or switch

When interface resets are occurring, examine other fields of the show interfaces serial command output to determine the source of the problem. Assuming that an increase in interface resets is being recorded, examine the following fields:

1. If there is a high number of output drops in the show interfaces serial output, see the section “Serial Lines: Increasing Output Drops on Serial Link,” earlier in this chapter.

2. Check the Carrier Transitions field in the show interfaces serial display. If carrier transitions are high while interface resets are being registered, the problem is likely to be a bad link or a bad CSU or DSU. Contact your leased-line or carrier service, and swap faulty equipment, as necessary.

3. Examine the Input Errors field in the show interfaces serial display. If input errors are high while interface resets are increasing, the problem is probably a bad link or a bad CSU/DSU. Contact your leased-line or other carrier service, and swap faulty equipment, as necessary.

 

Posted in Other, Troubleshooting | Leave a Comment »

Serial Lines: Troubleshooting Serial Line Input Errors

Posted by Peter Kurdziel on March 22, 2009

Serial Lines: Troubleshooting Serial Line Input Errors 

 

Input Error Type
(Field Name)

Possible Problem

Solution

CRC errors (CRC)

CRC errors occur when the CRC calculation does not pass (indicating that data is corrupted) for one of the following reasons:

•The serial line is noisy.

•The serial cable is too long, or the cable from the CSU/DSU to the router is not shielded

•SCTE mode is not enabled on DSU.

1. Ensure that the line is clean enough for transmission requirements. Shield the cable, if necessary.

2. Make sure that the cable is within the recommended length (no more than 50 feet [15.24 meters], or 25 feet [7.62 meters] for a T1 link).

3. Ensure that all devices are properly configured for a common line clock. Set SCTE on the local and remote DSU. If your CSU/DSU does not support SCTE, see the section “Inverting the Transmit Clock,” later in this chapter.

4. Make certain that the local and remote CSU/DSU are configured for the same framing and coding scheme as that used by the leased-line or other carrier service (for example, ESF/B8ZS).

CRC errors (CRC) (continued)

•The CSU line clock is incorrectly configured.

•A ones density problem has occurred on the T1 link (incorrect framing or coding specification).

5. Contact your leased-line or other carrier service, and have it perform integrity tests on the line.

Framing errors (frame)

A framing error occurs when a packet does not end on an 8-bit byte boundary for one of the following reasons:

•The serial line is noisy

•The cable is improperly designed; the 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.

•A ones density problem has occurred on the T1 link (incorrect framing or coding specification).

1. Ensure that the line is clean enough for transmission requirements. Shield the cable, if necessary. Make certain that you are using the correct cable.

2. Make sure that the cable is within the recommended length (no more than 50 feet [15.24 meters], or 25 feet [7.62 meters] for a T1 link).

3. Ensure that all devices are properly configured to use a common line clock. Set SCTE on the local and remote DSU. If your CSU/DSU does not support SCTE, see the section “Inverting the Transmit Clock,” later in this chapter.

4. Make certain that the local and remote CSU/DSU is configured for the same framing and coding scheme as that used by the leased-line or other carrier service (for example, ESF1 /B8ZS2 ).

5. Contact your leased-line or other carrier service, and have it perform integrity tests on the line.

Aborted transmission (abort)

Aborts indicate an illegal sequence of 1 bit (more than seven in a row)

The following are possible reasons for this to occur:

•SCTE mode is not enabled on DSU.

•The CSU line clock is incorrectly configured.

•The serial cable is too long, or the cable from the CSU or DSU to the router is not shielded.

•A ones density problem has occurred on the T1 link (incorrect framing or coding specification).

•A packet terminated in middle of transmission (typical cause is an interface reset or a framing error).

•A hardware problem has occurred (bad circuit, bad CSU/DSU, or bad sending interface on remote router).

1. Ensure that all devices are properly configured to use a common line clock. Set SCTE on the local and remote DSU. If your CSU/DSU does not support SCTE, see the section “Inverting the Transmit Clock,” later in this chapter.

2. Shield the cable, if necessary. Make certain that the cable is within the recommended length (no more than 50 feet [15.24 meters], or 25 feet [7.62 meters] for a T1 link). Ensure that all connections are good.

3. Check the hardware at both ends of the link. Swap faulty equipment, as necessary.

4. Lower data rates and determine whether aborts decrease.

5. Use local and remote loopback tests to determine where aborts are occurring (see the section “Special Serial Line Tests,” later in this chapter).

6. Contact your leased-line or other carrier service, and have it perform integrity tests on the line.

1 ESF = Extended Superframe Format

2 B8ZS = binary eight-zero substitution

Posted in Other, Troubleshooting | Leave a Comment »

Serial lines: Increasing Input Errors in Excess of 1 Percent of Total Interface Traffic

Posted by Peter Kurdziel on March 22, 2009

 Increasing Input Errors in Excess of 1 Percent of Total Interface Traffic

If input errors appear in the show interfaces serial output (refer to Figure 15-1), there are several possible sources of those errors. The most likely sources are summarized in Table 15-4.

Note Any input error value for cyclic redundancy check (CRC) errors, framing errors, or aborts above 1 percent of the total interface traffic suggests some kind of link problem that should be isolated and repaired.

Symptom: Increasing number of input errors in excess of 1 percent of total interface traffic

Table 15-4 Serial Lines: Increasing Input Errors in Excess of 1 Percent of Total Interface Traffic 

Possible Problem

Solution

The following problems can result in this symptom:

•Faulty telephone company equipment

•Noisy serial line

•Incorrect clocking configuration (SCTE not set)

Note: Cisco strongly recommends against the use of data converters when you are connecting a router to a WAN or a serial network.

1. Use a serial analyzer to isolate the source of the input errors. If you detect errors, there likely is a hardware problem or a clock mismatch in a device that is external to the router.

•Incorrect cable or cable that is too long

•Bad cable or connection

•Bad CSU or DSU

•Bad router hardware

•Data converter or other device being used between router and DSU

2. Use the loopback and ping tests to isolate the specific problem source. For more information, see the sections “Using Extended ping Tests” and “CSU and DSU Loopback Tests,” later in this chapter.

3. 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. 

Posted in Other, Troubleshooting | Leave a Comment »

Serial Lines: Increasing Input Drops on Serial Link

Posted by Peter Kurdziel on March 22, 2009

Serial Lines: Increasing Input Drops on Serial Link 

 

Possible Problem

Solution

Input rate exceeds the capacity of the router, or input queues exceed the size of output queues

Note: Input drop problems are typically seen when traffic is being routed between faster interfaces (such as Ethernet, Token Ring, and FDDI1 ) and serial interfaces. When traffic is light, there is no problem. As traffic rates increase, backups start occurring. Routers drop packets during these congested periods.

Input rate exceeds the capacity of the router, or input queues exceed the size of output queues (continued)

1. Increase the output queue size on common destination interfaces for the interface that is dropping packets. Use the hold-queue number out interface configuration command. Increase these queues by small increments (for instance, 25 percent) until you no longer see drops in the show interfaces output. The default output hold queue limit is 100 packets.

2. Reduce the input queue size, using the hold-queue number 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.

1 FDDI = Fiber Distributed Data Interface 

Posted in Other, Troubleshooting | Leave a Comment »

Serial Lines: Increasing Output Drops on Serial Link

Posted by Peter Kurdziel on March 22, 2009

Serial Lines: Increasing Output Drops on Serial Link 

Possible Problem

Solution

Input rate to serial interface exceeds bandwidth available on serial link

1. Minimize periodic broadcast traffic, such as routing and SAP1 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.

Input rate to serial interface exceeds bandwidth available on serial link (continued)

2. Increase the output hold queue size in small increments (for instance, 25 percent), using the hold-queue out interface configuration command.

3. 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.

4. 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.

Note: Output drops are acceptable under certain conditions. For instance, if a link is known to be overused (with no way to remedy the situation), it is often considered preferable to drop packets than to hold them. This is true for protocols that support flow control and can retransmit data (such as TCP/IP and Novell IPX2 ). However, some protocols, such as DECnet and local-area transport, are sensitive to dropped packets and accommodate retransmission poorly, if at all.

1 SAP = Service Advertising Protocol

2 IPX = Internetwork Packet Exchange

Posted in Other, Troubleshooting | Leave a Comment »

show interfaces serial Status Line Conditions

Posted by Peter Kurdziel on March 22, 2009

show interfaces serial Status Line Conditions 

Status Line
Condition

Possible Problem

Solution

Serial x is up, line protocol is up

—

This is the proper status line condition. No action is required.

Serial x is down, line protocol is down (DTE1 mode)

The router is not sensing a CD2 signal (that is, the CD is not active).

A telephone company problem has occurred—line is down or is not connected to CSU3 /DSU4 .

Cabling is faulty or incorrect.

Hardware failure has occurred (CSU/DSU).

1. Check the LEDs on the CSU/DSU to see whether the CD is active, or insert a breakout box on the line to check for the CD signal.

2. Verify that you are using the proper cable and interface (see your hardware installation documentation).

3. Insert a breakout box and check all control leads.

4. Contact your leased-line or other carrier service to see whether there is a problem.

5. Swap faulty parts.

6. 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)

A local or remote router is misconfigured.

Keepalives are not being sent by the remote router.

A leased-line or other carrier service problem has occurred (noisy line or misconfigured or failed switch).

A timing problem has occurred on the cable (SCTE5 not set on CSU/DSU).

A local or remote CSU/DSU has failed.

Router hardware (local or remote) has failed.

1. Put the modem, CSU, or DSU in local loopback mode and use the show interfaces serial command to determine whether the line protocol comes up.

If the line protocol comes up, a telephone company problem or a failed remote router is the likely problem.

2. If the problem appears to be on the remote end, repeat Step 1 on the remote modem, CSU, or DSU.

3. Verify all cabling. Make certain that the cable is attached to the correct interface, the correct CSU/DSU, and the correct telephone company network termination point. Use the show controllers exec command to determine which cable is attached to which interface.

4. Enable the debug serial interface exec command.mmm ,,,,

Serial x is up, line protocol is down (DTE mode) (continued)

  

Caution: Because debugging output is assigned high priority in the CPU process, it can render the system unusable. For this reason, use debug commands only to troubleshoot specific problems or during troubleshooting sessions with Cisco technical support staff. Moreover, it is best to use debug commands during periods of lower network traffic and fewer users. Debugging during these periods decreases the likelihood that increased debug command processing overhead will affect system use.

5. 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.

6. If the line protocol comes up and the keepalive counter increments, the problem is not in the local router. Troubleshoot the serial line, as described in the sections “Troubleshooting Clocking Problems” and “CSU and DSU Loopback Tests,” later in this chapter.

7. If you suspect faulty router hardware, change the serial line to an unused port. If the connection comes up, the previously connected interface has a problem.

Serial x is up, line protocol is down (DCE6 mode)

The clockrate interface configuration command is missing.

The DTE device does not support or is not set up for SCTE mode (terminal timing).

The remote CSU or DSU has failed.

1. Add the clockrate interface configuration command on the serial interface.

Syntax:

clock rate bps

Syntax Description:

•bps—Desired clock rate in bits per second: 1200, 2400, 4800, 9600, 19200, 38400, 56000, 64000, 72000, 125000, 148000, 250000, 500000, 800000, 1000000, 1300000, 2000000, 4000000, or 8000000.

Serial x is up, line protocol is down (DCE mode) (continued)

The clockrate interface configuration command is missing.

The DTE device does not support or is not set up for SCTE mode (terminal timing).

The remote CSU or DSU has failed.

2. Set the DTE device to SCTE modem if possible. If your CSU/DSU does not support SCTE, you might have to disable SCTE on the Cisco router interface. Refer to the section “Inverting the Transmit Clock,” later in this chapter.

3. Verify that the correct cable is being used.

4. If the line protocol is still down, there is a possible hardware failure or cabling problem. Insert a breakout box and observe leads.

5. 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.

1. Use the show running-config privileged exec command to look for any loopback interface configuration command entries.

2. If you find a loopback interface configuration command entry, use the no loopback interface configuration command to remove the loop.

3. If you do not find the loopback interface configuration command, examine the CSU/DSU to determine whether they are configured in manual loopback mode. If they are, disable manual loopback.

4. Reset the CSU or DSU, and inspect the line status. If the line protocol comes up, no other action is needed.

5. 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)

A high error rate has occurred due to a telephone company service problem.

A CSU or DSU hardware problem has occurred.

Router hardware (interface) is bad.

1. Troubleshoot the line with a serial analyzer and breakout box. Look for toggling CTS7 and DSR8 signals.

2. Loop CSU/DSU (DTE loop). 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.

3. Swap out bad hardware, as required (CSU, DSU, switch, local or remote router).

Serial x is administrat-ively down, line protocol is down

The router configuration includes the shutdown interface configuration command.

A duplicate IP address exists.

1. Check the router configuration for the shutdown command.

2. Use the no shutdown interface configuration command to remove the shutdown command.

3. Verify that there are no identical IP addresses using the show running-config privileged exec command or the show interfaces exec command.

4. If there are duplicate addresses, resolve the conflict by changing one of the IP addresses.

1 DTE = data terminal equipment

2 CD = carrier detect

3 CSU = channel service unit

4 DSU = digital service unit

5 SCTE = serial clock transmit external

6 DCE = data circuit-terminating equipment or data communications equipment

7 CTS = clear-to-send

8 DSR = data-set ready

Posted in Other, Uncategorized | Leave a Comment »

CCIE COMMAND MEMORIZER

Posted by Peter Kurdziel on December 19, 2008

For a limited time configureterminal.com is offering all their stuff for a monthly cancel anytime subscription of $9.99.

I went through the EIGRP section quickly. I liked the tool  but have to enter configure terminal was annoying .

I’m looking forward to the working on the other subjects.

Posted in Other, Routing & Switching Lab | Leave a Comment »

not enough space on flash to store vlan database even after squeeze Error on database apply 40: NV storage failure sw1(vlan)#

Posted by Peter Kurdziel on November 20, 2008

When trying to create a vlan in dynamips.

not enough space on flash to store vlan database even after squeeze Error on database apply 40: NV storage failure sw1(vlan)#

“delete flash:vlan.dat”

squeeze or erase flash

Posted in Other | Leave a Comment »

« Previous Entries
Next Entries »
 
Follow

Get every new post delivered to your Inbox.