<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Network errors / authentication delays in Operating System - HP-UX</title>
    <link>https://community.hpe.com/t5/operating-system-hp-ux/network-errors-authentication-delays/m-p/3695193#M544418</link>
    <description>Hi,  I just noticed your post to my old problem.&lt;BR /&gt;&lt;BR /&gt;Basically I had to eat my words.  It WAS DNS! - probably.&lt;BR /&gt;&lt;BR /&gt;Although nslookup worked to both hostname and IP in most cases, the PC/Windows admin people in our company had changed a whole bunch of IP addresses and in particular the IP of a webserver that connected to the instance had a different IP in the DNS server.&lt;BR /&gt;The problem mysteriously went away after a couple of weeks, when they had fixed their windows servers and added them to DNS both ways round.&lt;BR /&gt;&lt;BR /&gt;</description>
    <pubDate>Tue, 05 Dec 2006 11:48:42 GMT</pubDate>
    <dc:creator>Steve Lewis</dc:creator>
    <dc:date>2006-12-05T11:48:42Z</dc:date>
    <item>
      <title>Network errors / authentication delays</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/network-errors-authentication-delays/m-p/3695186#M544411</link>
      <description>I have a bizarre problem that I cannot diagnose.  The database (informix) is starting to give long delays on authenticating users, say 10-30 seconds.  This includes local users connecting through shared memory, not just tcpip, although remote users are also affected.&lt;BR /&gt;It happens on several machines and none of them have been changed themselves, but there was a network change put in - a vlan was defined for one server and port spanning was enabled for a linux box to snort traffic.  The network people are telling me that they are not snooping, or pen testing and are not creating packets.&lt;BR /&gt;&lt;BR /&gt;netstat -s has started flagging huge error numbers in certain places, compared with other machines on the subnet.&lt;BR /&gt;&lt;BR /&gt;Logging on to the servers using telnet and ssh is fine, no delays there.&lt;BR /&gt;&lt;BR /&gt;At the same time, some UNIX client-server processes on the boxes have started to go wrong.  These communicate through UNIX sockets (ie files) and do not bind.  These processes are getting errnos 2 (no such file) and 235 ( socket is not connected).&lt;BR /&gt;&lt;BR /&gt;If anyone can help with this output below and give me some help in diagnosing or drilling down then I would be very grateful.&lt;BR /&gt;&lt;BR /&gt;tcp:&lt;BR /&gt;        875535732 packets sent&lt;BR /&gt;                2509258801 data packets (3425152922 bytes)&lt;BR /&gt;                1990723 data packets (984694790 bytes) retransmitted&lt;BR /&gt;                2684954798 ack-only packets (70404651 delayed)&lt;BR /&gt;                11497 URG only packets&lt;BR /&gt;                166545 window probe packets&lt;BR /&gt;                22145002 window update packets&lt;BR /&gt;                37393177 control packets&lt;BR /&gt;        674107630 packets received&lt;BR /&gt;                2620141777 acks (for 3446326145 bytes)&lt;BR /&gt;                10730561 duplicate acks&lt;BR /&gt;                0 acks for unsent data&lt;BR /&gt;                1905166156 packets (1476689041 bytes) received in-sequence&lt;BR /&gt;                88 completely duplicate packets (33565 bytes)&lt;BR /&gt;                35906 packets with some dup, data (45425434 bytes duped)&lt;BR /&gt;                460389 out of order packets (434148997 bytes)&lt;BR /&gt;                468 packets (2232675199 bytes) of data after window&lt;BR /&gt;                36101 window probes&lt;BR /&gt;                16612861 window update packets&lt;BR /&gt;                2682 packets received after close&lt;BR /&gt;                786 segments discarded for bad checksum&lt;BR /&gt;                1 bad TCP segment dropped due to state change&lt;BR /&gt;        13594352 connection requests&lt;BR /&gt;        8573855 connection accepts&lt;BR /&gt;        22168207 connections established (including accepts)&lt;BR /&gt;        22675633 connections closed (including 507795 drops)&lt;BR /&gt;        500444 embryonic connections dropped&lt;BR /&gt;        2591777834 segments updated rtt (of 2591777834 attempts)&lt;BR /&gt;        597693 retransmit timeouts&lt;BR /&gt;                47747 connections dropped by rexmit timeout&lt;BR /&gt;        166545 persist timeouts&lt;BR /&gt;        336856 keepalive timeouts&lt;BR /&gt;                317643 keepalive probes sent&lt;BR /&gt;                822 connections dropped by keepalive&lt;BR /&gt;        0 connect requests dropped due to full queue&lt;BR /&gt;        1508750 connect requests dropped due to no listener&lt;BR /&gt;udp:&lt;BR /&gt;        0 incomplete headers&lt;BR /&gt;        0 bad checksums&lt;BR /&gt;        0 socket overflows&lt;BR /&gt;ip:&lt;BR /&gt;        1083471845 total packets received&lt;BR /&gt;        0 bad IP headers&lt;BR /&gt;        2023613 fragments received&lt;BR /&gt;        0 fragments dropped (dup or out of space)&lt;BR /&gt;        10039 fragments dropped after timeout&lt;BR /&gt;        0 packets forwarded&lt;BR /&gt;        0 packets not forwardable&lt;BR /&gt;icmp:&lt;BR /&gt;        656461 calls to generate an ICMP error message&lt;BR /&gt;        62 ICMP messages dropped&lt;BR /&gt;        Output histogram:&lt;BR /&gt;         echo reply: 201606&lt;BR /&gt;         destination unreachable: 444759&lt;BR /&gt;         source quench: 0&lt;BR /&gt;         routing redirect: 0&lt;BR /&gt;         echo: 0&lt;BR /&gt;         time exceeded: 10034&lt;BR /&gt;         parameter problem: 0&lt;BR /&gt;         time stamp: 0&lt;BR /&gt;         time stamp reply: 0&lt;BR /&gt;         address mask request: 0&lt;BR /&gt;         address mask reply: 0&lt;BR /&gt;        0 bad ICMP messages&lt;BR /&gt;        Input histogram:&lt;BR /&gt;         echo reply: 92536&lt;BR /&gt;         destination unreachable: 109208&lt;BR /&gt;         source quench: 72&lt;BR /&gt;         routing redirect: 0&lt;BR /&gt;         echo: 201606&lt;BR /&gt;         time exceeded: 331&lt;BR /&gt;         parameter problem: 0&lt;BR /&gt;         time stamp request: 2&lt;BR /&gt;         time stamp reply: 0&lt;BR /&gt;         address mask request: 2&lt;BR /&gt;         address mask reply: 0&lt;BR /&gt;        201606 responses sent&lt;BR /&gt;igmp:&lt;BR /&gt;        148286 messages received&lt;BR /&gt;        0 messages received with too few bytes&lt;BR /&gt;        0 messages received with bad checksum&lt;BR /&gt;        0 membership queries received&lt;BR /&gt;        0 membership queries received with incorrect fields(s)&lt;BR /&gt;        88102 membership reports received&lt;BR /&gt;        0 membership reports received with incorrect field(s)&lt;BR /&gt;        88091 membership reports received for groups to which this host belongs&lt;BR /&gt;        60229 membership reports sent&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;</description>
      <pubDate>Tue, 20 Dec 2005 12:41:03 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/network-errors-authentication-delays/m-p/3695186#M544411</guid>
      <dc:creator>Steve Lewis</dc:creator>
      <dc:date>2005-12-20T12:41:03Z</dc:date>
    </item>
    <item>
      <title>Re: Network errors / authentication delays</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/network-errors-authentication-delays/m-p/3695187#M544412</link>
      <description>I should mention that IBM informix support are stumped on this.  The database server has the symptom of the miscellaneos (MSC) vp being active for up to 30 seconds during the period of initiating a connection.  Normally you hardly ever see it.  This vp specifically handles o/s calls which require a large stack.  Since the user has no database connection at that point in time, I cannot get any database diagnostics out.</description>
      <pubDate>Tue, 20 Dec 2005 12:58:05 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/network-errors-authentication-delays/m-p/3695187#M544412</guid>
      <dc:creator>Steve Lewis</dc:creator>
      <dc:date>2005-12-20T12:58:05Z</dc:date>
    </item>
    <item>
      <title>Re: Network errors / authentication delays</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/network-errors-authentication-delays/m-p/3695188#M544413</link>
      <description>Shalom,&lt;BR /&gt;&lt;BR /&gt;Appears to be trouble in the networking environment.&lt;BR /&gt;&lt;BR /&gt;Has someone disabled ping in all or part of this servers network?&lt;BR /&gt;&lt;BR /&gt;It also could be a problem with any physical part of the network including the network card.&lt;BR /&gt;&lt;BR /&gt;On the software side, since its mostly informix, perhaps a disk error or other event has corrupted part of the software.&lt;BR /&gt;&lt;BR /&gt;Is there a way to relink the binaries in Informix like in Oracle?&lt;BR /&gt;&lt;BR /&gt;SEP</description>
      <pubDate>Tue, 20 Dec 2005 14:01:39 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/network-errors-authentication-delays/m-p/3695188#M544413</guid>
      <dc:creator>Steven E. Protter</dc:creator>
      <dc:date>2005-12-20T14:01:39Z</dc:date>
    </item>
    <item>
      <title>Re: Network errors / authentication delays</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/network-errors-authentication-delays/m-p/3695189#M544414</link>
      <description>Many things to check.&lt;BR /&gt;&lt;BR /&gt;1. any delays reaching dns servers?? (If you use them for name resolution)&lt;BR /&gt;2. Network card settings on system and switch/port side.-duplex setting. Are thay matching?? What about speed settings?? hard coded or autoneg??&lt;BR /&gt;3. Any other specific message in syslog.log, dmesg, informix logs??&lt;BR /&gt;4. Is server experiencing any kind of bottleneck??-cpu, network, memorym disk?? - Check with glance.&lt;BR /&gt;5. Is delay specific to informix operations?? Or anything else?? When you telnet,bdf or other commands, do you experience delays??</description>
      <pubDate>Tue, 20 Dec 2005 21:31:42 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/network-errors-authentication-delays/m-p/3695189#M544414</guid>
      <dc:creator>RAC_1</dc:creator>
      <dc:date>2005-12-20T21:31:42Z</dc:date>
    </item>
    <item>
      <title>Re: Network errors / authentication delays</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/network-errors-authentication-delays/m-p/3695190#M544415</link>
      <description>THe 10-30 second delays and the stats above that show unreachable destinations strongly suggest that your DNS servers are not working. Now they may be fine but for this HP-UX box, the first DNS server is not responding. Verify this with nslookup in both directions as in:&lt;BR /&gt;  &lt;BR /&gt;nslookup some_cpu&lt;BR /&gt;nslookup some_IP_addr&lt;BR /&gt; &lt;BR /&gt;HP-UX security requires reverse DNS lookup. If the primary server has been changed, then 20-30 second delays for mostr network activities will be normal. Temporarily fix the problem by putting a working DNS entry first in /etc/resolv.conf. Then use nslookup to test the other DNS servers as in:&lt;BR /&gt; &lt;BR /&gt;nslookup some_cpu dns_server2&lt;BR /&gt;nslookup some_IP_addr dns_server2&lt;BR /&gt; &lt;BR /&gt;DNS is a critical resource for networking and must be equal or more reliable than the servers that use it. Note that the DNS servers might be working but the vlan configuration is blocking access from the HP-UX box.</description>
      <pubDate>Tue, 20 Dec 2005 22:26:17 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/network-errors-authentication-delays/m-p/3695190#M544415</guid>
      <dc:creator>Bill Hassell</dc:creator>
      <dc:date>2005-12-20T22:26:17Z</dc:date>
    </item>
    <item>
      <title>Re: Network errors / authentication delays</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/network-errors-authentication-delays/m-p/3695191#M544416</link>
      <description>ping works fine on all 3 networks (100, 1000-base-SX and token ring).&lt;BR /&gt;&lt;BR /&gt;The cards are fine and so are the settings - remember that this started happening on 4 servers at the same time.  Similarly on the database side, highly unlikely to affect 4 out of 6 servers.&lt;BR /&gt;You cannot re-link the binaries with informix.&lt;BR /&gt;&lt;BR /&gt;It mysteriously stopped happening last night and I am not aware of any server changes.  I spoke to the network people and they didn't make any changes last night. &lt;BR /&gt;&lt;BR /&gt;As for DNS, nslookup for both IP and hostname comes back straight away, as does nsquery.  We did some investigation on the local DNS server this morning and discovered that its lancard was set to dns lookup to itself which looked suspicious, so we set it to the main dns server for the company and re-started the service just in case.&lt;BR /&gt;The network settings are all fine.  There are no login delays in the o/s which makes me think that maybe DNS isn't the issue.&lt;BR /&gt;There are no messages in the database or server syslogs. &lt;BR /&gt;There are no server bottlenecks, it just mysteriously cropped up every few minutes.  most commands are fine, apart from some client-server processes which time out when trying to connect via a UNIX domain socket.  Our nfiles/ maxfiles usage is quite low at just 25% of maximum.&lt;BR /&gt;&lt;BR /&gt;I now suspect that there may have been an issue with an ODBC or JDBC driver and will start questioning the PC software people instead.  They are the ones who complained first, so it could be something they did which broke it.&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;</description>
      <pubDate>Wed, 21 Dec 2005 05:11:51 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/network-errors-authentication-delays/m-p/3695191#M544416</guid>
      <dc:creator>Steve Lewis</dc:creator>
      <dc:date>2005-12-21T05:11:51Z</dc:date>
    </item>
    <item>
      <title>Re: Network errors / authentication delays</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/network-errors-authentication-delays/m-p/3695192#M544417</link>
      <description>I am on the phone with Informix as I type this.  We are experiencing a very similar problem.  I was wondering if you ever were able to resolve the issue.  Both HP and Informix are struggling to come up with a solution.  Any help would be greatly appreciated.  Thanks.</description>
      <pubDate>Tue, 05 Dec 2006 10:43:41 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/network-errors-authentication-delays/m-p/3695192#M544417</guid>
      <dc:creator>Jeff Dukes</dc:creator>
      <dc:date>2006-12-05T10:43:41Z</dc:date>
    </item>
    <item>
      <title>Re: Network errors / authentication delays</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/network-errors-authentication-delays/m-p/3695193#M544418</link>
      <description>Hi,  I just noticed your post to my old problem.&lt;BR /&gt;&lt;BR /&gt;Basically I had to eat my words.  It WAS DNS! - probably.&lt;BR /&gt;&lt;BR /&gt;Although nslookup worked to both hostname and IP in most cases, the PC/Windows admin people in our company had changed a whole bunch of IP addresses and in particular the IP of a webserver that connected to the instance had a different IP in the DNS server.&lt;BR /&gt;The problem mysteriously went away after a couple of weeks, when they had fixed their windows servers and added them to DNS both ways round.&lt;BR /&gt;&lt;BR /&gt;</description>
      <pubDate>Tue, 05 Dec 2006 11:48:42 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/network-errors-authentication-delays/m-p/3695193#M544418</guid>
      <dc:creator>Steve Lewis</dc:creator>
      <dc:date>2006-12-05T11:48:42Z</dc:date>
    </item>
  </channel>
</rss>

