IBM Support

OMPROUTE address space being cancelled every 5 minutes by TCPIP

Troubleshooting


Problem

A UDP port is coded in the tcpip.profile for OMPROUTE and is also included in the autolog list. One of the following configurations is used: 1. OMPROUTE is not configured to process RIP packets on UDP port 520. As a result, UDP port 520 is not used by OMPROUTE and OMPROUTE gets cancelled periodically by TCPIP. 2. OMPROUTE is configured to process RIP packets on UDP port 520 but no RIP packets were being received on the UDP port. As a result, OMPROUTE gets cancelled periodically by TCPIP. 3. OMPROUTE is configured to process RIP packets on UDP port other than 520 but no RIP packets were being received on that port. As a result, OMPROUTE gets cancelled periodically by TCPIP. 4. OMPROUTE is configured to process packets on a TCP port but no TCP packets were being received on that port even though OMPROUTE is receiving RIP packets on a UDP port. As a result, OMPROUTE gets cancelled periodically by TCPIP.

Cause

Autolog considerations for OMPROUTE are discussed in z/OS Communications Server IP Configuration Reference.
If a procedure in the AUTOLOG list also has a PORT statement reserving a TCP or UDP port but does not have a listening connection on that port, TCP/IP periodically attempts to cancel that procedure and start it again.

If OMPROUTE is being started with AUTOLOG and only the OSPF protocol is being used (no RIP protocol and, therefore, no listening connection on the RIP UDP port), it is important to do one of the following:

  • Ensure that the RIP UDP port (520) is not reserved by the PORT statement in the PROFILE.TCPIP

  • Add the NOAUTOLOG parameter to the PORT statement in the PROFILE.TCPIP. For example,

    • PORT
    520 UDP OMPROUTE NOAUTOLOG



    Note that when using only the OSPF protocol, the auto-start feature of AUTOLOG can be used as described above. However, the monitoring and auto-restart features of AUTOLOG are unavailable due to AUTOLOG's dependence on a listening TCP or UDP connection, which does not exist with OSPF.

    If OMPROUTE is being started with AUTOLOG and RIP protocol is being used (with or without OSPF), it is important to do one of the following:
  • If using UDP port 520 for RIP, ensure that it is reserved by the PORT statement in the PROFILE.TCPIP.

  • If using a UDP port other than 520, ensure that the specified port number matches the one used by the neighboring RIP routers that are sending the RIP packets. Reserve this port on the PORT statement in the PROFILE.TCPIP.


  • If a TCP port was coded for OMPROUTE, remove the definition from the PORT statement in the PROFILE.TCPIP.


    • Even though OMPROUTE uses a TCP port for informational sockets support with the TCPIP stack, the port does not need to be reserved because ephemeral ports are used.

    If RIPv1 protocol is being used, ensure that the attached network device supports broadcasting. For example, for MPCIPA OSA Express QDIO devices and MPCIPA Hipersockets devices that do not support broadcasting by default, specify the IPBCAST parameter on the corresponding LINK statement in the PROFILE.TCPIP.

    If RIPv2 protocol is being used, ensure that multicast IP address 224.0.0.9 is registered for the device so that TCPIP will receive the RIPv2 packets. Otherwise, the device will discard the RIPv2 packets. Issue DISPLAY TCPIP,,Netstat,DEVlinks or TSO NETSTAT DEVlinks command to display the registered multicast addresses on a device.

    If you fail to take one of the above actions, OMPROUTE will be periodically canceled and restarted by TCP/IP.

    Resolving The Problem

  • If OMPROUTE is being started with AUTOLOG and only the OSPF protocol is being used:


    • For temporary resolution, use obeyfile to remove a UDP port from the port reservation list in TCPIP to cause TCPIP to stop monitoring that port. For example, if using port 520 issue statement:

    DELETE 520 UDP OMPROUTE

    For a permanent solution, remove the statement from the TCPIP profile or add the NOAUTOLOG parameter to the existing statement. For example, if using port 520, issue statement:

    520 UDP OMPROUTE NOAUTOLOG

  • If OMPROUTE is being started with AUTOLOG and RIP protocol (with or without OSPF) is being used:


    • For temporary resolution, use obeyfile to change a UDP port in the port reservation list of TCPIP to cause TCPIP to monitor the correct port for RIP packets. Also, if TCP port was coded, use obeyfile to remove the TCP port so that TCPIP will stop monitoring that port. For example, if using TCP port xxx issue statement:

    DELETE xxx TCP OMPROUTE

    If RIPv1 protocol is being used for a MCPIPA OSA Express QDIO or MPCIPA Hipersockets device and the IPBCAST parameter is not coded in the corresponding LINK statement in the TCPIP profile, stop the device, use obeyfile to delete and readd the LINK statement with the IPBCAST parameter, and restart the device.

    If RIPv2 protocol is being used and if the multicast address 224.0.0.9 is not reserved for the device according to DISPLAY TCPIP,,Netstat,DEVlinks or TSO NETSTAT DEVlinks report, contact the IBM Software and Support center to determine what documentation to collect for problem determination.

    For a permanent solution, update the PORT statement in the TCPIP profile to use the correct listening UDP port that will be monitored by TCPIP for RIP packets. If using RIPv1 protocol on a MPCIPA OSA Express QDIO or MPCIPA Hipersockets device, update the corresponding LINK statement in the TCPIP profile with the IPBCAST parameter.

    [{"Product":{"code":"SSSN3L","label":"z\/OS Communications Server"},"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Component":"All","Platform":[{"code":"PF035","label":"z\/OS"}],"Version":"2.1;2.2;2.3","Edition":"","Line of Business":{"code":"LOB35","label":"Mainframe SW"}}]

    Document Information

    Modified date:
    15 June 2018

    UID

    swg21192776

    Page Feedback