Verify Access Appliance: Managing advanced tuning parameters

Manage advanced tuning parameters

Change the advanced tuning parameter values only under the supervision of IBM software support.
In the local management interface, select System > System Settings > Advanced Tuning Parameters. The following table lists the advanced tuning parameters available.

Parameter Value Description

nist.sp800-131a.strict Default is false. Whether nist.sp800-131a.strict mode is enabled.CAUTION:A value of true causes us to lose access to the appliance local management interface if your browser does not support TLS 1.2.

gw_net.tuning.downdelay Default is 0. Time, in milliseconds, to wait before disabling a slave after a link failure is detected.
The gw_net.tuning.downdelay value must be a multiple of the gw_net.tuning.miimon value; if not, it is rounded down to the nearest multiple.
If your switches take a long time to go into backup mode, it might not be desirable to activate a backup interface immediately after a link goes down. It is possible to delay the moment at which a link is disabled by passing the module parameter downdelay.

gw_net.tuning.miimon Default is 100. Specifies the MII link monitoring frequency in milliseconds.
High availability is achieved by using MII status reporting. The bonding driver can regularly check all its slaves links by checking the MII status registers. This parameter determines how often the link state of each slave is inspected for link failures.
A value of 0 disables MII link monitoring. A value of 100 is typically a suitable value. It means that a dead link will be detected 100 milliseconds at most after it goes down. The value must not come to close to 1000/HZ (10 ms on i386) because such setting might reduce the system interactivity.

gw_net.tuning.updelay Default is 0. Time, in milliseconds, to wait before enabling a slave after a link recovery is detected.
The gw_net.tuning.updelay value must be a multiple of the gw_net.tuning.miimon value; if not, it is rounded down to the nearest multiple.
When a switch restarts, it is possible that its ports report "link up" status before they become usable. This behavior might cause a bond device to use some ports that are not ready yet. It is possible to delay the moment at which an active link is reused by passing the module parameter gw_net.tuning.updelay (in milliseconds, must be a multiple of gw_net.tuning.miimon).
A similar situation can occur when a host renegotiates a lost link with the switch (in case of cable replacement).
A special case is when a bonding interface loses all slave links. Then, the driver immediately reuses the first link that goes up, even if gw_net.tuning.updelay parameter was specified. If there are slave interfaces in the gw_net.tuning.updelay state, the interface that first went into that state is immediately reused. This setting reduces downtime if the value of gw_net.tuning.updelay was overestimated.

gw_net.tuning.use_carrier 0, 1(default) Whether gw_net.tuning.miimon uses MII / ETHTOOL ioctls, or netif_carrier_ok() to determine the link status. The MII / ETHTOOL ioctls are less efficient and use a deprecated calling sequence within the kernel. The netif_carrier_ok() relies on the device driver to maintain its state with netif_carrier_on/off. Most, but not all, device drivers support this facility.
If bonding insists the link is up when it cannot be, the cause might be the network device driver does not support netif_carrier_on/off. The default state for netif_carrier is "carrier on". So if a driver does not support netif_carrier, it appears as if the link is always up. In this case, setting gw_net.tuning.use_carrier to 0 causes bonding to revert to the MII / ETHTOOL ioctls method to determine the link state.
A value of 1 enables the use of netif_carrier_ok(). A value of 0 specifies to use the deprecated MII / ETHTOOL ioctls. Default is 1.

gw_net.tuning.xmit_hash_policy layer2 (default), layer2+3, layer3+4 Selects the transmit hash policy to use for slave selection in balance-xor, 802.3ad, and tlb modes. Here are the possible values:

layer2

Uses XOR of hardware MAC addresses and packet type ID field to generate the hash. The formula is as follows:

hash = source MAC XOR destination MAC XOR packet type ID
slave number = hash modulo slave count

This algorithm places all traffic to a particular network peer on the same slave.
This algorithm is 802.3ad compliant.

layer2+3

This policy uses a combination of layer2 and layer3 protocol information to generate the hash. It uses XOR of hardware MAC addresses and IP addresses to generate the hash. The formula is as follows:

hash = source MAC XOR destination MAC XOR packet type ID
hash = hash XOR source IP XOR destination IP
hash = hash XOR (hash RSHIFT 16)
hash = hash XOR (hash RSHIFT 8)
hash = hash Modulo (bonding_slave_count)

If the protocol is IPv6, then the source and destination addresses are first hashed by using ipv6_addr_hash.
This algorithm places all traffic to a particular network peer on the same slave. For non-IP traffic, the formula is the same as for the layer2 transmit hash policy.
This policy is intended to provide a more balanced distribution of traffic than layer2 alone, especially in environments where a layer3 gateway device is required to reach most destinations.
This algorithm is 802.3ad compliant.

layer3+4

This policy uses upper layer protocol information, when available, to generate the hash. This allows for traffic to a particular network peer to span multiple slaves, although a single connection does not span multiple slaves.
The formula for unfragmented TCP and UDP packets is:

hash = source port, destination port (as in the header)
hash = hash XOR source IP XOR destination IP
hash = hash XOR (hash RSHIFT 16)
hash = hash XOR (hash RSHIFT 8)
hash = hash Modulo (bonding_slave_count)

If the protocol is IPv6, then the source and destination addresses are first hashed by using ipv6_addr_hash.
For fragmented TCP or UDP packets and all other IPv4 and IPv6 protocol traffic, the source and destination port information is omitted. For non-IP traffic, the formula is the same as for the layer2 transmit hash policy.
This algorithm is not fully 802.3ad compliant. A single TCP or UDP conversation that contains both fragmented and unfragmented packets causes packets to be striped across two interfaces. This situation might result in out of order delivery. Most traffic types do not meet this criteria, as TCP rarely fragments traffic, and most UDP traffic is not involved in extended conversations. Other implementations of 802.3ad might or might not tolerate this noncompliance.

Parent topic: System settings

Parameter	Value	Description
nist.sp800-131a.strict	Default is false.	Whether nist.sp800-131a.strict mode is enabled.CAUTION:A value of true causes us to lose access to the appliance local management interface if your browser does not support TLS 1.2.
gw_net.tuning.downdelay	Default is 0.	Time, in milliseconds, to wait before disabling a slave after a link failure is detected. The gw_net.tuning.downdelay value must be a multiple of the gw_net.tuning.miimon value; if not, it is rounded down to the nearest multiple. If your switches take a long time to go into backup mode, it might not be desirable to activate a backup interface immediately after a link goes down. It is possible to delay the moment at which a link is disabled by passing the module parameter downdelay.
gw_net.tuning.miimon	Default is 100.	Specifies the MII link monitoring frequency in milliseconds. High availability is achieved by using MII status reporting. The bonding driver can regularly check all its slaves links by checking the MII status registers. This parameter determines how often the link state of each slave is inspected for link failures. A value of 0 disables MII link monitoring. A value of 100 is typically a suitable value. It means that a dead link will be detected 100 milliseconds at most after it goes down. The value must not come to close to 1000/HZ (10 ms on i386) because such setting might reduce the system interactivity.
gw_net.tuning.updelay	Default is 0.	Time, in milliseconds, to wait before enabling a slave after a link recovery is detected. The gw_net.tuning.updelay value must be a multiple of the gw_net.tuning.miimon value; if not, it is rounded down to the nearest multiple. When a switch restarts, it is possible that its ports report "link up" status before they become usable. This behavior might cause a bond device to use some ports that are not ready yet. It is possible to delay the moment at which an active link is reused by passing the module parameter gw_net.tuning.updelay (in milliseconds, must be a multiple of gw_net.tuning.miimon). A similar situation can occur when a host renegotiates a lost link with the switch (in case of cable replacement). A special case is when a bonding interface loses all slave links. Then, the driver immediately reuses the first link that goes up, even if gw_net.tuning.updelay parameter was specified. If there are slave interfaces in the gw_net.tuning.updelay state, the interface that first went into that state is immediately reused. This setting reduces downtime if the value of gw_net.tuning.updelay was overestimated.
gw_net.tuning.use_carrier	0, 1(default)	Whether gw_net.tuning.miimon uses MII / ETHTOOL ioctls, or netif_carrier_ok() to determine the link status. The MII / ETHTOOL ioctls are less efficient and use a deprecated calling sequence within the kernel. The netif_carrier_ok() relies on the device driver to maintain its state with netif_carrier_on/off. Most, but not all, device drivers support this facility. If bonding insists the link is up when it cannot be, the cause might be the network device driver does not support netif_carrier_on/off. The default state for netif_carrier is "carrier on". So if a driver does not support netif_carrier, it appears as if the link is always up. In this case, setting gw_net.tuning.use_carrier to 0 causes bonding to revert to the MII / ETHTOOL ioctls method to determine the link state. A value of 1 enables the use of netif_carrier_ok(). A value of 0 specifies to use the deprecated MII / ETHTOOL ioctls. Default is 1.
gw_net.tuning.xmit_hash_policy	layer2 (default), layer2+3, layer3+4	Selects the transmit hash policy to use for slave selection in balance-xor, 802.3ad, and tlb modes. Here are the possible values: layer2 Uses XOR of hardware MAC addresses and packet type ID field to generate the hash. The formula is as follows: hash = source MAC XOR destination MAC XOR packet type ID slave number = hash modulo slave count This algorithm places all traffic to a particular network peer on the same slave. This algorithm is 802.3ad compliant. layer2+3 This policy uses a combination of layer2 and layer3 protocol information to generate the hash. It uses XOR of hardware MAC addresses and IP addresses to generate the hash. The formula is as follows: hash = source MAC XOR destination MAC XOR packet type ID hash = hash XOR source IP XOR destination IP hash = hash XOR (hash RSHIFT 16) hash = hash XOR (hash RSHIFT 8) hash = hash Modulo (bonding_slave_count) If the protocol is IPv6, then the source and destination addresses are first hashed by using ipv6_addr_hash. This algorithm places all traffic to a particular network peer on the same slave. For non-IP traffic, the formula is the same as for the layer2 transmit hash policy. This policy is intended to provide a more balanced distribution of traffic than layer2 alone, especially in environments where a layer3 gateway device is required to reach most destinations. This algorithm is 802.3ad compliant. layer3+4 This policy uses upper layer protocol information, when available, to generate the hash. This allows for traffic to a particular network peer to span multiple slaves, although a single connection does not span multiple slaves. The formula for unfragmented TCP and UDP packets is: hash = source port, destination port (as in the header) hash = hash XOR source IP XOR destination IP hash = hash XOR (hash RSHIFT 16) hash = hash XOR (hash RSHIFT 8) hash = hash Modulo (bonding_slave_count) If the protocol is IPv6, then the source and destination addresses are first hashed by using ipv6_addr_hash. For fragmented TCP or UDP packets and all other IPv4 and IPv6 protocol traffic, the source and destination port information is omitted. For non-IP traffic, the formula is the same as for the layer2 transmit hash policy. This algorithm is not fully 802.3ad compliant. A single TCP or UDP conversation that contains both fragmented and unfragmented packets causes packets to be striped across two interfaces. This situation might result in out of order delivery. Most traffic types do not meet this criteria, as TCP rarely fragments traffic, and most UDP traffic is not involved in extended conversations. Other implementations of 802.3ad might or might not tolerate this noncompliance.