PH70620: NETWORK EXPRESS (OSH) ARP REQUESTS ARE FAILING EQENET/EQDIO ADDARPCACHE FAILURE 2019

APAR status

• Closed as program error.

Error description

• OSH ARP requests are failing with a hardware error code 0x2019
  (seen in systcpip exception trace records). The ARP Requests are
  being rejected by OSA firmware because the source and target IP
  addresses are not on the same subnet. In this case a static VIPA
  was used as the source address in the ARP request which was in a
  different subnet then the destination IP address. This will have
  different effects on IP packet delivery. For example TCP traffic
  will be re-transmitted, and hopefully delivered to the
  destination using a different route over a different interface.
  PINGs will timeout, and UDP packets will not delivered
  

Local fix

• none
  
  additional symptoms:
  
  systcpip exception record
  XXX     VTAM      1001022A  10:59:28.348110  !Unexpected EqeNet
  Set Assist Pa
  HASID..00CC      PASID..00CC      SASID..00CC      USER...TCPIP
  TCB....00000000  MODID..EZBIFIND  REG14..41372B42
  DUCB...2900240D
  CID....00000000  PORT...0         CPUA...12
  IPADDR. 0.0.0.0
  ADDR...00000000  00000000_7F358068  LEN....000010  Device Name
   +0000  D6E2C1C9  C6F1F040  40404040  40404040   | OSAXYZ|
  ADDR...00000000  00000050_002D6FB8  LEN....000044  Inbound
  EqeNet Ipa Control Rec
   +0000  B3000024  20190100  13040000  0000007B
          00000000  00000001  002C0004  00000101
   +0020  00030000  00000000  5A49424F  43F10000
          srcip     dstip     00000000  00000000
   +0040  FFFFFF00 (subnet Mask)
  
  ADDR...00000000  00000050_002D6FB8  LEN....000001  EQENET Ipa
  Command    +0000  B3
  
  ADDR...00000000  00000050_002D6FBC  LEN....000002  EqeNet
  SetAssist Parms Return C
           +0000  2019
  
  netstat arp shows zero hardware/mac addresses:
  
  INTERFACE: OSAXYZ             ETHERNET: xxxxxxxxxxF1
  QUERYING ARP CACHE FOR ADDRESS y.y.y.60
  INTERFACE: OSAXYZ             ETHERNET: 000000000000
  QUERYING ARP CACHE FOR ADDRESS y.y.y.90
  INTERFACE: OSAXYZ             ETHERNET: 000000000000
  QUERYING ARP CACHE FOR ADDRESS y.y.y.1
  INTERFACE: OSAXYZ             ETHERNET: xxxxxxxxxx87
  

Problem summary

• ****************************************************************
  * USERS AFFECTED: All users of the IBM Communications Server   *
  *                 for z/OS 2.5, 3.1 and 3.2                    *
  *                 Network Express (OSH)                        *
  ****************************************************************
  * PROBLEM DESCRIPTION: Outbound IPSEC encrypted packets being  *
  *                      transmitted over EQENET interfaces are  *
  *                      being discarded by TCP/IP due to ARP    *
  *                      resolution failures.                    *
  *                                                              *
  *                      E9175/K                                 *
  ****************************************************************
  * RECOMMENDATION: Apply PTF                                    *
  ****************************************************************
  The problem is summarized as follows:
  1) Failure occurs when outbound packet initiating ARP resolution
     to target IP address is using IPSEC encryption.
  2) The IPSEC code path led to the IP assist ARP request being
     invalidly built by TCP/IP.
  3) The source IP address is being set to a source VIPA address
     which is outside the destination IP address subnet.
  4) This leads to the ARP IP assist being rejected by OSA
     firmware.
  5) This causes all packets waiting for ARP resolution to this
     next hop IP address to be discarded causing packet loss,
     delays and potential retransmissions.
  
  Notes: For non-IPSEC packets which initiate ARP processing, the
         ARP cache is correctly resolved and no problems are
         encountered.
         Environments with heavy IPSEC usage increases the
         probability of repeatedly hitting this problem which
         may cause loss of connectivity.
  

Problem conclusion

• ezbifarp.plx - Has been corrected to always set the source IP
  address for outbound ARP requests to the home IP address of
  the EQENET (OSH) interface.
  

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:

  UO07394 UO07395 UO07396

Modules/Macros

• EZBIFARP
  

Fix information

• Fixed component name

  TCP/IP MVS

• Fixed component ID

  5655HAL00

Applicable component levels