Protecting web applications hosted by your company and ensuring their availability is essential to the success of your business.  If your network is breached and your customers data is exposed not only is it bad for you and bad for your company. It’s also very bad for priority number 1… Your Customers.  With today’s economy the negative publicity associated with a breach could spell doom for your company.  With hackers rapidly exploiting Zero Day attacks,  SQL Injection attacks and XSS attacks through vast armies of online bot networks it is only a matter of time until they start attacking your network.  If they aren’t already….

OK, I will step down off my soap/sales pitch box now.  It is just hard to have any kind of a discussion in the realm of network security without mentioning the consequences of NOT implementing a solution to address those concerns.  In this post I am going to discuss some information on an implementation that I have been working on over the last few weeks.  Of course the normal disclaimers do apply. The solution I am going to discuss is just an example of one implementation.  There are a number of ways roll out one of these devices into your existing infrastructure.  And last but not least I recommend that you seek further guidance from a Certified F5 Product Consultant if you are planning on adding one these devices to your network.

Now for some background information about the network that this implementation will be carried out on. The client already has a BIG-IP 6400 unit set up and running in their live/production environment.  It is licensed for a wide variety of modules from F5 Networks including load balancing, SSL offload, WAM and GTM.  The client also has a BIG-IP 6400 setup as a failover peer to the production box just in case of a hardware failure.  However, the BIG-IP ASM 4100 unit that they have CANNOT be licensed for load balancing and is only licensed for a few modules, mainly the ASM and LTM modules.

Since the 4100 does not have a failover peer like the 6400 we had to come up with a way to ensure that if this device failed that it would not have a negative impact on network traffic. We also had to figure out a way to load balance traffic going through the device.

So how do you load balance traffic AND ensure that traffic always makes it to the target server when you only have one device and no load balancing module?  I have to admit I was stumped for a bit.  It was then that a friend (a wise man I must say) pointed out what is now obvious.  Use all of your available resources.  So the method of implementation that we chose addresses both of those issues by relying on the BIG-IP 6400 for Priority Group Activation and Load Balancing.  The solution is simple really:

On the BIG-IP ASM 4100

We created nodes each pointing to IP’s hosted on our production web servers. We created a separate pool for each node and then we created a Virtual Server (also known as a VIP) that references each pool.

On the BIG-IP 6400

We created individual nodes on the BIG-IP 6400 that point to the VIP’s that we created on the ASM 4100.  We then added those nodes to the existing pools for each web application. For each of those new pool members we set the Priority Group Activation to Less than 1 and assigned the new pool members to Priority Group #2. Therefore, if the ASM 4100 has a critical hardware failure all traffic will bypass the VIP’s associated to the ASM 4100 and will be directed to the other pool members that are available.

This solution has a wide variety of benefits including: preventing the client from having to load balance in two places, prevents the client from having to rewrite numerous complex iRules, eliminates the worry of having a single point of failured and all of that allowed the device to be rolled out in a very short amount of time.  One other important thing worth mentioning is that since the VIP to node address are a one to one mapping in this instance, it allows the security policy builder to ease into high traffic sites because you can apply the policy to one VIP at a time.  If you have four VIP’s all aimed at the same web application/service, using this method you can choose to build the policy based off just two of the VIP’s .  Which in a high traffic environment is less taxing on the policy builder and the ASM 4100 unit.

(ADDED 4-10-2009)

It has come to my attention that the stand alone version of the BIG-IP ASM 4100 cannot be used for load balancing period.  That feature has never been supported on the ASM 4100.


5 comments so far

Add Your Comment
  1. Have you found any good design guides for implementing LTM and ASM on two different appliances?

  2. Hello pjvela,

    What is it that you are trying to do exactly? I currently operate daily in an environment where a 6400 unit is used that runs GTM, LTM and WA. The 4100 unit that we have is tied directly to that as mentioned in the article above.

  3. It is possible to run the ASM module in transparent bridge mode as well:

  4. I almost forgot, there is also a good thread on the DevCentral forums that discusses this topic that you may want to check out if you have not already:

  5. […] naladar on BIG-IP ASM 4100 Implementation: A Few Tricks Of The Trade […]