MM
On Nov 7, 12:53, David Buchanan wrote:
> Subject: 28.8 Dialin Problems
> User Support Staff Members,
>
> I think many of you are already aware that Cisco has acknowledged a bug in
> the terminal servers that we use for our 28.8 dialin lines. However, to
> make sure that all of USD has the same and current information, let me
> describe the situation.
>
> The effect of this bug is that the user gets a modem connection, but no
> characters from the user are ever acknowledged by the terminal server. The
> terminal server's receive channel is "deaf". In the case of an
> asynchronous terminal emulator connection, the user sees the terminal
> server prompt, but cannot type anything in response. Connections
> negotiated automatically, like PPP or ARA, will produce some sort of
> protocol negotiation failure message. You are probably more familiar with
> what these would be than I am.
>
> We have been talking to Cisco about this problem for some time and testing
> various suggestions and software revisions that they have produced, but
> none of these has been satisfactory. They should have a new revision for
> us to test next week (we hope).
>
> We can monitor the dialin logs and locate ports that have developed this
> problem. Once a day we manually remove these ports from the modem pools by
> busying out the lines or removing them from the rotor. Periodically we
> reset the terminal servers, which brings the ports back into service, but
> requires a downtime notice. This is what is being done during tomorrow's
> downtime (11/7).
>
> This known bug does not account for all of the problems. With 64 or more
> lines in a single rotor it's not surprising that one or more modems or
> ports would have a problem of one sort or another. A major factor in the
> number of complaints we get is the amount of usage, something that has been
> increasing constantly to the point where our lines are saturated most of
> the time from 8 am to 2 am. In this situation the only lines that don't
> have users on them have problems. It would probably be better if users got
> busy signals so that they would realize the problem is at least as much one
> of capacity as of reliability, and might consider a SprintLink account.
>
> At any rate, I hope this information helps in troubleshooting problems and
> communicating with users.
>
> David Buchanan
> ITC Network Systems
>
> -- End of excerpt from David Buchanan <dbb@virginia.edu>