Devious Networks

Objective 2.05 on the 301a blueprint requires the candidate to describe use cases for MAC masquerading. MAC masquerading is a feature that allows you to manually allocate a MAC address to a traffic group across a BIG-IP pair configured for High Availability. More specifically this MAC address floats between the devices in a HA pair along with the floating self-IPs and Virtual Addresses within the same traffic group.

Here is a typical network setup before MAC masquerade. Everyone is plodding along happily, all tables have converged and traffic is flowing.



Under failover conditions, the standby unit will become active for the traffic group(s) and send out a GARP for all failover objects in the traffic group(s):


The network infrastructure must now converge on the new topology. The Layer 2 switches will need to flush out their CAM tables for the MAC addresses associated with the floating objects and learn about them via the new interface attached to the previously standby, now active, unit. The Layer 3 devices (routers, firewalls etc.) are not immune to change in this scenario. They too will need to update their ARP tables with the new information.

MAC Masquerade Configuration

If we now add MAC masquerade into the mix we should see slightly different behaviour. Configuring a MAC masquerade address is done per traffic group. F5 provide some guidelines on how to craft a unique MAC masquerade address. The steps are:

1. Identify the pre-assigned MAC address.
2. Convert the first byte of the address to binary.
3. Change the second-to-last bit from 0 to 1.
4. Convert the binary value back to hexadecimal.
5. Replace the first byte of the original MAC address with the new hexadecimal value.

1. Original MAC address = 00:0C:29:8B:B3:45
2. First byte to binary = 0000 0000
3. Second to last bit from 0 to 1 = 0000 0010
4. Binary back to hex = 02
5. Replace first byte with new hex = 02:0C:29:8B:B3:45

Summary

Objective 2.06 of the 301a blueprint requires the candidate to have an understanding of how to setup Sync-Only and Sync-Failover Device Groups on a BIG-IP system. These two concepts form part of the Device Service Clustering (DSC) feature, basically High Availability. Introduced in v11.x, DSC improved on the previous High Availability mechanisms available by allowing configuration synchronisation and failover between two or more BIG-IP devices, in addition to mirroring connections between peers for faster failover.

DSC has a number of key components, however, this post will look into that of Device Groups, specifically Sync-Only Device Groups.

BIG-IP Device Groups

A device group is a collection of BIG-IP devices that trust each other and can synchronise, and fail over, their BIG-IP configuration data.

A BIG-IP system supports two types of device groups:

Sync Failover

This is the more common type of device group on production networks as it is the type that allows you to synchronise and failover configuration data from one device to another, e.g. those in an active/standby pair. A Sync-Failover device group uses another concept called Traffic Groups (see below) to determine which system objects (virtual servers, pools, nodes etc.) are include in the failover.

Sync-Only

This device group, and the topic of this post, allows you as the administrator to manually synchronise specific configuration data to one or more members of that device group by utilising system folders. A Sync-Only device group does not synchronise failover objects such as floating virtual servers.

Traffic Groups

What do we mean exactly by failover objects? A failover object on a BIG-IP system is part of another feature called Traffic Groups. A traffic group is a collection of related configuration objects on a BIG-IP system that can float between two or more BIG-IP systems in a High Availability cluster thus allowing those objects to be used on the standby device when a failover occurs. These objects include:

• iApps application services
• Virtual IP addresses
• NATs
• SNAT translation addresses
• Self IP addresses

Folders

• Default partition - the default partition on a BIG-IP system is the Common partition. You can of course create multiple partitions depending on your needs.
• Default folder - the default folder on a BIG-IP system is the /Common folder.

Sync-Only Device Groups

Now that we understand what folders are on a BIG-IP system we now need to take a look at Sync-Only device groups. One of the main uses of Sync-Only device groups that F5 recommends is to synchronise policy data within a specific folder to BIG-IP devices that are part of the same Sync-Only device group. All other configuration data are then synchronised between a subset of BIG-IP devices that are part of the same Sync-Failover group. This allows you to be granular with what you want to synchronise.

So for example, we have an active data centre and a standby disaster recovery site. Under steady-state conditions any changes we make to the BIG-IP cluster in the active site, such as adding new nodes, new pools and new virtual servers, we want to synchronise to the cluster in the DR site. However, we don't want the active site cluster to actually failover to the DR site. They are from a HA point-of-view separate systems. Or to put it another way, the HA pairs in each DC are in different Sync-Failover device groups and therefore do not have an associated Traffic Group(s) to failover.

Configuration

A prerequisite to configuring a Sync-Only device group is course to establish a trust relationship between the devices. This is required as you cannot add a device into a device group without the BIG-IP system having already established a trust relationship with that device. This post will not detail how to setup a device trust relationship between BIG-IP systems.

If you go to Device Management  ››  Device Groups then click Create and create the Sync-Only device group. The two key pieces of information required here are to set the Group Type to Sync-Only and ensure you add in as members, all the BIG-IP devices you want to in the Sync-Only device group. Automatic synchronisation is not supported using Sync-Only.

Once you've added all the details click Submit and now you'll have something like this:


Now we can go ahead and create a sub-folder under the default Common folder partition. To do this we need to SSH to the active unit in the active data centre and go into TMSH.

Folders are contained within the /sys folder configuration stanza so let's go there:

/sys folder

Now let's create a folder and define some attributes. By default when you create a folder it inherits some defaults attributes we don't want, specifically it inherits Traffic Group settings which we don't want.

create Sub-folder_1 device-group LAB-SYNC-ONLY-DG traffic-group none

A quick point on the above command. If you do not specify traffic-group none you will receive this error:

01070734:3: Configuration error: The floating traffic-group: /Common/traffic-group-1 must be set with the failover device-group: /Common/LAB-SYNC-FAILOVER-GRP on folder /Common/Sub-folder_1

The reason you get this is because by default the system will attempt to associate the traffic group under the parent /Common folder. As this is a Sync-Only device group we don't want to associated this with a traffic group.

Now we have our folder, let's go ahead and create an object within that folder. We'll use a simple example and create a node and a pool to use the node...

First change directory so you are in the new folder

cd Sub-folder_1

Now create a test node:

(/Common/Sub-folder_1)(tmos)# create ltm node TEST-NODE address 1.1.1.1

New create a test pool:

(/Common/Sub-folder_1)(tmos)# create ltm pool TEST-POOL members add { TEST-NODE:80 }

Don't forget to save:

save /sys config

Now we can see what LTM objects we have under this specific folder:

(Common/Sub-folder_1)(tmos.ltm)# show running-config
...
ltm node TEST-NODE {
    address 1.1.1.1
    session monitor-enabled
    state down
}
ltm pool TEST-POOL {
    members {
        TEST-NODE:http {
            address 1.1.1.1
        }
    }
}

We can also verify this on the GUI. What is interesting now is that we can see which folder the objects we created are within:

A question that may be on your mind is - do I need to manually create the folder on the standby device within the Sync-Failover device group? The answer is no, folders are synchronised between devices in a Sync-Failover device group so just ensure you synchronise the devices after you have created the folder(s).

So how do we know this is actually working? How can we verify that the objects we've created within the new sub-folder are being synchronised within the Sync-Only device group?

In the above configuration example we created a test node and pool. If we go to the GUI we can see in the top left-hand corner the device is telling us there are Changes Pending. If we click that link it'll take us to the Device Management overview page. Here we can see clearly that the system only shows changes pending for the Sync-Only device group and not the Sync-Failover device group.


If we now synchronise this device to all devices in the Sync-Only device group we will push the new objects to those devices only.

There is an alternative way you can create objects on the GUI. If let's say you wish to create a node you can use the following syntax when defining the name of the object:

<SUB-FOLDER>/<OBJECT-NAME>

E.g.:

Summary

Using the Sync-Only feature allows you to pick and choose what you want to synchronise amongst your BIG-IP systems fairly easily. This post did not delve too deeply, especially in regards to the other options available in the folder creation but hopefully provides enough high level insight to build upon. Consult a TMSH guide to check out some of the other options that may be useful for you.

Objective 2.04 in the 301a syllabus requires the candidate to have an understanding of the authentication process as it relates to remote authentication and authorisation on a BIG-IP system.

The BIG-IP system utilises two different account types:

System maintenance account:

This is your 'root' user, the account which is enabled by default on a BIG-IP device. This is the most powerful user on the system and by default it is granted full access to all BIG-IP system resources.

Standard user account

These are user accounts that are manually created by an administrator. These accounts can use local or remote authentication & authorisation.

A special note regarding the 'admin' account. Although this account comes on a BIG-IP system by default, it is still considered a user account because it resides in the local user account database.

This is the first of three posts that will provide detail on how to setup three methods of authentication & authorisation using a remote authentication server using the following protocols:

• TACACS+
• LDAP
• RADIUS

Cisco ACS TACACS+

TACACS+ is a protocol developed by Cisco and is used for all things Authentication, Authorisation & Accounting (AAA). TACACS+ adds a further layer of security to the process by encrypting the entire packet between the client and the server. The following section will show you how to setup the Cisco ACS v5.6 server to allow a BIG-IP system to utilise its AAA services. As we are also interested in remote authorisation I will demonstrate how to setup Active Directory integration so you can use AD Groups to determine roles on the BIG-IP. I will not be demonstrating Accounting in this post.

For this demonstration I have used a 90 day trial license of the ACS product. Note that you will need a CCO account with sufficient privileges to download this software.

AD Integration

First up let's integrate Cisco ACS with Active Directory. As this is a lab setting, all devices are on a common subnet. In a production environment you'll need to ensure you have the necessary ports open between the servers.

In ACS go to Users and Identity Stores >  External Identity Stores >  Active Directory, then click Join/Test Connection. Add the domain name for your network, then add an AD user + password with sufficient access to be able to create/delete Computers to the domain. Click Test Connection. A successful outcome should look like this:


Close this window and click Join on the first popup window. The two systems should now be integrated with ACS showing as a Computer device on AD and ACS showing as Joined and Connected:



Now we have AD integration we can leverage AD Directory Groups to provide granular authorisation to the BIG-IP based upon the group a user resides in. First we need to tell ACS which Directory Groups it can use for group mapping conditions.

In the same section we were in - Users and Identity Stores >  External Identity Stores >  Active Directory, click the Directory Groups tab then click Select. We need to now tell ACS the Search Base DN to start the group search. I've gone and started at the Users level as this is where I have defined my F5 user groups. I've also filtered it down to search for the specific groups I wish to add into ACS:

For the purposes of this demonstration I have added in a group containing F5 Admins (read/write access) and a group for F5 Operators (read-only access). Don't forget to save the configuration!

Identity Store Sequence

Now we need to tell ACS which databases to use for authentication using the Identity Store Sequence feature. Go to Users and Identity Stores >  Identity Store Sequences and click Create. Provide a meaningful name for the sequence and for the Authentication Method List select Password Based. Now add into the Selected box on the right the 'AD1' object within the Authentication and Attribute Retrieval Search List & Additional Attribute Retrieval Search List boxes. Click Submit.


First we need to add define a Device Group. Go to Network Resources >  Network Device Groups >  Device Type and click Create, enter a meaningful name, then click Submit.

Secondly we to add the device itself. Browse to Network Resources >  Network Devices and AAA Clients click Create and provide a meaningful name (hostname is a good idea), add it to the Device Group we've created, the IP address the ACS will expect the request to come from, and finally ensure that we select TACACS+ as the authentication protocol and include the Shared Secret key. Click Submit.


Now we need to create an Identity Group. Go to Users and Identity Stores >  Identity Groups and click Create. We'll create two Identity Groups; one for the F5 Admins and one for the F5 Operators.

Now we need to bind the Identity Groups to the appropriate Active Directory Groups. Go to Access Policies >  Default Device Admin, ensure the checkbox for Group Mapping is ticked click Submit.

Go Access Policies >  Default Device Admin > Group Mapping and select the Rule based result selection radio button and click OK when it warns you. Now click Create and give the rule a name and ensure the Compound Condition box is ticked. In the Dictionary choose the Active Directory config which takes the form AD-AD1. Click the Select button next to Attribute and then click ExternalGroups, then click OK. In the Value box click Select and now choose the AD Directory Groups the F5 admins reside in, then click OK. Now highlight the value in the Value box and click Add to add it to the Current Condition Set. In the Results box select the F5 admin Identity Group. Click OK. Repeat the above steps to create the Operator group and save.
We now need to select the Identity Source Sequence for the device admin authentication. Go to Access Policies >  Default Device Admin > Identity and click Select then choose the Active Directory object created in the Identity Store Sequence and click OK, then save.

Authorisation  

The next piece deals with authorisation and ensures the ACS passes back the appropriate attributes to the LTM. Go to Access Policies >  Access Services >  Default Device Admin >  Authorization and click Create. We'll start with the F5 Admin authorisation. Give it a name then under Conditions > Identity Group check the box and select 'in' then click the Select button and choose the 'F5-Admin' Identity Group created above and click OK.

Now select the checkbox next to the NDG: Device Type box and select 'in' then click the Select button and select the 'F5' Device Type created above and click OK.


In the Results section click the Select button. We'll create a shell profile on the fly. Click Create and on the General tab enter a meaningful name such as 'F5-Admin-Shell'. In the Common Tasks tab enter a value of Static, then 1 for the Default Privilege Level and Static then 15 for the Maximum Privilege Level.


In the Custom Attributes tab enter 'F5-LTM-User-Info-1' into the Attribute box. Leave the default Requirement of Mandatory and for the Attribute Value select Static and enter the following into the box - admin. Now click Add^, then Submit.

 Repeat the process by creating another shell profile for the Operators, however, use the value 'Ops' in the Attribute Value box. Now back on the Shell Profiles popup window select the 'F5-Admin-Shell' radio button and click OK, then OK again.


You will need to create another Device Administration Policy for the F5 Operators group but as you have already create the Operator shell profile above you won't need to go through that specific process again. You should now have two authorisation policies:

Finally the Cisco ACS TACACS+ server is now ready. Let's move onto the BIG-IP...

F5 TACACS+ AAA

Authentication

If we head on over to System  ››  Users : Authentication we have the option to change the authentication method for the entire box, that is, both GUI and SSH (terminal) access. There are a few key pieces of configuration required to set this up.

• Servers: No hidden meaning here. Quite simply add all the TACACS+ servers either by IP address or hostname (DNS is required to be configured for hostname resolution).
• Secret: Enter the password used to encrypt the TACACS+ session between the BIG-IP and the Cisco ACS servers.
• Encryption: For TACACS+ we set this to enabled.
• Service Name: For most implementations the value ppp is required.
• Protocol Name: This is the protocol associated with the Service Name. For most implementations the value ip is required.
• Authentication: If your ACS setup is active/standby leave the default option. If active/active choose the second option.
• Accounting Information:  As per the Authentication setting.
• Role: It may seem odd at first but we want to set this to No Access. The reason is because we don't want to do authorisation on the box itself.
• Partition Access: This will vary according to your setup but if only using the default partition leave this at the default setting of Common.
• Terminal Access: This can be left at the default as we control TMSH (CLI) access via authorisation.

Putting it altogether we have following:

Authorisation

On BIG-IP devices, the role a user is given is determined when using remote authorisation is determined by the Remote Role Group feature. We'll create two groups; one for admin and one for Operator. Go to System  ››  Users : Remote Role Groups and click Create, and enter the fields as shown:

Testing

With that we are now ready to test. I am using Wireshark to capture the TACACS+ packets between the BIG-IP and the ACS servers. If you open up Wireshark and go to Edit > Preferences > Protocols > TACACS+ you are able to enter the encryption key so you can see the messages in plain view. Of course, in a production setting you would need to consult your group security before doing this in Wireshark.

I have created two users on AD - John who is in the 'F5 Admins' group and Dave who is in the F5 Operators group. If I first log in using John's AD credentials...success! I am logged in and granted the Administrator role:



If I login using Dave's AD credentials it is also successful and I am granted the Operator role as planned:


If we analyse the Wireshark capture for Dave's transaction we see that the BIG-IP first sends a TACACS authentication packet:


The ACS then contacts Active Directory using LDAP and Kerberos requesting authentication for user 'Dave'. Once passed the ACS returns a TACACS authentication response back to the BIG-IP:

The BIG-IP now sends a TACACS authorisation message to ACS:


The ACS server then evaluates the request and responds back with the attributes within the Operator Shell Profile:


The BIG-IP now evaluates its Remote Role Group configuration and compares the attribute the ACS has sent back ('F5-LTM-User-Info-1=Ops') and then applies the Operator role to this user's login session.

Summary

There is no doubt that there are many steps to configure Cisco ACS for AAA services. This example only really touched on ACS's capabilities. A production enterprise system would go further in carving up the various locations, departments etc. to provide fine granular authentication and authorisation to network devices. From a BIG-IP perspective the Remote Role Groups feature provides us a relatively simple way to limit user access. This example only used two roles, however, the BIG-IP system offers many more depending on your needs.

TLS Client Authentication

One of the objectives (3.02) on the 301a exam blueprint talks about how to configure the various different SSL profile settings. One feature that you will struggle to find (or at least I have) utilised outside of some relatively focused and specialised situations, is that of Client Authentication (sometimes referred to as 'mutual TLS authentication').

Unlike the bog standard TLS connection we've all come to know and love whereby the client authenticates or verifies the server's certificate, Client Authentication works by the server requesting the client's certificate to verify. Madness.

The resulting TLS (v1.2) exchange ends up looking something like this, note the Client Certificate Request four steps down:

So why is this not used everywhere? This does appear to add another layer of security into the mix, although this has been debated. The most likely answers are that commercially, for most websites, this level of authentication is not needed. You also have to deploy this on mobile platforms which I would imagine would add a further layer of headache.

In business, however, there are times when it is beneficial, or even mandated by policy, that this form of 'mutual TLS authentication' is required. Business-to-business (B2B) transactions are a good example of where this technology might be employed. In fact, I know this because we implement mutual TLS authentication with some of our B2B partners. If a B2B partner wishes to consume some service within our network, the TLS handshake requires both parties to present and verify their certificates, anchored by a common 3rd party CA.

LTM TLS Client Authentication

So with that, we have the Client Authentication section of the Client SSL Profile on the LTM. This feature is disabled by default, that is, disabled on the parent clientssl profile. When enabled you get by default, the following settings which as they stand don't actually do very much. Indeed, enabling the feature without modifying is as practically useful as not enabling it at all. So you need to do something with it.

The first setting - Client Certificate has options thrice:

• Ignore (default): ignores any certificate presented and will not authenticate the client.
• Request: the system will request a certificate but will still establish a TLS session regardless of whether a valid certificate from a trusted CA is presented. Typically used alongside an iRule.
• Require: enforces client authentication. A session is established only if a valid cert from a trusted CA is presented.

For the purposes of this demonstration I will set this to require as this allows us to easily see what this feature actually does.

The next setting Frequency tells the system how often the client should authenticate a TLS session.

The Certificate Chain Traversal Depth  (default is 9) specifies how many certificates in the certificate chain presented to the LTM it should look through. For clarity, a chain represents the list of certificates from the root certificate all the way up to the end-device certificate itself. Here is an example of Amazon's certificate chain:



The Trusted Certificate Authorities setting allows you to specify which trusted CAs the LTM can use to verify the client certificate. It is here you'll probably want to take some further action to enhance the security posture of the overall connection. If you choose the system supplied ca-bundle you're widening, quite dramatically, the scope of what can be used to verify and ultimately trust the client certificate. For the purposes of this demonstration I have limited this to my lab CA server.

The Advertised Certificate Authorities setting allows you to specify to the client which CAs the server trusts. The use of this setting is optional and in most cases you won't actually need it. Firstly, in advertising a long list of CAs you increase the size of the TLS handshake message which is limited to 14,304 bytes. There may be limited cases where this setting is required as F5 K9839 describes. For the purposes of this demonstration I'll set this to the same CA as per the Trusted Certificate Authorities setting.

Finally, the Certificate Revocation List (CRL) allows you to specify a CRL file the LTM can use to verify the client certificate has not been revoked. The problem with using CRLs is the management overhead of constantly having to update them. An OCSP authentication profile may work better, however, I hang my head in shame as I have yet to successfully get this to work. The OCSP transaction is successful but the LTM resets the connection as soon as it gets back the OCSP response.

Putting it altogether we have the following profile:


Now when I (successfully) connect to the virtual server, in addition to the LTM sending the Certificate Request to the client it also sends across the CAs it will use to authenticate the session using the Distinguished Names parameter as shown:


If things go a little awry F5 have written a handy troubleshooting guide.

There is another thing to think about when using client authentication and that is of the end-user experience. In an enterprise environment a user may have more than one certificate in their personal certificate store that can be used for client authentication. I, for example, have two:



When a user targets an LTM virtual server configured for client authentication their browser may prompt them to select a certificate to use. This is the default behaviour for most browsers and looks something like this (Firefox prompt):


The choice of browser will determine what happens next. In Internet Explorer you can change a setting that tells IE not to prompt the user for a certificate selection if there is only one certificate in the Security Settings:


If there are more than two certificates then the user will always be prompted by IE.

In Firefox the behaviour is slightly different. You can set Firefox to automatically select a certificate:



When a connection is made Firefox will (unsurprisingly) automatically select one of the certificates. This behaviour may not be desirable as you may have certificates by more than one CA in the personal certificate store.

Chrome is a different beast as there is no obvious setting as per the other two browsers. I've done some digging around and it looks like a registry tweak to the AutoSelectCertificateForUrls is required although I haven't actually tested this out.

Summary

TLS Client Authentication on the LTM is fairly straightforward to setup and works well. The real challenge with this technology is a policy and process one. For example, if you need to make changes to the browser settings as above then obviously this will need to be discussed with your customers or your own group security department first to get buy-in.

In pursuit of my LTM specialist certification one of the early topics (Objective 1.03) in the blueprint is that of offloading functions to the LTM device. One of those functions - HTTP compression is a topic I've never given a great deal of thought to as we don't tend to use it heavily with our customers. It's difficult to say what level of understanding F5 expects a candidate to have in regards to HTTP compression for the 301a exam, but regardless, when you do something it's worth doing it right.

With that, this post will provide the reader with some insight of what HTTP compression is, why we need it and how it is implemented on the F5 LTM.

Sail Away...

HTTP is like a ship that carries cargo. The cargo is our data. HTTP ensures its cargo can be identified correctly, can be unpacked properly & can be moved quickly and efficiently. Sometimes, for the purposes of saving bandwidth, or increasing the speed of HTTP transactions, compression is performed by the web server. Not all data is a good candidate for compression, however. For example, data that is already compressed such as music files or video would not be suitable. Raw HTML & CSS would be suitable for compression.

Encoding

HTTP uses labelled entities to describe the meaning of the data and carry the content. A HTTP request & response message contains a number of headers, or entities. When a web client (e.g. a browser) makes a HTTP request to a web server it sends across a specific entity called Accept-Encoding in the header, amongst many others:


This entity tells the web server which compression algorithms the client supports. There are a number of compression algorithms that are used:

• GNU Zip (GZIP): Described in RFC1952
• DEFLATE: Described in RFC1951
• Compress: Unix shell compression (Wikipedia)
• SDCH: Google compression algorithm (see White Paper)

For this post we will only be looking at GZIP and DEFLATE as these are most commonly used.

Looking at the above image you can see that the client has informed the server it supports three algorithms. If a client does not indicate which algorithm it supports the server will assume it can support any, or the equivalent of Accept-Encoding: *. In fact taking this one step further, the Accept-Encoding entity can take the following forms:

Accept-Encoding: gzip, deflate (Both algorithms equally preferred)
Accept-Encoding: * (Accept any algorithm)
Accept-Encoding: gzip;q=0.5, deflate;q=0.8 (Deflate preferred, followed by GZIP)
Accept-Encoding: gzip;q=0.5, deflate;q=0.2, *;q=0 (GZIP preferred, followed by deflate, nothing else accepted)

The HTTP/1.1 specification defines an optional parameter called the quality value. This value indicates to the server the relative importance ("weight") of this parameter, where 0 is the minimum (least preferred) and 1 the maximum value (most preferred). If a parameter has a quality value of 0, then content with this parameter is `not acceptable' for the client. In the above example, since both algorithms do have a value explicitly defined they default to 1 so are equally preferred by the client.

The question now is, which one should the server choose when compressing the response?

When the web server generates the response message it encodes the message. An encoded message has the same Content-Type as the request. This is required to describe the original format so the client can properly display it once it has been decoded. The server also adds a Content-Encoding header indicating the algorithm used to compress the data. This is required to help the client understand how to decode or decompress the contents. The Content-Length header now represents the length of the encoded (compressed) body, not the original size.

Putting this altogether looks something like this:

F5 HTTP Compression

If there is one thing that can be said about F5 it's that they love a profile.

The BIG-IP system allows you to offload the HTTP compression task from the back-end web server through the use of a HTTP Compression Profile, which then needs to be applied to a virtual server. The gist of it works such that the system reads the Accept-Encoding header of the incoming client request to determine the preferred encoding method. The system then removes the Accept-Encoding header before sending it to the pool member. When the system receives the response from the pool member it compresses the data using the algorithm as set in the profile and re-inserts the Content-Encoding header.

Due to the number of settings available, the HTTP Compression Profile can be a little daunting at first, as is the case with many of the LTMs profiles. F5 do a good job of explaining what each of the settings actually do, all I would do is simply repeat it. I'd recommend heading over to this page to find out.

Some Checks

When considering HTTP compression for your network it is also prudent to first check your BIG-IP system's capability. First off check what limits your license allows for using the following command:

show /sys license detail | grep perf_http_compression_Mbps

In my lab I have an unlimited license, however, on our production boxes there is a limit:

Lab:

# show /sys license detail | grep perf_http_compression_Mbps

Production:

# show /sys license detail | grep perf_http_compression_Mbps

Secondly, check to see if your system supports hardware compression. This will obviously help to increase performance. The BIG-IP system does allow you to set different 'compression strategies'. This CLI only command allows you to define if you want the system to use hardware or software resources when doing compression. See this Knowledge Base article. The absence of any output from the command below tells you the system does not support hardware compression. On our production system, however, we do:

# show /sys license detail | grep "HTTP Hardware Compression"

The Test

For the purposes of this demonstration I'll be using the following setup:

I'll also be using Fiddler to monitor the transactions.

To ensure the LTM is actually doing something I'll perform a transaction without the HTTP compression profile applied. Here we can see that the total length of the uuencoded body is 22,215 bytes:


I'll now go ahead and apply the following custom HTTP compression profile to the virtual server:

ltm profile http-compression HTTP-COMPRESSION {

Note the underlined and italic commands - these are where I have applied the following custom settings to the profile, which has automatically inherited all other settings from its parent profile ('httpcompression'):

• content-type-include { text/html } -  only compress the body HTML content
• gzip-level 6  - set the degree to which the system compress the content where three values are possible: 1 (least compression but fastest), 6 (optimal in terms of compression & speed), 9 (most compression but slowest)
• uri-include { index.php } - only compress content if it is from this URI

The moment of truth...



We can see the LTM was perfunctory in its role as compressor of HTTP. Content length down to 4,805 bytes which represents a 78.4% saving compared to the original request. Not bad. Multiply this by thousands for a busy site and you can see the benefits.

You'll need to play around with the settings on your network to achieve optimal settings for your requirements. For example, does your network still use HTTP/1.0? If so, you would need to set the allow-http-10 setting to enabled. Do you need to modify the data compression strategy to make better use of hardware compression? If so, then this must be set at the command line. What type of content do you actually need compressing? My simple example demonstrates HTML compression, however, you can be more granular and even specify Linux regular expressions. Some examples of other types of content compression include:

• application/(xml|javascript|json) - Compress XML, JavaScript or JSON content
• .*\.pdf - Compress PDF files
• text/css - Compress CSS files

The above are examples of MIME types. Browsers often use the MIME type to determine what default action to do when a resource is fetched

Summary

HTTP compression can clearly provide significant benefits to your web application's performance. The F5 HTTP Compression feature helps to alleviate pressure from your backend servers and improve performance further. In saying that, like all features of any system, turning them on just because they are there is not how to do things. Approach this with a healthy degree of caution and understanding and always test out before deploying into production.

Thank for reading.

Getting there...

The path to becoming a F5 certified requires a number of prerequisites. At the most basic level you are required to create an account with the F5 Credential Management System (CMS) at https://certification.f5.com. Once registered and assigned a candidate ID, you login and are faced with a screen similar to the following (note: as I have already passed the 101 and 201 exams my status and homepage will look different to yours depending on which stage you are at):


A key point to note here is that you are also required to register with Pearson Vue for an F5-specific account. Even if you have an account with Pearson Vue for Cisco, as an example, you are still required to register for your F5 account.

With the exception of the Pearson Vue exam booking system, the F5 CMS is the place you manage all things related to your F5 certification. Here you are provided with a number of resources to help you through your studies to include the official study guides for the 101, 201, 301a, 301b, 302 and 303 certification, all written by Eric Mitchell.

One of the things I like about the F5 certification process is the controlled methodology by which you go through. F5 have a concept of being authorised to test. What this means is that you are initially authorised to take the first F5 exam on the curriculum - the 101 exam, and thus are provided materials to help you through this via the CMS, although the study guides can be downloaded directly from the F5 website.

With the right wind, and a sprinkle of dedication, once you pass your 101, the CMS unlocks the second exam and preparation materials for you - the 201 exam. This allows you to book the 201 exam via Pearson Vue. Once certified, the CMS offers a similar function to Cisco in that you can publish your credentials via email to a recipient as proof of your status.

As the following diagram illustrates, in successfully passing these exams you are now a Certified BIG-IP Administrator (F5-CA). A level I achieved in December 2016.