IPCONFIG statement

Use the IPCONFIG statement to update the IPv4 IP layer of TCP/IP.

Parameters

ARPTO ARP_cache_timeout

Use ARPTO to specify the number of seconds between creation or revalidation and deletion of ARP table entries. The default is 1200 seconds. An LCS ARP table entry is revalidated when another ARP packet is received from the same host specifying the same hardware address. The minimum value is 60, and the maximum value is 86400.

This parameter serves the same purpose as the ARPAGE statement, but the value specified on ARPAGE is in minutes while the value specified on the ARPTO parameter is in seconds.

Because ARP cache entries for MPCIPA and MPCOSA interfaces are not managed by the TCP/IP stack, they are not affected by the ARPTO statement. For more information about devices that support ARP Offload, see z/OS Communications Server: IP Configuration Guide.

CHECKSUMOFFLOAD | NOCHECKSUMOFFLOAD

Specifies whether the stack should offload inbound and outbound checksum processing (IP header, TCP, and UDP checksums) for IPv4 packets to OSA-Express features. The checksum offload support transfers the overhead of most checksum processing to QDIO-attached OSA-Express devices that support this function. Offloading checksum processing reduces CPU use and increases throughput. This parameter is ignored for OSA-Express features that do not support checksum offload.

See Steps for modifying for information about changing this parameter while the TCP/IP stack is active. See Checksum offload in z/OS Communications Server: IP Configuration Guide for more information about the checksum offload support and for specific information about which packets can have checksum processing performed by the OSA-Express.

NOCHECKSUMOFFLOAD

Checksum processing is performed by the TCP/IP stack.

CHECKSUMOFFLOAD

Checksum processing is offloaded to the OSA-Express feature. This value is the default value.

CLAWUSEDOUBLENOP

Forces channel programs for CLAW devices to have two NOP CCWs to end the channel programs. This is required for some vendor devices, and applies to only first-level MVS™ systems. The CLAWUSEDOUBLENOP parameter is confirmed by the message:

EZZ0337I CLAWUSEDOUBLENOP IS SET

DATAGRAMFWD | NODATAGRAMFWD

NODATAGRAMFWD

Disables the forwarding of IP packets that are received by, but not addressed to, the stack. This statement can be used for security or to ensure correct usage of limited resources. The NODATAGRAMFWD parameter is confirmed by the message:

EZZ0334I IP FORWARDING IS DISABLED

DATAGRAMFWD

Enables the forwarding of IP packets that are received by, but not addressed to, the stack. This is the default value.

Tip: The FWDMULTIPATH and NOFWDMULTIPATH keywords used with DATAGRAMFWD are independent of the MULTIPATH keyword on the IPCONFIG statement.

NOFWDMULTIPATH

When forwarding is in effect and there are multiple equal-cost routes to the destination and the NOFWDMULTIPATH parameter is specified, TCP/IP uses the first active route found for forwarding each IP packet. This is the default value. The DATAGRAMFWD NOFWDMULTIPATH parameter is confirmed by the message:

EZZ0641I IP FORWARDING NOFWDMULTIPATH SUPPORT IS ENABLED

FWDMULTIPATH PERPACKET

When forwarding is in effect and there are multiple equal-cost routes to the destination and the FWDMULTIPATH PERPACKET parameter is specified, TCP/IP selects a route for forwarding each IP packet on an approximate round-robin basis from the multiple equal-cost routes. The selected route is used for routing that IP packet. Connection or connectionless-oriented IP packets using the same destination address do not always use the same route, but they do use all possible active routes to that destination host. All IP packets for a given association with a destination host are spread across the multiple equal-cost routes. The DATAGRAMFWD FWDMULTIPATH PERPACKET parameter is confirmed by the message:

EZZ0641I IP FORWARDING FWDMULTIPATH PERPACKET SUPPORT IS ENABLED

Guideline: If the TCP/IP stack is also configured to be a sysplex distributor (see VIPADYNAMIC statement summary for more information), datagrams destined to a sysplex-distributed dynamic VIPA are forwarded to stacks, whether or not forwarding is enabled.

DEVRETRYDURATION dev_retry_duration

Specifies the duration (in seconds) of the retry period for a failed device or interface. TCP/IP performs reactivation attempts at 30 second intervals during this retry period. The default for DEVRETRYDURATION is 90 seconds. A specification of 0 generates an infinite recovery period, which means reactivation attempts are performed until the device or interface is either successfully reactivated or manually stopped (by way of the VARY TCPIP,,STOP command, or the VARY TCPIP,,OBEYFILE command with a data set containing the STOP profile statement). The maximum specifiable value is 4294967295.

Guideline: The default 90–seconds retry duration is sufficient for transparent recovery following many types of device or channel errors. However, certain ESCON-attached routers cannot complete a microcode load in 90 seconds and installations might want to increase the DEVRETRYDURATION to automatically recover the device following these longer outages. On the other hand, installations running extensive automation built upon SNMP status and alerts can choose to code a small (nonzero) value in DEVRETRYDURATION, such that device recovery is deferred to external automation software, rather than a function of TCP/IP. For IPv4 interfaces that are defined with DEVICE and LINK statements, see also the AUTORESTART parameter in Overview of DEVICE and LINK statements. For IPv6 interfaces and IPv4 interfaces that are defined with the INTERFACE statement, the autorestart function is always active.

DYNAMICXCF | NODYNAMICXCF

Indicates XCF support status.

NODYNAMICXCF

Indicates XCF dynamic support is not enabled. The NODYNAMICXCF parameter is confirmed by the message:

EZZ0624I DYNAMIC XCF DEFINITIONS ARE DISABLED

NODYNAMICXCF is the default value.

DYNAMICXCF

Indicates that dynamic XCF support is enabled for IPv4.

When DYNAMICXCF is coded in the profile, the purpose is to generate dynamic XCF interfaces, if possible. When TCP/IP is active, but ISTLSXCF is not active, dynamic creation is deferred. Later, when a TCP/IP command such as VARY TCPIP,,OBEYFILE or VARY TCPIP,,START is executed, triggering profile processing, the stack again checks to see if ISTLSXCF is active. If ISTLSXCF is active at that time, then the dynamic XCF interfaces are generated.

Dynamic XCF definitions are not generated if there is a DEVICE and LINK definition with the same device or link name that dynamic XCF would generate, or if there is an INTERFACE definition with the same interface name that dynamic XCF would generate.

Activation of dynamic XCF interfaces is delayed if VTAM® is not up or if OMPROUTE is not up and DELAYJOIN is coded on the GLOBALCONFIG SYSPLEXMONITOR statement. For more information about connectivity problems in a sysplex, see z/OS Communications Server: IP Configuration Guide.

When using dynamic XCF for Sysplex configuration, make sure that XCFINIT=YES or XCFINIT=DEFINE is coded in the VTAM start options, or if XCFINIT=NO was specified, ensure that a VARY ACTIVATE command is issued for the ISTLSXCF major node. This ensures that XCF connections between TCP stacks on different VTAM nodes in the sysplex can be established. See z/OS Communications Server: SNA Resource Definition Reference for directions to code the XCFINIT VTAM start option. The DISPLAY NET,VTAMOPTS command can be used to determine the XCFINIT setting.

cost_metric

Specifies the interface-level metric for the cost of use for the DYNAMICXCF interface. The cost_metric value is an integer in the range 0 - 14. If using OMPROUTE, the cost_metric value is overridden with a corresponding OMPROUTE interface parameter value that can be coded or set to the default value (Cost0= on OSPF_INTERFACE or In_Metric= on RIP_INTERFACE).

ipv4_address

The IP address to be used as the home address for all dynamically generated XCF, Same Host, and HiperSockets™ interfaces. A multicast address is not accepted in this case.

subnet_mask

Specifies the interface-level subnet mask for the DYNAMICXCF interface. If using OMPROUTE, the subnet_mask value is overridden with a corresponding OMPROUTE interface parameter value that can be coded or set to the default value.

/num_mask_bits

It is an integer value in the range 1 - 32 that represents the number of leftmost significant bits for the address mask.

SECCLASS security_class

Use this parameter to associate a security class for IP filtering with each dynamic XCF interface. In order for traffic over the interface to match a filter rule, the filter rule must have the same security class value as the interface or a value of 0. Filter rules can be specified in the TCP/IP profile or in an IP Security policy file read by the Policy Agent. Filter rules can include a security class specification on the IpService statement in an IP Security policy file or on the SECCLASS parameter on the IPSEC statement in the TCP/IP profile.

Valid security classes are identified as a number in the range 1 - 255. The default value is 255. For more information about security class values, see z/OS Communications Server: IP Configuration Guide.

This value is used only when IPSECURITY is specified on the IPCONFIG statement.

SOURCEVIPAINTERFACE vipa_name

The SOURCEVIPAINTERFACE parameter is optional. This parameter specifies which static VIPA interface is to be used as the source IP address when IPCONFIG SOURCEVIPA is specified and outbound packets are sent over the dynamically generated XCF, Same Host, or HiperSockets interfaces. The vipa_name value is the interface name for a VIRTUAL interface. The maximum length is 16 characters.

The use of the SOURCEVIPAINTERFACE parameter can be overridden. See Source IP address selection in z/OS Communications Server: IP Configuration Guide for the hierarchy of ways that the source IP address of an outbound packet is determined.

Requirement: The VTAM ISTLSXCF major node must be active for XCF dynamics to work, except for the following scenarios:

• Multiple TCP/IP stacks on the same MVS image; a dynamic samehost definition is generated whether ISTLSXCF is active or not.
• HiperSockets is configured and enabled across multiple z/OS® systems that are in the same sysplex and the same CEC; a dynamic IUTIQDIO link is created whether ISTLSXCF is active or not.

For information about activating the ISTLSXCF major node, see z/OS Communications Server: SNA Resource Definition Reference.

Restriction: A mix of static and dynamic IPv4 and IPv6 definitions for a device are not allowed. For example, if a static IUTSAMEH IPv4 interface is defined, then the IPv6 dynamic definition for IUTSAMEH is not created. If a static IUTSAMEH IPv6 interface is defined, then the IPv4 dynamic definition for IUTSAMEH is not created. The same logic is also applied for XCF interfaces; a mix of static and dynamic IPv4 and IPv6 definitions is not allowed for an XCF interface.

Guidelines:

1. Dynamic XCF can be enabled even in a single system sysplex. HiperSockets can be used between LPARs on the same central processor complex (CPC) even when MVS images in those LPARs are not defined to be part of the same sysplex. HiperSockets can also be used between LPARs even when some of those other LPARs are running Linux, as long as all of the stacks connecting to HiperSockets and needing to exchange IP packets with each other define IP addresses that are all in the same subnet (as defined by the dynamic XCF IP address and subnet mask in the IPCONFIG DYNAMICXCF profile statement).
2. If the DYNAMICXCF parameter is added (using a VARY TCPIP,,OBEYFILE command data set) after the TCP/IP stack and OMPROUTE are active, the DYNAMICXCF link should be configured to OMPROUTE prior to issuing the VARY TCPIP,,OBEYFILE command. If you do not do this, the network mask is used as the subnet mask for the interface.

For more details about the use of DYNAMICXCF, see the DYNAMICXCF information in z/OS Communications Server: IP Configuration Guide. The DYNAMICXCF parameter is confirmed by the message:

EZZ0624I DYNAMIC XCF DEFINITIONS ARE ENABLED

FORMAT

The FORMAT keyword is optional, and there is no default.

The FORMAT keyword is meaningful only for stacks that are not enabled for IPv6. It controls the format of the command output. If FORMAT SHORT is specified and the stack is enabled for IPv6, then an error message is displayed. If the stack is not enabled for IPv6 and the user specified LONG format, the command output is displayed as if it could contain IPv6 addresses. If the stack is not enabled for IPv6 and the user specified SHORT format or did not specify the FORMAT keyword, then the command output is displayed as if it could contain only IPv4 addresses and not the longer IPv6 addresses.

If the stack is enabled for IPv6, then specifying the FORMAT keyword does not make any difference to the command format

IGNOREREDIRECT

Causes TCP/IP to ignore ICMP Redirect packets. The IGNOREREDIRECT parameter is confirmed by the message:

EZZ0335I ICMP WILL IGNORE REDIRECTS

If you are using OMPROUTE and you have IPv4 interfaces configured to OMPROUTE and this option is not specified, IGNOREREDIRECT is enabled automatically.

If you are using intrusion detection services (IDS) policy to detect and discard ICMP Redirects and this option is not specified, ICMP Redirects are discarded anyway while the policy is active.

If this option is not specified, and an ICMP redirect is received for a destination for which there is a HOST route in the routing table, then the original route is deleted and replaced by the redirect. This applies to all routes, including static routes.

IPSECURITY

Activates IPv4 IP filtering and IPv4 IPSec tunnel support.

Requirements:

• Use this parameter so that the stack can function with the Communications Server IKE daemon, and for the stack to receive IPv4 IPSec policy information such as IP filter rules from the policy agent.
• Use this parameter so that the stack can receive defensive filters from the Defense Manager daemon (DMD).

The IPSECURITY parameter is confirmed by the message:

EZZ0753I IPV4 SECURITY SUPPORT IS ENABLED 

Restriction: IPSec functions can be activated only at initial activation of TCP/IP.

IQDIOROUTING | NOIQDIOROUTING

NOIQDIOROUTING

Specifies that inbound packets that are to be forwarded by this TCP/IP stack should not be routed directly between a HiperSockets device and an OSA-Express device in QDIO mode. These packets are processed and routed by this TCP/IP stack.

NOIQDIOROUTING is the default value. If NOIQDIOROUTING is explicitly specified, then the stack confirms that direct routing is disabled with the following message:

EZZ0688I IQDIO ROUTING IS DISABLED

IQDIOROUTING

Specifies that inbound packets that are to be forwarded by this TCP/IP stack are eligible to be routed directly between a HiperSockets device and an OSA-Express device in QDIO mode without needing to be sent to this TCP/IP stack for forwarding. This type of routing over a HiperSockets device (iQDIO) is called HiperSockets Accelerator. If specified, HiperSockets Accelerator routes are created dynamically as this TCP/IP stack learns of destination IP addresses that can be routed to or from HiperSockets links without needing to be forwarded to this TCP/IP stack. HiperSockets Accelerator support cannot be enabled if the IPSECURITY parameter or the NODATAGRAMFWD parameter is specified. Use of the IQDIOROUTING parameter is confirmed by the following message:

EZZ0688I IQDIO ROUTING IS ENABLED

If HiperSockets Accelerator support cannot be enabled, message EZZ0689I is issued with the reason. This message is also issued if IQDIOROUTING is specified in the data set that is used with the VARY TCPIP,,OBEYFILE command, if TCP/IP was activated with NOIQDIOROUTING and NOQDIOACCELERATOR on the initial profile.

Rule: This parameter is ignored if QDIOACCELERATOR is specified.

Restrictions:

• HiperSockets Accelerator support cannot be enabled during VARY TCPIP,,OBEYFILE command processing unless either IQDIOROUTING or QDIOACCELERATOR was specified on the IPCONFIG statement in the initial profile.
• HiperSockets Accelerator does not accelerate packets either from or to interfaces configured with optimized latency mode. For more information about optimized latency mode, see Optimized latency mode in z/OS Communications Server: IP Configuration Guide.
• You cannot enable HiperSockets accelerator support if you specify the NODATAGRAMFWD parameter.
• You cannot enable HiperSockets accelerator support if you specify the IPSECURITY parameter.

QDIOPRIORITY priority

If traffic is being routed by way of HiperSockets Accelerator, the data is sent using the priority level specified by priority. priority values are in the range 1 - 4. The default is to send data using priority level 1. See the OSA-Express documentation in z/OS Communications Server: SNA Network Implementation Guide.

QDIOACCELERATOR | NOQDIOACCELERATOR

NOQDIOACCELERATOR

Specifies that inbound packets that are to be forwarded by this TCP/IP stack should not be routed directly between any of the following combinations of interface types:

• A HiperSockets interface and an OSA-Express QDIO interface
• Two OSA-Express QDIO interfaces
• Two HiperSockets interfaces

These packets are processed and routed by this TCP/IP stack.

NOQDIOACCELERATOR is the default value. If NOQDIOACCELERATOR is explicitly specified, the stack confirms this type of routing with the message:

EZZ0817I QDIO ACCELERATOR IS DISABLED

QDIOACCELERATOR

Specifies that inbound packets that are to be forwarded by this TCP/IP stack are eligible to be routed directly between any of the following combinations of interface types:

• A HiperSockets interface and an OSA-Express QDIO interface
• Two OSA-Express QDIO interfaces
• Two HiperSockets interfaces

These packets do not need to be sent to this TCP/IP stack for forwarding. This also applies to packets that would be forwarded by the Sysplex Distributor. This type of routing is called QDIO Accelerator. See the information about QDIO Accelerator in z/OS Communications Server: IP Configuration Guide for more details on this function.

Use of the QDIOACCELERATOR parameter is confirmed by one of the following messages:

EZZ0817I QDIO ACCELERATOR IS ENABLED
EZZ0819I QDIO ACCELERATOR IS ENABLED FOR SYSPLEX DISTRIBUTOR ONLY
EZD2020A QDIO ACCELERATOR IS ENABLED ONLY FOR SYSPLEX DISTRIBUTOR BECAUSE OF TCPIP PROFILE FILTER RULES
EZD2021A QDIO ACCELERATOR IS ENABLED ONLY FOR SYSPLEX DISTRIBUTOR BECAUSE OF POLICY FILTER RULES
EZD2022A QDIO ACCELERATOR IS ENABLED ONLY FOR SYSPLEX DISTRIBUTOR BECAUSE OF DEFENSIVE FILTER RULES
EZD2023I QDIO ACCELERATOR IS ENABLED WITH CURRENTLY INSTALLED IP FILTER RULES

You receive the following message with the appropriate reason if QDIO Accelerator support cannot be enabled. You also receive this message if QDIOACCELERATOR is specified in the data set used with the VARY TCPIP,,OBEYFILE command, if TCP/IP was activated with NOIQDIOROUTING and NOQDIOACCELERATOR on the initial profile.

EZZ0818I CANNOT ENABLE QDIO ACCELERATOR - reason

Rule: IQDIOROUTING is ignored if QDIOACCELERATOR is specified.

Restrictions:

• If you specify the NODATAGRAMFWD parameter, then QDIO Accelerator applies only to packets that are forwarded by the Sysplex Distributor.
• If you specify the IPSECURITY parameter, TCP/IP monitors your IP filter rules and defensive filter rules that apply to routed traffic. Depending on your filter configuration, QDIO Accelerator might be restricted to only packets that are forwarded by the Sysplex Distributor. For more information about QDIO Accelerator and IPSECURITY, see Search orders used in the native MVS environment in z/OS Communications Server: IP Configuration Guide.
• QDIO Accelerator support cannot be enabled during VARY TCPIP,,OBEYFILE command processing unless either QDIOACCELERATOR or IQDIOROUTING was specified on the IPCONFIG statement in the initial profile.
• QDIO Accelerator does not accelerate packets either from or to interfaces configured with optimized latency mode. For more information about optimized latency mode, see Optimized latency mode in z/OS Communications Server: IP Configuration Guide.

QDIOPRIORITY priority

Specifies that traffic routed by QDIO Accelerator to an OSA-Express QDIO interface be sent using the priority level specified by the priority value. The priority level can be in range 1 - 4. The default is to send data using priority level 1. See the OSA-Express information in the z/OS Communications Server: SNA Network Implementation Guide.

MULTIPATH | NOMULTIPATH

NOMULTIPATH

Disables the multipath routing selection algorithm for outbound IP traffic. If there are multiple equal-cost routes to a destination and NOMULTIPATH is specified, TCP/IP uses the first active route found to send each IP packet. The NOMULTIPATH parameter is confirmed by the message:

EZZ0615I MULTIPATH SUPPORT IS DISABLED

This is the default value.

Rule: The NOMULTIPATH parameter applies to outbound IP traffic that is routed by using the main route table. This parameter applies also to outbound IP traffic that is routed by using a policy-based route table if the Multipath UseGlobal parameter is specified on the RouteTable statement that defines the policy-based route table. See RouteTable statement for more information.

MULTIPATH

Enables the multipath routing selection algorithm for outbound IP traffic. In general, multipath routing provides the routing distribution necessary to balance the network utilization of outbound packets by load splitting. Multipath routing requires multiple equal-cost routes that are either defined statically or added dynamically by routing protocols (except for RIP, which does not provide multipath routing). If MULTIPATH is specified without any subparameters, the default is PERCONNECTION. The MULTIPATH parameter has no effect if there are no multipath routes in the TCP/IP configuration.

Guideline: In some cases, it might appear data is not being equally distributed among each of the equal-cost interfaces. This depends upon the characteristics of the application that is sending or receiving data. For example, when osnmp walk is issued, the application initially sends data using a source IP address of INADDR_ANY. Subsequently, when the application receives a response, all future sends use the source IP address of the interface where data was just received. The result is that all data is sent out on a single interface, independent of any multipath setting.

Rules:

• The MULTIPATH parameter and its subparameters apply to outbound IP traffic that is routed by using the main route table. This parameter and its subparameters apply also to outbound IP traffic that is routed by using a policy-based route table if the Multipath UseGlobal parameter is specified on the RouteTable statement that defines the policy-based route table. See RouteTable statement for more information.
• The multipath routing selection algorithm is applied and can be specified separately for each route table. Specify the algorithm for the main route table by using the MULTIPATH parameter on the IPCONFIG statement. Specify the algorithm for policy-based route tables in the policy definition for each table. See RouteTable statement for more information.

Note: The IPCONFIG MULTIPATH|NOMULTIPATH configuration option affects Enterprise Extender (EE) traffic when MULTPATH=TCPVALUE is coded. For information about multipath for EE see z/OS Communications Server: SNA Network Implementation Guide. For information about the MULTPATH start option, see z/OS Communications Server: SNA Resource Definition Reference.

PERCONNECTION

After a round-robin route is selected, connection or connectionless oriented IP packets using the same association always use the same route, as long as that route is active. The MULTIPATH PERCONNECTION parameter is confirmed by the message:

EZZ0632I MULTIPATH PERCONNECTION SUPPORT IS ENABLED

For more information about EE load balancing and standard logic for a UDP application, see z/OS Communications Server: SNA Network Implementation Guide.

PERPACKET

Connection or connectionless oriented IP packets using the same source and destination address pair do not always use the same route, but do use all possible active routes to that destination host. The MULTIPATH PERPACKET parameter is confirmed by the message:

EZZ0632I MULTIPATH PERPACKET SUPPORT IS ENABLED

Restrictions:

• Use this option only as an attempt to improve aggregate throughput of IP traffic over multipath routes and for routes for which potentially high CPU consumption in reassembly of out-of-order packets at the receiving end is not an issue. Performance varies according to network configurations used.
• The MULTIPATH PERPACKET parameter cannot be specified if IP security is configured. If both are specified, the following messages are displayed, and multipath routing is disabled:

  EZZ0763I CANNOT ENABLE IPV4 MULTIPATH PERPACKET SUPPORT WHEN 
           IPV4 SECURITY IS ENABLED
  EZZ0615I MULTIPATH SUPPORT IS DISABLED 

• IP traffic on RSVP-based routes cannot use this option. Instead, the PERCONNECTION option is used for these routes.
• Fragmented and packed IP datagrams cannot use this option. These datagrams are being sent over one selected route to the intended destination.

PATHMTUDISCOVERY | NOPATHMTUDISCOVERY

NOPATHMTUDISCOVERY

Indicates that TCP/IP is not to provide path MTU (PMTU) discovery support. This is the default value. The NOPATHMTUDISCOVERY parameter is confirmed by the message:

EZZ0623I PATH MTU DISCOVERY SUPPORT IS DISABLED

PATHMTUDISCOVERY

Indicates that TCP/IP is to dynamically discover the PMTU, which is the smallest MTU of all the hops in the path. Use this parameter to prevent fragmentation of datagrams. The PATHMTUDISCOVERY parameter is confirmed by the message:

EZZ0623I PATH MTU DISCOVERY SUPPORT IS ENABLED

Requirement: PATHMTUDISCOVERY uses ICMP fragmentation-needed errors to detect the PMTU for a path. If you use PATHMTUDISCOVERY, you must permit ICMP errors to flow at all hosts along the path of a connection. PATHMTUDISCOVERY does not function if a firewall blocks ICMP errors.

For a policy-based route table, the IgnorePathMtuUpdate parameter on the Policy Agent RouteTable statement can be used to prevent the path MTU value from being updated for routes in the table. See the information about the IgnorePathMtuUpdate parameter in RouteTable statement for information about determining when you should prevent the path MTU value from being updated for a policy-based route table.

REASSEMBLYTIMEOUT reassembly_timeout

The amount of time (in seconds) allowed to receive all parts of a fragmented packet before the fragments received are discarded. The minimum value is 1, the maximum value is 240, and the default is 60.

SEGMENTATIONOFFLOAD | NOSEGMENTATIONOFFLOAD

Specifies whether the stack should offload TCP segmentation for IPv4 packets to OSA-Express features. The TCP segmentation offload support transfers the overhead of segmenting outbound data into individual TCP packets to QDIO-attached OSA-Express devices that support this function. Offloading segmentation of streaming-type workloads reduces CPU use and increases throughput. This parameter is ignored for OSA-Express features that do not support segmentation offload. This value overrides the SEGMENTATIONOFFLOAD or NOSEGMENTATIONOFFLOAD parameter specified on the GLOBALCONFIG statement.

See the steps for modifying topic for information about changing this parameter while the TCP/IP stack is active. See TCP segmentation offload in z/OS Communications Server: IP Configuration Guide for more information about TCP segmentation offload support.

NOSEGMENTATIONOFFLOAD

TCP segmentation is performed by the TCP/IP stack. This value is the default value.

SEGMENTATIONOFFLOAD

TCP segmentation is offloaded to the OSA-Express feature.

SOURCEVIPA | NOSOURCEVIPA

NOSOURCEVIPA

Specifies that TCP/IP is not requested to use the corresponding virtual IP address in the HOME list as the source IP address for outbound datagrams. The NOSOURCEVIPA parameter is confirmed by the message:

EZZ0351I SOURCEVIPA SUPPORT IS DISABLED.

NOSOURCEVIPA is the default value.

SOURCEVIPA

Requests that TCP/IP use the TCPSTACKSOURCEVIPA address (if specified) or the corresponding virtual IP address in the HOME list as the source IP address for outbound datagrams that do not have an explicit source address. If the outgoing interface was defined with the INTERFACE statement, TCP/IP uses the VIPA specified on the SOURCEVIPAINTERFACE parameter of the INTERFACE statement instead of the HOME list. You must specify the TCPSTACKSOURCEVIPA parameter, update the HOME statement, or use the SOURCEVIPAINTERFACE parameter of the INTERFACE statement for the SOURCEVIPA parameter to take effect. For more information about how the order of the HOME list impacts source VIPA selection, see HOME statement. This parameter has no effect on RIP packets used by RIP services (NCPROUTE or OMPROUTE) or OSPF packets used by OSPF services (OMPROUTE). The SOURCEVIPA parameter is confirmed by the following message:

EZZ0351I SOURCEVIPA SUPPORT IS ENABLED

Tip: You can override the SOURCEVIPA or TCPSTACKSOURCEVIPA values. See the information about source IP address selection in z/OS Communications Server: IP Configuration Guide for the hierarchy of ways that the source IP address of an outbound packet is determined.

STOPONCLAWERROR

Stops channel programs (HALTIO and HALTSIO) when a device error is detected. The STOPONCLAWERROR parameter is confirmed by the message:

EZZ0345I STOPONCLAWERROR IS ENABLED

SYSPLEXROUTING | NOSYSPLEXROUTING

NOSYSPLEXRouting

Specifies that this TCP/IP host is not part of an MVS sysplex domain. Use of the NOSYSPLEXROUTING parameter is confirmed by the message:

EZZ0350I SYSPLEX ROUTING SUPPORT IS DISABLED 

NOSYSPLEXROUTING is the default value.

SYSPLEXRouting

Specifies that this TCP/IP host is part of an MVS sysplex domain. The SYSPLEXROUTING parameter is confirmed by the message:

EZZ0350I SYSPLEX ROUTING SUPPORT IS ENABLED 

TCPSTACKSOURCEVIPA | NOTCPSTACKSOURCEVIPA

NOTCPSTACKSOURCEVIPA

Specifies that TCP/IP does not use a stack-level IP address as the source address for outbound TCP connections. The source IP address is governed by the IPCONFIG SOURCEVIPA setting.

TCPSTACKSOURCEVIPA vipa_addr

The IPv4 address (vipa_addr) is used as the source IP address for outbound TCP connections if SOURCEVIPA has been enabled. The vipa_addr value must be a static VIPA or an active dynamic VIPA (DVIPA).

If SOURCEVIPA has not been enabled, TCPSTACKSOURCEVIPA is ignored, and the following message is issued:

EZZ0706I TCPSTACKSOURCEVIPA IS IGNORED - SOURCEVIPA IS NOT ENABLED

Restriction: At the time of an outbound TCP request, the TCPSTACKSOURCEVIPA address must be a static VIPA or active dynamic VIPA, or it is not used for the source IP address.

Tips:

• After it is set, TCPSTACKSOURCEVIPA is not disabled until a profile explicitly adds NOTCPSTACKSOURCEVIPA to the IPCONFIG statement.
• If you specify the same distributed DVIPA interface for TCPSTACKSOURCEVIPA on multiple target stacks, you also should specify SYSPLEXPORTS on the VIPADISTRIBUTE statement. Otherwise connections might be disrupted because identical connections could be created from more than one stack.
• Carefully consider the following condition when determining the interface to use for TCPSTACKSOURCEVIPA. A dynamic VIPA that becomes inactive because it moves to another TCP/IP stack, or that is deleted because the application that caused its creation (in the case of a VIPARANGE created address) causes its deletion, is no longer a valid interface for TCPSTACKSOURCEVIPA.
• The use of TCPSTACKSOURCEVIPA can be overridden. See the information about source IP address selection in z/OS Communications Server: IP Configuration Guide for the hierarchy of ways that the source IP address of an outbound packet is determined.
• TCPSTACKSOURCEVIPA is not used when an outbound TCP request is connecting to an IP address that is active in the Home list.

TTL time_to_live

Number of hops that packets originating from this host can travel before reaching the destination. If the destination is more hops away, the packet never reaches the destination. The minimum value is 1, the maximum value is 255, and the default is 64.

Steps for modifying

Usage notes

• If the stack is enabled for IPv6 and the user specified LONG format, the command output is displayed in IPv6 format.
• The FORMAT keyword is meaningful only for stacks that are not enabled for IPv6. It controls the format of the command output. If FORMAT SHORT is specified and the stack is enabled for IPv6, then the following error message is displayed:

  EZZ0687I FORMAT SHORT IGNORED - IPV6 SUPPORT IS ENABLED

• If you do not include any configuration data in the OMPROUTE configuration file for the XCF links, OMPROUTE does not communicate a routing protocol (OSPF or RIP) over the interfaces. OMPROUTE includes (in the data sent to other routers) information relative to the XCF links as long as Send_Static_Routes=YES is configured for RIP Interfaces and AS_Boundary_Routing(Import_Static_Routes=YES) is configured for OSPF.

  Rule: If you want to communicate the OSPF or RIP protocol over a subset of the XCF links, you must configure the appropriate links in the OMPROUTE configuration file using the OSPF_Interface or RIP_Interface statements. Doing this enables OMPROUTE to communicate to other routers not only the information relative to the XCF links, but also information relative to resources on the other side of the host at the opposite end of the XCF links.

  To configure the appropriate links, you can explicitly configure each XCF link as either an OSPF or RIP interface (including those that might become active in the future). Alternatively, you can use the wildcard configuration capability of OMPROUTE to configure your XCF links.

  To use the wildcard configuration, use a wildcard address (for example, 9.67.100.*) on the OSPF_Interface or RIP_Interface statement instead of an explicit address. In this way, any interface address falling within that wildcard range (9.67.100.1, 9.67.100.2, and so on) is configured using the parameters specified on the wildcard definition statement.

  When adding links, XCF or otherwise, to both OMPROUTE and TCP/IP, it is necessary to add them to OMPROUTE before adding them to TCP/IP for proper routing protocol configuration.

Related topics

• GLOBALCONFIG statement
• IPCONFIG6 statement
• SRCIP statement