F5 BIG-IP Local Traffic Manager (LTM) Reviews

We use it as a load balancer.

We have always used it and never had any issues with it.

The most valuable feature is being able to manipulate the iRules, so you can send traffic to different avenues.

The auto logout feature after three minutes is terrible. I wish they would make that longer, since it is not a feature that we can change.

It contributes to our traffic by about fifty percent. That's why we love it. We have never had any issues.

We put a lot of stress on our F5 on-premise. We have support, which is great. It is a ten out of ten.

We have over 12 applications that we use it for with about 300 servers which are connected up using this load balancer. 

We're a big company. We do like the on-premise version. However, we are looking into AWS servers to help us scale for larger avenues as well.

We reached out to the technical support a few times, and they are great. They are a ten out of ten.

The integration and configuration are great. When I need to make changes, I have been fine.

We are currently using the Terraform Infrastructure as Code. Therefore, we are using the F5 provider to create new nodes, pools, and purchase servers, and the integration has been seamless for us.

We are going to the AWS Marketplace because purchasing there is simple to do. We are looking for the ease it provides. We have tried other providers, but it wasn't as good.

We did not evaluate anything else.

Take advantage of it and use it.

We use the on-premise version of this product. We are looking into moving over to the AWS version.

We are using it for load balancing and security.

When someone requests data through the load balancer, we pull the certificate name out to identify who that person is. This is one of the things that F5 does. We haven't able to replicate this so far with the Amazon products. That is why we are going to F5.

It has the ability to do the security work that we need along with the current thing which is supporting the load balancer. Therefore, it can determine if the system is going down, then route the traffic somewhere else.

It does what we need.

We had a problem where customers were doing transactions in our system, pulling health records, and the system had to be shut down for maintenance. Unfortunately, we wouldn't know that the system was being shut down, and we would lose that information. Then, the customer would get upset.

Using the F5, we were able to build rules to detect that the shutdown was occurring, then begin to route people elsewhere, so we didn't have any outages or downtime. This made customers a lot happier, and it made us a lot happier.

They could improve the product's ease of use. There has been a bit of complication on some things from the admin side. There is some confusion how to operate it.

I don't think too much stress placed on it. In F5 Studio, the stability been very good.

We run 14 servers. We get up to about half a million transactions an hour, and the scalability has been good. It has not been a problem.

I would rate the technical support as a five out of ten. Our admin had to learn everything and do it himself. He seems to have had difficultly at times with the tech support. However, this may be a manifestation of the fact the government bought it, but didn't buy the support.

The integration and configuration of this product were pretty good. Once you get going, it gets easier to use.

It works with Red Hat JBoss application server, and it integrates reasonably well.

It is sort of a commodity product. A load balancer is a load balancer. What will be, at the end of the day, the cheapest option or have the best performance, that is what it will come down to. Can it do the necessary performance that we need, and if so, is there a cheaper alternative? If not, then we'll stick with what we have.

We also evaluated some free stuff on the AWS Marketplace, or some cheaper stuff. We also looked at the Amazon offerings, like the Elastic Load Balancing.

The customer wanted to take what they had on-premise and put it in Amazon: full stop. Because we could obtain the certifications for security and the existing Amazon products didn't do 100 percent of what F5 did, they didn't want us to change any code. They just wanted us to keep going the way we were. This is the reason why we pulled F5 over.

Try doing a proof of concept or a prototype, before you go full in on a load balancer, to make sure it does everything you need.

We have both the AWS and on-premise versions. We used the on-premise version to compare it to what Amazon had to offer. 

• Load balancing
• Certificate management
• Pooling of services

• Load balancing deployments
• Active pools and standby pools for high availability.

• Load balancing
• Being able to adjust headers. 
• Request response headers. 
• Patching issues in the load balancer that we don't want in the application layer.

Certificate management needs improvement. I would like automated deployment of new certificates without manual intervention to be in the next release of this product.

The product is very stable. We put a decent amount of stress on it given our load.

It seems to be a very scalable product. 

As for the size of our environment, we have our own data center, but it's a small data center.

I would give it a nine out of ten for its stability and feature set, as well as the way it handles our load.

Definitely consider this product on your product evaluation list.

It is the front-end to the cloud for all the services in our data center. So, it sort of integrates with all of our services.

We have yet to integrate it with AWS.

We use it for load balancing and routing.

It supports APIs and virtual additions for cloud and VMware.

It integrates with various firewall and networking devices along with application services, and it works fine.

• Routing
• Load balancing

• Cloud native integration should be provided.
• Native support for containers should be added to future releases, as this is the future of load balancing.

The stability is great. We put our production load on it, which is very stressful.

Scalability has been great. We have thousands of severs. F5 has scaled very well.

They provide average enterprise technical support.

I also evaluated Cisco, but chose F5 because it had better features in terms of load balancing. I liked the various features in F5, including input/output routing, load balancing, and global load balancing.

Explore the API support and integration with the open source products. Those are the key thing to analyze. F5 are the experts in their area.

I use the on-premise version.

We use it for a number of solutions that we build, mostly for identity and access management control.

It is the centerpiece of a lot of the solutions that we build, and it has integrated with everything that we have needed it to.

It is the best value for our engineers and architects who know how to use it. It meets the government's requirements every time that we've used it. It is easy for us to keep integrating with our solutions.

We have found the consistency of the application always being the way it is supposed to be as its most valuable feature.

We put a lot of stress on the application. It is very stable.

The scalability is awesome. Our environment is thousands upon thousands of instances in AWS.

Purchasing through the AWS Marketplace was very simple. The main reason that we went this way was the simplicity of buying it there. It is maintained and upgraded for us, and this makes it easy to stay current.

While the licensing is good through the AWS Marketplace, it is more expensive than what you could buy yourself. However, the convenience outweighs the price.

When we migrate workloads into the cloud, we need the same functionality in the cloud, and low balancing is part of that. Being able to manage the platform on cloud, the same as on-premise, is the use case.

Load balancing generally brings high availability and a bigger ability to scale out. In some cases, it brings security, depending on how it is configured.

• Flexibility
• Capacity
• Reputation in the market.

I would like them to expand load balancing, being able to go across multiple regions to on-premise and into the cloud. This could use improvement, as it is sometimes a little cumbersome.

It is very stable. It's a pretty solid product.

Our clients use it pretty heavily. Most all of them are production workloads and some of them are external facing workloads, so you can see seasonal peaks.

It's very scalable. Probably the largest implementation I did was with hundreds of servers behind it.

The technical support is very good.

We haven't had any issues with the integration and configuration of AWS. It works just like it would on-premise. I have some questions around its scale in the cloud. We haven't done as much work in the cloud as we've done with on-premise. However, so far we haven't had any problems with it either.

My clients have seen ROI.

It could be priced a little less, especially on the virtual side. It gets a bit expensive, but you get what you pay.

There is always the Cisco on-premise solution in play. There are also the AWS native functionalities.

The ease of management is the tie-breaker for F5, being able to manage the on-premise and cloud with the same tools.

It's fairly easy to integrate. If you compare it to Cisco products, Cisco is very regimented and works best with themselves. F5 has been forced to play nice with others, which is a bonus.

The three key things to look at closely:

1. Look at the flexibility of the products.
2. The ability to work with it on-premise and in the cloud is a huge advantage.
3. The ability to integrate it with other non-F5 products.
   

We use both the AWS and on-premise versions. They work about the same, which is what I like about the product: same management plane and configuration.

It integrates with the networking layer, which is fairly complicated. Depending on the customer, there are different products that it integrates with. More often than not, it's load balancing in front of Windows in Unix. In some cases, integrating with other tools like the LP or other network products.

We use it for low balancing.

It has been in our environment for four to five years, but I have only been using it for a little over a year.

• The detail that you have available when setting up iRules. 
• How the traffic routing works in F5.

The management process seems a bit difficult. 

The management interface is unclear, complex, and not concise. I would like a better user interface.

For integration with other AWS environments, we do some tie-ins with some autoscaling groups. This has been challenging for us. We have had issues, where when autoscaling groups scale up, there are some instances which are not showing up in the proper size. Then, those IPs would get registered with F5, but never get released. Therefore, we are ending up with a whole bunch of ghosted IPs. However, this is more an implementation detail than an F5 detail.

It is very stable. I have no concerns regarding stability for F5.

We are seasonal, so we go from low to high volumes. F5 has never been a concern of ours for stability.

We run an Active-Active version of two instances, so scalability between the on-premise and AWS versions hasn't been a huge issue for us. Where we are finding the AWS version helpful is when we are trying to scale up new environments. AWS Marketplace helps here a lot.

We have support agreements in place, but they are managed by the infrastructure team. I do not contact the technical support, they do.

The integration and configuration into the AWS environment was pretty good.

The product was already in place when I came onboard.

My preference is to use AWS natively, but there are some issues around session management and so on, which have prevented us from using it. While a lot of these issues have been solved, a lot of our applications are tied to the F5 infrastructure.

Always use the Automatic Synching between F5. Don't try to use the API to do the synching. This is where we went wrong. We were trying to push the nodes to F5 individually instead of letting F5 handle the synchronization process, and it doesn't work.

We were previously using the on-premise version, but now we are using the AWS version. They are about the same as far as functionality.

We use it primarily for WAF.

The ability to quickly set up. I understood it very quickly. I had some URLs which pointed to my load balancers, and inside there, I had to send an action to the API Gateway. I thought it was going to be a very complex thing for me to do, but that one rule that I had to create, it solved everything for me.

The connection through the API Gateway worked in no time, which was fantastic. From the perspective of us building it, once you have that one rule you can stamp it out. Also, it was easy for me to show operations, "Look how easy it is. There's nothing complex about it." 

• iRules
• Simplicity

I was able to simply and quickly set up the WAF rules and security, and also set up easily complex policies and rules which gave me some great features to redirect. So, I had to integrate API Gateway into our WAF, because we're a healthcare company, and we have to maintain security. Therefore, they didn't want to have public endpoints that had not been inspected. The policy features inside the WAF rules were really easy for me to set up. What I thought was going to take me two months, I had done in about two weeks. Between Googling and F5 having great information, so instead of using traditional iRules, I used a policy thing that they recommended. It was much simpler and cleaner, and seemed to execute faster. It was a great feature.

The configuration and implementation of what I thought I was going to have to do was a lot simpler than I expected it to be. That was a plus.

People love them in security, but their costs are completely out of bounds. However, I'm not a security guy, so I don't necessarily know all the ins and outs of why our security team may have chosen this product versus other ones.

I am disappointed with the additional cost. 25 megabytes is low. If we get to a thousand, a gig, It is like three dollars an hour. While you can get a reduction in price, when I price them against anyone else, they are wildly overpriced.

I used GitHub for autoscaling CloudFormation, and I found two bugs and I submitted them. Their implementation in GitHub could be cleaner and allow for a bit more customization. We always end up customizing these things, so I found two bugs and I thought they were big bugs so I was surprised. This wasn't necessarily relative to product. It was more about the support role of GitHub and the way it was launching. However, the features that they said would work, did not.

It seems very stable. I've had no problems with stability at all. It's been rock solid, from the perspective of staying in line and working as expected.

I did individual testing. We were doing very small tests to start, 25 megabits. So, I was driving close to 25 megabits through it. Memory and CPU, I thought might be a bit of a concern, but overall it seemed good. It was doing what I needed it to do, and doing it well, so I didn't notice anything in my traffic.

I haven't thought of production workloads on it yet. I don't know how the performance is going to be in terms of CPU memory, but I was told by other people because of what we're doing on it, it could be hard to scale. So, we may have to end up buying more because we will be encrypting and decrypting. We have to inspect that traffic, so that will be CPU intensive. Therefore, one instance may not be enough for us, as we may be spinning up multiples across Multi-AZs.

We will be just stacking our costs. Granted, it is virtualization, and you can only get so much out of it. However, I haven't put true production workloads through it. I have only done my testing, and I am concerned a bit about these factors and how they may drive our costs even more, because I will have to spin up more WAFs to accommodate for high CPU and memory loads.

From a cost perspective, I agreed to analyze the standards in terms of load balancing. However, the cost that they have with AWS are almost prohibitive. I'm being forced to use F5 WAF. I would not simply use it based on cost. I agree that they have some great features, but for me, cost is key in terms of AWS. 

This applies to buying in the AWS Marketplace. If you go to a simple WAF doing 25 megabits, and I'm paying for the instance cost as well, it is over a dollar an hour. You can add that up and ask for some discounts, but relative to other players, they are significantly more expensive.

We will need a lot of these, and it can be a real negative driver in terms of spend and how we will be able to move forward.

Purchasing though the AWS Marketplace was easy; it was a piece of cake. You go right in, and the options are there. It was nice you can pick the different kind of group you wanted and what type of security you wanted. It did put in a lot of information that would build a lot of the initial infrastructure for me in terms of supporting my load balancer and creating security. Granted, I destroyed it all, but it was nice and it was there. It gave me the ability to level set what I should create versus what they put in place. I could see what they're doing here and I can match it to my own criteria. What they put in the AWS Marketplace and came through with the license, it worked well.

We chose to go through the AWS Marketplace because you can do almost anything you are going to launch there. The first time you launch, you always grab from the market, particularly for PoCs, as it's just easier. There's no reason why I wouldn't go through the AWS Marketplace, because they've already have F5 WAF. It's exactly what I want and it's exactly what I needed, so I can go from there.

I am a fan of using AWS natively. It is much cheaper.

We also looked at Check Point and Barracuda, but they were not markedly cheaper. The whole reason to use AWS was its ability to create resources which have more economic scale. This has almost started to get lost with the prices that these companies are charging.

I started my PoC back in April, which is when  I finished three PoCs across different deployments for F5. So, I'd probably been using the product for about eight months.

The product works.

We have F5 all across our environment. We use them for both VPNs and for traditional load balancers. So, we have VIPRIONs and several different versions of on-premise F5 hardware, as well. From an operations team perspective, everything is easy to learn; seamless. The ability to get teams to focus on AWS F5 is easy because they already know everything there. From an operational perspective, it is a win-win because they already know how to work with the F5.

Within our AWS environment, it is integrated with network load balancers. Then, depending on the traffic flow, it can either be back-end through the Palo Alto IDS IPS or it can be front-end for the IDS IPS. So, it has integration in between there, which was very nice. I was able to set up very intricate NAT rules, because I had to handle the traffic away. It did work very well. There were some issues with the routing, but that was more how AWS routes rather than F5 which I had to work around. Other than that, getting traffic back and forth between the two and the network load balancing was a piece of cake.