PM95548: DELETING OR MOVING A DVIPA IN SAME SUBNET AS PARALLEL OSPF INTERFACES RESULTS IN CONNECTIVITY LOSS OF DIRECT SUBNET ROUTES

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• If using the VIPARANGE statement to add a DVIPA that is in the
  same subnet as the parallel OSPF interfaces (for example, OSAs),
  the DVIPA implicit host route will be added to the routing
  tables in OMPROUTE and in the TCPIP stack. The DVIPA host route
  will be advertised to the OSPF network according to the setting
  of the Advertise_VIPA_Routes parameter on the corresponding
  OSPF_INTERFACE statement for the DVIPA.
  
  When the DVIPA is deleted or moved to another TCPIP stack,
  OMPROUTE incorrectly searches for a backup physical interface
  that is in the same subnet as the DVIPA's and deletes the direct
  subnet route attached to the primary interface used to carry the
  OSPF traffic. As a consequence, connectivity loss to the local
  subnet occurs and routing results can be unpredictable.
  
  A report from the NETSTAT ROUTE will show the missing direct
  subnet route on a primary parallel network interface and might
  show the other direct subnet route on the backup parallel
  network interface.
  
  Additional symptoms:
  --------------------
  If the missing direct subnet route(s) were observed on the
  parallel network interfaces (e.g. OSAs) and if they were
  recycled in attempt to restore the direct subnet route(s),
  OMPROUTE might lose the "backup state (2)" assigned to one
  of the parallel interfaces.  In this case, the "backup state"
  might change to match the other interface's state (e.g. 64).
  As a consequence, OMPROUTE's adjacency formations with the
  neighbors might not succeed.
  
  Before the recycles of the parallel interfaces, a report of
  the configured OSPF interfaces might look like:
  
    F OMPROUTE,OSPF,IF
    EZZ7849I INTERFACES
    IFC ADDRESS PHYS       ASSOC. AREA   TYPE STATE  #NBRS  #ADJS
    9.1.1.1     OSAQDIO84  0.0.0.0     BRDCST     2      3      0
    9.1.1.2     OSAQDIO24  0.0.0.0     BRDCST    64      3      2
  
  OSAQDIO84 is the backup (state 2) and OSAQDIO24 is the primary
  as a BDR (state 64). After the recycles of these interfaces,
  the backup state was changed to state 64, also a BDR which
  should not have occurred because this can cause confusion to
  the OSPF neighbors on what the designated routers are. Also,
  OMPROUTE would no longer have a backup interface in case of a
  failure on one of these interfaces. A report of the configured
  OSPF interfaces might look like the following:
  
     F OMPROUTE,OSPF,IF
     EZZ7849I INTERFACES
     IFC ADDRESS PHYS       ASSOC. AREA   TYPE STATE  #NBRS  #ADJS
     9.1.1.1     OSAQDIO84  0.0.0.0     BRDCST    64      3     0
     9.1.1.2     OSAQDIO24  0.0.0.0     BRDCST    64      3      2
  
  Here, both parallel OSPF interfaces share the same state (64)
  for a backup designated router (BDR), hence the confusion.
  
  Note: This fix applies to IPv4 parallel OSPF interfaces only.
        The fix is not needed for IPv6 parallel OSPF interfaces
        because different logic involving a special interface
        property flag (SPI_MULTIONLINK) is used. Interfaces
        without this flag (for example, static or dynamic VIPAs)
        are not used in the search for backup interfaces.
  

Local fix

• Code non-replaceable static and direct subnet routes for the
  parallel network interfaces (for example, OSAs) in BEGINROUTES
  or GATEWAY statement in the TCPIP profile.
  
  KEYWORDS:
  VIPADYNAMIC VIPARANGE DVIPA VIPA PARALLEL OSPF OMPROUTE
  MODDVIPA SUBNET EZAORSPF SPFFNDALT BEGINROUTES GATEWAY
  MULTIPATH OSPF EZZ7921I EZZ7913I BACKUP MULTIONLINK OSA
  

Problem summary

• ****************************************************************
  * USERS AFFECTED: All users of the IBM Communications Server   *
  *                 for z/OS Version 1 Release(s) 12 and 13 IP   *
  ****************************************************************
  * PROBLEM DESCRIPTION: A delete of a DVIPA in same subnet      *
  *                      as external parallel OSPF network       *
  *                      interfaces (e.g. OSAs) can result       *
  *                      in a network outage from unexpected     *
  *                      deletion of OSPF routes attached        *
  *                      to the parallel network interfaces.     *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  
  
  
  
  
  
  
  
  +-------------------------------------------------------------+
  + Please check our Communications Server for OS/390 homepages +
  + for common networking tips and fixes.  The URL for these    +
  + homepages can be found in Informational APAR II11334.       +
  +-------------------------------------------------------------+
  

Problem conclusion

• EZAORSPF has been amended to ignore VIPAs (static
  or dynamic) from the search for alternate parallel
  network interfaces after a VIPA in the same subnet
  as those network interfaces gets deleted.
  
  * Cross Reference between External and Internal Names
  EZAORSPF (SPF     )  EZAORSPF (SPF     )
  

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:

  PM98428 UK98419 UK98420

Modules/Macros

• EZAORSPF
  

Fix information

• Fixed component name

  TCP/IP V3 MVS

• Fixed component ID

  5655HAL00

Applicable component levels

• R1C0 PSY UK98419

     UP13/11/23 P F311

• R1D0 PSY UK98420

     UP13/11/23 P F311

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.