To anybody that has experience with Sniffers. or more perhaps more specifically, Priscilla- I'm trying to hunt down the culprit of Telnet Session disconnects without Administrative or User interaction to invoke such action. The situation is Telnet clients on remote ends of PIX VPNs have their sessions dropped without warning, and without Administrative action to cause such sudden session endings. All users that connect to the same Telnet Server on the local subnet never experience this problem. For the remote users that do experience this problem, it usually occurs after roughly 30 minutes of inactivity. This used to not be the case when all such remote clients were connecting via private Frame Relay networks back to the Server in a hub-n-spoke fashion.. Only since the switch to VPNs for connectivity to the Telnet Server's Private Network has this anomaly arisen. The Telnet Server is a custom application service for Unidata DB Server by Informix. It uses the standard Telnet port, and runs on NT 4.0. For everything I can see in the registry referencing the Telnet App Service, it doesn't specify any settings for keep-alive or session monitoring. Also, from the Unidata Application Server's point of view, the Server thinks the user is still connected, so it never clears the session. When the user finds his/her application rendering a Pop-Up dialogue stating that the session was disconnected, and asks if they want to reconnect, they choose "Yes" naturally. From the Server side, a second session for that user is started, and the first session becomes an "orphan" process (in my own words). This of course then causes a problem of exhausting the limited number of users licenses, and eventually causes users to not be able to get back on the system until the old orphaned processes are administratively cleared. So, I open a case with Cisco, and they say "Slap a Sniffer on the Server side of the network, and see what is causing the disconnects". They also say that they are suspect that the Telnet Server is sending its session keep-alives via Broadcast, and that by design of Security, the VPN tunnels don't pass Broadcast Traffic. The Sniffer capture is supposed to prove or disprove this. I put a Sniffer (Ethereal on Windows 2K) out and collected a Time Window of data, but am at a loss as to how to identify the disconnect process of a telnet session..Which is where I could use a few pointers. Could someone tell me what to look for in a session trace that identifies a sudden termination of a specific telnet session (most probably initiated by the server)?? Unfortunately, I'm not a very well experienced person in following the SYN, FIN, PSH, ACK, SYN ACK, etc. process. But I want to learn! If I had the time and money, I'd go take a Sniffer class, but that's another story. so, in the mean time, if someone would be kind enough to point me in a direction on how to interpret and follow a sniffer trace, I'd be eternally greatful. Thanks, Mark
Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=44793&t=44793 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
