[Date Prev] [Date Index] [Date Next] [Thread Prev] [Thread Index] [Thread Next]
alfcab alfcab@mail.magma.ca
Wed, 28 Nov 2001 12:18:50 -0800 (PST)
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