09-17-2010 11:23 AM - edited 03-04-2019 09:48 AM
I have a T1 connection between two locations. Some while ago we started having latency issues with the lines. when I run a ping from the router to the other routher this is the result I get.
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/8/8 ms
SCFU01#ping 192.168.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.2.2, timeout is 2 seconds:
!!...
Success rate is 40 percent (2/5), round-trip min/avg/max = 8/8/8 ms
SCFU01#ping 192.168.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.2.2, timeout is 2 seconds:
..!!!
Success rate is 60 percent (3/5), round-trip min/avg/max = 8/8/8 ms
SCFU01#ping 192.168.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms
The telco company is telling me that the line was tested for over one hour on several occasions and it is clean, but it was working before fine and I did not change anything on the routers. I replaced the Wic t1 cards in both routers and get the same issue. Below are the router configs.
Router 1
memory-size iomem 25
tdm clock T1 0/0 both export line
tdm clock T1 0/1 both import T1 0/0 internal
voice-card 0
!
ip subnet-zero
!
!
!
!
!
!
!
!
!
!
!
!
no voice hpi capture buffer
no voice hpi capture destination
!
!
!
!
controller T1 0/0
framing esf
linecode b8zs
channel-group 0 timeslots 1-24
no yellow generation
no yellow detection
!
controller T1 0/1
framing esf
linecode b8zs
no yellow generation
no yellow detection
!
!
interface FastEthernet0/0
ip address 192.168.1.30 255.255.255.0
speed auto
!
interface Serial0/0:0
ip address 172.16.254.1 255.255.255.192
encapsulation ppp
!
ip classless
ip route 0.0.0.0 0.0.0.0 192.168.1.32
ip route 192.168.2.0 255.255.255.0 Serial0/0:0
ip route 192.168.3.0 255.255.255.0 Serial0/0:0
no ip http server
!
!
!
!
call rsvp-sync
!
dial-peer cor custom
!
!
!
!
line con 0
login local
transport output pad udptn telnet rlogin
line aux 0
line vty 0 4
login local
transport input telnet
line vty 5 15
login local
transport input telnet
!
end
Router 2
memory-size iomem 25
clock timezone EST -5
clock summer-time EDT recurring
tdm clock T1 0/0 both export line
tdm clock T1 0/1 both import T1 0/0 internal
voice-card 0
!
ip subnet-zero
!
!
!
!
!
!
!
!
!
!
!
!
no voice hpi capture buffer
no voice hpi capture destination
!
!
!
!
controller T1 0/0
framing esf
linecode b8zs
channel-group 0 timeslots 1-24
no yellow generation
no yellow detection
!
controller T1 0/1
framing esf
linecode b8zs
no yellow generation
no yellow detection
!
!
interface FastEthernet0/0
description Data
ip address 192.168.2.2 255.255.255.0
speed auto
!
interface Serial0/0:0
description point-to-point to Elmsford
ip address 172.16.254.2 255.255.255.192
encapsulation ppp
!
ip classless
ip route 0.0.0.0 0.0.0.0 192.168.2.1
ip route 192.168.1.0 255.255.255.0 Serial0/0:0
ip route 192.168.3.0 255.255.255.0 192.168.2.1
no ip http server
!
!
!
!
call rsvp-sync
!
dial-peer cor custom
!
!
!
!
line con 0
login local
transport output pad udptn telnet rlogin
line aux 0
session-timeout 10
login local
modem InOut
modem autoconfigure type mt56k
transport input all
transport output pad udptn telnet rlogin
autohangup
stopbits 1
speed 2400
flowcontrol hardware
line vty 0 4
login local
transport input telnet
line vty 5 15
login local
transport input telnet
!
end
Any help would be really appreciated as I cant figure what the problem is.
Thanks.
09-17-2010 11:44 AM
You need to make sure that when you have your TELCO provider do the testing that you schedule
"intrusive" testing for when you don't need the circuit. This will allow them to do more elaborate testing but will cause an outage on the circuit. You may need to have them show up on-site at each end and perform BERT (Bit Error Rate Testing) on the circuit.
09-17-2010 11:47 AM
All of the above mentioned was done. They tested it several times. I still believe it is a problem with the circuit, but they will not acknowledge that in fact it is the circuit.
09-18-2010 10:33 AM
What is your interface utilization during times of poor performance? Are you seeing errors on the interfaces or controllers? If so what are the errors?
Sometimes point to point T1's require the customer to supply clock on one side. Have you had a clocking conversation with the service provider?
Chris
09-20-2010 10:44 AM
This is what I have
Serial0/0:0 is up, line protocol is up
Hardware is DSX1
Internet address is 172.16.254.1/26
MTU 1500 bytes, BW 1536 Kbit, DLY 20000 usec,
reliability 162/255, txload 1/255, rxload 1/255
Encapsulation PPP, LCP Open
Open: CDPCP, IPCP, loopback not set
Last input 00:00:23, output 00:00:13, output hang never
Last clearing of "show interface" counters 00:12:58
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: weighted fair
Output queue: 0/1000/64/0 (size/max total/threshold/drops)
Conversations 0/2/256 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
Available Bandwidth 1152 kilobits/sec
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
996 packets input, 365979 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
401880 input errors, 42834 CRC, 358138 frame, 0 overrun, 0 ignored, 908 abo
rt
722 packets output, 99160 bytes, 0 underruns
0 output errors, 0 collisions, 8 interface resets
0 output buffer failures, 0 output buffers swapped out
11 carrier transitions
Timeslot(s) Used:1-24, SCC: 0, Transmitter delay is 0 flags
I have clocking set on routers.
tdm clock T1 0/0 both export line
tdm clock T1 0/1 both import T1 0/0 internal
09-20-2010 02:20 PM
Last clearing of "show interface" counters 00:12:58
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: weighted fair
Output queue: 0/1000/64/0 (size/max total/threshold/drops)
Conversations 0/2/256 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
Available Bandwidth 1152 kilobits/sec
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
996 packets input, 365979 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
401880 input errors, 42834 CRC, 358138 frame, 0 overrun, 0 ignored, 908 abo
rt
722 packets output, 99160 bytes, 0 underruns
0 output errors, 0 collisions, 8 interface resets
0 output buffer failures, 0 output buffers swapped out
11 carrier transitions
Timeslot(s) Used:1-24, SCC: 0, Transmitter delay is 0 flags
#################
After 13 minutes there are over 400 thousand input errors. Certainly looks like a circuit issue.
Both routers are configured to pull clock off the line. Ask the service provider if they are providing clock. If they are not at least on of your routers will need to be changed to provide clock.
From the folloiwng link: http://www.cisco.com/en/US/products/hw/routers/ps259/products_tech_note09186a008031a072.shtml
These devices use different commands and terminology for their clocking. In the voice mode of operation, the clocking can be exported (the clock is taken externally from the line or interface), or imported (the clock on a port can be taken from the internal oscillator of the router, or another port or interface).
tdm clock {T1 | E1} slot/port {voice | data | both} export line !--- Issue this command on one line: tdm clock {T1 | E1} slot/port {voice | data | both} import {T1 | E1 | atm | bri | onboard} slot/port {line | internal}
This import and export terminology can be confusing, because the term import seems to suggest that the clocking comes directly from the referenced port or interface, and not from the internal oscillator of the router.
Refer to Clock Configuration for Cisco 1751/1760 Routers for more information.
09-21-2010 06:00 AM
Your CRC's are indicative of a physical problem. You need to replace the cables on your rout
ers and if this doesn't clear the problem up then you need to call your service provider back and have them get out there and do
BERT testing on each end.
09-21-2010 08:42 AM
Echo Jason Bliss on changing the cables b/c of the CRC errors. I go through this ALL the time w/ my provider.
09-21-2010 10:13 AM
Thank you for all your help guys. It was actually the clocking on the routers. I did not realize, nor was I informed that at one point we were provided with clocking and then all the sudden they stoped. Verizon did not inform me of the changes so I figured clocking was correct. I changed it on one of the routers to tdm clock T1 0/0 both import onboard internal and now it works like a charm Thanks again for all your help.
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