II11926: IBM TCP/IP CS FOR OS/390 V2R5 AND V2R6 FAULT TOLERANCE APARS AND OSA-2 CONFIGURATION TIPS FOR TCP/IP PASSTHRU MODE

APAR status

• Closed as canceled.

Error description

• This informational APAR is intended to brief customers on two
  recent APARs  to the eNetwork  Communications  Server, in the
  area of fault tolerance: PQ25476 (UQ29215 for HTCP340, UQ29216
  for HTCP350) and PQ23444 (UQ29217 for HTCP340, UQ29218 for
  HTCP350). This informational APAR also provides tips for OSA-2
  configuration,enabling certain aspects of the PQ23444 function.
  
  PQ25476 Overview
  ================
  
   PQ25476  corrects function within the routing layer that deals
   with recovery  of  TCP connections in  existence  at the time
   of a route failure. Without PQ25476, TCP-layer  connections in
   existence at the time of the route failure will timeout,
   rather than being immediately recovered  over  the  backup
   route.  PQ25476  corrects this function, such that transport-
   layer connections are immediately rerouted over a suitable
   backup route (if one exists).
  
  PQ23444 Overview
  ================
  
   PQ23444 corrects an existing flaw with ARP in certain config-
   urations, and provides some new recovery function.  This same
   discussion is applicable to CS for OS/390 V2R7, which will be
   addressed via a separate APAR (PQ26689), due to intersect with
   the newly-announced Gigabit Ethernet support.
  
   The ARP flaw corrected by PQ23444 is visible in configurations
   where multiple LCS links onto the same LAN are defined.  In
   such a configuration, ARP REQUEST broadcasts will be received
   on each of OS/390's interfaces to the LAN, and each interface
   will recognize that the ARP request is targeted for one of
   OS/390's HOME Addresses. Multiple ARP responses will then be
   generated (one from each receiving interface), where each ARP
   response maps the target IP address (that being queried in the
   ARP request) to the MAC address of the receiving interface.
   (That is, a series of ARP responses will be sent, where each
   maps the target IP address to a different MAC address.)
  
   While connection establishment and data transfer are still
   functional with this ARP flaw, this 'multiple ARP response'
   behavior has caused some problems with certain LAN-monitoring
   software packages.
  
   With PQ23444 applied, ARP responses will now be generated in
   accordance with the following:
  
   - If the interface targeted by the ARP Request is active, it
     alone will generate the ARP response.  Other interfaces
     receiving the broadcast will discard the ARP.
  
   - If the interface targeted by the ARP Request is inactive,
     one of the other interfaces  on  the LAN  will automatically
     take over responsibility  for  answering  ARPs  on  behalf
     of the inactive interface.  No special TCP/IP configuration
     statement is required for defining backup links;  this
     information is learned dynamically at link initialization
     time.
  
   At the time that one of the interfaces to the LAN fails, the
   link chosen (by CS for OS/390) as backup will broadcast a
   'gratuitous' ARP, to immediately inform  stations on the LAN
   that the failing IP address is now reachable via the backup
   link.  In this way, fault tolerance is achievable on the LAN
   without requiring a dynamic routing protocol. Note that both
   PQ25476 and PQ23444 are required in order to achieve this
   fault-tolerance, and that this fault-tolerance applies for all
   LANs connected to CS for OS/390 via LCS Devices (including
   OSA-2 ATM LAN Emulation).
  
   Customers that employ bridging between different LAN protocols
   (e.g.,FDDI to Ethernet) should apply PQ25956 (UQ30543/UQ30544)
   along with PQ23444.
  
  ===============================================================
  OSA-2 Configuration Tips
  with Port Sharing in TCP/IP Passthru Mode.
  ===============================================================
  
   In customer shops that implement 'OSA Port Sharing', some
   decisions regarding configuration of the OSA Address Table
   (OAT) must be made.
  
   Specifically, in Port Sharing Mode, the OAT must be configured
   with all destination IP addresses that are to be handled by
   the TCP/IP stacks sharing the port.  Datagrams (and ARP
   packets) that do not match these configured IP addresses will
   either be discarded by the adapter, or, if a PRIMARY or
   SECONDARY entry is defined in the OAT, these unrecognized
   packets will be presented to the PRIMARY or SECONDARY TCP/IP
   Stacks. (See 'Planning for the System/390 Open Systems Adapter
   Feature', GC23-3870-07, section 6.4.)
  
   IBM recommends the OSA Address Table be configured as follows:
  
  (1) Always configure an OAT Entry containing the TCP/IP HOME
      address associated with the LINK defined in the TCP/IP
      Profile.
  
  (2) If Virtual IP Addressing (VIPA) is in use on the LAN,
      configure OAT Entries that contain the TCP/IP stack's
      Virtual IP Address(es).
  
  (3) OSA-2 will allow two TCP/IP Stacks sharing the port to
      act as IP routers: a PRIMARY Stack and a SECONDARY Stack.
      When a packet with an unrecognized (not configured)
      destination IP address is received, OSA-2 will present the
      packet to the TCP/IP stack configured as PRIMARY, if that
      stack is available.  If the PRIMARY stack is not available,
      OSA-2 will present the packet to the stack configured as
      SECONDARY, if that stack is available.
  
      To enable a TCP/IP stack to act as a router, then, one of
      the OAT entries defined in step (1) must be defined as
      PRIMARY, and the TCP/IP stack acting as PRIMARY must enable
      IP FORWARDING (IPCONFIG DATAGRAMFWD in the TCP/IP Profile).
      Likewise, if a second stack is to backup the PRIMARY OS/390
      router, one of the OAT entries defined in step (1) must be
      configured as SECONDARY, and the stack acting as SECONDARY
      must enable IP FORWARDING.
  
   Bearing in mind that only 16 defined IP addresses can exist
   for all partitions sharing the PORT, if you haven't used all
   16 IP addresses after steps (1) and (2) above, then any
   remaining OAT Entries should be configured as follows:
  
  (4) 'Same-Network' Fault Tolerance without requiring
       Dynamic Routing:
  
   If the fault-tolerance described above in "PQ23444 Overview"
   is desired, an OAT Entry containing the HOME IP address for
   each potential backup link needs to be defined in the OAT.
   For example:
  
         +--------+--------+
         |        |        |   In this example, the customer has
         |OS/390-1|OS/390-2|   a "flat" network, where traffic
         |        |        |   flows directly between communicat-
         +-+-----++-+-----++   ing endpoints, with no need for an
        A.1|  A.2|  |A.3  |A.4 intermediate router.  The custom-
           |     |  |     |    er has two S/390 partitions, which
           | +---|--+     |    share two OSA-2 ports on the LAN.
           | |   |        |
           | |   +--+     |
           | |      |     |
           | |      |     |    Since no dynamic routing protocols
           | |      |     |    are in use, fault tolerance is
           V V      V     V    achieved at the link layer (i.e.,
         +--------+--------+   in the ARP function), rather than
         | OSA    |  OSA   |   at the network layer (IP routing
         | Port 1 |  Port 2|   function).
         +--------+--------+
                  |
                 -|-
                 -|-
                Network A
  
   The OSA Address Tables for the two OSA's are configured as
   follows:
  
   -------OSA Port 1 ---------   ----------OSA Port 2 -----------
   OAT                              OAT
   Ent#  IP@  Comment               Ent#  IP@  Comment
   ------------------            --------------------------------
   1     A.1  partition 1's          1    A.2  partition 1's
              home IP address                  home IP address
              for Port 1.                      for Port 2.
   2     A.3  partition 2's          2    A.4  partition 2's
              home IP address                  home IP address
              for Port 1.                      for Port 2.
   3     A.2  In the case of a       3    A.1  In the case of a
              Port-2 failure,                  Port-1 failure,
              Port-1 will takeover             Port-2 will take-
              for this IP address.             over for this IP@.
   4     A.4  In the case of a       4    A.3  In the case of a
              Port-2 failure,                  Port-1 failure,
              Port-1 will takeover             Port-2 will take-
              for this IP address.             over for this IP@.
  
  
   Each of the TCP/IP stacks (the stack in each partition)
   configures two LCS device/link pairs for Network A.  One
   Dev/Link accesses Network A via OSA Port 1, and the other via
   OSA Port 2.
  
   Assume now that traffic is flowing on Network A for IP address
   A.1, and OSA Port 1 fails.  The TCP/IP Stack in partition 1
   will detect the Port-1 failure, so a gratuitous ARP request
   will be broadcast out the second link (via Port 2), informing
   all LAN stations that IP address A.1 is now reachable via the
   Port-2 MAC address.  Likewise, the TCP/IP Stack in partition 2
   will detect the Port-1 failure,and will broadcast a gratuitous
   ARP out its Port-2 link,informing stations that IP address A.3
   is now reachable via the Port-2 MAC address.
  
   *VIPA Note:Virtual IP Addressing was originally intended to be
    used exclusively in conjunction with dynamic routing proto-
    cols.  The eNetwork Communications Server documentation
    recommends AGAINST configuring VIPA addresses matching any
    subnet addresses to which the node is attached, and a natural
    consequence of this recommendation is that ARP requests will
    never flow for VIPA addresses (indeed, until PQ23444,
    ARP'ing a VIPA Address was not supported).
  
    With PQ23444,eNetwork Communications Server now supports VIPA
    ARP, and customers with flat networks (like the above) may
    find using VIPA in a flat network to be a convenient method
    for achieving fault-tolerance.  For instance (using the above
    configuration), the TCP/IP Stack in partition-1 might define
    a VIPA address of A.5, and the partition-2 stack might define
    VIPA A.6.  The OSA Address Tables would be updated to contain
    entries for these VIPA addresses.  Stations on the LAN would
    always reach OS/390-1 via VIPA A.5, and OS/390-2 via VIPA A.6.
    Since the VIPA addresses are configured on Network A, ARPs
    will flow for the VIPA addresses, and the ARP Takeover
    function in PQ23444 will provide non-disruptive fault-
    tolerance in the case of an OSA failure.  Note that the ARP
    Takeover function may not complete as quickly for a VIPA
    address as it would for a real IP address, as the takeover
    function for a VIPA address is triggered only upon reception
    of an ARP request looking for that VIPA address.  The per-
    formance of the ARP Takeover function for VIPA addresses will
    be improved in V2R7, with APAR PQ26689.
  
  (5) When network-layer fault tolerance (i.e., IP rerouting) is
      desired, and an OSA-2 is to backup another interface, and
      application traffic is targeted to the OS/390 home IP
      address of this other interface, as in:
  
         +--------+--------+
         |        |        |  CLAW (ESCON)<-----+
         |OS/390-1|OS/390-2|---------------+    | traffic to/from
         |        |        |ip@ B          |    | Network E norm-
         +-----+--+--+-----+               |    V ally flows over
               | OSA |                     |      this link
               +--+--+                     |
         ip@=A.1  |ip@=A.2                 |
    (for OS/390-1)|(for OS/390-2)          | ip@ C
                 -|-                   +------+
                  |--------------------|RTR A |
                 -|             ip@ A.3+---+--+
                  |                        |ip@ E
                 -|-                       |
                  |                       -|-
                  |                        |
                  |                       -|-
                Network A                  |
                                          Network E
  
  
      In this example, traffic is generated from Network E, dest-
      ined for OS/390-2 ip@ B.  This traffic normally flows over
      the ESCON channel to OS/390-2's B interface.  If this ESCON
      link fails, and dynamic routing is in use on OS/390-2 and
      on RTR A, then RTR A may reroute traffic for ip@ B over
      Network A.  In order for the OSA-2 to pass this traffic up
      to OS/390-2, an OAT Entry must be defined for ip@ B (or the
      OAT Entry for OS/390-2 ip@A.2 needs to be configured as
      PRIMARY).
  
      Note that this fourth backup scenario is not recommended.
      VIPA addressing is a more elegant solution (i.e., traffic
      should be targeted to the VIPA address, rather than to ip
      address B).
  KEYWORDS: TCPIPINFO ROUTINGX
  

Local fix

Problem summary

Problem conclusion

Temporary fix

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

Fix information

Applicable component levels