12-21-2010 08:26 PM - edited 03-04-2019 10:51 AM
Hi All.
We have two wan channels, both connect to MPLS cisco, go in on direction i.e (City-1 to City-2). On first channel no have problem, but on second from time to time we see CRC errors. It doesn't depends on amount of traffic on this channel. We have replace interface on both side, change Cisco route, even change type of interfece (STM to E1) crc still appear. But when me reconnect this channel to Promina (Frame Ralay Switch) crc not ocur, BER tester also show no errors. On Cisco site I not find any documents about how debug this problem.
show interface output
Serial1/0/0 is up, line protocol is up
Hardware is Serial
MTU 1546 bytes, BW 2048 Kbit, DLY 20000 usec,
reliability 255/255, txload 98/255, rxload 66/255
Encapsulation PPP, LCP Open, multilink Open
Link is a member of Multilink bundle Multilink7, crc 16, loopback not set
Keepalive set (10 sec)
Last input 19:12:41, output 00:00:00, output hang never
Last clearing of "show interface" counters 00:26:27
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: Class-based queueing
Output queue: 0/40 (size/max)
30 second input rate 535000 bits/sec, 350 packets/sec
30 second output rate 793000 bits/sec, 293 packets/sec
628956 packets input, 113297570 bytes, 0 no buffer
Received 0 broadcasts (0 IP multicasts)
0 runts, 0 giants, 0 throttles
346464 input errors, 346753 CRC, 0 frame, 67 overrun, 0 ignored, 28 abort
523299 packets output, 213206488 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 output buffer failures, 0 output buffers swapped out
0 carrier transitions
RTS up, CTS up, DTR up, DCD up, DSR up
Solved! Go to Solution.
12-21-2010 08:59 PM
Hello ,
Look like it is clocking issue.
can you go through below details:
-------------------------------------------------------------------------------------------------------------
To detect clocking conflicts on a serial interface, look for input errors as follows:
Step 1 Use the show interfaces serial exec command on the routers at both ends of the link.
Step 2 Examine the command output for CRC, framing errors, and aborts.
Step 3 If either of these steps indicates errors exceeding an approximate range of 0.5 percent to 2.0 percent of traffic on the interface, clocking problems are likely to exist somewhere in the WAN.
Step 4 Isolate the source of the clocking conflicts, as outlined in the following section, “Isolating Clocking Problems.”
Step 5 Bypass or repair any faulty patch panels.
After you determine that clocking conflicts are the most likely cause of input errors, use the following procedure to isolate the source of those errors:
Step 1 Perform a series of ping tests and loopback tests (both local and remote), as described in the section “CSU and DSU Loopback Tests,” earlier in this chapter.
Step 2 Determine which end of the connection is the source of the problem, or whether the problem is in the line. In local loopback mode, run different patterns and sizes in the ping tests (for example, use 1500-byte datagrams). Using a single pattern and packet size may not force errors to materialize, particularly when a serial cable to the router or CSU/DSU is 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.
Regards
mahesh
12-21-2010 08:59 PM
Hello ,
Look like it is clocking issue.
can you go through below details:
-------------------------------------------------------------------------------------------------------------
To detect clocking conflicts on a serial interface, look for input errors as follows:
Step 1 Use the show interfaces serial exec command on the routers at both ends of the link.
Step 2 Examine the command output for CRC, framing errors, and aborts.
Step 3 If either of these steps indicates errors exceeding an approximate range of 0.5 percent to 2.0 percent of traffic on the interface, clocking problems are likely to exist somewhere in the WAN.
Step 4 Isolate the source of the clocking conflicts, as outlined in the following section, “Isolating Clocking Problems.”
Step 5 Bypass or repair any faulty patch panels.
After you determine that clocking conflicts are the most likely cause of input errors, use the following procedure to isolate the source of those errors:
Step 1 Perform a series of ping tests and loopback tests (both local and remote), as described in the section “CSU and DSU Loopback Tests,” earlier in this chapter.
Step 2 Determine which end of the connection is the source of the problem, or whether the problem is in the line. In local loopback mode, run different patterns and sizes in the ping tests (for example, use 1500-byte datagrams). Using a single pattern and packet size may not force errors to materialize, particularly when a serial cable to the router or CSU/DSU is 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.
Regards
mahesh
12-21-2010 09:57 PM
Ok I try this. But one question remain, why BER Tester show that the channel is clear?
12-21-2010 10:18 PM
Hi,
Well I am not sure where you attached berr tester. But i am sure it is not
behind router like
(Atleast this would not be the case Berr-RTR1--DCE--DCE--RTR2)
and clocking is something between RTR and DCE
Regards
mahesh
12-21-2010 10:40 PM
i would suggest to do loopback test with your ISP/telco provider to isolate which portion is having errors. could you post your show controller serial 1/0/0, show interface multilink7 and show ppp multilink? if loopback tests didn't solve try to re-create your ppp bundled link on this router.
12-22-2010 09:05 PM
Thanks All. Problem is solved. Our DCE not support SCTE, and as suggest Troubleshooting Serial Line Problems from Cisco we set Invert txclock (Inverting the Transmit Clock section). CRC disappear.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide