• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 634
  • Last Modified:

Intermittent ping timeouts/high ms times. Related to clock rates?

I have 12 branches all connect to my server building via Point to Point T1 in a terminal server environment. From my servers I can ping all of my branches and they come back with times of ~5ms on average, except for one of them. When I run a 'ping 192.168.206.1 -t' (problematic branch) about 1 in every 15 pings is either a timeout or 1200ms - 1700ms, the other 14 are ~7ms. I'm running 2 Cisco 2600's going out to CSU/DSU's then to Cisco 1720's at the branches with CSU/DSU cards.

The reason why I think its the clock rates is because I had that Gilbert branch (192.168.206.X) go down, I thought it was Quest, they proved me wrong, so then I changed the interface on the router, and then the connection worked for 5 days. Then the connection went down again, I called Quest, once again they couldn't loop-back my CSU/DSU on the server side. So then I changed out the CSU/DSU on then server side and the interface on one of the 2600's again, the connection still didn't work, properly. I started another 'ping 192.168.206.1 -t' from the server, 1 in every 15 pings came back successful, then other 14 failed :-\. I then started messing with the clock rates on the interface that connects to that branch, they started improving but still not perfect. Then I set the CSU/DSU (The one that goes out to 192.168.206.1) Clock Rate to 'Internal' from 'Network' and it worked, but still with intermittent ping issues, 1 in every 15 fails, 14 successful.

Could someone point me in the right direction? I wouldn't be too worried about it but my users at that branch are complaining because it is very laggy for them, while typing they have to stop and let the computer catch up. Again, they are the only branch experiencing this problem, while sharing terminal servers with other branches. Also, if someone can tell me why this happened to the first interface card in the first place?
0
EquityIT
Asked:
EquityIT
  • 3
1 Solution
 
ECNSSMTCommented:
If you don't mind, can you provide Telco's reasoning that the issue is on your side?  How did they prove out their network to your demarc?

And if there is something wrong with YOUR CSU/DSU (is it a racal or northern?), can Quest supply something to test on your side for 24 hrs?

If you do a "show interface" on the suspect port; what do you get?

The issue still seems to be a toss-up between the CSU/DSU and telco.  At least as fair as I can think, given the above info.

In terms of trouble shooting steps.
1. present the above info from telco, so that it can be proved out at least history wise.
2. I am assuming that the circuit is still down. Schedule testing with telco using their "known good" CSU/DSU.  Loopback and pattern testing (that will take about 24hrs)
3. Test out the "defectice 2600 card".  Your call on how to do it; I am kinda hesitant to even suggest testing it out on a good circuit as there is a potential that the "bad card" can damage something else.

Regards,
0
 
EquityITAuthor Commented:
Quest sent a tech out after me telling them the problem was not our equipment. I told him to test the line from the biscuit in our suite, I was right there when he did it and from there he was able to get a good outbound connection, I even had him check the cat5 that goes to the CSU/DSU. I'll have to give them another call and see if they can test further or if they can provide testing equipment.

Also, I changed out the CSU/DSU with a known good unit from another office with a good connect. The connection didn't come backup until I changed the clock source to internal. And if I set it to 'network' the connect drops again.

This is what the 'sh int ser1/3' shows:
--------------------------------------------------------------
Equity_Corp_2#sh int ser1/3
Serial1/3 is up, line protocol is up
  Hardware is DSCC4 Serial
  Description: Gilbert Point to Point
  Internet address is 192.168.0.21/30
  MTU 1500 bytes, BW 2048 Kbit, DLY 20000 usec,
     reliability 255/255, txload 4/255, rxload 2/255
  Encapsulation HDLC, loopback not set
  Keepalive set (10 sec)
  Last input 00:00:00, output 00:00:01, output hang never
  Last clearing of "show interface" counters never
  Queueing strategy: fifo
  Output queue 0/40, 25 drops; input queue 0/75, 0 drops
  5 minute input rate 17000 bits/sec, 19 packets/sec
  5 minute output rate 40000 bits/sec, 21 packets/sec
     3600002 packets input, 341410771 bytes, 0 no buffer
     Received 145948 broadcasts, 0 runts, 13 giants, 0 throttles
     326139 input errors, 30207 CRC, 295927 frame, 0 overrun, 0 ignored, 5 abort
     4116943 packets output, 2119607776 bytes, 0 underruns
     0 output errors, 0 collisions, 5094 interface resets
     0 output buffer failures, 0 output buffers swapped out
     103 carrier transitions
     DCD=up  DSR=up  DTR=up  RTS=up  CTS=up
--------------------------------------------------------------
The number of 'input errors' is high. I assume that has to do with this same 'clock rate' problem.
0
 
ECNSSMTCommented:
I can't see your equipment needing to create the clock rate.  I've always seen it generated by DTE equipment(telecoms).  The only time when the site equipment generates a clock signal is when you have 2 routers hooked up together via serial ports.  
Also you shouldn't have to be reconfiguring those CSU/DSUs.  
Next thing, test telco from end to end.  Demarc of your near site to demarc of your distant site.

Also what ever is coming in  10 percent of it is bad from the looks.  and why you have 13 oversized packets I'm not too sure.
and carrier went up and down 103 times. CURIOUS (in a neutral manner).

I guess just have them send a pattern from telco to you for 24 hrs and when ever you feel like have them test end to end.  Let them prove out their end and ensure that when there is a load on the circuit, circuit is good.  

Regards
0
 
ECNSSMTCommented:
Hi EquityIT,

I hate to ask, but I am very curious about the ultimate cause and solution.

Regards,
0

Featured Post

VIDEO: THE CONCERTO CLOUD FOR HEALTHCARE

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now