Overview
For IPv4, OMPROUTE implements the Open Shortest Path First (OSPF) protocol described in RFC 1583, "OSPF Version 2" as well as the Routing Information Protocols (RIP) described in RFC 1058, "Routing Information Protocol" (RIP Version 1) and in RFC 1723, "RIP Version 2–Carrying Additional Information" (RIP Version 2).
For IPv6, OMPROUTE implements the IPv6 OSPF protocol described in RFC 2740, "OSPF for IPv6", as well as the IPv6 RIP protocol described in RFC 2080, "RIPng for IPv6".
OMPROUTE provides an alternative to the static TCP/IP BEGINROUTES definitions. When configured properly, the MVS™ host running with OMPROUTE becomes an active OSPF or RIP router in a TCP/IP network. The dynamic routing protocols are used to dynamically maintain the host routing table. For example, OMPROUTE can determine that a new route has been created, that a route is temporarily unavailable, or that a more efficient route exists.
- It is a z/OS UNIX application. It requires the z/OS® UNIX file system to operate.
- OMPROUTE can be started from an MVS procedure, from the z/OS shell, or from AUTOLOG. See z/OS Communications Server: IP Configuration Guide for information about OMPROUTE.
- The OMPROUTE subagent provides an alternative to DISPLAY commands for displaying IPv4 Open Shortest Path First (OSPF) protocol configuration and state information. The subagent implements the Management Information Base (MIB) variables defined in Request for Comment (RFC) 1850. The OMPROUTE subagent is controlled by statements in the OMPROUTE configuration file. For details, see z/OS Communications Server: IP Configuration Reference.
- OMPROUTE needs to be started by a RACF® authorized user ID.
- OMPROUTE needs to be in an APF authorized library.
- A one-to-one relationship exists between an instance of OMPROUTE and a TCP/IP stack. OSPF/RIP support on multiple TCP/IP stacks requires multiple instances of OMPROUTE.
- All IPv4 dynamic routes are deleted from the routing table upon initialization of OMPROUTE if there are IPv4 interfaces configured to OMPROUTE as RIP or OSPF interfaces.
- All IPv6 dynamic routes (with the exception of routes learned using the IPv6 Router Discovery protocol) are deleted from the routing table upon initialization of OMPROUTE if there are IPv6 interfaces configured to OMPROUTE as OSPF or RIP interfaces.
- IPv4 Internet Control Message Protocol (ICMP) redirects are ignored when OMPROUTE is active and there are IPv4 interfaces configured to OMPROUTE as RIP or OSPF interfaces.
- IPv6 ICMP redirects are ignored when OMPROUTE is active and there are IPv6 interfaces configured to OMPROUTE as OSPF or RIP interfaces.
- OMPROUTE does not make use of the BSD Routing Parameters. Instead,
the maximum transmission unit (MTU), subnet mask, and destination
address parameters for IPv4 interfaces are configured using the OSPF_Interface,
RIP_Interface, and Interface statements in the OMPROUTE configuration
file. Also, for IPv6, OMPROUTE does not update the stack's MTU sizes
but learns them from the stack instead. Restriction: If using NCPROUTE, the BSD routing parameters in the BSDROUTINGPARMS TCP/IP configuration statement must be defined for the host-to-NCP channel interfaces, and the parameter values must match the corresponding values on the RIP_INTERFACE or INTERFACE statements in the OMPROUTE configuration file; otherwise, connection problems occur between NCPROUTE and its NCP clients.
- OMPROUTE uses the MVS operator
console, SYSLOGD, STDOUT, and CTRACE for its logging and tracing.
- The MVS operator console and SYSLOGD are used for major events such as initialization, termination, and error conditions.
- STDOUT and z/OS UNIX file system files are used for detailed tracing and debugging.
- CTRACE is used for the following purposes:
- Tracing the receipt and transmission of OSPF/RIP packets
- Tracing subagent/SNMP agent packets
- Tracing communication between OMPROUTE and the TCP/IP stack
- Detailed tracing and debugging
- If you want to communicate a routing protocol over an interface, configure the interface to OMPROUTE using the OSPF_INTERFACE, RIP_INTERFACE, IPV6_OSPF_INTERFACE, or IPV6_RIP_INTERFACE configuration statement.
- IPv4 interfaces that are not involved in the communication of the RIP or OSPF protocol (except VIPA interfaces) must be configured to OMPROUTE using the INTERFACE configuration statement, unless it is a non-point-to-point interface and all default values are acceptable as specified on the INTERFACE statement. All IPv4 interfaces known to the TCP/IP stack should be defined to OMPROUTE with the correct subnet mask and MTU values. For IPv4 interfaces that are not defined to OMPROUTE, OMPROUTE assigns default subnet mask and MTU values to the interfaces, with possibly undesirable results.
- IPv6 interfaces that are not involved in the communication of the OSPF or RIP protocol defaults to IPv6 generic interfaces when Global_Options Ignore_Undefined_Interfaces is coded to No (default value). The IPv6_Interface statement can be used if the IPv6 (generic) interface default values are not acceptable or you want to define additional IPv6 prefixes on the IPv6_Interface statement. If Global_Options Ignore_Undefined_Interfaces is coded to Yes, code IPv6_INTERFACE statements for all IPv6 Interfaces not involved in communication of OSPF or RIP that you want OMPROUTE to recognize.
- OMPROUTE uses a standard message catalog. The message catalog must be in the z/OS UNIX file system. The directory location for the message catalog path is set by the environment variables NLSPATH and LANG.
- If you want OMPROUTE to completely ignore IPv4 and IPv6 interfaces that are not defined to it, code the GLOBAL_OPTIONS statement with IGNORE_UNDEFINED_INTERFACES=YES in the OMPROUTE configuration file. For details, see z/OS Communications Server: IP Configuration Guide.
- OMPROUTE is enhanced with Virtual IP Addressing (VIPA) to handle network interface failures by switching to alternate paths. The virtual routes are included in the OSPF and RIP advertisements to adjacent routers. Adjacent routers learn about virtual routes from the advertisements and can use them to reach the destinations at the MVS host.
- OMPROUTE allows for the generation of multiple, equal-cost routes to a destination, thus providing load-balancing support.
- During a temporary shortage in storage, such as CSM ECSA or CSM data space conditions or reaching the TCP/IP defined limits for ECSA or private storage, OMPROUTE temporarily suspends the route timeout processing. This is done in an attempt to prevent the loss of routing information about the local host.
OMPROUTE works best without non-replaceable static routes, and the use of non-replaceable static routes (defined using the BEGINROUTES TCP/IP configuration statement) is not recommended. Non-replaceable static routes might interfere with the discovery of a better route to the destination as well as inhibit the ability to switch to another route if the destination should become unreachable by way of the static route. For example, if you define a non-replaceable static host route through one interface and that interface becomes unreachable, OMPROUTE does not define a route to that same host through an alternate interface.
If you must define static routes, all static routes are considered to be of equal cost and non-replaceable static routes are not replaced by OSPF or RIP routes. Use extreme care when working with static routes and OMPROUTE. Set IMPORT_STATIC_ROUTES = YES on the AS_Boundary Routing or IPv6_AS_Boundary_Routing configuration statement, or both. Alternatively, set SEND_STATIC_ROUTES = YES on the RIP_Interface or IPv6_RIP_Interface configuration statement, or both. This allows the static routes to be advertised to other routers.
You can define static routes as replaceable. Unlike non-replaceable static routes, replaceable static routes are always replaced by dynamic routes learned by OMPROUTE. In other words, a replaceable static route is used only if no dynamic route is known to the destination. Replaceable static routes can be thought of as last resort routes to reach a destination when no dynamic route is known.