IBM Support

PM33467: TIMEOUT WHEN PINGING A SPECIFIC IP ADDRESS BUT TCP OR UDP CONNECTIONS TO SAME IP ADDRESS WORK FINE

A fix is available

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • A ping to a specific IP address will time out.  A TCP or UDP
    connection will work to the same IP address, such as a FTP or
    Telnet session.  TCPIP is receiving the ICMP packet, but does
    not reply to the packet.  A routing table entry is flagged as a
    destination cache which will be deleted soon, but there are
    actual routes assoicated with the entry.
    .
    VERIFICATION STEPS:
    1) Only ICMP traffic fails to the host
    2) A ctrace with option ROUTE option will show a route is
    returned, but the rtp_dcache_cleanup bit is on in the RTOP.
    .
    KEYWORDS:
    RTE RTOP route ping icmp timeout not responding
    

Local fix

  • Recycle Omproute to rebuild the routing table
    

Problem summary

  • ****************************************************************
    * USERS AFFECTED: All users of the IBM Communications Server   *
    *                 for z/OS Version 1 Release(s) 10, 11, and 12 *
    *                 IP:  PATHMTUDISCOVERY                        *
    ****************************************************************
    * PROBLEM DESCRIPTION: Outbound ICMP response is not sent but  *
    *                      TCP and UDP connections to the same     *
    *                      remote address work.  In order to hit   *
    *                      this problem PATHMTUDISCOVERY must be   *
    *                      enabled on the IPCONFIG profile         *
    *                      statement.                              *
    ****************************************************************
    * RECOMMENDATION:                                              *
    ****************************************************************
    Outbound ICMP response is not sent but TCP and UDP connections
    to the same remote address work.  In order to hit this problem
    PATHMTUDISCOVERY must be enabled on the IPCONFIG profile
    statement.
    
    PATHMTUDISCOVERY causes the TCP/IP stack to generate destination
    cache entries for every TCP connection remote IP address to
    hold the minimum MTU.  The garbage collection timer periodically
    deletes destination cache entries that are no longer in use.
    The delete process creates a chain of routing nodes to be
    deleted and then removes them one at a time.  During the removal
    process the routing nodes and associated information may shift.
    If a node in the destination cache delete chain is shifted it
    may result in the node not being removed from the routing
    tree.  When this occurs the rtp_dcache_cleanup flag will remain
    on and if a matching host route is added to the remote
    destination this flag will prevent the route from being usable
    by EZBIPFRH.
    The ICMP outbound response flow uses EZBIPFRH to locate a route
    to the destination and may result in discarded outbound ICMP
    response packets due to no selectable route being found.
    +-------------------------------------------------------------+
    + 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

  • EZBIPRTE and EZB6PRTE have been amended to remove destination
    cache entries one at a time from the routing tree.  The
    traversal of the routing tree is re-driven each time a node is
    deleted to ensure any shift resulting from the delete does not
    effect the next node selection or removal process.
    
    * Cross Reference between External and Internal Names
    

Temporary fix

Comments

  • ×**** PE12/02/06 FIX IN ERROR. SEE APAR PM57513  FOR DESCRIPTION
    

APAR Information

  • APAR number

    PM33467

  • Reported component name

    TCP/IP V3 MVS

  • Reported component ID

    5655HAL00

  • Reported release

    1A0

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2011-02-23

  • Closed date

    2011-03-25

  • Last modified date

    2012-03-05

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

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

    UK66154 UK66155 UK66156 PM37586

Modules/Macros

  • EZBIPRTE EZBPTREE EZB6PRTE
    

Fix information

  • Fixed component name

    TCP/IP V3 MVS

  • Fixed component ID

    5655HAL00

Applicable component levels

  • R1A0 PSY UK66154

       UP11/05/11 P F105

  • R1B0 PSY UK66155

       UP11/05/11 P F105

  • R1C0 PSY UK66156

       UP11/05/11 P F105

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":"1A0","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":"1A0","Edition":"","Line of Business":{"code":"","label":""}}]

Document Information

Modified date:
05 March 2012