75 ways to demystify DB2: #18: Techtip: Why the DB2 HADR is not using the assigned port numbers ONLY ?

Body

When using DB2 HADR the  local service/port (HADR_LOCAL_SVC) and remote service/port (HADR_REMOTE_SVC)  are defined. But, why  netstat output shows that hadr is using other port numbers too ?

Both HADR_LOCAL_SVC and HADR_REMOTE_SVC are used as the lower  level TCP server listener port numbers only.  The client side of the TCP uses free ports available from OS from that side.

HADR uses TCP server and TCP client at the lower level. In this context, one HADR db side listens on its hadr_local_svc port as TCP server, the other side db connects to it, as TCP client. When a connection is established, the server end's port is hadr_local_svc, the client side port is assigned by OS. It is typically a random port between 32k and 64k. It can be  seen from "netstat -a", search for the local svc port.  Two entries could be found there, one in "listen" state and one in "established" state. The established one will show the assigned local port.

So,  with  HADR configuration the TCP server side port is set.  But, the client side port number range cannot be specified.  There is currently no config for this number and it's not easy to create one.
Not  being able to specify the TCP client side port range can cause inconveniences when there might be a need to specify port range for security reasons. But, this is working as designed from DB2 HADR design point of view

Example,

Database HADR config :

HADR database role                                      = PRIMARY
 HADR local host name                  (HADR_LOCAL_HOST) = host1
 HADR local service name                (HADR_LOCAL_SVC) = 5001
 HADR remote host name                (HADR_REMOTE_HOST) = host2
 HADR remote service name              (HADR_REMOTE_SVC) = 5002
 HADR instance name of remote server  (HADR_REMOTE_INST) = db2inst2
 HADR timeout value                       (HADR_TIMEOUT) = 300
 HADR target list                     (HADR_TARGET_LIST) =
 HADR log write synchronization mode     (HADR_SYNCMODE) = SUPERASYNC

 HADR database role                                      = STANDBY
 HADR local host name                  (HADR_LOCAL_HOST) = host2
 HADR local service name                (HADR_LOCAL_SVC) = 5002
 HADR remote host name                (HADR_REMOTE_HOST) = host1
 HADR remote service name              (HADR_REMOTE_SVC) = 5001
 HADR instance name of remote server  (HADR_REMOTE_INST) = db2inst1
 HADR timeout value                       (HADR_TIMEOUT) = 300
 HADR target list                     (HADR_TARGET_LIST) =
 HADR log write synchronization mode     (HADR_SYNCMODE) = SUPERASYNC

From netstat (primary side) :

tcp4       0      0  xxx.xxx.xxx.xxx.5001     xxx.xxx.xxx.xxx.62000   ESTABLISHED

From db2diag.log  file :

2015-03-14-12.57.41.270551-240 I44453A466           LEVEL: Warning
PID     : 6357010              TID : 30585          PROC : db2sysc 0
INSTANCE: db2inst1              NODE : 000           DB   : mydb
HOSTNAME: host1
EDUID   : 30585                EDUNAME: db2hadrp.0.1 (mydb) 0
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrHandleRemoteConn, probe:30160
MESSAGE : TCP socket connection accepted.  Remote Host: xxx.xxx.xxx.xxx Port:
          62000

So, port number 62000  is the TCP client side port number  and not the TCP server side assigned port number of 5001 or, 5002.  The port number 62000 was picked up randomly at TCP client side from  free ports available at OS level.