Backup Async going up and down.

Jason,

Debugs are your friend. I would NTP sync my routers, configure msec timestamps (service timestamps debug date msec), create good sized logging buffers (say, logging buffered 500000 debug). Then turn on the following debugs to see what's happening:

debug modem debug dialer debug ppp nego

Then when a given site disconnects, look at the debugs at this time from the central and remote and see what they tell you.

Your configs on on the router will also be relevant. If you don't like your calls dropping, then why not configure your backup links always to be up (while the primary path is down)? (Hint: consider using dialer watch.)

Regards,

Aaron

Do NOT use 500,000 for your log (500K)!!!! Use something a little more sane like 64000 (64k), which will keep more than enough debug info to see the problem. Using a logging buffer that big can be a problem because the latest events are at the END of the logging buffer. If you need to see the last few messages you would need to scroll through 500K of irrelevant data.

Aaron,

Thanks for the advice.

Most of my locations are in different states, therefore the long distance charge of being on all the time will not do.

I just thought there might be some time frame or something like that which was dropping the connection. I was hopping to bumping that time limit up to like 2 hours or something. If it is really lack of traffic I could see that being a problem at one of our locations. All the other locations have people hitting that all day long. Of course the one I did first was the smaller location which could be not sending traffic for an hour or so at a time.

I am going to order another 1811 and do what you suggested about the debugging. I will just set it up for one of the other locations and test it here before I send it out.

Thanks again,

Jason Baker

~ Do NOT use 500,000 for your log (500K)!!!! Use something a little more sane ~ like 64000 (64k), which will keep more than enough debug info to see the ~ problem.

Well, the o.p. had a situation where his remote routers were sometimes disconnecting. So he would probably have to get into them *after* they disconnect and reconnect, and so I suggested big logging buffers to avoid overwriting the event of interest.

~ Using a logging buffer that big can be a problem because the ~ latest events are at the END of the logging buffer. If you need to see the ~ last few messages you would need to scroll through 500K of irrelevant data. ~ ~ Scott

Did you know that you can now copy the contents of your logging buffer to an FTP / TFTP server? So just write your 500KB buffer to your server, then you can use grep or tail or wordpad or the application of your choice to peruse them.

AP1100-LAB-DOT25#show logging | redirect ? flash: Uniform Resource Locator ftp: Uniform Resource Locator http: Uniform Resource Locator https: Uniform Resource Locator nvram: Uniform Resource Locator rcp: Uniform Resource Locator scp: Uniform Resource Locator tftp: Uniform Resource Locator

AP1100-LAB-DOT25#show logging | redirect tftp://not-craw--craw/foo.tmp ! AP1100-LAB-DOT25#

Cheers,

Aaron

Well, one possibility could be modem problems. For example, your modems might be training at 33600/33600 bps then getting an erratic connection and going into retrain and dropping, then reconnecting. To figure this out is sort of tough ... it involves reverse telnetting into the modems at each end, after a drop event (before the modems attempt to redial!), then pulling out the call information from the modem using whatever command is peculiar to that modem (AT#UD is now semistandard, but you need to run a special program to decode this.)

Given that the application doesn't require high bandwith, one possibility might be to cap the modems at the problem sites to something like 14400 bps and see if that yields greater stability.

Regards,

Aaron