RouteTable statement

Use the RouteTable statement to create a table of the routes that can be used to route IP packets based on policy. A RoutingRule statement specifies the characteristics of IP packets and references a RoutingAction statement, which can reference one or more RouteTable statements.

The RouteTable statement is used to create a table of static and dynamic routes. The RouteTable statement is made up of Route entries and DynamicRoutingParms entries. A route entry is used to create a static route in the route table. The syntax for the route entry is compatible with UNIX standards and similar to the syntax for static routes in the TCP/IP profile's BEGINROUTES block. Dynamic routes are added to the route table by OMPROUTE based on the information provided in DynamicRoutingParms entries. IPv6 router advertisement routes are also added to the route table based on the information that is provided in the DynamicRoutingParms entries.

When a RouteTable statement is updated, the route table in the TCP/IP stack is updated. When a route entry is added, deleted, or updated, the static routes in the route table are updated and routes learned by way of ICMP or ICMPv6 redirect are deleted from the route table. When a DynamicRoutingParms entry is added, deleted, or updated, OMPROUTE updates the dynamic routes in the route table as needed, and any IPv6 router advertisement routes in the route table are updated as needed.

Route precedence is as follows:

1. If a route exists to the destination address (a host route), it is chosen first.
2. For IPv4, if subnet, network, or supernetwork routes exist to the destination, the route with the most specific network mask is chosen second. The most specific network mask is the mask with the most bits on. For IPv6, if prefix routes exist to the destination, the route with the most specific prefix is chosen second.
3. For IPv4, if the destination is a multicast destination and multicast default routes exist, the route with the most specific multicast address is chosen third.
4. Default routes are chosen when no other route exists to a destination.

Tip: The Options parameters on the route entry can be abbreviated using the same syntax that is used for static routes in the TCP/IP profile's BEGINROUTES block.

Parameters

name

A string 1 - 8 characters in length specifying the name of this RouteTable statement.

Restriction: Do not specify the values EZBMAIN or ALL (in any combination of upper and lower case letters) for the name value. The name EZBMAIN is reserved for the main route table that is generated by the TCP/IP profile's BEGINROUTES or GATEWAY statements. The name ALL is reserved for use with the PR modifier of the Netstat ROUTE/-r command.

IgnorePathMtuUpdate

Indicates whether IPv4 ICMP Fragmentation Needed messages should be ignored for this route table. When IPv4 path MTU discovery is enabled (PATHMTUDISCOVERY parameter on the IPCONFIG statement in the TCP/IP profile), IPv4 ICMP Fragmentation Needed messages are used to lower the MTU value that is used to send data to a specific IPv4 destination.

No

IPv4 ICMP Fragmentation Needed messages should be processed for this route table. This is the default.

Yes

IPv4 ICMP Fragmentation Needed messages should be ignored for this route table.

You might want to ignore the path MTU update for a policy-based route table that contains routes that are known to support large path MTU values. If routes in another route table are defined to the same destination or destinations that need a smaller path MTU value, specifying IgnorePathMtuUpdate Yes ensures that a path MTU update that is the result of sending data on a small MTU route does not cause an update to the path MTU for the route in the policy-based route table.

Guideline: The IgnorePathMtuUpdate option is an advanced option. You do not need to set IgnorePathMtuUpdate Yes. If you specify IgnorePathMtuUpdate Yes, path MTU updates are ignored for all IPv4 routes in the route table.

IgnorePathMtuUpdate6

Indicates whether IPv6 ICMP Packet Too Big messages should be ignored for this route table. IPv6 ICMP Packet Too Big messages are used to lower the MTU value that is used to send data to a specific IPv6 destination.

No

IPv6 ICMP Packet Too Big messages should be processed for this route table. This is the default.

Yes

IPv6 ICMP Packet Too Big messages should be ignored for this route table.

You might want to ignore the path MTU update for a policy-based route table that contains routes that are known to support large path MTU values. If routes in another route table are defined to the same destination or destinations that need a smaller path MTU value, specifying IgnorePathMtuUpdate6 Yes ensures that a path MTU update that is the result of sending data on a small MTU route does not cause an update to the path MTU for the route in the policy-based route table.

Guideline: The IgnorePathMtuUpdate6 option is an advanced option. You do not need to set IgnorePathMtuUpdate6 Yes. If you specify IgnorePathMtuUpdate6 Yes, path MTU updates are ignored for all IPv6 routes in the route table.

Multipath

Indicates whether the multipath routing selection algorithm is enabled for outbound IPv4 traffic that uses this policy-based route table.

UseGlobal

Use the MULTIPATH or NOMULTIPATH setting from the IPCONFIG statement in the TCP/IP profile to determine multipath processing. This is the default.

PerConnection

Enables the multipath routing selection algorithm for outbound IPv4 traffic that uses this policy-based route table. If multiple equal-cost routes to an IPv4 destination exist in this policy-based route table, a round-robin algorithm is used to select a route. After a route is selected, connection-oriented or connectionless-oriented IP packets using the same association always use the same route, as long as that route is active.

PerPacket

Enables the multipath routing selection algorithm for outbound IPv4 traffic that uses this policy-based route table. If multiple equal-cost routes to an IPv4 destination exist in this policy-based route table, a round-robin algorithm is used to select a route. Connection or connectionless oriented IP packets using the same association do not always use the same route, but do use all possible active routes to the destination.

The PerPacket option should not be used if IP security is enabled on the IPCONFIG statement in the TCP/IP profile. If Multipath PerPacket is specified for a policy-based route table and the route table is installed in a TCP/IP stack with IPv4 security enabled, multipath routing for IPv4 traffic is disabled. The following message is displayed: EZD0028I IPV4 MULTIPATH PERPACKET NOT VALID WITH IPV4 SECURITY - MULTIPATH SUPPORT DISABLED FOR ROUTE TABLE table

The Netstat ROUTE/-r PR command displays the MultiPath setting No(Policy) if multipath routing for IPv4 traffic has been disabled. This occurs because IPv4 security is enabled.

Disable

Disables the multipath routing selection algorithm for outbound IPv4 traffic that uses this policy-based route table. If multiple equal-cost routes to an IPv4 destination exist in this policy-based route table, the first active route that is found is used to send each IP packet to that destination.

Multipath6

Indicates whether the multipath routing selection algorithm is enabled for outbound IPv6 traffic that uses this policy-based route table.

UseGlobal

Uses the MULTIPATH or NOMULTIPATH setting from the IPCONFIG6 statement in the TCP/IP profile to determine multipath processing. This is the default.

PerConnection

Enables the multipath routing selection algorithm for outbound IPv6 traffic that uses this policy-based route table. If multiple equal-cost routes to an IPv6 destination exist in this policy-based route table, a round-robin algorithm is used to select a route. After a route is selected, connection-oriented or connectionless-oriented IP packets that use the same association always use the same route, as long as that route is active.

PerPacket

Enables the multipath routing selection algorithm for outbound IPv6 traffic that uses this policy-based route table. If multiple equal-cost routes to an IPV6 destination exist in this policy-based route table, a round-robin algorithm is used to select a route. Connection-oriented or connectionless-oriented IP packets that use the same association do not always use the same route, but use all possible active routes to the destination.

If IP security is enabled on the IPCONFIG6 statement in the TCP/IP profile, do not use the PerPacket option. If Multipath6 PerPacket is specified for a policy-based route table and the route table is installed in a TCP/IP stack with IPv6 security enabled, multipath routing for IPv6 traffic is disabled. The following message is displayed: EZD0028I IPV6 MULTIPATH PERPACKET NOT VALID WITH IPV6 SECURITY - MULTIPATH SUPPORT DISABLED FOR ROUTE TABLE table

The Netstat ROUTE/-r PR command displays the MultiPath6 setting No(Policy) if multipath routing for IPv6 traffic has been disabled. This occurs because IPv6 security is enabled.

Disable

Disables the multipath routing selection algorithm for outbound IPv6 traffic that uses this policy-based route table. If multiple equal-cost routes to an IPv6 destination exist in this policy-based route table, the first active route that is found is used to send each IP packet to that destination.

DynamicXCFRoutes

Indicates whether direct routes to IPv4 dynamic XCF addresses on other TCP/IP stacks should be added to this route table. The same routes are automatically generated in the main route table when IPv4 dynamic XCF links are active. See the dynamic XCF information in z/OS Communications Server: IP Configuration Guide for information about the dynamic XCF function and the definitions that are automatically generated when IPCONFIG DYNAMICXCF is specified in the TCP/IP profile.

Yes

Add direct routes to IPv4 dynamic XCF addresses on other TCP/IP stacks when the dynamic XCF links are active.

No

Do not add direct routes to IPv4 dynamic XCF addresses on other TCP/IP stacks. This is the default.

Rule: Duplicate routes are not allowed within a route table. If a statically defined route is a duplicate of a route generated by DynamicXCFRoutes Yes, the statically defined route takes precedence.

DynamicXCFRoutes6

Indicates whether direct routes to IPv6 dynamic XCF addresses on other TCP/IP stacks should be added to this route table. The same routes are automatically generated in the main route table when IPv6 dynamic XCF links are active. See the dynamic XCF information in z/OS Communications Server: IP Configuration Guide for information about the dynamic XCF function and the definitions that are automatically generated when IPCONFIG6 DYNAMICXCF is specified in the TCP/IP profile.

Yes

Add direct routes to IPv6 dynamic XCF addresses on other TCP/IP stacks when the dynamic XCF links are active.

No

Do not add direct routes to IPv6 dynamic XCF addresses on other TCP/IP stacks. This is the default.

Rule: Duplicate routes are not allowed within a route table. If a statically defined route is a duplicate of a route that the DynamicXCFRoutes6 Yes generates, the statically defined route takes precedence.

Route

A route entry is used to create a static route in the route table.

Restriction: Duplicate routes are not allowed within a RouteTable statement. Duplicate routes have the same destination and first hop specification (interface name and gateway address).

DynamicRoutingParms

A DynamicRoutingParms entry provides parameters for OMPROUTE to use when generating dynamic routes for the route table and for the stack to use when adding IPv6 router advertisement routes to the route table.

Restriction: Duplicate and overlapping DynamicRoutingParms values are not allowed within a RouteTable statement.

In the following example, the DynamicRoutingParms in both Table1 and Table2 are treated as routing policy errors because the DynamicRoutingParms values overlap:

RouteTable Table1
{
  DynamicRoutingParms Link1
  DynamicRoutingParms Link1 10.1.2.3
}

RouteTable Table2
{
  DynamicRoutingParms Link2 IPv6
  DynamicRoutingParms Link2 FE80::1:2:3
}

In the following example, the DynamicRoutingParms in both Table3 and Table4 are treated as Routing policy errors because the DynamicRoutingParms values are duplicates.

RouteTable Table3
{
  DynamicRoutingParms  Link1
  DynamicRoutingParms  Link1
}
RouteTable Table4
{
  DynamicRoutingParms  Link2 FE80::1:2:3
  DynamicRoutingParms  Link2 FE80::1:2:3}

ipaddress

The destination address. The address must be a fully qualified IP address.

The DEFAULT or DEFAULT6 keyword in this field specifies a default route. The destination address can be a host, network, subnetwork, supernetwork, or default address. For IPv6, the address cannot be an IPv4-mapped IPv6 address in hexadecimal or dotted decimal format or an IP address with the reserved prefix ::/96. A local address is not valid for the destination address. Multiple routes that have an identical destination can be specified. When multiple routes are specified, all of them are used when multipath is enabled; otherwise, only the first active route that is specified is used.

prefixLength

An integer value that represents the number of bits in the ipaddress value that are used to determine the destination address of the route. For an IPv4 destination, the value is in the range 1 - 32. For an IPv6 destination, the value is in the range 1 - 128.

gateway_addr

On a route entry, the gateway_addr value is the host IP address of a gateway or router that you can reach directly, and that forwards packets for the destination network or host. The value must be either a fully qualified address or an equal sign (=), which indicates that the messages are routed directly to destinations on that network or directly to that host. A local address is not valid for the gateway address. The equal sign is not supported for a default route entry. For IPv6, the address cannot be an IPv4-mapped IPv6 address in hexadecimal or dotted decimal format or an IP address with the reserved prefix ::/96.

On a DynamicRoutingParms entry, the gateway_addr value is one of the following values:

• IPv4

  Indicates that the intf_name value that is specified on this DynamicRoutingParms entry is an IPv4 interface. This is the default.

• IPv6

  Indicates that the intf_name value that is specified on this DynamicRoutingParms entry is an IPv6 interface.

• The host IP address of a gateway or router that you can reach directly, and that forwards packets for the destination network or host.

  It must be a fully qualified address. A local address is not valid for the gateway address. If an IPv6 address is specified, it must be a link-local address. OMPROUTE uses the IP address and the intf_name value to select dynamic routes to be included in this route table. If the gateway_addr value is an IPv6 address, the value is used with the intf_name value to determine which IPv6 router advertisement routes are added to this route table.

intf_name

The name of an interface as defined on the LINK or INTERFACE statement in the TCP/IP profile.

Restriction: Loopback and VIPA links are not allowed.

On a route entry, the intf_name value is the name of the interface through which packets are sent to the specified destination. If an intf_name value is specified that is not defined in the TCP/IP profile, the route is created but is not usable until that interface value is defined in the TCP/IP profile.

Tip: Routes that are configured for an undefined interface name are flagged as invalid on a Netstat ROUTE/-r PR display. The flags field includes the letter I.

On a DynamicRoutingParms entry, the intf_name value is the name of an interface through which packets can be sent. OMPROUTE uses the intf_name value to select dynamic routes to be included in this route table. If intf_name is the name of an IPv6 interface, the value is used to determine which IPv6 router advertisement routes are added to this route table. If gateway_addr has been specified, then intf_name is used in combination with the gateway_addr value. If an interface name is specified that is not defined in the TCP/IP profile, no dynamic routes or IPv6 router advertisement routes are created until the interface name is defined in the TCP/IP profile.

MTU mtu_size

The maximum transmission unit (MTU) in bytes for the destination. This value can be up to 65535. The keyword DEFAULTSIZE in this field requests that TCP/IP supply a default value of 576 for IPv4 routes and 1280 for IPv6 routes.

See Figure 1 for more information about the largest MTU value that each IPv4 link type supports.

See Table 1 for more information about the largest MTU value that each IPv4 interface type supports.

See Table 2 for more information about the largest MTU value that each IPv6 interface type supports.

Packet size considerations

• The largest mtu_size value that z/OS® Communications Server can handle varies for different networks. For example, although the largest packet size for the Ethernet protocol is 1500 bytes, the largest packet size for the 802.3 protocol is 1492 bytes.
• The actual packet size is determined by the total network connection.
  • If a locally attached host has a packet size smaller than your packet size, transfers to that host use the smaller size.
  • The TCP maximum segment size for the 3172 Interconnect Controller Program is 4096. Any packet specifications over 4096 are limited by this restriction. For example, if you specified the packet size 4352, the resulting packet size would still only be 4096 plus the header size, for a total packet size of 4132.
• Large packets can be fragmented by intervening gateways for IPv4 only. Fragmenting and reassembling packets is expensive because of high bandwidth use and CPU time. Packets sent through gateways to other networks should use the default size, DEFAULTSIZE, unless one of the following conditions is true:
  • All intervening gateways and networks are known to accept larger packets.
  • IPv4 Path MTU discovery is enabled by using PATHMTUDISCOVERY on the IPCONFIG statement, which results in the TCP/IP stack dynamically learning the maximum MTU for the total network connection. For IPv6, Path MTU discovery is always enabled.
• If this is a CLAW link, the mtu_size cannot exceed the write_size specified on the corresponding DEVICE statement.
• You cannot specify an MTU value that is smaller than the default MTU size. For IPv4, the default MTU value is 576 and for IPv6 it is 1280.

REPLACEABLE

Indicates that the static route can be replaced by OMPROUTE or IPv6 router advertisements if a dynamic route to the same destination is discovered. This parameter can be abbreviated to REPL.

Restrictions:

• Only one type (replaceable or nonreplaceable) of static route can be defined to the same destination. If multiple route entries are specified to the same destination and the REPLACEABLE or NOREPLACEABLE setting is not the same, it is considered to be a Routing policy error.
• Do not define replaceable static routes to destination addresses that correspond to dynamic VIPAs for which the TCP/IP stack is a sysplex distributor target. This is not validated by Policy Agent.

Tip: You can use the Netstat ROUTE/-r PR ALL RSTAT command to display all replaceable static routes currently configured in policy-based routing tables.

NOREPLACEABLE

Indicates that the static route cannot be replaced by dynamic routes. The static route is always used to reach the destination, regardless of any information that dynamic routes might be available. This is the default behavior. This parameter can be abbreviated NOREPL.

Restriction: Only one type (replaceable or nonreplaceable) of static route can be defined to the same destination. If multiple route entries are specified to the same destination and the REPLACEABLE or NOREPLACEABLE setting is not the same, it is considered to be a Routing policy error.

Retransmission parameter considerations

The parameters listed in this topic 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 specified 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 that 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 data packets are retransmitted 15 times before the connection is timed out. All of the remaining parameters listed in this topic affect the data packet retransmission algorithm. Only the MINIMUMRETRANSMITTIME parameter affects the initial connection establishment.

DELAYACKS | NODELAYACKS

Controls transmission of acknowledgments when a packet is received with the PUSH bit on in the TCP header.

NODELAYACKS

Specifies that an acknowledgment is returned immediately when a packet is received with the PUSH bit on in the TCP header. The NODELAYACKS parameter on the BEGINROUTES, GATEWAY, and RouteTable statements affects only the connections that use this route. Specifying NODELAYACKS on the TCP/IP stack BEGINROUTES or GATEWAY profile statements, or on the Policy Agent RouteTable statement, overrides the specification of the DELAYACKS parameter on the TCP/IP stack PORT, PORTRANGE, and TCPCONFIG profile statements.

DELAYACKS

Delays transmission of acknowledgments when a packet is received with the PUSH bit on in the TCP header. The DELAYACKS parameter on the BEGINROUTES, GATEWAY, and RouteTable statements affects only the connections that use this route. This is the default, but you can override the default by specifying the NODELAYACKS parameter on the TCP/IP stack PORT, PORTRANGE, or TCPCONFIG profile statements.

MAXIMUMRETRANSMITTIME

Limits the TCP retransmission interval. Decreasing this value might decrease the total time it takes a connection to timeout. Specifying MAXIMUMRETRANSMITTIME assures that the interval time never exceeds the specified limit. The minimum value that can be specified for MAXIMUMRETRANSMITTIME is 0. The maximum is 999.990. The default is 120 seconds. This parameter does not affect initial connection retransmission.

MINIMUMRETRANSMITTIME

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 MINIMUMRETRANSMITTIME is 0. The maximum is 99.990. The default is 0.5 (500 milliseconds).

ROUNDTRIPGAIN

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 RTT has on the average. The minimum value that can be specified for ROUNDTRIPGAIN is 0. The maximum value is 1.0. The default is 0.125. This parameter does not affect initial connection retransmission.

VARIANCEGAIN

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 VARIANCEGAIN is 0. The maximum value is 1.0. The default is 0.25. This parameter does not affect initial connection retransmission.

VARIANCEMULTIPLIER

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 VARIANCEMULTIPLIER is 0. The maximum value is 99.990. The default is 2. This parameter does not affect initial connection retransmission.

Retransmission parameters

Use the ROUNDTRIPGAIN, VARIANCEGAIN, and VARIANCEMULTIPLIER parameters to instruct TCP how heavily to weigh the most recent behavior of the network versus the long term behavior for updating the SRTT and VAR values. If you specify smaller values for these parameters, TCP attempts to correct for congestion only if the congestion is sustained. With larger values, TCP corrects for congestion more quickly, and the system is more sensitive to variations in network performance. Use the default values (unless your retransmission rate is too high).

Use DELAYACKS to delay the acknowledgments so that they can be combined with data sent to the foreign host.