[HPADM] [SUMMARY] Re: Login delay
From: Kevin (kevinjk_at_ix.netcom.com)
Date: 07/29/03
- Previous message: Sudhansu Dora: "[HPADM] GSP time Change"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
To: hpux-admin@dutchworks.nl Date: Tue, 29 Jul 2003 06:09:10 -0400
Thanks a lot to Bill Hassell for the information. Hopefully, we'll be
able to pinpoint the cause shortly.
"Bill Hassell" <blhconsulting@mindspring.com> wrote:
>Hi,
>
>Very common problem, easy answer...
>
>> -----Original Message-----
>> From: hpux-admin-owner@DutchWorks.nl
>> [mailto:hpux-admin-owner@DutchWorks.nl]On Behalf Of Kevin
>> Sent: Saturday, July 26, 2003 8:28 AM
>> To: hpux-admin@dutchworks.nl
>> Subject: [HPADM] Login delay
>>
>>
>> Hello,
>>
>> Our environment is mostly HP-UX boxes with some Solaris boxes still
>> around. Some of the SUN boxes are NIS slaves and in some buildings the HP
>> boxes will hang for around twenty seconds or so when logging in to the HP
>> from the console or remotely when they bind to particular SUN slaves. If
>> we force the HP box to bind to an HP slave on the same subnet there is no
>> longer any delay and we've also seen it where there is no delay if it
>> binds to particular SUN slaves on the same subnet.
>
> The issue is DNS (in your case, NIS) response. Durng telnet login, the
> network code will try to verify that the client's IP address is valid
> (known by DNS, NIS or /etc/hosts). If the information service does not
> respond, there is a 20 second delay until the next choice is tried.
> In other words, your primary NIS or DNS server is unreachable or is
> refusing to reply to your queries. The best tool to see this behavior
> is nsquery (or the older nslookup). nsquery is much more useful as you
> can specify the exact behavior you want to test, regardless of the
> settings in /etc/resolv.conf or /etc/nsswitch.conf.
>
> The fastest way to verify the issue is to add your client(s) to /etc/hosts
> in your server. Then change /etc/nsswitch.conf to look at files first,
> followed by DNS or NIS:
>
> hosts: files [NOTFOUND=continue UNAVAIL=continue TRYAGAIN=continue] nis
>
> If the delay goes away, your NIS servers are no good, at least from your
> current subnet. Routers are often the culprit, followed by routing tables.
> Use traceroute on your server to look at the path taken from your server
>to
> selected NIS servers.
>
>
>> In other buildings
>> there is no delay at all when the HPs bind to the SUN machines. Any ideas
>> on what could cause this? Could it be related to a duplex mismatch? In
>> most cases we hard code the HPs to 100/FD from the prom and set the
>> switch/port to the same which works well. We had been having problems
>> with auto negotiate being unreliable. TIA.
>
>
> While 100BaseT duplex mismatch is a VERY common problem (for Sun too),
>this
> would not cause your delays. Duplex mismatch reduces the bandwidth of
>100BaseT
> from 100Mbit to about 3-4Mbit and lanadmin statistics will show collisions
>and
> FCS errors. (100FD cannot ever have a collision unless something is
>broken).
--
---> Please post QUESTIONS and SUMMARIES only!! <---
To subscribe/unsubscribe to this list, contact majordomo@dutchworks.nl
Name: hpux-admin@dutchworks.nl Owner: owner-hpux-admin@dutchworks.nl
Archives: ftp.dutchworks.nl:/pub/digests/hpux-admin (FTP, browse only)
http://www.dutchworks.nl/htbin/hpsysadmin (Web, browse & search)
- Previous message: Sudhansu Dora: "[HPADM] GSP time Change"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
