circuit taking errors

cisco steps · ‎10-05-2011

This is a weird connection .. at the present time the Ospf cost on this T3 link is set to 9999 ..as there is an other route that traffic takes... once we change to cost to match the other route and traffic start flowing the links takes errors. put back to 9999 and run stress test w/ /big load there is no single error. the link can stay for days w/ ospf cost of 9999 w/ no errors. the carrier tested the ckt and all is good. any idea dear friends..

Thanks

R1#sho int s1/1
Serial1/1 is up, line protocol is up
Hardware is M2T-T3+ pa
Internet address is 192.168.1.62/30
MTU 4470 bytes, BW 44210 Kbit/sec, DLY 200 usec,
     reliability 255/255, txload 1/255, rxload 1/255
Encapsulation PPP, LCP Open
Open: IPCP, CDPCP, crc 16, loopback not set
Keepalive set (10 sec)
Restart-Delay is 0 secs
Last input 00:00:02, output 00:00:00, output hang never
Last clearing of "show interface" counters 05:03:31
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
     14614 packets input, 4557522 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
              0 parity
     3 input errors, 3 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     15768 packets output, 5059370 bytes, 0 underruns
     0 output errors, 0 applique, 0 interface resets
     0 unknown protocol drops
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions
   rxLOS inactive, rxLOF inactive, rxAIS inactive
   txAIS inactive, rxRAI inactive, txRAI inactive

R1 #sho run int s1/1
Building configuration...

Current configuration : 359 bytes
!
interface Serial1/1
ip address 192.168.1.62 255.255.255.252
ip flow ingress
encapsulation ppp
ip ospf network point-to-point
ip ospf cost 9999
ip ospf hello-interval 3
ip ospf dead-interval 9
dsu bandwidth 44210
framing c-bit
cablelength 10
serial restart-delay 0
end

==============================================================

R2 #sho int s2/0
Serial2/0 is up, line protocol is up
Hardware is M2T-T3+ pa
Internet address is 192.168.1.61/30
MTU 4470 bytes, BW 44210 Kbit/sec, DLY 200 usec,
     reliability 255/255, txload 1/255, rxload 1/255
Encapsulation PPP, LCP Open
Open: IPCP, CDPCP, crc 16, loopback not set
Keepalive set (10 sec)
Restart-Delay is 0 secs
Last input 00:00:02, output 00:00:00, output hang never
Last clearing of "show interface" counters 05:02:29
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
     15727 packets input, 5056126 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
              0 parity
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     14572 packets output, 4554020 bytes, 0 underruns
     0 output errors, 0 applique, 0 interface resets
     0 unknown protocol drops
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions
   rxLOS inactive, rxLOF inactive, rxAIS inactive
   txAIS inactive, rxRAI inactive, txRAI inactive

R2#sho run int s2/0
Building configuration...

Current configuration : 341 bytes
!
interface Serial2/0

ip address 192.168.1.61 255.255.255.252
encapsulation ppp
ip ospf network point-to-point
ip ospf cost 9999
ip ospf hello-interval 3
ip ospf dead-interval 9
dsu bandwidth 44210
framing c-bit
cablelength 10
serial restart-delay 0
end

vmiller · ‎10-05-2011

what kind of errors? input & CRC speak to a physical layer problem (cable/ port)

cisco steps · ‎10-05-2011

4649 input errors, 4530 CRC, 0 frame, 117 overrun, 0 ignored, 2 abort

0 output errors, 0 applique, 0 interface resets

paolo bevilacqua · ‎10-05-2011

You have a faulty circuit, complain to telco.

cisco steps · ‎10-05-2011

Thanks Paolo , there is no way to prove that .. the telco provies a loopback facing both side of the ckt and it comes clean many times. so how I can prove that this is a telco issue/

Thanks all

Leo Laohoo · ‎10-05-2011

there is no way to prove that .. the telco provies a loopback facing both side of the ckt and it comes clean many times

Yes there is. It's called a disruptive end-to-end Bit Error Rate (BER) test. The mere suggestion to the telco by the customer alone can cause shivers in the back of the spine of the telco. Sometimes the request to conduct this test can "uncover" line errors that was once deemed as "clean" by the telco.

Trust Paolo.

cisco steps · ‎10-05-2011

leolaohoo

Thanks , the carrier did the bert test and concluded no errors. and they pointed the finger to the protocol . I do not know what protocol they were talking about. But I agree w/ Paolo and the rest . I just need to find a way to convince them that this is their issue .

Thanks

paolo bevilacqua · ‎10-05-2011

Have the BER test done in front of you.

Loopbak one end, BER tester the other.

Again: make sure you personally observe it .

cisco steps · ‎10-05-2011

Per cisco website BERT test are not supported on T3 link...

http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/bert.html

Is that true ?

paolo bevilacqua · ‎10-06-2011

What we are telling you, use an EXTERNAL T3 tester.

Not the router.

Leo Laohoo · ‎10-05-2011

I've worked with serials for four years. 9 out of 10 complaints about "dirty" line and the telco will always say it's "our" equipment fault. Now before I will continue, during that time (2001 to 2005), the telco I would deal with use software-driven to conduct a quick test. Accuracy of the test is akin to sinking a hole-in-one at St. Andrew's 1st hole on a windy day.

Back to the story: Anyway, I would verify their "findings" by putting our Nortel WAN link into a loop condition and tell the telco to "fire" their test. Guess what their NEXT response is?

My point is: Unless you have something to verify the telco's findings, don't trust their word. The less work for them the more money they make from you. What Paolo has recommended will most-definitely bring accurate results. Loopback at the telco's exchange (the-nearest-exchange-from-your-site and move further away) and a BER hardware at your site.

BER tests, because of the amount of money you throw at the telco, is mostly free. The telco has the obligation to ensure the services they provide to you are within standards. Dirty lines, unfortunately, isn't part of that standard. Whenever you deal with the telco, take down the exact time, date, person you dealt with and the synopsis of the conversation. You will need these information when you escalate or take "action".

vmiller · ‎10-05-2011

Two famous telco quotes."The trouble is leaving here just fine" and "Cleared on Testing"