External Modem problem

Sounds like just your ordinary trainup issue. Some circuit paths are worth than others and it is harder for the calls to train over them.

For a site that consistently trains in V.34, leave the client modem configured with its defaults. For sites that train unreliably, try backing down to say each of: V.34 capped at 24k; 19.2K; V.32/V.32bis capped at 14400 or 9600; V.22bis capped at 2400 bps.

If you can't train in V.22bis, then you've really got a bad circuit I would assume.

Aaron

Aaron, Thanks for the suggestion. I am not sure how to cap the data rate on the Motorola Codex 3260, but I am going to scour the user's guide and try and find out. Are there any resources online or perhaps paper publications might suggest that I can read to learn more about the trainup process and how to troubleshoot dial issues like these? I am still a newbie when it comes to the dial technology and I am trying to learn as much as I can before I contemplate going toe-to-toe with our teleco and just make troubelshooting easier by truly understanding the process :)

Once again thanks for the help, I will look into capping the data rate on the unreliable locations.

Robert

~ Aaron, ~ Thanks for the suggestion. I am not sure how to cap the data rate ~ on the Motorola Codex 3260, but I am going to scour the user's guide ~ and try and find out. Are there any resources online or perhaps paper ~ publications might suggest that I can read to learn more about the ~ trainup process and how to troubleshoot dial issues like these? I am ~ still a newbie when it comes to the dial technology and I am trying to ~ learn as much as I can before I contemplate going toe-to-toe with our ~ teleco and just make troubelshooting easier by truly understanding the ~ process :)

The one good general book that I know of on modems is Gilbert Held's _The Complete Modem Reference_, 3rd Ed. which only goes up thru V.34 however.

There might be something good on the Internet although a quick scan right now didn't turn up much.

As far as commands specifically for the Codex 326x modems ... see

~ Once again thanks for the help, I will look into capping the data rate ~ on the unreliable locations. ~ ~ Robert

Good luck. Capping the rate is typically your only real option (that, or trying a different modem.)

Aaron

Aaron, So would I need to cap the rate just on the dialing in modem side, or would the RAS need to be configured to handle this as well. We hae some sites that seem to be connecting just fine via the Codex's default auto-modulation, and I would like to avoid having to change those (if it ain't broke don't fix it).

Thanks again for the help.

~Robert

Robert,

I'm not sure that I understand your topology correctly ... assuming that you have a setup like this:

and that remote1 and remote2 dial into central router, and that central router has a pool of modems that are used by all remotes ...

and assuming that remote1 always dials in and trains in say V.34 at 31200, but remote2 has problems training up or trains up and gets an unstable connection ...

and assuming that the reason why remote2 is having problems is that it is on a bad POTS line or tends to get bad circuits thru the PSTN ...

and assuming that remote2's bad circuit problems are not fixable ...

THEN I would reconfigure remote2's modem (via AT settings in its dial chat script) to cap its modulation at the highest rate that yields consistent stable connections.

I would NOT modify the central router's configuration, since if you detune its modems to help out problem sites like remote2, you will have to reduce EVERYONE's performance to the lowest common denominator.

Regards,

Aaron

You have the topology right and have confirmed my suspicion. The modem capping would only be done on remote modems dialing in because the possibility still exists that a remote modem with a clearer circuit path might be able to negotation a higher data rate. I just wanted to make sure that capping the remote modem did not in some way change how the central router needed to be configured to train up.

We are trying to troubleshoot unclean or degraded circuit paths but the telcos are not being incredibly helpful. So while we plug away at them I am trying to have other solutions on-hand.

I appreciate your infinite patience in terms of helping em out with this and some other issues I have raised here on comp.dcom.sys.cisco in the past, now I have one additional question :)

We also have a 3745 and we are hanging an external modem off the aux port for dialin out-of-band management. I have everything set up and I can dial into just fine. I don't have login set on the aux port so when I dial in I go to directly to router> prompt, the issue that when I do so it appears that the modem has responded back to the connection before I see it on my screen, for example I might seen something like this:

router>

router>RING router>

router>

router>

router>CONNECT router>

I can still access the router fine, just wondering why I am getting what looks like modem responses back on the display like that. Occasionally I'll even get something like

router>

router>NO CARRIER router>

router>

even though the call connected and I am getting access to the router. What might cause this. I tried turning command echo off on the modem (ATE0) and that didn't work, I though perhaps a chat script was the culprit (we have one on the aux port for dialout on that same modem) but removing it did not help. If I enable 'login' on the aux port when I dialin I get '%Bad Passwords' and I suspect this might be the cause

Any thoughts?

Thanks aga>Robert,

~ You have the topology right and have confirmed my suspicion. The modem ~ capping would only be done on remote modems dialing in because the ~ possibility still exists that a remote modem with a clearer circuit ~ path might be able to negotation a higher data rate. I just wanted to ~ make sure that capping the remote modem did not in some way change how ~ the central router needed to be configured to train up.

HOPEFULLY not.

~ We are trying to troubleshoot unclean or degraded circuit paths but ~ the telcos are not being incredibly helpful. So while we plug away at ~ them I am trying to have other solutions on-hand. ~ ~ I appreciate your infinite patience in terms of helping em out with ~ this and some other issues I have raised here on comp.dcom.sys.cisco ~ in the past, now I have one additional question :) ~ ~ We also have a 3745 and we are hanging an external modem off the aux ~ port for dialin out-of-band management. I have everything set up and I ~ can dial into just fine. I don't have login set on the aux port so ~ when I dial in I go to directly to router> prompt, the issue that when ~ I do so it appears that the modem has responded back to the connection ~ before I see it on my screen, for example I might seen something like ~ this: ~ ~ router>

~ router>RING ~ router>

~ router>

~ router>

~ router>CONNECT ~ router>

~ ~ I can still access the router fine, just wondering why I am getting ~ what looks like modem responses back on the display like that. ~ Occasionally I'll even get something like ~ ~ router>

~ router>NO CARRIER ~ router>

~ router>

~ ~ even though the call connected and I am getting access to the router. ~ What might cause this. I tried turning command echo off on the modem ~ (ATE0) and that didn't work, I though perhaps a chat script was the ~ culprit (we have one on the aux port for dialout on that same modem) ~ but removing it did not help. If I enable 'login' on the aux port when ~ I dialin I get '%Bad Passwords' and I suspect this might be the cause ~ ~ Any thoughts? ~ ~ Thanks again, ~ Robert

Do you have "modem inout" or "modem dialin" and "flush-at-activation" configured on the aux port? If so, then when DCD (which we call "DSR") comes up on the modem, the line's input buffer should be flushed of any "NO CARRIER" "RING", "CONNECT" result code stuff, then the router prompt should be displayed.

To add suspenders to your belt, maybe you can configure your modem not display result codes when answering. (This would be set via Q2 on many modems.)

Aaron

Here is the aux port config:

line aux 0 no flush-at-activation script dialer dial modem InOut transport input all transport output none autoselect ppp stopbits 1 speed 115200 flowcontrol hardware

so if I change the "no flush-at-activation" to "flush-at-activation" it should clear that up? Will changing this affect our dialout on that modem adversely? I will also look into the result code thing but right now we have implemented a rather low end Best Data modem for this job and I am not sure it supports it, but I will find out, might just dig an old USR out of my desk and slap it on there.

Thanks, Robert

~ Here is the aux port config: ~ ~ line aux 0 ~ no flush-at-activation ~ script dialer dial ~ modem InOut ~ transport input all ~ transport output none ~ autoselect ppp ~ stopbits 1 ~ speed 115200 ~ flowcontrol hardware ~ ~ so if I change the "no flush-at-activation" to "flush-at-activation" ~ it should clear that up? Will changing this affect our dialout on that ~ modem adversely?

Yeah, your culprit is "no flush-at-activation". With "no flush-at-activation", when DSR goes high (i.e. incoming modem call has arrived), we do NOT clear out all the junk ("NO CARRIER", "RING", "CONNECT", etc.) that arrived in our line input buffer while the DSR was low. So this stuff gets delivered to your new EXEC session with the results described below.

In general, you should always use "flush-at-activation" unless you are doing "async mode dedicated". (With async mode dedicated, any incoming junk will just be discarded as bad packets and will do no harm.)

Aaron

Again, thanks a bunch for the knowledge Aaron.

Robert