VM65705: IPV4 ADDR LIST FOR LAYER2 VIRT NIC IS INCOMPLETE

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• After VMRELOCATE is used to move a VSWITCH guest from one member
  to another, the customer observed that it took longer than
  expected for QUERY VSWITCH output to include the associated IPv4
  address in the new location.
  We used TRSOURCE TYPE LAN to record network activity within the
  destination VSWITCH during and after relocation.  Analysis of
  the trace data revealed that the external switch was sending
  network traffic to this guest without the expected ARP Request
  broadcast.  Further investigation suggests that it is valid for
  a host to infer ownership from an inbound ARP Request (using the
  source MAC and IP from the request).
  VSWITCH logic currently monitors ARP Reply from a guest NIC, so
  we do not populate the VSWITCH IP cache unless some host or
  switch requests the IP address.  Eventually the external switch
  ARP cache times out and it is forced to generate the ARP request
  (which compels the guest to send the ARP reply so VSWITCH can
  detect it).  This delay is unpredictable.
  

Local fix

• Apply PTF
  

Problem summary

• ****************************************************************
  * USERS AFFECTED: Systems using ETHERNET (Layer2) VSWITCH or   *
  *                 Guest LAN are affected.                      *
  ****************************************************************
  * PROBLEM DESCRIPTION:                                         *
  ****************************************************************
  * RECOMMENDATION: APPLY PTF                                    *
  ****************************************************************
  The customer relocated (VMRELOCATE) a Layer2 VSWITCH guest and
  observed (via CP QUERY VSWITCH DETAILS) that no IP address was
  active.  Upon further investigation it was discovered that the
  guest was active on the network but it took hours for the IP
  address to be added to the LAN IP table.
  The existing support detects ARP Reply frames in an ETHERNET
  (Layer2) VSWITCH network and collects the source IPv4 addresses.
  These IPv4 addresses are reported in QUERY VSWITCH and Diagnose
  X'26C' output.
  In a typical network environment, any host in the broadcast
  domain uses an ARP Request to learn the owner (MAC address) of
  an IP address.  The owner sends an ARP Reply to the requestor
  where it can be used for subsequent TCP/IP traffic.
  In some networks, we have observed that the physical switch
  collects source IPv4 address from the ARP Request broadcast
  (seldom sending an ARP Request of its own).  This practice
  allows the VSWITCH guest to communicate for a significant
  period of time without sending an ARP Reply (which means the
  active IP address is unknown to CP).  In some cases the
  VSWITCH guest may be active for hours before the external
  switch solicits an ARP Reply.
  Reference:
  RFC 5227, Section 3 describes the reasons for preferring ARP
      requests over ARP replies.
  RFC 5944, Section 4.6 states that either requests or replies
      can be used for gratuitous ARPs
  

Problem conclusion

• This enhances Layer2 (ETHERNET) VSWITCH support by collecting
  active IPv4 addresses from ARP Request frames (in addition to
  ARP Reply frames).  In some networks IP addresses will be
  discovered hours earlier.
  When this APAR is applied, ARP frames will be used to update
  the Layer2 LAN IP table if they meet the following requirements:
  (1) Hardware type is x'0001' with a 6 byte address.
  (2) Protocol is x'0800' (IPv4) with a 4 byte address.
  (3) Source Protocol Address is NOT 0.0.0.0.
  Notes:
  - This only applies to an ETHERNET network (Layer2).  The
    IP addresses collected from ARP frames will be persistent
    for VM guests coupled to the VSWITCH/LAN.  They will be
    removed when another host claims the IP address, or the
    interface is reset.
  - In a Layer2 network, datagrams are delivered based on
    destination MAC address (not IP address).  The LAN IP table
    exists for usability and problem determination.
  

Temporary fix

• FOR RELEASE VM/ESA CP/ESA R540 :
  PREREQ: VM64635 VM65601 VM65626 VM64918
  CO-REQ: NONE
  IF-REQ: NONE
  FOR RELEASE VM/ESA CP/ESA R620 :
  PREREQ: VM65042 VM65601 VM65626
  CO-REQ: NONE
  IF-REQ: NONE
  FOR RELEASE VM/ESA CP/ESA R630 :
  PREREQ: VM65583 VM65601
  CO-REQ: NONE
  IF-REQ: NONE
  

Comments

APAR Information

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

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

  UM34747 UM34748 UM34749

Modules/Macros

• HCPDGQ   HCPIPN   HCPNDQ   HCPVQA   HCPVQS
  

Fix information

• Fixed component name

  VM CP

• Fixed component ID

  568411202

Applicable component levels

• R540 PSY UM34747

     UP16/02/18 I 1000

• R620 PSY UM34748

     UP16/02/18 I 1000

• R630 PSY UM34749

     UP16/02/18 P 1602

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.