Hello,

Setup:
Latest 64-bit Windows client on Windows Server 2008 connecting to a DB2
9.7 server (running on Linux) with latest fixpack. The database being
connected to is activated.

When using the client, connnection setup takes more than 50 seconds.
Sniffing on the network with Wireshark reveals that no outgoing packets
are seen during the first 20 seconds. So, for some reason, the DB2 client
"hesitates" for a rather long while before even trying to connect.

I tried temporarily closing the DB2 server and set up netcat to listen on
port 50000 instead. I then ran netcat in client mode on the Windows-box.
Data were immediately tranferred.

Name resolving doesn't /seem/ to be the culprit: The netcat client has no
trouble quickly initiating a connection. And even if I catalog the DB2
node with IP address instead of a DNS name, the problem prevails.

Why might the DB2 client waiting? Can the client be set in some kind of
debug mode where it tells me what it's doing?

--
Troels

Troels Arvin wrote:

Do you specify the server address as a numeric URL or as a name? You could
be seeing DNS lookup delays. I resorted to entering the server into the
hosts (lmhosts) file and that also worked.

--
Will Honea

Will Honea wrote:
I have tried both. And when I catalog the node with a node name, I have
also tried putting the IP address of the node name in the hosts-file and
the lmhosts.sam-file. No improvement.

The problem seems to be rather similar to these problem descriptions:

http://forums.techarena.in/active-directory/1197307.htm

http://www.mombu.com/microsoft/windo...ctory/t-which-
process-trigger-lsassexe-for-using-lsarpc-to-start-lsarlook-563961.html

Unfortunately, there are no resolutions in the above cases.

In the network sniff, I see a strange call lsa_LookupNames4 call to the
Windows-machine's domain controller over a "LSARPC" protocol as soon as I
try to initiate the connection. This call is returned 14 seconds later.

At this point, a conversation is initiated with the database; this
proceeds quickly, but then another lsa_LookupNames4 call is made by the
client to its domain controller. After 21 seconds, the domain controller
responds again, and now, conversation with the database resumes.
Hereafter, thing proceed as expected, with good speed.

Connection termination is fast.

As mentioned in my initial post, things work quickly if I try simple TCP-
connections, e.g. using telnet from the client.

So it seems that the DB2 client waits for some strange and slow
correspondence with the domain controller, before completing the database
connection setup.

On the client, I have tried all of this, without the situation improving:
- UPDATE DBC CFG USING CLNT_KRB_PLUGIN NULL
- turn off OS firewall completely
- turn off "UAC" (a "security" "feature" in Windows Server 2008)
- explicitly turning off netbios over tcp (should be off, implicitly
in this setup)

--
Troels

"Troels Arvin" <troels (AT) arvin (DOT) dk> wrote

Are you cataloguing databases with authentication server?

Hello,

Mark A wrote:
No: I had cataloged it without specifying authentication (as I usually do
on unix/linux clients).

Setting it explicitly to SERVER made the problem go away (there are some
old clients which also need to connect to the server, so I think I cannot
improve to SERVER_ENCRYPT). Connections are now instantaneous.

Thanks, Mark!

--
Troels

Hi Troels,

If you don't specify the authentication method at the client, it defaults to
SERVER_ENCRYPT. If SERVER is specified at the server, the client should fall
back to SERVER. Maybe there is a bug in the negotiating process between Win
and Linux, which makes the negatiation sequence take so long.

What do you mean by old clients? Version 7? DB2 uses SERVER_ENCRYPT since v8.

--
Helmut K. C. Tessarek
DB2 Performance and Development

/*
Thou shalt not follow the NULL pointer for chaos and madness
await thee at its end.
*/

"Helmut Tessarek" <tessarek (AT) evermeet (DOT) cx> wrote

I know that for DB2 version 8, remote Type 2 connections were very slow
without AUTHENTICATION SERVER on the catalog db. This was true even if the
server was configured with SERVER authentication. Same was true for Linux
and AIX servers (Windows clients).

I don't know about later releases of DB2, because I have always used
AUTHENTICATION SERVER when cataloging remote databases ever since V8.

Hi Mark,

As I said: w/o the AUTHENTICATION SERVER on the catalog db, the client
defaults to SERVER_ENCRYPT. If the authentication on the server is SERVER, the
client has to re-negotiate the client authentication to SERVER.

Therefore, if you set the server to SERVER_ENCRYPT and don't use the
AUTHENTICATION clause on the catalog db, it will be as fast as both set to
SERVER (because in both cases no re-negotiation is necessary).

If you use remote clients you should either use SERVER_ENCRYPT, DATA_ENCRYPT,
DATA_ENCRYPT_CMP or SSL for authentication on the server (except, if you don't
care about security).
The connection establishment will be the fastest, when both authentication
methods (client and server) are set to the same value.

Because you probably always used authentication SERVER at the server, correct?

--
Helmut K. C. Tessarek
DB2 Performance and Development

/*
Thou shalt not follow the NULL pointer for chaos and madness
await thee at its end.
*/

"Helmut Tessarek" <tessarek (AT) evermeet (DOT) cx> wrote

We have very secure firewalls in our production envrionements. We cannot
even connect from a non-produciton machine to a producion DB2 server inside
our company.

Yes, we use the default authentication which is SERVER.

Hi Mark,

Ok, if you are not worried about people sniffining within your network, you
won't need any encryption. I just want to point out that it is a matter of
about 90 seconds to find out your user/pwd. If I get access to the instance
user...
Anyway, you are probably right. I'm usually not too concerned about security
within my own network as well, but depending on the system, I would probably
change my mind.
But just to make a stand, I am using either DATA_ENCRYPT or SSL, when I'm
connecting between WAN's or over the Internet.

In that case your solution is the fastest. :-)

--
Helmut K. C. Tessarek
DB2 Performance and Development

/*
Thou shalt not follow the NULL pointer for chaos and madness
await thee at its end.
*/