A fix is available
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
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