INTERFACE statement

Use the INTERFACE statement to allow certain values to be specified for generic IPv4 interfaces, which are interfaces that are neither OSPF nor RIP interfaces. Each IPv4 interface that is neither an OSPF nor an RIP interface should be configured to OMPROUTE using the INTERFACE statement unless it is a non-point-to-point interface and the default values for Subnet_Mask and MTU are acceptable for that interface.

Tip: To display information about INTERFACEs, use the d tcpip,tcpname, OMP,GENERIC commands.

Syntax


>>-Interface--IP_address--=--ip_address------------------------->

>--Name--=--interface_name--Subnet_Mask--=--mask---------------->

                                     .-MTU=576------.   
>--+------------------------------+--+--------------+----------->
   '-Destination_Addr--=--address-'  '-MTU--=--size-'   

   .-Max_Xmit_Time=120------.  .-Min_Xmit_Time=0.5------.   
>--+------------------------+--+------------------------+------->
   '-Max_Xmit_Time--=--time-'  '-Min_Xmit_Time--=--time-'   

   .-RT_Gain=0.125-----.  .-Variance_Gain=0.25------.   
>--+-------------------+--+-------------------------+----------->
   '-RT_Gain--=--value-'  '-Variance_Gain--=--value-'   

   .-Variance_Mult=2--------.  .-Delay_Acks=YES-------.   
>--+------------------------+--+----------------------+--------><
   '-Variance_Mult--=--mult-'  '-Delay_Acks--=--value-'

Parameters

IP_address

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 below. The result of coding a wildcard value is that all configured interfaces whose IP address matches the wildcard are configured as interfaces. Configured interface IP addresses and names are matched against possible wildcards in the order they appear below with the name and any matching wildcard being the best match, x.y.z.* being second best, and so forth.

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, additional wildcard capabilities exist on the INTERFACE statement for use only with DVIPAs. Ranges of DVIPA interfaces can be defined using the subnet mask parameter on the INTERFACE statement. The range defined in this way is 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. 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 fall into the 9.67.101.8/29 subnet:

IP_ADDRESS= 9.67.101.8
SUBNET_MASK= 255.255.255.248

Alternatively, the following code is 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 only matches 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.

For Dynamic VIPA (DVIPA), link names are assigned programmatically by the stack when the DVIPA is created; therefore, the name field set on the INTERFACE statement is ignored by OMPROUTE for DVIPAs.

Subnet_Mask

Subnet mask for the associated interface's IP address. 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). A subnet route for the interface is added when OMPROUTE is initialized whether or not this parameter is specified.

MTU

The maximum transmission unit size that OMPROUTE 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.

Retransmit Parameters

The following parameters are used by OMPROUTE to set values in the routes which use this interface that 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 retransmits, 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.

Tip: A new route lookup is performed after every two retransmissions for a data packet. For more information about the route lookup process, see Route selection algorithm in z/OS Communications Server: IP Configuration Guide. Be careful when you design networks with firewalls. A firewall in an alternate routing path can generate a RESET packet for the rerouted data packets, which causes TCP to abort the connection.

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. A value of NO can override the specification of 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.