IBM Support

PI67701: EZD0834I ENCAPSULATION FAILED RSN=9 IN SWSA IPSEC ENVIRONMENT

A fix is available

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • EZD0834I Encapsulation failed with rsn=9 in SWSA IPSEC
    environment may be experienced after Distributed DVIPA addresses
    move from primary to backup and back to primary. The rsn=9
    indicates that a peer tunnel using SWSA has failed to obtain an
    ESP seq# from the EZBDVIPA CF structure.  A scenario exists
    where IPSEC tunnels existed between a Distributed DVIPA and a
    remote client. This DVIPA moved to a backup LPAR. In SWSA
    environment, the backup LPAR is responsible for initiating a new
    tunnel between itself and the client that was existing in the
    tunnel that moved. When a stack takes over a DVIPA but is unable
    to reestablish a tunnel from the CF data and the DVIPA moved
    back to the prmary, 30 minutes later the prior backup stack
    will delete the seq number data from the CF.... even if it no
    longer owns the DVIPA. When this failure occurred, the following
    message will be seen in the IKED syslogd log on the
    DVIPA owner (backup) trying to re-establish the tunnel from
    itself (dvipa x.x.x.x)  to the remote client (y.y.y.y):
    
    EZD0917I Could not find applicable KeyExchangeRule - LocalIp :
    x.x.x.x RemoteIp : y.y.y.y
    
    This results in corrupted tunnel info pointing to EZBDVIPA
    structure info (ESP seq# ) that either no longer exists or has
    been used by different tunnels created in the sysplex after the
    data was deleted by the backup LPAR.
    
    additional symptoms:
    
    A takeover of a DVIPA happens & tunnels can not be
    re-established. This could be due to policy issues, routing
    issues, etc. Usually, you will see the following messages in
    the IKED syslogd output:
    
    - EZD1036I Phase 2 security association for DVIPA %s is not
      re-established with remote security endpoint %s
    - EZD1051I Phase 1 security association for DVIPA %s is not
      re-established with remote security endpoint %s
    
    In less than 30 minutes from the point where the DVIPA was taken
    over, the DVIPA ownership is given back (or goes to another
    stack) & the tunnels are re-established. Usually see messages
    like:
    
    - EZD1052I Phase 1 security association for DVIPA %s is
      re-established with remote security endpoint %s  OR
    - EZD1034I Phase 1 security association for DVIPA %s is already
      re-established with its remote security endpoint %s
    - EZD1097I Phase 2 security association for DVIPA %s is
      re-established with remote security endpoint %s
    
    EZD0834I messages begin occurring after 30 minutes from the
    original takeover. May not be immediately after 30 minutes
    since it depends on what types of entries are deleted. And it
    can have a cascading effect. So the local fix of rebuilding the
    EZBDVIPA CF structure should be taken
    

Local fix

  • rebuild the EZBDVIPA CF structure by issuing the following
    command:
    
    SETXCF START,REBUILD,STRNAME=EZBDVIPA
    

Problem summary

  • ****************************************************************
    * USERS AFFECTED:                                              *
    * All users of the IBM Communications Server for z/OS Version  *
    * 2, Releases 1 and 2: IP Security Sysplex Wide Security       *
    * Associations (SWSA)                                          *
    ****************************************************************
    * PROBLEM DESCRIPTION:                                         *
    * IPSec encapsulation failures occur due to the incorrect      *
    * deletion of sequence number entries from the EZBDVIPA        *
    * structure in the coupling facility.                          *
    ****************************************************************
    * RECOMMENDATION:                                              *
    * Apply PTF                                                    *
    ****************************************************************
    When IPSec is being used within a sysplex to protect traffic
    (Sysplex wide security associations (SWSA)), the following
    series of events can lead to the incorrect deletion of sequence
    number entries from the EZBDVIPA structure:
    1. A DVIPA is defined on TCPIP stack A and there are active
    tunnels protecting traffic to the DVIPA
    2. The DVIPA moves to backup TCPIP stack B.
    3. Attempts to renegotiate tunnels for the DVIPA fail.
    4. In less than 30 minutes (from 2.) the DVIPA moves again,
    either back to the original TCPIP stack A or another TCPIP stack
    in the sysplex.
    5. The new DVIPA owner successfully negotiates new tunnels. Old
    tunnel entries are removed from the EZBDVIPA coupling facility
    structure and new tunnel entries are added.
    6. TCPIP stack B, which was unable to renegotiate the tunnels,
    deletes tunnel entries from the EZBDVIPA structure based on
    stale information. This potentially deletes sequence number
    entries that are needed for active tunnels.
    
    Encapsulation failures might be seen immediately or at a later
    time.
    

Problem conclusion

  • The SWSA processing has been amended to prevent the deletion of
    EZBDVIPA entries based on stale information, following a
    takeover where the tunnels could not be re-negotiated.
    

Temporary fix

Comments

APAR Information

  • APAR number

    PI67701

  • Reported component name

    TCP/IP V3 MVS

  • Reported component ID

    5655HAL00

  • Reported release

    210

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2016-08-17

  • Closed date

    2016-09-29

  • Last modified date

    2017-02-23

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

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

    UI41267 UI41268

Modules/Macros

  • EZBXFDTN EZBX6DVI EZBXFDVI
    

Fix information

  • Fixed component name

    TCP/IP V3 MVS

  • Fixed component ID

    5655HAL00

Applicable component levels

  • R220 PSY UI41268

       UP16/12/02 P F612

  • R210 PSY UI41267

       UP16/12/02 P F612

Fix is available

  • Select the PTF appropriate for your component level. You will be required to sign in. Distribution on physical media is not available in all countries.

[{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SG19M","label":"APARs - z\/OS environment"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"210","Edition":"","Line of Business":{"code":"","label":""}},{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SSCY4DZ","label":"DO NOT USE"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"210","Edition":"","Line of Business":{"code":"","label":""}}]

Document Information

Modified date:
23 February 2017