GLOBALCONFIG EXPLICITBINDPORTRANGE
You must specify the EXPLICITBINDPORTRANGE parameter on the GLOBALCONFIG profile statement if you are using or intend to use either of the following configurations:
- A distributed DVIPA as a source IP address in a DESTINATION rule in a SRCIP block
- A distributed DVIPA as a source IP address in a JOBNAME rule in a SRCIP block for an application that might use an IPv6 socket to connect to a mapped IPv4 destination address (this applies only if the stack is IPv6 enabled)
The EXPLICITBINDPORTRANGE parameter on the GLOBALCONFIG statement establishes a pool of ephemeral ports that is managed to guarantee the uniqueness of an assigned port across the sysplex (or subplex). This pool of ports is used to provide a sysplex-wide unique ephemeral port for any application that issues an explicit bind() to INADDR_ANY or the IPv6 unspecified address (in6addr_any) and port 0 before issuing a connect() request.
If an application uses an explicit bind() to INADDR_ANY or in6addr_any and port 0 before connecting, TCP assigns an ephemeral port from this pool to assure uniqueness across the sysplex, because it cannot be determined at the time of the explicit bind() whether the source IP address determined at connect() time might be a distributed DVIPA derived from a match on a JOBNAME or DESTINATION rule in the SRCIP block. Sysplex-wide coordination of the assigned ephemeral port value is required when the source IP address is a distributed DVIPA, so that each connection 4-tuple remains unique across the sysplex.
When EXPLICITBINDPORTRANGE is configured, selecting a distributed DVIPA during connect processing from a matching SRCIP JOBNAME or DESTINATION rule is also permitted when the application has explicitly bound the source port to either a port number less than 1024 or to an ephemeral port that is reserved for the job by a PORT or PORTRANGE profile statement. However, if the source port is bound to an ephemeral port that is not reserved for the job and the source address selected from a SRCIP rule during connect processing is a distributed DVIPA, the connect request will fail.
When a profile is processed, a stack with a profile that contains a GLOBALCONFIG statement with an EXPLICITBINDPORTRANGE parameter takes the following actions:
- Connects to the coupling facility SYSPLEXPORTS structure that contains sysplex port assignment information
- Associates the stack with the pool established by the EXPLICITBINDPORTRANGE parameter
The structure is a list structure with an entry for each DVIPA address that has a VIPADISTRIBUTE statement with the SYSPLEXPORTS parameter anywhere in the sysplex (or within the subplex, if subplexing is being used). List 0 contains entries to maintain the explicit bind port range pool. Each stack that associates itself with the pool sets the port range for that pool. The stack creates and initializes, in the structure, a sublist in list 0 of assigned ports for that stack.
- When the GLOBALCONFIG EXPLICITBINDPORTRANGE statement in the TCP/IP profile is processed, each stack sets the range for the pool established by the EXPLICITBINDPORTRANGE parameter for all the participating stacks in the sysplex. If each stack defines a different range, the last EXPLICITBINDPORTRANGE parameter processed supercedes any previously specified port ranges. To prevent the range from varying based on the order in which stacks complete their profile processing, specify the same port range for each stack that configures GLOBALCONFIG EXPLICITBINDPORTRANGE. You can do this by specifying the GLOBALCONFIG EXPLICITBINDPORTRANGE statement in a file that is included in each stack's TCP/IP profile using an INCLUDE statement.
- Avoid overlap of the explicit bind port range with other ports
or port ranges reserved through either the PORT or PORTRANGE profile
statements. If you are using the EPHEMERALPORTS parameter of the TCPCONFIG
profile statement, ensure that the explicit bind port range does not
consume too many of the ephemeral ports that the stack might need
for general use. If a port in the pool established by the EXPLICITBINDPORTRANGE
parameter is reserved on a TCP/IP stack through the PORT or PORTRANGE
statements, the port cannot be allocated to that stack for EXPLICITBINDPORTRANGE
processing, which might restrict the number of ports in the explicit
bind port range that are available for EXPLICITBINDPORTRANGE processing.
For example, if you defined an explicit bind port range 40000 –
41000, and you have a PORTRANGE statement on that stack that reserves
ports 40500 – 41000, only ports 40000 – 40499 are available
to that stack for EXPLICITBINDPORTRANGE processing.
If an application binds to a port in the explicit bind port range that is reserved using a PORT or PORTRANGE statement, the bind is allowed, but the port is not treated as an EXPLICITBINDPORTRANGE port. It is not marked in the SYSPLEXPORTS coupling facility structure for coordination across the sysplex. This situation might cause connections to fail as a result of duplicate connection 4-tuples.
If an application binds to a port in the explicit bind port range that is not reserved using a PORT or PORTRANGE statement, the bind fails with errnojr JrExpBndPortRangeConflict (x734C).
Ports that are specified by the EXPLICITBINDPORTRANGE parameter cannot be used for normal ephemeral port allocation. Therefore, if the range of ports specified by the EXPLICITBINDPORTRANGE parameter overlaps the range of ports specified in the EPHEMERALPORTS parameter, this overlap might restrict the number of ports in the ephemeral port range. For example, if you defined an explicit bind port range 40000 – 41000, and you have an EPHEMERALPORTS parameter on the TCPCONFIG statement on that stack that limits ephemeral ports to 40000 – 41500, only ports 41001 – 41500 are available to that stack for general ephemeral port processing.
Result: EXPLICITBINDPORTRANGE takes precedence over TCPCONFIG EPHEMERALPORTS, which means that if TCPCONFIG EPHEMERALPORTS is in use, EXPLICITBINDPORTANGE might specify ports outside the EPHEMERALPORTS range.
To remove a stack's participation in the EXPLICITBINDPORTRANGE pool, specify the GLOBALCONFIG statement with the NOEXPLICITBINDPORTRANGE parameter using a VARY TCPIP,,OBEYFILE command. This causes that stack to disassociate itself from the EXPLICITBINDPORTRANGE pool. If you do this and you have applications that issue an explicit bind() to INADDR_ANY or in6addr_any and port 0 on this stack that might match the following rules, you must ensure that no distributed DVIPAs are used as the source IP address on the matching rule.
- The DESTINATION rule of the SRCIP block on this stack
- A JOBNAME rule of the SRCIP block on this stack, where the application associated with the job name might use an IPv6 socket to connect to an IPv4 mapped destination address (this applies only to stacks that are IPv6 enabled)