Ascend Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: (ASCEND) Can't telnet anymore
Sajari wrote:
>>> I have this problem with one of my Max4000.
>>> After sometimes i'm not able to telnet in anymore.
>>> The only solution is to load again the ascend firmware.
>>> Currently i'm using 5.0Ap13.
...and Kevin Smith replied:
>Sometimes, people telnet in and leave the session hanging. There are limits
>to the number of telnet sessions that the various units will accept, so you
>may be hitting that. Also, there is a 2-minute "wait" period after a session
>has been "killed" during which the socket is kept open (I believe it's per
>the RFC....I just don't recall the exact details), so maybe if you wait for
>a couple of minutes and try again.
>
>Reloading the firmware seems to be way-overkill....have you at least tried
>resetting the box ?
There are more graceful ways to handle this than resetting the
entire Max.
Rather than simply dropping the session from the workstation
from which you telnet, hit Cntrl-D, select "Close Telnet Session"
from the list of choices, and let the Max drop the session from
its end. SNMP logs seems to indicate that this method is "cleanest".
If you are not able to telnet, and/or are not sure of what is
going on, use SNMP to examine the Max and see what IT thinks is
happening.
When one telnets to (or drops a telnet session to) an Ascend Max,
the Max will reveal this via two mechanisms:
a) Any SNMP software can read the consoleEntry table
and look at:
(usual prefixes...)
ascend (529)
console (8)
consoleTable (2)
consoleEntry (1)
consoleIndex1 (1) If the session is via the
serial port on the Max itself.
OR
(blah, blah, as above)
consoleIndex2 (2) If the session is via telnet
rather than a direct connection
to the serial port on the Max.
If there IS a telnet session active, then
the consoleEntryconsoleType field for the
console index referenced above will be
"remote" rather than "inactive".
In numeric terms (if your SNMP software does
not do auto-translation to what passes for
English in the world of SNMP):
"inactive" = 5
"remote" = 6
The Max will even report on the security level
of the session, using the same numbers listed
in the profile list. This is done in the "Security"
entry, one little GetNext away from the entry
mentioned above.
b) The Max will also issue a trap when any of the virtual
consoles "change state" (go from "inactive" to "active",
or visa versa). The trap looks something like this:
9/29/97 20:13:42 Bed-VA-Ascend
consoleStateChange, ent=max4000, consoleIndex.2=2
So, you get a time/date stamp, the name assigned to
that Max in your SNMP system, and which virtual console
was changing.
Sadly, (unlike Cisco's SNMP mib for their routers), the Max never
tells you:
a) How long the session lasted (one must try and infer from
time between IDENTICAL traps, without knowing which was
a "start" of a telnet session, and which was a "stop".
(Ascend engineering, take note of Cisco's
"tcpConnectionClose" trap)
b) What IP address the telnet session came from (Gee, Cisco
routers do this too...)
So, you really cannot have a log of which staff member was "in"
an Ascend at what time, which is a shame.
I do not even pretend to understand why Ascend's mib includes
a whopping 199 possible telnet session entries. Two or three
is understandable, but 199?
One guess is that the only practical application would be to
allow every member of this list to telnet into a single Max as
"read-only" administrators, set up a conference call, and walk
through the new and obscure option settings du juor with an
Ascend engineer doing the actual changes in a security profile
that allows edits while he tells us all about the nuances of
each...
Wow! Low-cost online interactive training! Kevin,
Ascend owes me some serious loose change for this idea!
C:\unix C:\unix\run ..\RUN\unix\RUN
james fischer jfischer@supercollider.com
++ Ascend Users Mailing List ++
To unsubscribe: send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd: <http://www.nealis.net/ascend/faq>