?
Solved

PPP Connection from Atlanta to Charlotte drops daily

Posted on 2005-04-25
9
Medium Priority
?
255 Views
Last Modified: 2010-04-10
We have a ppp connection from Atlanta to Charlotte provided by USLec that loses connection daily.  I've switched out the WIC card and Serial card for the PPP interface on the Atlanta router in hopes it would correct the problem.  I no longer think this is hardware related but more of a configuration issue. I need help in auditing our router scripts to determine the problem.  Here is the scenario:

4/15/2005 :  Atlanta router configuration script lost.  Not sure of cause.  Rebuild script pretty close to what we had previously.

4/16/2005:  Atlanta to Charlotte PPP dropped.  Atlanta T1 Internet fine.  

4/17/2005 – 4/20/2005:  Atlanta to Charlotte PPP drops every 9 hours.  We power down both routers, power charlotte router back up first then power Atlanta router.  We average 3 attempts to keep the connection.  The first 2 attempts the connection drops within 2-3 minutes.

4/20/2005 evening:  Removed Atlanta WIC card with Serial Interface 1/0, this is the PPP WIC.  Replaced WIC with a brand new WIC.  PPP Connection down.

4/21/2005:  Reset both routers at 7:20am. PPP Connection stays up for about 16-18 hours.  

4/22/2005:  7:30am  Shut down the Atlanta router and had to reboot the Charlotte router.  After Charlotte came up, booted up Atlanta.  Circuit stay up about 2 to 3 minutes.7:45  I had remote employee reboot the Charlotte router and it came up and the circuit has been up since that time.  

4/22/2005 evening:  5:15pm.  Connection drops again, purchase new serial interface card swap out old one in Atlanta router.  Connection comes right back up, things start to look good.

4/23/2005:  Connection drops again.

4/25:2005:  Ready to blow up the router.

 
Throughout this entire problem the Atlanta Internet Connection is just fine.  It has not dropped or given us any problems.  
0
Comment
Question by:capraez
  • 4
  • 2
6 Comments
 

Author Comment

by:capraez
ID: 13858700
Router scripts available upon request.
0
 
LVL 79

Expert Comment

by:lrmoore
ID: 13859432
Sounds like a circuit timing issue. If this is p2p T1, then one end should be providing clocking.
Do you have this on one end?

   interface serial 1/0
    service-module T1 clock source internal

The other end should be default clock source line, which won't show up in the config...

Do you have any error counts with "show interface serial 1/0"
0
 

Author Comment

by:capraez
ID: 13860524
I set the Atlanta router to:

service-module t1 clock source internal

I set the Charlotte router to:

service-module t1 clock source line

After doing that we could not get the routers to communicate.  We rebooted the atlanta router first then rebooted charlotte router.  They still would not synch up.  

I then tried the following settings:

Atlanta:  service-module t1 clock line
Charlotte:  service-module t1 clock internal

The line came back up immediately without rebooting.  This is working for right now.  I cleared the counters on both ends and waited 10 minutes and received no errors on either side.  

The weird part is when I do a "show clock detail" on either router it displays:  "no time source"

I'm also monitoring an extending ping from atlanta to charlotte.  the reply times are <10ms sometimes and then jump from 15ms to 16ms back to <10ms.  We'll see how long this will hold up.
0
Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

 

Author Comment

by:capraez
ID: 13860628
Below is the detail of the clocks:

Atlanta Router:
corp-rou#sho clock detail
01:54:06.911 UTC Mon Apr 25 2005
Time source is user configuration

Charlotte Router:
CHAR-ROU#sho clock detail
*00:55:14.011 UTC Mon Mar 1 1993
0
 

Author Comment

by:capraez
ID: 13860678
This is what the extended ping looks like:

Reply from 10.10.40.1: bytes=32 time<10ms TTL=254
Reply from 10.10.40.1: bytes=32 time<10ms TTL=254
Reply from 10.10.40.1: bytes=32 time<10ms TTL=254
Reply from 10.10.40.1: bytes=32 time<10ms TTL=254
Reply from 10.10.40.1: bytes=32 time<10ms TTL=254
Reply from 10.10.40.1: bytes=32 time<10ms TTL=254
Reply from 10.10.40.1: bytes=32 time<10ms TTL=254
Reply from 10.10.40.1: bytes=32 time=16ms TTL=254
Reply from 10.10.40.1: bytes=32 time=16ms TTL=254
Reply from 10.10.40.1: bytes=32 time<10ms TTL=254
Reply from 10.10.40.1: bytes=32 time<10ms TTL=254
Reply from 10.10.40.1: bytes=32 time<10ms TTL=254
Reply from 10.10.40.1: bytes=32 time<10ms TTL=254
Reply from 10.10.40.1: bytes=32 time<10ms TTL=254
Reply from 10.10.40.1: bytes=32 time<10ms TTL=254
Reply from 10.10.40.1: bytes=32 time<10ms TTL=254
Reply from 10.10.40.1: bytes=32 time<10ms TTL=254
Reply from 10.10.40.1: bytes=32 time=16ms TTL=254
Reply from 10.10.40.1: bytes=32 time=16ms TTL=254
Reply from 10.10.40.1: bytes=32 time<10ms TTL=254
Reply from 10.10.40.1: bytes=32 time<10ms TTL=254
Reply from 10.10.40.1: bytes=32 time<10ms TTL=254
Reply from 10.10.40.1: bytes=32 time<10ms TTL=254
Reply from 10.10.40.1: bytes=32 time<10ms TTL=254
Reply from 10.10.40.1: bytes=32 time<10ms TTL=254
Reply from 10.10.40.1: bytes=32 time<10ms TTL=254
Reply from 10.10.40.1: bytes=32 time=16ms TTL=254
Reply from 10.10.40.1: bytes=32 time<10ms TTL=254
Reply from 10.10.40.1: bytes=32 time=31ms TTL=254
Reply from 10.10.40.1: bytes=32 time<10ms TTL=254
Reply from 10.10.40.1: bytes=32 time=16ms TTL=254
Reply from 10.10.40.1: bytes=32 time<10ms TTL=254
Reply from 10.10.40.1: bytes=32 time=16ms TTL=254
Reply from 10.10.40.1: bytes=32 time=16ms TTL=254
Reply from 10.10.40.1: bytes=32 time=16ms TTL=254
Reply from 10.10.40.1: bytes=32 time<10ms TTL=254
Reply from 10.10.40.1: bytes=32 time<10ms TTL=254
Reply from 10.10.40.1: bytes=32 time<10ms TTL=254
Reply from 10.10.40.1: bytes=32 time=15ms TTL=254
Reply from 10.10.40.1: bytes=32 time<10ms TTL=254
Reply from 10.10.40.1: bytes=32 time<10ms TTL=254
Reply from 10.10.40.1: bytes=32 time=15ms TTL=254
Reply from 10.10.40.1: bytes=32 time<10ms TTL=254
Reply from 10.10.40.1: bytes=32 time<10ms TTL=254
Reply from 10.10.40.1: bytes=32 time=31ms TTL=254
Reply from 10.10.40.1: bytes=32 time<10ms TTL=254
Reply from 10.10.40.1: bytes=32 time<10ms TTL=254
Reply from 10.10.40.1: bytes=32 time=16ms TTL=254
Reply from 10.10.40.1: bytes=32 time=16ms TTL=254
Reply from 10.10.40.1: bytes=32 time<10ms TTL=254
Reply from 10.10.40.1: bytes=32 time<10ms TTL=254
Reply from 10.10.40.1: bytes=32 time<10ms TTL=254
Reply from 10.10.40.1: bytes=32 time=16ms TTL=254
Reply from 10.10.40.1: bytes=32 time<10ms TTL=254
Reply from 10.10.40.1: bytes=32 time<10ms TTL=254
0
 
LVL 79

Accepted Solution

by:
lrmoore earned 2000 total points
ID: 13860864
Apples and oranges with "show clock"
What you're seeing is the system clock, just like the PC's time clock.
Whenever a Cisco router is rebooted, since it does not have an onboard battery like a CMOS battery in a PC, the system clock goes back to March 1, 1993

NTP can help you keep the system clocks set to a national NTP server, else it really doesn't matter unless you want accurate time stamps on syslog entries..

This has nothing whatsoever to do with the T1 clocking/timing..

Ping times don't look bad at all. Keep fingers crossed that the error counters don't start going up again.
I hope it stays up for you this time!

0

Featured Post

Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

This article is a collection of issues that people face from time to time and possible solutions to those issues. I hope you enjoy reading it.
If you try to migrate from Elastix to Issabel, you will face a lot of issues. These problems are inevitable but fortunately, you can fix them. In the guide below, I will explain how I performed the migration while keeping all data and successfully t…
Get a first impression of how PRTG looks and learn how it works.   This video is a short introduction to PRTG, as an initial overview or as a quick start for new PRTG users.
Monitoring a network: how to monitor network services and why? Michael Kulchisky, MCSE, MCSA, MCP, VTSP, VSP, CCSP outlines the philosophy behind service monitoring and why a handshake validation is critical in network monitoring. Software utilized …

621 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