Using Content Distribution tool with Jive

Many of Jive Software's customers rely on a third-party content distribution and content delivery network (CDN) tool to help their Jive pages load faster for globally-dispersed users. In this section, we describe some best practices for using Jive with these tools.

Note: The application can be configured to work with most CDN tools. While there are a number of hardware appliances that customers use inside their firewall, Jive has found that the majority of on-premise customers choose to deploy behind devices by F5 (http://www.f5.com/).

Recommended settings for F5

In most cases, your Jive configuration should rely on the default settings in F5. However, there are a few settings that Jive Software’s hosting engineers commonly customize to optimize hosted Jive deployments.

Generally, we recommend using the default settings in F5 because F5 is already optimized for them and customizations you create may require more processing, and thus, more load.

The following tables list the settings that our hosting engineers typically change in F5. These are general guidelines. Your needs may be different. Contact your Jive Software representative with specific questions.

Table 1. Node configuration
Setting Description
ICMP Health Monitor A simple ICMP request (PING) to the node to confirm it is online and operating at its most basic level.
Table 2. Pool configuration
Setting Description
TCP Health Monitor This is necessary because HTTP does not always show it is down when the Jive application goes into a maintenance mode. We depend on Web Injections via a separate monitoring service to determine whether a node in a pool is operational or not. Therefore, if a TCP connection fails to the port that is specified by the VIP, the node is considered down and removed from the pool. Note that a node is not considered down if the Jive application is down but the service is still running. This is why we use Web Injections to do more appropriate application level up time validation. For more information, see Monitoring your Jive environment.
Load balancing method: Least Connections (node) This causes the Jive application to load balance based on the number of connections to the node, regardless of whether the connections are related to the pool traffic. Therefore, load is balanced overall between individual nodes.
Table 3. HTTP VIP configuration
Setting Description
OneConnect /32 profile This profile is used to accommodate the CDN fronting the Jive application access. This setting allows F5 to properly handle multiple HTTP requests within the same TCP connection, as you would see when using a CDN. For more information, refer to F5’s documentation (http://support.f5.com/kb/en-us/solutions/public/7000/900/sol7964.html?sr=11716037).
HTTP Profile (this applies only if you are using F5 VIP’s with SNAT). This is a customized profile based on the parent HTTP profile to insert the true client source IP using either Request Header Insert or Insert X-Forwarded-For. This is for HTTP logging because F5 acts as a reverse proxy to the Jive web application nodes.
Set the SNAT Pool to Auto Map. F5 acts as a reverse proxy to the Jive web application nodes; the Jive application needs the traffic response from the web application nodes to respond back through F5. This setting isn’t required, but we recommend it as a best practice for configuring the F5 in a one-armed mode.
Set the default persistence profile to cookie This maintains session persistence based on an inserted cookie.
Keep iRules as simple as possible. At Jive Software, our hosting engineers try to keep iRule use to a minimum because they are evaluated each time traffic passes the VIP to which it is attached. Because this adds processing load, we recommend keeping it simple and adding as few iRules as possible.
Use an iRule or HTTP Class Profile for redirect from HTTP to HTTPS. To keep processing to a minimum, we recommend using the configuration options built into F5 rather than iRules to accomplish HTTP to HTTPS redirects. However, note that using an HTTP Class Profile for redirects uses a 302 redirect (Temporary), not a 301 redirect (Permanent). This may cause problems with your configuration. If this is acceptable for you, then you can use an HTTP Class Profile to accomplish your redirect; otherwise, you need to use an iRule. Here is an example of each:
  • iRule: 
    when HTTP_REQUEST {                                   
HTTP::respond 301 Location "https://[HTTP::host][HTTP::uri]"
}
  • HTTP Class Profile: use the Send To option and select Redirect To. Then, in the Redirect to Location, set it to https://[HTTP::host][HTTP::uri]
Table 4. HTTPS VIP configuration
Setting Description
Set everything the same as above in HTTP VIP Configuration, except the following:
Use the default HTTP Profile (this applies only if you are using F5 VIP’s with SNAT). The HTTP profile cannot be used to insert the true client source IP into the header of an HTTPS connection. This must be done by using an iRule for HTTPS traffic. Here is a simple example: 
when HTTP_REQUEST { HTTP::header insert JiveClientIP [IP::remote_addr] }
Set the Client SSL Profile to cover your SSL certificate, key, and chain. We recommend leaving everything else as the default parent profile of clientssl. You may want to consider removing the renegotiation option from the parent clientssl profile for security reasons.
Attention: Note that there is a potential DoS risk here. For more information, see https://community.qualys.com/blogs/securitylabs/2011/10/31/tls-renegotiation-and-denial-of-service-attacks.