OSPF_INTERFACE statement

Parameters

IP_address

IP address of the local interface to be configured for OSPF.

The IP address can be a valid IP address that is configured on the system, or it can be specified with asterisks (*) as wildcards. The valid wildcard specifications are shown in the following example. The result of coding a wildcard value is that all configured interfaces whose IP address matches the wildcard are configured as OSPF interfaces. Configured interface IP addresses and names are matched against possible wildcards in the order they appear in the following example with the name and any matching wildcard being the best match, x.y.z.* being second best, and so on.

interface name and any matching wildcard
x.y.z.*
x.y.*.*
x.*.*.*
*.*.*.* - Same as ALL
ALL - Same as *.*.*.*  

Tip: For more information about how wildcard interfaces are parsed, see this Method of assigning interface definitions to stack interfaces (wildcard and explicit): in z/OS Communications Server: IP Configuration Guide.

Because a stack could have a large number of Dynamic VIPAs (DVIPAs) defined, as well as DVIPA ranges, an additional wildcard capability exists on the OSPF_INTERFACE statement for use only with DVIPAs. Ranges of DVIPA interfaces can be defined using the subnet mask parameter on the OSPF_INTERFACE statement. This mode of definition applies to Dynamic VIPAs defined in the stack with VIPADEFINE, VIPABACKUP, or VIPARANGE. The range defined in this way are all the IP addresses that fall within the subnet defined by the mask and the IP address. When this type of wildcarding is being used, the value of the IP_ADDRESS parameter must be the subnet number of the range. Note that this subnet number is not equivalent to a DVIPA address as defined in VIPADEFINE or VIPABACKUP parameter of the VIPADYNAMIC statement in the TCP/IP profile. If VIPARANGE is defined, you should code DVIPA subnet address for the subnet number. For example, the following code defines a range of six addresses (9.67.101.9 to 9.67.101.14) that can be used for DVIPA addresses and matches any DVIPA interface that falls into the 9.67.101.8/29 subnet:

IP_ADDRESS = 9.67.101.8
SUBNET_MASK = 255.255.255.248

Alternatively, the following code does not because 9.67.101.17 is an address within the subnet range, not the subnet number itself (that would be 9.67.101.16). This second definition matches only an interface whose home address is 9.67.101.17.

IP_ADDRESS= 9.67.101.17
SUBNET_MASK=255.255.255.248

Name

The name of the interface. A valid value is any string 1 - 16 characters in length.

Rules:

• If this is not a wildcard interface definition, the name must match the link name that is coded for the corresponding IP address on the HOME statement or the interface name coded for the corresponding IPv4 INTERFACE statement in the TCP/IP profile.
• If this is a wildcard interface definition, then this parameter is used in conjunction with the defined wildcard IP address when searching for definitions to match a stack interface. For more details about this process, see method of assigning interface definitions to stack interfaces (wildcard and explicit): in z/OS Communications Server: IP Configuration Guide.

Subnet_Mask

The subnet mask of the subnet to which this interface attaches. This value must be the same for all routers attached to a common network. For more information, see z/OS Communications Server: IP Configuration Guide. If you configure this interface in the TCP/IP profile using the IPv4 INTERFACE statement and you configure a subnet mask on that statement that does not match the value that you specify on this parameter, OMPROUTE issues message EZZ8164I and uses this subnet mask.

Destination_Addr

IP address of the host at the remote end of this interface. This parameter is valid only for point-to-point links. If this parameter is not specified for a point-to-point link, a route to the host at the remote end of the interface is not added to the appropriate TCP/IP route tables (main and policy-based tables) until OSPF communication is established with that host. A subnet route for the interface is added when OMPROUTE is initialized whether or not this parameter is specified.

Attaches_To_Area

OSPF area to which this interface attaches. Valid values are 0.0.0.0 (the backbone), or any area defined by the AREA statement.

MTU

The maximum transmission unit size that OSPF adds to the appropriate routing tables (main and policy-based tables) for routes that use this interface. Valid values are in the range 0 - 65535. If you configure this interface in the TCP/IP profile using the IPv4 INTERFACE statement and you configure an MTU on that statement and the MTU that you configure on that statement does not match the MTU (the configured value or the default value) on this statement, OMPROUTE issues message EZZ8163I and uses the MTU value on this statement.

Tip: See z/OS Communications Server: IP Configuration Guide, in section Maximum transmission unit considerations, for additional information about how TCP/IP uses the MTU to determine the largest size frame to send.

Retransmission_Interval

Sets the frequency (in seconds) of retransmitting link-state update packets, link-state request packets, and database description packets. Valid values are in the range 1 - 65535 seconds.

If this parameter is set too low, needless retransmissions occur that could affect performance and interfere with neighbor adjacency establishment. It should be set to a higher value for a slower machine.

Transmission_Delay

This parameter is an estimate of the number of seconds that it takes to transmit link-state information over the interface. Each link-state advertisement has a finite lifetime of 1 hour. As each link-state advertisement is sent out from this interface, it is aged by this configured transmission delay. Valid values are in the range 1 - 65535 seconds.

Router_Priority

This value is used for broadcast and nonbroadcast multiaccess networks to elect the designated router, with the highest priority router being elected. Valid values are in the range 0 - 255.

A value of 0 indicates that OMPROUTE never becomes the designated router. A value of 1 indicates the lowest possible eligible priority and a value of 255 indicates the highest possible priority.

Hello_Interval

This parameter defines the number of seconds between OSPF Hello packets being sent out on this interface. This value must be the same for all routers attached to a common network. Valid values are in the range 1 - 255 seconds.

DB_Exchange_Interval

The interval in seconds that the database exchange process cannot exceed. If the interval elapses, the procedure is restarted. This value must be larger than the Hello_Interval. If no value is specified, the DB_Exchange_Interval is set to the Dead_Router_Interval. Valid values are 2 through 65535.

Dead_Router_Interval

The interval in seconds, after not having received an OSPF Hello, that the neighbor is declared to be down. This value must be larger than the Hello_Interval. Setting this value too close to the Hello_Interval can result in the collapse of adjacencies. A value of 4*Hello_Interval is preferred. This value must be the same for all routers attached to a common network. Valid values are 2 - 65535.

Cost0

The OSPF cost for this interface. The cost is used to determine the shortest path to a destination. Valid values are in the range 1 - 65535.

Subnet

The meaning of this parameter depends on the interface type.

For an interface to a point-to-point link, this option enables the advertisement of a stub route to the subnet that represents the link rather than the host route for the other router's address. In effect, this parameter controls whether, for this interface, OMPROUTE implements option 1 (SUBNET=NO) or option 2 (SUBNET=YES) described in RFC 2328 (OSPF version 2) topic 12.4.1.1. For a detailed explanation of this option, see the IPv4 interface information in z/OS Communications Server: IP Configuration Guide.

For a VIPA interface, this option suppresses advertisement of either the VIPA host or subnet route. Normally z/OS® Communications Server advertises both a host route and a subnet route for owned VIPA interfaces. With this option set to NOVIPAHOST, the VIPA host route is suppressed and only the VIPA subnet route is advertised. With this option set to NOVIPASUBNET, the VIPA subnet route is suppressed and only the VIPA host route is advertised.

Legal values are:

• YES
• NO
• NOVIPASUBNET
• NOVIPAHOST

Guidelines:

• Using the NOVIPAHOST value has the same effect as setting SUBNET=YES or ADVERTISE_VIPA_ROUTES=SUBNET_ONLY, using the NOVIPASUBNET value is equivalent to setting ADVERTISE_VIPA_ROUTES=HOST_ONLY
• The ADVERTISE_VIPA_ROUTES option is the preferred method to suppress VIPA advertisements.

Rule: Do not use this option for dynamic VIPAs or for any VIPA whose subnet might exist on multiple hosts. If you do, problems can occur routing to all VIPAs that share the subnet.

Tips:

• Specifying SUBNET=YES on a VIPA interface has the same effect as specifying SUBNET=NOVIPAHOST.
• In order to fully suppress the VIPA subnet route, SUBNET=NOVIPASUBNET must be specified on every VIPA OSPF_INTERFACE statement that defines a VIPA in a common subnet.

Advertise_VIPA_Routes

This option is valid only on VIPA interfaces and controls how OMPROUTE advertises the VIPA address. The default value of HOST_AND_SUBNET advertises both the VIPA host and subnet route. With this option set to HOST_ONLY, only the VIPA host route is advertised. With this option set to SUBNET_ONLY, only the VIPA subnet route is advertised.

The value specified on the ADVERTISE_VIPA_ROUTES option overrides any value specified on the SUBNET option. Legal values are:

• HOST_AND_SUBNET
• HOST_ONLY
• SUBNET_ONLY

Rule: Do not specify SUBNET_ONLY for dynamic VIPAs or for any VIPA whose subnet might exist on multiple hosts. Problems can occur routing to all VIPAs that share the subnet when the subnet exists on multiple hosts.

Tip: The HOST_ONLY option must be specified for every VIPA in a common subnet. If the HOST_ONLY option is not specified for every VIPA in a common subnet, OMPROUTE still advertises the VIPA subnet route for the interfaces not specifying HOST_ONLY.

Authentication_Type

The security scheme to be used on the network to which the interface attaches. If parameter is not specified, takes on the default value specified for the area to which the interface is attached. Valid values for authentication types are MD5, which indicates MD5 cryptographic authentication as described in Appendix D of RFC 2328; PASSWORD, which indicates a simple password; or NONE, which indicates that no authentication is necessary to pass packets. All hosts on the network must be configured with the same security scheme.

Authentication_Key_ID

The identifier of the authentication key defined with the AUTHENTICATION_KEY keyword. This is a constant numeric value from 0 - 255, with a default value of 0. It is relevant only when MD5 cryptographic authentication is employed on the interface; otherwise, it is ignored. This field is provided for compatibility with other routers that might require identification of a key identifier with the authentication key.

Authentication_Key

The value of the authentication key for this interface. This value must be the same for all routers attached to a common medium. The coding of this parameter depends on the authentication type being used on this interface.

For authentication type none, this parameter is not required and is ignored if coded.

For authentication type password, code the password for OSPF routers that are attached to this subnet. Valid values are any characters from EBCDIC code page 1047 up to 8 characters in length coded within double quotation marks or any hexadecimal string up to 8 bytes (16 hexadecimal characters) long that begins with 0x.

For authentication type MD5, code the 16-byte MD5 authentication key for OSPF routers attached to this subnet. This value can be coded in one of the following ways:

• The standard method is with a 16-byte hexadecimal string beginning with 0x (0x plus 32 hexadecimal characters). In some cases, pwtokey can be used to generate hexadecimal MD5 keys. See z/OS Communications Server: IP System Administrator's Commands for more information.
• An additional method, which provides compatibility with Cisco, Extreme, and other vendor routers that use a Cisco-compatible CLI interface is to code the MD5 key as an ASCII string, specified in double quotation marks prefixed with A. For example, to be compatible with this Cisco key definition, use the following code:

  ip ospf message-digest-key 4 md5 ABCDEFGHIJKLMNOP

  This value would be coded in OMPROUTE as follows:

  AUTHENTICATION_KEY_ID =4
  AUTHENTICATION_KEY = A"ABCDEFGHIJKLMNOP"

Demand_Circuit

This parameter, when coded with YES, causes Link State Advertisements (LSAs) to not be periodically refreshed over this interface. Only LSAs with real changes are advertised. In addition, coding this parameter to YES causes LSAs flooded over this interface to never age out. Valid values are YES or NO. For more information about the Demand_Circuit=YES and related topics, such as handling high cost links, see z/OS Communications Server: IP Configuration Guide.

Hello_Suppression

This parameter is used only on point-to-point and point-to-multipoint interfaces that are demand circuits. It allows you to configure the interface for Hello Suppression. Valid values are ALLOW, REQUEST, or DISABLE.

If either or both sides specify DISABLE, Hello_Suppression is disabled. If both specify ALLOW, Hello_Suppression is disabled. If one specifies ALLOW and the other REQUEST, or if both specify REQUEST, Hello_Suppression is enabled.

PP_Poll_Interval

This parameter specifies the interval (in seconds) that OMPROUTE should use when attempting to contact a neighbor to reestablish a neighbor relationship when the relationship has failed, but the interface is still available. This parameter is meaningful only if Demand_Circuit is coded YES and Hello_Supression has been enabled. Valid values are in the range 0 - 65535.

Parallel_OSPF

This parameter designates whether the OSPF interface is primary or backup when more than one OSPF interface is defined to the same subnet. Only one of these interfaces can be configured as primary, meaning that it is the interface to carry the OSPF protocol traffic between OMPROUTE and the subnet. Failure of the primary interface results in automatic switching of OSPF traffic to one of the backup interfaces. If the primary interface is later reactivated, OSPF traffic is not automatically switched back from the backup interface to the primary interface. If you want to switch OSPF traffic back to the primary interface, stop the backup interface. If none of the interfaces to the common subnet are configured as primary, a primary interface is selected by OMPROUTE. Valid values are BACKUP and PRIMARY.

Non_Broadcast

If the router is connected to a nonbroadcast, multiaccess network (NBMA), such as Frame Relay, coding a Non_Broadcast helps the router discover its neighbors. This can also be coded for a broadcast-capable network when you want OMPROUTE to unicast its packets instead of multicasting them. In addition to coding this parameter, each neighbor must be configured with the DR_NEIGHBOR parameter, for those neighbors that are eligible to become the designated router, or NO_DR_NEIGHBOR for those neighbors that are not eligible to become the designated router. This statement is ignored when this OSPF interface is coded as a wildcard. Valid values are YES or NO.

NB_Poll_Interval

This parameter specifies the frequency (in seconds) of hellos sent to neighbors that are inactive. You must set this poll interval consistently across all interfaces that attach to the same subnetwork for OSPF to function correctly. This statement is valid only when Non_Broadcast is coded as YES. Valid values are in the range 1 - 65535.

DR_Neighbor

Configures the IP interface address of a designated router-eligible neighbor adjacent to the router over this interface. In nonbroadcast multi-access networks, neighbors need to be configured to all OSPF routers on the network. Multiple DR_Neighbor statements can be coded on an OSPF_interface statement as necessary.

Guideline:You should not define neighbors on broadcast-capable or multicast-capable media. If you do define neighbors on these media, OMPROUTE can communicate OSPF information only with those neighbors that are defined (it does not form adjacencies with any additional neighbors).

No_DR_Neighbor

Configures the IP interface address of a nondesignated router-eligible neighbor adjacent to the router over this interface. In nonbroadcast multi-access networks, neighbors need to be configured to all OSPF routers on the network. Multiple No_DR_Neighbor statements can be coded on an OSPF_Interface statement as necessary.

Guideline: You should not define neighbors on broadcast-capable or multicast-capable media. If you do define neighbors on these media, OMPROUTE can communicate OSPF information only with those neighbors that are defined (it does not form adjacencies with any additional neighbors).

Retransmit Parameters

The following parameters are used by OMPROUTE to set values in the routes that use this interface; the values are added to the TCP/IP route tables. The values affect the TCP retransmit algorithms. When TCP packets are not acknowledged, TCP begins to retransmit these packets at certain time intervals. If these packets are not acknowledged after a certain number of retransmissions, TCP aborts the connection. The time interval between retransmissions increases by approximately twice the previous interval until the packets are acknowledged or the connection times out.

The time intervals between retransmissions and the number of times packets are retransmitted before the connection times out differs for initial connection establishment and for data packets. For initial connection establishment, the initial time interval is set at approximately 3 seconds and the SYN packet is retransmitted 5 times before the connection is timed out. Data packets use a smoothed Round Trip Time (RTT) as the initial time interval and are retransmitted 15 times before the connection is timed out. All of the following parameters affect the data packet retransmission algorithm. Only the Min_Xmit_Time parameter affects the initial connection establishment.

Max_Xmit_Time

Limits the TCP retransmission interval. Decreasing this value might decrease the total time it takes a connection to time out. Specifying Max_Xmit_Time assures that the interval time never exceeds the specified limit. The minimum value that can be specified for Max_Xmit_Time is 0. The maximum is 999.990. The default is 120 seconds. This parameter affects the initial connection establishment retransmission timeout for all APIs, except the Pascal API (TcpOpen), that are using the socket connect function.

Min_Xmit_Time

Sets a minimum retransmit interval. Increasing this value might increase the amount of time it takes for TCP to time out a connection. The minimum value that can be specified for Min_Xmit_Time is 0. The maximum is 99.990. The default is 0.5 (500 milliseconds).

RT_Gain

This value is the percentage of the latest Round Trip Time (RTT) to be applied to the smoothed RTT average. The higher this value, the more influence the latest packet's RTT has on the average. The minimum value that can be specified for RT_Gain is 0. The maximum value is 1.0. The default is 0.125. This parameter does not affect initial connection retransmission.

Variance_Gain

This value is the percentage of the latest RTT variance from the RTT average to be applied to the RTT variance average. The higher this value, the more influence the latest packet's RTT has on the variance average. The minimum value that can be specified for Variance_Gain is 0. The maximum value is 1.0. The default is 0.25 . This parameter does not affect initial connection retransmission.

Variance_Mult

This value is multiplied against the RTT variance in calculating the retransmission interval. The higher this value, the more affect variation in RTT has on calculating the retransmission interval. The minimum value that can be specified for Variance_Mult is 0. The maximum value is 99.990. The default is 2. This parameter does not affect initial connection retransmission.

Delay_Acks

The delay acknowledgments value that is added to the routing tables for routes that use this interface. Specify YES to delay transmission of acknowledgments when a packet is received with the PUSH bit on in the TCP header. Specify NO to return acknowledgments immediately when a packet is received with the PUSH bit on in the TCP header. This parameter affects only connections that use the routes associated with this interface.

Even if you specify YES, you can override the delay acknowledgments behavior can be overridden by specifying the NODELAYACKS parameter on the TCP/IP stack PORT, PORTRANGE, or TCPCONFIG profile statements. The value NO can override the specification the DELAYACKS parameter on the TCP/IP stack PORT, PORTRANGE, and TCPCONFIG profile statements.

Valid values are YES and NO. The default value is YES.

Usage notes

When you configure multiaccess parallel interfaces (primary and secondary interfaces that have IP addresses in the same subnet) for OMPROUTE (OSPF), code the Parallel_OSPF=Primary parameter to set a specific interface as the primary interface. If none of the interfaces on the same subnet are coded as primary, OMPROUTE will select the primary interface from the set of interfaces attached to the subnet. In case of a primary interface failure, OMPROUTE uses the first available secondary interface and marks it as the primary interface.