OSPF statement
Use the OSPF statement to specify parameters that apply globally to IPv4 OSPF, either to all interfaces or to the overall OSPF autonomous system.
The following parameters can also be specified as stand-alone configuration statements:
- DEMAND_CIRCUIT
- ROUTERID
- COMPARISON
Guideline: You should use the OSPF statement for defining these parameters. If both the OSPF statement and the standalone statements are coded, the last one coded in the configuration file takes precedence.
Syntax
Parameters
- RouterID
- Every router in an IPv4 OSPF routing domain must be assigned a
unique 32-bit router ID.
The value used for the OSPF router ID is chosen as follows:
- If this RouterID statement is specified, the value configured
is used as the OSPF router ID. This value must be one of the OSPF
interface IP addresses that is configured for the stack.
Rule: Loopback and reserved 0.0.0.0 addresses are not valid IP interface addresses.
- If the router ID is not configured, one of the OSPF interface
addresses will be used as the OSPF router ID, provided that the interface
exists in the TCPIP profile and matches the corresponding OSPF interface
statement in the OMPROUTE configuration file at startup.
Result: When OMPROUTE has to assign the router ID, it does not use dynamic VIPA IP addresses. This avoidance of dynamic VIPA IP addresses cannot be guaranteed; for example, if dynamic VIPAs are the only active OSPF interfaces when OMPROUTE chooses the router ID, then one of them will be chosen.
Guideline: Because dynamic VIPAs (DVIPAs) can move between z/OS® hosts, the router ID should be a physical interface or a static VIPA, not a dynamic VIPA address. To ensure an appropriate router ID, specify the router ID to OMPROUTE.
Valid values are any IPv4 dotted-decimal address that matches a configured OSPF interface.
- If this RouterID statement is specified, the value configured
is used as the OSPF router ID. This value must be one of the OSPF
interface IP addresses that is configured for the stack.
- Comparison
- Tells OMPROUTE where external routes fit in the IPv4 OSPF hierarchy. OSPF supports two types of external metrics. Type 1 external metrics are equivalent to the link state metric. Type 2 external metrics are greater than the cost of any path internal to the autonomous system. Use of type 2 external metrics assumes that routing between autonomous systems is the major cost of routing a packet, and eliminates the need for conversion of external costs to internal link state metrics. For more information about the COMPARISON configuration parameter, see z/OS Communications Server: IP Configuration Guide. Valid values are Type1 (or 1) or Type2 (or 2).
- Demand_Circuit
- This value determines the global demand circuit setting. Coding YES enables demand circuits. Demand circuit parameters can then be coded on the OSPF_Interface statement. Valid values are Yes or No.
- DR_Max_Adj_Attempt
- Specifies the maximum number of adjacency attempts to be used
for reporting and controlling futile neighbor state loops. After the
adjacency attempt count for a neighboring designated router reaches
the threshold, an informational message is issued to report the problem.
If a redundant interface is available that can reach the neighbor,
adjacency formation is attempted over that interface. An informational
message is issued to report the interface switch and adjacency formation
attempt. Valid values are in the range 0 - 100. The value 0 specifies
infinite retries.
For information about futile neighbor state loops, see the network design considerations information in z/OS Communications Server: IP Configuration Guide. For the types of interfaces that support the futile neighbor state loop detection for OSPF, see Interfaces supported by OMPROUTE.
