TDM group 1, line protocol is UP
Encapsulation PPP (ppp 1)
78302830 packets input, 3357028120 bytes, 0 no buffer
0 runts, 0 giants, 0 throttles
294 input errors, 52 CRC, 132 frame
110 abort, 0 discards, 0 overruns
72663688 packets output, 3645450601 bytes, 0 underruns
We use the Cisco 7606 to tie into each T1 for several different locations. I see these TDM errors commonly and they show up on our monitoring system OpManager so depending on how diligent I decide to be my day can be eaten up quickly. The T1 interface has no errors, we're not bundling T1s on these TDM interfaces.
What can cause these? Is there a config change that need to take place or is this just normal operating?
Thanks
If this is a T-1 supplied over a WAN link it isn't really something to worry about, at least not yet. Since counters were cleared you've received input of 3,357,028,120 bytes, or 26,856,224,960 bits. You've taken 294 errors, which is a bit error rate of 1.09 * 10^-9.
If your monitoring system graphs them over time, keep an eye on it to see if the error rate per minute starts to creep up, or if they're bursty. This could indicate wet cable pairs or other outside plant damage. Low levels of errors along these lines are often seen with microwave links. You could play around with line buildout to see if the signal is too hot or to long coming in, but this may require involving the other end to adjust their settings as well.
show interface [if-name] performance will give a history of the last 24 hours in 15-minute intervals which can show bursty errors.
If there's a WAN carrier in the mix, intrusive stress testing may be useful to pinpoint the problem but prepare to have the T-1 down for some time. The carrier puts both ends into loopback and runs a "stressful" pattern of bits for a long time. If errors are noted, then the line is isolated section by section until the trouble is found and then repaired.
At this level of errors I'd just make a note of it and look for trends if it gets worse.
Rhill,
Thanks for posting! I have just a few additional details. First, the general T-1 errors shown just above the TDM section in the output of "show interfaces t1 0/x" are reset periodically. Therefore, as Jay mentioned, it is a good idea to use a command like "show interfaces t1 0/1 performance-statistics total-24-hour" to view all errors in the last 24 hours. Also, the TDM errors are not reset periodically, so these errors may still be in the unit from the time the T-1 interface was initially brought up. It is typical to get TDM framing errors while the clocks are still syncing up.
Thanks!
David
Rhill,
I went ahead and flagged this post as "Assumed Answered". If any of the responses on this thread assisted you, please mark them as Correct or Helpful as the case may be with the applicable buttons. This will make them visible and help other members of the community find solutions more easily. If you still need assistance, I would be more than happy to continue working with you on this - just let me know in a reply.
Thanks!
David
TDM group 2, line protocol is UP
Encapsulation PPP (ppp 2)
23052391 packets input, 640095975 bytes, 6 no buffer
0 runts, 0 giants, 0 throttles
1129 input errors, 132 CRC, 987 frame
4 abort, 0 discards, 0 overruns
26057924 packets output, 2893815818 bytes, 0 underruns
Hi,
I'm getting the same errors. How can I clear these errors, How much errors do I need to have before it's a big deal?
touristsis wrote:
TDM group 2, line protocol is UP
Encapsulation PPP (ppp 2)
23052391 packets input, 640095975 bytes, 6 no buffer
0 runts, 0 giants, 0 throttles
1129 input errors, 132 CRC, 987 frame
4 abort, 0 discards, 0 overruns
26057924 packets output, 2893815818 bytes, 0 underruns
Hi,
I'm getting the same errors. How can I clear these errors, How much errors do I need to have before it's a big deal?
Do a "show interface t1 0/1 performance total" to see the errors in the last 24 hours. If there are slips, then you have a timing issue with the other end, either both are sourcing clock or neither. "show interface t1 0/1 performance" will show errors in the past 24 hours in 15-minute intervals.
If no slips and no errors in the last 24 hours, it may not be worth worrying about.
If this is a PRI to a PBX in the same room and these errors are increasing daily, it might be of concern.
If this is a T1 connected via telco cable to a device across town or across the country, a minor increase in error count is more or less normal. T1 circuits send 1,544,000 bits of data every second. These bits are sent as frames with a checksum. If the checksum doesn't match, that's a CRC error. CRC = Cyclic Redundancy Checksum. If the frame doesn't contain the correct start/end pattern and length, that's a framing error.
If a SONET ring somewhere in the mix switches ends, or a splicer on a pole somewhere touches one of the wires of your T1 with a screwdriver, that will generate an error, or a whole bunch of them. Errors are evaluated as bit error rates. If one in every ten billion bits has an error, that's a bit error rate of 1 in 10 ^10, considered very acceptable. That's about an error every two hours, or 12 per day. If the counters haven't been cleared on the interface in weeks you'll see lots of errors.
Likewise, at 1,544,000 bits per second, if the circuit is down for two seconds because an installer shorted the line accidentally while working on the adjacent pair, you'll rack up a huge number of errors in a very short time. Trying to open a trouble ticket on this will get nowhere, as future tests on the line will show it good.
Do a "clear counter t1 0/1" and look at the interface in 24 hours.
If the error rate is increasing at the rate of hundreds per hour, or the rate of errors is increasing, or it gets worse when it rains, etc. there's a good chance that there is a problem with the physical T1.
Also, always run a ground wire from the screw on the Adtran device to the ground bus used by telco for their entrance gear.