There are quite a few new Profile settings in the LocalLB interface, I’m here putting all the different documentary evidence together for you so that you have an idea of how and when to use them. Verified Accept and Packet Loss settings are the most interesting to me, but if you use SIP, you might be more interested in the via_userdata settings, and if you’re concerned about protocol level security, the security_enabled TCP profile settings might be of more interest to you.

 

All in all, some cool stuff. Hope you enjoy it...

And I'll be back with more information on the SNAT ant Virtual Server interfaces.

ProfileHttp New Settings

ProfileHttp received only one new setting, and it requires that you have the Protocol Security Module (PSM) licensed to make use of it.

 

get_security_enabled_request_state

This routine takes an array of strings that represent the profile names you’d like to query, and returns an array of ProfileEnabledState variables that indicate the current state of protocol-level security on those Http profiles. Throws an exception if PSM is not licensed.

If set to “Enabled” for a given profile, all traffic on that profile will use a profile in the PSM to scan for security vulnerabilities in HTTP and attempt to block attacks via the protocol layer.

 

set_security_enabled_request_state

This interface takes an array of profile names and an array of ProfileEnabledState structures, one per name in the first array. It sets the current state of protocol-level security on the profiles listed. Like get_security_enabled_request_state, this routine will throw an exception if PSM is not licensed.

 

ProfileSIP New Settings

ProfileSIP (Session Initiation Protocol) only received one new value – the string to be appended at the top of the call routing history (in the Via command) when tracking is enabled.

 

get_via_userdata

This routine takes an array of profile names and returns an array of ProfileString elements, one entry per entry in the input array. The return value for a given profile is the string that will be inserted at the top of the routing trail for the Via command. You must have Insert Via Header enabled for the profile, and the value of the string is what is appended to other information BIG-IP places into the header.

 

set_via_userdata

This routine takes an array of profile names and an array of ProfileString elements, one per profile name, and sets the value to be appended to the via command to be the value in the ProfileString for the corresponding element of the profile name array. You must have Insert Via Header enabled for the profile for this routine to matter – it will work fine if you do not, but the value will never be appended.

 

ProfileTCP New Settings

ProfileTCP received three new settings, one telling the BIG-IP to ping the server before Acknowledging the client’s connection and two that manipulate when the BIG-IP begins to use congestion control. While most routines in this document are in alphabetical order by profile or module, these two have been flipped for ease of documentation.

 

get_packet_loss_ignore_rate

This routine gets the rate of packet loss that can be ignored. The rate is expressed as an integer and indicates the number of packets per million that can be lost before the BIG-IP begins applying congestion controls to the connections on this profile. The default value is zero and indicates that any packet loss will invoke congestion control. If set to a non-zero value, then that many packets out of a million must be lost before congestion control is activated… But see set_packet_loss_ignore_burst for an exception to this rule, and of course if the Profile’s Congestion Control value is set to “none”, then this value is ignored..

 

The routine takes an array of strings that are profile names, and returns an array of ProfileULong values, one per entry in the input array, specifying the rates applied to each profile.

 

set_packet_loss_ignore_rate

Takes an array of profile names and an array of ProfileULong variables, one per element in the profile name list, and applies the values in the ProfileULong variables as the ignore rate (per million) of the named profiles. Note that since the value is per million, you will raise an exception if you send a value larger than 1 million.

 

get_packet_loss_ignore_burst

The packet loss ignore burst value is the likelihood that the BIG-IP will kick in with congestion control even though the loss rate hasn’t been hit. It has a range of 1 to the maximum value of an unsigned long (4,294,967,295), with zero being a special “automatically kick in if a single packet is lost” value.

 

The routine takes an array of profile names and returns an array of ProfileULong values, one per name passed in. The values returned are the current settings for each respective profile.

 

set_packet_loss_ignore_burst

This routine sets the packet loss ignore burst values for the indicated profiles. It takes an array of profile names as Strings, and an array of ProfileULong values representing the ignore burst values, setting the ignore burst values in the profiles listed in the array of names to the corresponding values in the ProfileULong array

 

get_verified_accept_state

Normally, the BIG-IP acknowledges a client’s connection before handing the connection off to the destination server (as chosen from the Pool). When get_verified_accept_state is enabled for a given profile, BIG-IP selects the server from the pool that will receive this connection, sends it a SYN, and awaits the servers’ SYN-ACK before sending a SYN-ACK back to the client. While this increases connection integrity somewhat, it also slows down the rate of connection acceptance.

This routine takes an array of Profile names and returns an array of ProfileEnabledState variables, one per entry in the input array indicating the current state of verified accept for the corresponding input Profile name.

 

set_verified_accept_state

Sets the value of verified accept for the indicated profiles.

This routine takes an array of profile names and an array of ProfileEnabledState variables, setting the state of verified accept for the indicated profile names to the corresponding values from the array of ProfileEnabledState variables.

 

Still to Come

v.10 has a lot packed into it, and BIG-IP is a highly complex system. Some items require a lot more research and testing than others. The following routines are new in the LocalLB module, but I do not yet have a firm enough grasp on how they interact with other parts of the system to document them adequately for you, so I will circle back as soon as I understand the issues. Specific issues I am researching are listed with each interface, along with a general description of what they do.

VirtualServer

get_module_score

Kudos to Jason for pointing me at the relevant documentation on this one. As originally noted under this heading, it was documented, I just hadn't found it. He had.

The module score is used when load-balancing dynamically amongst Virtual servers that rely upon certain modules - ASM, or Web Accelerator for example - to show the weighting this instance should have when distributing load. Note that setting up module score is a multi-step process that involves creating score-based monitors and SNMP traps for those nodes/pools they monitor. It's use is optional. get_module_score simply returns the weight value associated with the Virtual Server in question. By itself it has not much meaning, but if you know of several Virtual Servers being dynamically load balanced against, the relative burden placed on each one can be found by comparing the module scores from each.

 

VirtualServer and SNAT

The problem here isn’t what source port behavior is – it’s how to handle connection contention for a port. The default is to allow multiple connections and service them on multiple ports, masking them to look like all the same port. The problem is that you can set the source port behavior in several places, and I’m not certain which one wins. If the Virtual Server says “force all connections through the same port on the target server”, but the SNAT servicing that Virtual Server says “handle this with a bunch of ports and just make them all look like the same port number to the client”, who wins? Intuitively, the most restrictive setting should win, but I need to do some research and validate that fact, don’t want to leave you with horribly incomplete documentation, and don’t want to hold up all the other good information in this document over these four routines, so as soon as I know, I’ll let you know.

get_source_port_behavior

set_source_port_behavior

get_source_port_behavior

set_source_port_behavior