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

Posted on 2006-03-28
Last Modified: 2012-06-27
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 -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 -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 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?
Question by:EquityIT
    LVL 14

    Expert Comment

    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.


    Author Comment

    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
      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.
    LVL 14

    Accepted Solution

    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.  

    LVL 14

    Expert Comment

    Hi EquityIT,

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


    Write Comment

    Please enter a first name

    Please enter a last name

    We will never share this with anyone.

    Featured Post

    Highfive Gives IT Their Time Back

    Highfive is so simple that setting up every meeting room takes just minutes and every employee will be able to start or join a call from any room with ease. Never be called into a meeting just to get it started again. This is how video conferencing should work!

    Hello , This is a short article on how would you go about enabling traceoptions on a Juniper router . Traceoptions are similar to Cisco debug commands but these traceoptions are implemented in Juniper networks router . The following demonstr…
    Quality of Service (QoS) options are nearly endless when it comes to networks today. This article is merely one example of how it can be handled in a hub-n-spoke design using a 3-tier configuration.
    After creating this article (, I decided to make a video (no audio) to show you how to configure the routers and run some trace routes and pings between the 7 sites…
    After creating this article (, I decided to make a video (no audio) to show you how to configure the routers and run some trace routes and pings between the 7 sites…

    737 members asked questions and received personalized solutions in the past 7 days.

    Join the community of 500,000 technology professionals and ask your questions.

    Join & Ask a Question

    Need Help in Real-Time?

    Connect with top rated Experts

    18 Experts available now in Live!

    Get 1:1 Help Now