[Date Prev] [Date Index] [Date Next] [Thread Prev] [Thread Index] [Thread Next]
Lorris J. Woods lwoods@email.unc.edu
Thu, 29 Nov 2001 11:47:21 -0800 (PST)
alfcab I have a setup using PM2E, but I cannot get conserver.passwd and conserver.cf right ttya is the only one I can get to work. BTW my PM2E is coming off a second NIC card and I use a hub for all the PM2E connections. in your what is unix1, unix2, cisco, & cisco2,... routers ???? --On Wednesday, November 28, 2001 3:19 PM -0500 alfcab <alfcab@mail.magma.ca> wrote: > I have the same setup working as follows : > > > \ internal net / > -------------- > | TCP > V > +------------+ > | solarisx86 | > +------------+ > | TCP crossover > V > +------------+ > | portmaster |-------------------------+ > +------------+ | | | > | Serial | Serial | Serial | Serial > V V V V > +-------+ +-------+ +-------+ +--------+ > | unix1 | | unix2 | | cisco | | cisco2 | > +-------+ +-------+ +-------+ +--------+ > > Each port on portmaster PM2e configured as follows : > > set <port> cd on > set <port> extended on > set <port> modem > set <port> cd off > set <port> speed 1 9600 > set <port> speed 2 9600 > set <port> speed 3 9600 > set <port> idletime 0 > set <port> hangup off > set <port> prompt : > set <port> device /dev/network > set <port> service_device telnet <tcp_port> > set <port> service_login telnet <tcp_port> > > The entry in conserver.cf is as follows : > > LOGDIR=/var/consoles > > unix1:!portmaster:<tcp_port>:& > unix2:!portmaster:<tcp_port>:& > cisco:!portmaster:<tcp_port>:& > cisco2:!portmaster:<tcp_port>:& > > As well the cabling is important, you don't want to send the > break to sparc gear if the portmaster is resetted for any reason. > I'm using standard cisco serial connectors on both ends pm2e and > sparc gear with straight trough cables, for the cisco gear we use > roll-overs ( they come with the cisco stuff ). > > FYI I tried linux first as a conserver server, and had the same > behaviour you are experiencing, I decided to try solaris on x86 > and voila my hangups on active connections dissapeared, maybe > it's something related to specific's in OS's had no time to > troubleshoot, just had to get it working in a reliable way ( no > hangups ). > > Alfredo Cabrera > > > > >> To: users@conserver.com >> Sender: users-admin@conserver.com >> Errors-To: users-admin@conserver.com >> X-BeenThere: users@conserver.com >> X-Mailman-Version: 2.0.5 >> Precedence: bulk >> List-Help: <mailto:users-request@conserver.com?subject=help> >> List-Post: <mailto:users@conserver.com> >> List-Subscribe: <https://www.conserver.com/mailman/listinfo/users>, > <mailto:users-request@conserver.com?subject=subscribe> >> List-Id: Conserver Users <users.conserver.com> >> List-Unsubscribe: <https://www.conserver.com/mailman/listinfo/users>, > <mailto:users-request@conserver.com?subject=unsubscribe> >> List-Archive: <https://www.conserver.com/pipermail/users/> >> Message-Id: <20011128200007.160853C7CE@underdog.stansell.org> >> Date: Wed, 28 Nov 2001 12:00:07 -0800 (PST) >> Content-Length: 11409 >> >> Send users mailing list submissions to >> users@conserver.com >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://www.conserver.com/mailman/listinfo/users >> or, via email, send a message with subject or body 'help' to >> users-request@conserver.com >> >> You can reach the person managing the list at >> users-admin@conserver.com >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of users digest..." >> >> >> Today's Topics: >> >> 1. lines going "down" (Jim Gottlieb) >> 2. RE: lines going "down" (Ernie Oporto) >> 3. Re: lines going "down" (David Harris) >> >> --__--__-- >> >> Message: 1 >> Date: Tue, 27 Nov 2001 16:21:45 -0800 >> From: Jim Gottlieb <jimmy@nccom.com> >> To: users@conserver.com >> Subject: lines going "down" >> >> Hi all. We were using conserver 7.0.0 for several months, but ports >> seemed to get stuck too often, forcing me to restart the daemon, so I >> upgraded to 7.1.3. Unfortunately, things have been worse under this >> version. More often than not, ports suddenly go "down", and restarting >> the server makes some ports come up and others go down. >> >> Is there some better in-bewteen version I should try? I'm starting to >> get frustrated. >> >> oracle1 down <none> >> pbxp1 down <none> >> sunray1 up <none> >> sunray2 up <none> >> cisco up <none> >> jtsd07 up <none> >> jtsd08 up <none> >> jtsd09 up <none> >> toro up <none> >> shasta down <none> >> tahoe down <none> >> vodavi up <none> >> >> Right now, the four shown "down" should be "up". Five minutes ago, >> jtsd0[789] showed "down" for no explicable reason. 'netstat' shows no >> active connection between the conserver and the terminal server for the >> "down" ports. ^Eco just comes back with "line is still down". >> >> We are using a Portmaster PM2e. Any help or suggestions would be >> appreciated. Thank you. >> >> >> --__--__-- >> >> Message: 2 >> From: "Ernie Oporto" <Ernie.Oporto@viragelogic.com> >> To: <users@conserver.com> >> Subject: RE: lines going "down" >> Date: Wed, 28 Nov 2001 10:44:05 -0500 >> >> This is a multi-part message in MIME format. >> >> ------=_NextPart_000_00C9_01C177F9.9863BD80 >> Content-Type: text/plain; >> charset="us-ascii" >> Content-Transfer-Encoding: 7bit >> >> We saw a problem this week where the lines would not come up no matter >> what. After an hour of coaxing (stoping the daemon and restarting it, >> stopping and restarting...) they finally came up. Never went through >> that before, and they seem stable since then. Have to keep an eye on >> this... >> >> Ernie >> >> >>> -----Original Message----- >>> From: users-admin@conserver.com [mailto:users-admin@conserver.com]On >>> Behalf Of Jim Gottlieb >>> Sent: Tuesday, November 27, 2001 7:22 PM >>> To: users@conserver.com >>> Subject: lines going "down" >>> >>> >>> Hi all. We were using conserver 7.0.0 for several months, but ports >>> seemed to get stuck too often, forcing me to restart the daemon, so I >>> upgraded to 7.1.3. Unfortunately, things have been worse under this >>> version. More often than not, ports suddenly go "down", and restarting >>> the server makes some ports come up and others go down. >>> >>> Is there some better in-bewteen version I should try? I'm starting to >>> get frustrated. >>> >>> oracle1 down <none> >>> pbxp1 down <none> >>> sunray1 up <none> >>> sunray2 up <none> >>> cisco up <none> >>> jtsd07 up <none> >>> jtsd08 up <none> >>> jtsd09 up <none> >>> toro up <none> >>> shasta down <none> >>> tahoe down <none> >>> vodavi up <none> >>> >>> Right now, the four shown "down" should be "up". Five minutes ago, >>> jtsd0[789] showed "down" for no explicable reason. 'netstat' shows no >>> active connection between the conserver and the terminal server for the >>> "down" ports. ^Eco just comes back with "line is still down". >>> >>> We are using a Portmaster PM2e. Any help or suggestions would be >>> appreciated. Thank you. >>> >>> _______________________________________________ >>> users mailing list >>> users@conserver.com >>> https://www.conserver.com/mailman/listinfo/users >>> >> > >> >> >> --__--__-- >> >> Message: 3 >> Date: Wed, 28 Nov 2001 09:19:00 -0800 >> From: David Harris <zonker@certaintysolutions.com> >> To: users@conserver.com >> Cc: zonker@gnac.com >> Subject: Re: lines going "down" >> >> I've seen a similar scenario in one particular lab, using a >> Cisco 3640 with NM-32A cards. I don't think this is a brand >> issue. I merely offer it as another clue.... >> >> When we see the failure, we typically see 8 ports in a group >> go down...all 8 in a modulo-8 group. (i.e. 1-8, 17-24, etc.) >> All of the affected lines are run by the same OCTART chip. >> >> While I could point to a failure in IOS for this (which >> would only be circumstantial and unsupported by fact), I >> actually have another working theory, based on looking at >> the devices attached... >> >> In these cases, there was usually a network interruption >> between the conserver and the console server. This could be >> a switch/router failure in the network, or a forced reboot >> of the conserver host without a polite shutdown...and the >> devices showing 'down' were what I call 'quiet hosts'. (A >> quiet host is a device that only replies when you talk to >> it...it doesn't usually offer any log traffic, time stamps, >> etc. to the logs unless someone is typing to it.) >> >> In the case of a network break like this, the TCP session >> to all of the ports (from Conserver to the Console Server) >> don't get cleared out when the connectivity failure occurs! >> Since the host doesn't generate any traffic on the serial >> port, the console server never tries to send traffic to the >> conserver host, and the console server leaves the session >> open, thinking that the conserver host is just idle. The >> root cause here is that the TCP FIN sequence never occured. >> So, when you restart your Conserver, and it tries to then >> connect to these ports on the console server, the console >> server tells the conserver that the TCP port is busy (since >> the console server still thinks the old session is still >> there and idle...) >> >> In these cases, our cure has been to log into the console >> server, and reset each affected line, one by one. This will >> blow away the (already broken) TCP session, and allow you to >> either restart your conserver, or just force open each of >> the lines that were down. >> >> While this doesn't happen too often in the data centers, >> I have seen this in some of the remote locations. Maybe >> that's another good argument for having a distributed >> Conserver deployment, and putting a logging host 'closer' >> to the console servers? :-) >> >> Regards, >> >> -Z- http://www.conserver.com/consoles/breakoff.html >> >> >> >> >> >> --__--__-- >> >> _______________________________________________ >> users mailing list >> users@conserver.com >> https://www.conserver.com/mailman/listinfo/users >> >> >> End of users Digest > > _______________________________________________ > users mailing list > users@conserver.com > https://www.conserver.com/mailman/listinfo/users Thanx Much, Lorris