TCP/IP source addressing problems in V4.0F with PK7.

From: Derek Haining (Derek.Haining@iLAN.com)
Date: Thu Jan 22 2004 - 15:18:50 EST


Configuration: Tru64 UNIX V4.0F w/ PK7.
Two DS20s using ASE clustering.
Each node has a "box" IP address.
Alias IP addresses defined for "services".

The primary problem:

An application on one of these two nodes attempts to connect to another
system
via a TCP/IP connection. This other system is behind a firewall that allows
packets from the box's specific IP address to pass through the firewall.

For some reason the source IP address that the application gets is sometimes
NOT the box IP address, but an alias address. As a result the application
cannot connect to the other system.

Note that there are several V4.0F clusters configured in this manner, but
this
problem has only recently surfaced on a particular system.

*UPDATE* Since I originally posted this query to the ITRC, this problem has
          surfaced on another cluster.

The secondary problem:

In the release notes for patch kit 7 there are several notes which seems to
indicate that this problem has been fixed. To wit:

- Fixes a problem when a default IP address and a cluster virtual IP address
  are interchanged after a network restart. The default interface address is
  used by all outgoing traffic and the alias address is only usable for the
  incoming packets. (Patch 859.00)
- Fixes a problem when using multiple subnets on a network interface; APR
  request packets sent by the system will contain the IP alias address in
  the sender field when that alias is in the same subnet as the requested IP
  address. (Also Patch 859.00)
- Fixes a problem that sometimes caused the system to select the incorrect
  IP source address for out-going connections when using IP aliases and
  subnetting on a network interface. (Sounds >really< good, and also in
  Patch 859.00)

The problem is that PK7 is installed. I looked at the Patch Kit 8 Release
Notes and saw these same patch descriptions for Patch 1493.00 and thought
"it's fixed", but when I saw them in the PK7 Release Notes I began to
wonder.

How do I tell if the PK7 patch has been patched in PK8? That is, it seems
that the patch in PK7 doesn't fix the problem. Does the change of patch
number in PK8 indicate that the *new* patch actually fixes the problem?

PK8 >also< has this additional note that appears to be relevant.

- Corrects a problem which could result in an alias IP address being
  incorrectly promoted to being the primary address when another alias
  is removed. (Patch 1493.00 also.)

Another problem is that we have not yet figured out if there is a specific
set of actions that results in the alias address being used, so we don't
know if this description fits our problem.

Now this problem was seen once before about 2 months ago on one member of
another cluster. The member was rebooted and the problem has not been since
since it showed up on this cluster.

So the questions are: what is the likely cause of this problem. (I know, a
bug in the TCP/IP stack.) Has the fix in PK7 been fixed in PK8? (I don't
know.) Help!

This is what dupatch says:

# dupatch -track -type patch | grep 00859
Patch 00859.00 - Security (SSRT0563U, SSRT0676U, SSRT0742U)

Hoping that someone an help.



This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:49:49 EDT