PM86331: OUTBOUND PINGS (IPV4 ICMP) CAN BE INADVERTENTLY SUBJECTED TO POLICY-BASED ROUTING TABLES FOR UNEXPECTED RESULTS

A fix is available

Subscribe

You can track all active APARs for this component.

APAR status

  • Closed as program error.

Error description

  • When using policy-based routing (PBR) tables, unexpected results
    can occur for the outbound pings using IPv4 ICMP protocol. If
    a PBR table is defined and if the PMTU option is not specified
    (to allow fragmentation) in the ping command, the outbound ICMP
    packet is inadvertently subjected to the PBR table. If a route
    was found from the PBR table that matches the ping's target IP
    address, the outbound ping packet will be allowed to be sent
    over the selected interface and the main IP routing table is not
    used. If no route was found from the PBR table, then the main
    IP routing table will be searched when allowed according to the
    UseMainRouteTable [YES] parameter as coded on the RoutingAction
    rule. In either case if no matching route was found, an error
    message with errno x'46A'(1130) for EHOSTUNREACH and reason code
    74420291 will be issued as follows:
    
       EDC8130I Host cannot be reached
    
    The unexpected behavior occurs when the ping is allowed by PBR
    but is not allowed by the main IP routing table. As a general
    rule, the outbound ICMP packets for the pings should not be
    using the PBR tables but rather the main IP routing table. PBR
    tables are restricted to TCP and UDP protocol packets only.
    
    PBR was inadvertently used for the pings because the protocol
    parameter passed to the obtain route handle routine (EZBIPORH)
    was set to UDP rather than RAW for ICMP packets.
    

Local fix

  • Specify the PMTU option in the ping command to force the main
    IP routing table to be used instead of the PBR tables provided
    that the UseMainRouteTable [YES] parameter is coded on the
    RoutingAction rule. Also, if IPCONFIG PATHMTUDISCOVERY is not
    specified, then the length of the ping packet must not exceed
    the selected route's MTU to prevent the outgoing packet from
    being dropped. Another circumvention method is to disable PBR.
    
    KEYWORDS:
    PING IPV4 ICMP UDP PMTU PMTUD PATHMTUDISCOVERY PBR ROUTINGACTION
    USEMAINROUTETABLE EZBRWWRI EZBIPRHD EZBIPORH TORUWP EDC8130I
    EHOSTUNREACH
    

Problem summary

  • ****************************************************************
    * USERS AFFECTED: All users of the IBM Communication Server    *
    *                 for z/OS Version 1 Release 13 IP:            *
    ****************************************************************
    * PROBLEM DESCRIPTION: Ping can use the wrong route if         *
    *                      Policy Based Routing is being           *
    *                      used.                                   *
    *                                                              *
    ****************************************************************
    * RECOMMENDATION:                                              *
    ****************************************************************
    When using policy-based routing tables, unexpected results
    can occur for the outbound pings using IPv4 ICMP protocol. If
    a PBR table is defined and if the PMTU option is not specified
    (to allow fragmentation) in the ping command, the outbound ICMP
    packet is inadvertently subjected to the PBR table. The
    outbound ping can be sent over the wrong interface.
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    +-------------------------------------------------------------+
    + 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

  • TCP/IP has been modified to have outbound pings
    not use the PBR tables.
    
    
    * Cross Reference between External and Internal Names
    

Temporary fix

Comments

APAR Information

  • APAR number

    PM86331

  • Reported component name

    TCP/IP V3 MVS

  • Reported component ID

    5655HAL00

  • Reported release

    1D0

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2013-04-04

  • Closed date

    2013-05-10

  • Last modified date

    2013-08-02

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

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

    UK94206 PM91127

Modules/Macros

  • EZBRWWRI EZBRWWR1 TORUWP
    

Fix information

  • Fixed component name

    TCP/IP V3 MVS

  • Fixed component ID

    5655HAL00

Applicable component levels

  • R1D0 PSY UK94206

       UP13/07/13 P F307

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.



Rate this page:

(0 users)Average rating

Document information


More support for:

z/OS family

Software version:

1D0

Operating system(s):

z/OS

Reference #:

PM86331

Modified date:

2013-08-02

Translate my page

Machine Translation

Content navigation