F5 BIG-IP Local Traffic Manager (LTM) Reviews

I basically work for the solutioning only, so I've been migrating the F5 from the existing chassis to the new chassis for the last three years. Before that, I was a part of operations so I was working to support any incidents on F5. 

We have multiple solutions we can deploy through the F5.

The basic load balancing is acting as a round-robin. Other features we can use are based on the application team's requirements. F5 is not only basically giving solutions based on the network background, but it's also compatible based on the application level. Therefore, whenever the application team has a specific requirement, we can tweak it and we can provide the solution over the LTM.

For load balancing, for related solutioning, it is user-friendly. We have a good knowledge base over the F5 knowledge base. 

The stability is good.

The solution is scalable.

Technical support and documentation are excellent. 

For right now, I don't have anything I would suggest in terms of improvements.

I worked mainly on the CLI. Working on the CLI on the operations level or on the configuration level is sometimes a bit complex to understand. You have to have a good background in Linux so that you can perform the necessary solutioning or operations through the CLI. Whenever we want to investigate something we need to use the CLI, however, the CLI level troubleshooting and the solutioning, it is a little bit complicated. We have a limitation when it comes to the GUI. That said, I have found that we can do much better analysis with troubleshooting over the CLI.

Scaling up is complex. 

It's expensive. 

We need to have good security features available. It's something I still need to explore more, however.

I started using the solution six years ago.

It is quite stable. I never faced any issues. I would rate it ten out of ten for the LTM. It's a very stable product.

For scaling, there has to be a lot of planning when we need to scale up F5. It is a bit complex.

We cannot easily scale up the LTM. We cannot put an additional box into the production without any downtime with the user experience. So adding the box or scaling up has to be done with proper planning.

We have an extensive network of users across Office 365, SharePoint, custom applications, Skype for Business, et cetera.

Some customers who have been using the solution for the last six years are wanting to migrate or wanting to upgrade their chassis to the newer version. It is typically if they have a station-hungry application to deploy, like Teams, where this is quite a useful product. With F5, the transition is quite smooth.

I don't do any operation-related stuff. I don't deal with them too much.

Neutral

We also use many Cisco products.

I directly got the opportunity to work on the F5. I didn't work with any other vendor.

I worked on projects that were both difficult and simple. 

I remember I was working closely with the application team where they wanted to migrate their platform with zero downtime. They wanted to migrate the user data from one SharePoint to another SharePoint without any downtime. We used a specific i-rule. That i-rule checks the URLs and then it checks the decision as to whether to redirect the traffic to the specific node, which is the existing node, or in the new data center.

This was a kind of complex project. We had to troubleshoot when the users were getting the "page cannot be displayed" message. It was pointed out that it was an F5-related issue, however, later, when we check the per page of the node, which is behind EVIP, we tried to check the meeting URL on each node and we found that a specific node was giving the page cannot be displayed or 404 error. We learned we had to be careful about the migration of the application using the URL with zero downtime.

The main complexity was felt by the application team requirement. They wanted it in such a way that the user should not face any issues. The SharePoint migration should be from the existing infra to the new infra and should be transferred to the user. Due to that complexity, we have to work on the i-rule mainly, which was defining i-rules or providing solutions based on the URL part and it was a bit complex to do everything successfully. 

That said, on a normal application, a standard application, we have a good i-rule available over the F5, which we can use. It is only complex for custom applications.

For the standard application, it was very quick to deploy. We can deploy it in a day. If it is a complex i-rule with multiple URLs to be analyzed, or which checks the background, then it has to be tested well before being put in production. It takes longer. It takes time, based on the scope of the project and where you need to deploy.

How much help you need with maintenance depends on the scope of this project. If there is 24/7 support required in the operation, so based on the, let's say, specific DC, if we have one cluster for a specific application and additional, or two pairs of clusters or three pairs of clusters, I would say you would need three full-timers required in a day for operation-related topics. 

For solutioning, it typically depends on the scope of work, however, I would say a single full-timer can manage the solutioning. 

For complex issues we generally take a consultation from the F5, however, for the standard or medium standard application, we do it on our own. For the SharePoint migration using the complex i-rule, we took a consultation from F5.

We have seen an ROI. I would rate it five out of five in terms of the returns we've seen.

If you have LTM specifically, you can deploy multiple applications using one cluster and it will definitely be beneficial.

I'm not aware of the licensing costs. My understanding is that it is expensive. I'd rate it a four out of five in terms of the rather expensive cost.

We do pay for extra support.

I'm still one step behind the pre-sales in my current organization. I don't deal with any evaluations of other solutions. 

I'm a customer and end-user.

Currently, it's on-premises, however, we are targeting the cloud.

Sometimes we have to definitely look for external support, which is very good. They provide good support and good documentation. Once you have their help, with a good document, you can get some idea of what to do and how you can further customize the solution for other needs. For the very complex options, it's a good idea to have F5 support included at the beginning just to not waste time.

I'd rate the solution eight out of ten.

We have deployed it for two customers. One uses the local LTM for load balancing the application. The other uses it as a raft and for load balancing.

F5 is easy to deploy, though more challenging than Kemp. Configuration takes time, but it's stable. It offers features Kemp doesn't provide. For example, there are predefined templates for handling Office 365. You can download them for automatic configuration.

In terms of pricing, it could be more competitive.

I have been working with this solution for more than six years. 

It is a stable product.

It is scalable. All our customers are enterprise-level. 

I'm satisfied with the technical support from F5. The customer service and support are good. 

Positive

It is easy to deploy. It took us a few hours to deploy because we had experience with the solution. A few hours will be sufficient if you have already studied how to deploy.

Configuration and deployment depend on the GUI. F5 has a different GUI, so it takes some time to get used to it. Kemp, on the other hand, has a single page where you can access everything. 

With F5, you have to go to different sections for configuration. For example, to deploy a certificate, you import it, create a profile, go to the virtual service section, and link the profile. Kemp simplifies this process by allowing a static import of the certificate, making it more straightforward.

GUI plays a significant role in the ease of configuration.

One person is enough for the deployment process. 

Maintenance is not that difficult, but compared to Kemp, it is. Upgrading can be challenging; I faced issues with F5 upgrades, needed support assistance.

Pricing is quite high. We have taken it on a five-year basis. Not yearly.

And for support also, there is an extra cost.

It depends on the customer's requirements. If both F5 and Kemp provide have the same features, I would suggest the customer go with Kemp because it's the cheapest solution. But if the customer requires something different supported by F5, then go with F5.

Overall, I would rate the product a nine out of ten; there is room for improvement in the pricing model. 

I use the tool as a load balancer to distribute user traffic across different servers. It is used for scalability purposes. Depending on the amount of traffic that comes in, I can send that traffic to different servers and load-balance it. Also, the web application firewall protects our servers and applications from cyberattacks.

The most valuable feature of F5 BIG-IP Local Traffic Manager is that it allows you to manipulate things. Now, manipulation here is in the sense that you can do whatever you want to do in the solution using something called iRule, which is a programming interface for F5. So, this is something I find to be extremely useful when compared to other vendors.

Based on my experience using F5 and by only taking into consideration the last seven years, I have found that the reporting mechanism is bad. F5 seems to prioritize its core functions and has not placed a strong emphasis on logging and reporting. I say that the reporting is bad based on my experiences and after considering the requests from customers over the past 11 years. They often ask for specific reports and information that are not available from the devices.

I want the response from tech support to get faster.

I have worked for almost 11 years with F5 BIG-IP Local Traffic Manager.

The solution's stability is pretty good.

I handle almost a hundred-plus customers who are using this solution. The solution comes in different form factors. The high-end models are scalable owing to their ability to cater to certain requirements. So, since there are different models available, the solution is scalable.

I am not happy with the tech support. If I compare it with Fortinet, it is not great. Though I am able to connect over a call with the tech team, it is very difficult to get the right engineer at the right time. When it comes to Fortinet, you get the right person to help you at the right time.

While the initial setup of the tool is easy and straightforward, the complexity of onboarding each application can vary and depends on the specific application being used. Also, since I have been working on F5 for about 11 years, it may take me a day to deploy the whole setup.

I am not aware of the exact cost of the product. However, it is expensive. The pricing can either be on a yearly or monthly subscription basis, and this choice is left to the customer's discretion. The product also includes a basic hardware support guarantee and subscription-based services, which can affect the overall cost.

People need to have a basic understanding of HTTP and SSF. Additionally, this device is not solely a networking device but rather a solution that operates as an application device. Therefore, knowledge of applications, programming, and related fields is essential. I just mean to say that the people who are planning to use this solution should not only have a background in networking but also should possess some application programming knowledge. I rate this solution an eight out of ten.

We're offering services to citizens who access them over the internet, and we use F5 BIG-IP Local Traffic Manager (LTM) for load balancing between many physical servers or backend servers.

I like that F5 BIG-IP Local Traffic Manager (LTM) is a product that comes with valuable features, but what stands out from all features is load balancing.

An area for improvement in F5 BIG-IP Local Traffic Manager (LTM) is troubleshooting on the command line, which should be more graphical.

Another area for improvement is that it's a high-priced product.

What I want to see in the product's next release is more analytics.

I've worked with F5 BIG-IP Local Traffic Manager (LTM) for about five years, and I'm still using the solution.

F5 BIG-IP Local Traffic Manager (LTM) is stable, so I'm rating it nine out of ten.

F5 BIG-IP Local Traffic Manager (LTM) is a scalable product, but my company has yet to try scaling it because there's no need.

The technical support for F5 BIG-IP Local Traffic Manager (LTM) is responsive. F5 has a beneficial knowledge base that allows my team to solve many problems by consulting the knowledge base.

I'd rate support eight out of ten.

Positive

The initial setup for F5 BIG-IP Local Traffic Manager (LTM) was straightforward, so I'd rate its setup as nine out of ten.

It took a few days to deploy F5 BIG-IP Local Traffic Manager (LTM) because the company had a lot of applications.

My company set up the hardware, configured the network parameters, then tested the product on one application before applying it to all applications.

We used a consultant to deploy F5 BIG-IP Local Traffic Manager (LTM).

I found F5 BIG-IP Local Traffic Manager (LTM) an expensive product. The costs would depend on the appliance and infrastructure size. However, my company didn't have to pay extra to use additional features.

As F5 BIG-IP Local Traffic Manager (LTM) is very pricey, I'd rate its pricing as two out of ten.

I'm working with ADC products, particularly with F5 BIG-IP Local Traffic Manager (LTM).

A total of five people deployed F5 BIG-IP Local Traffic Manager (LTM) for my company. Three were internal, in particular, engineers, and two were consultants.

The solution requires maintenance when my company has a new application to publish and when, at times, there's a need to reset the backend configuration.

My company has many F5 BIG-IP Local Traffic Manager (LTM) users, with four people in charge of the administration and management of the product, though there's a plan to replace it because it will be EOL. The company is still prospecting and looking for alternatives, such as Barracuda or Fortinet.

I'd tell anyone looking to implement F5 BIG-IP Local Traffic Manager (LTM) that it's a good product, but its only problem is pricing.

My F5 BIG-IP Local Traffic Manager (LTM) rating is eight out of ten.

My company is a customer.

In terms of our primary use cases - all our web services, our main web portals, and our TV service sit behind the F5, so any customer would have to traverse our F5 for the services at the back of it.

It serves our backend and front end services.

In terms of what could be improved, I would expect more integration with different platforms and more integration with the backend systems.

Additionally, in the next release, I would like a more secure version.

I have been using F5 BIG-IP Local Traffic Manager for about five years now.

In terms of stability, it is stable, but we have a regular update program because of the security vulnerabilities, meaning bugs. So it is an ongoing thing maintaining them.

It's a bit of an overhead at the moment.

In terms of how many users we have using it, for the end user, all our customers go through the F5, so they are using it in terms of service. In terms of our engineers and how many people use it, that depends. If you're deploying it or you're in operations, like I am, there are hundreds of engineers and internal users.

We have weekly calls with F5 directly. We used to go through a third party, but now we go directly to F5 for our support.

When you buy it you have a license bundle which I think you have to renew every year or every couple of years.

On a scale of one to ten, I would probably give F5 BIG-IP Local Traffic Manager a six.

I would give it a warm recommendation, I would not give it a glowing recommendation. I'd give it a warm, "Tread with caution."

Our engineers use various products from the F5 BIG-IP range when creating application solutions. Primarily, we make use of F5 BIG-IP's ASM (Application Security Manager) and WAF (Web Application Firewall). For most of our applications, we require that our servers, and server-related software, are hosted in virtual machine environments.

In my team, we work in a very agile environment and the solutions from BIG-IP, including BIG-IP WAF, suit us well when developing and serving our applications.

I am happy with most of the features made available to us through BIG-IP's software and I enjoy using the interfaces (dashboards, etc.). 

There are some aspects of F5 BIG-IP that could be improved, the main one being virtual machine support. We have seen that even with the virtual editions, there are some things that we would like to do that are currently not possible with virtual machines.

We have seen some problems mainly with F5 BIG-IP ASM, and so I think the virtual editions of the ASM could be improved.

Another negative aspect is the cost, as it can be expensive.

I have been using F5 BIG-IP for five years now. 

As far as I can tell, it's a stable and secure solution. 

Although BIG-IP's solutions are scalable for most purposes, it's not always scalable for certain scenarios, in my opinion. From an API perspective, though, it is quite scalable.

We have used F5 BIG-IP's technical support and it is very good. 

The initial setup is very easy. Very, very easy. Especially for the web guys. 

F5 BIG-IP can be expensive, although there are trial versions available which are helpful to find out if the solution is right for your company.

We have been considering using Nginx as an alternative or complementary solution to our application delivery and security needs, but we have not pursued this option further at this point.

For the most part, we are looking for a solution that has better support for virtual machines, and Nginx is one alternative we have looked at because of its good virtual machine support. 

I would rate F5 BIG-IP a five out of ten.

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.

I used LTM to segment traffic between servers, secure them from deficient connections, and protect them from web attacks and malicious behavior.

F5 LTM supports the application delivery in high-demand scenarios.

F5 is very efficient in the services it provides, whether it's LTM or ASM. The policies and machine learning are one of a kind, efficient, and provide minimal disturbance to the servers.

From an ASM perspective, the most valuable feature was the DOS protection, SQL injection protection, bot protection, bot URLs, and many other features.

There were a lot of good features. The most beneficial for maintaining server health included the algorithms for the virtual IP, which segment traffic between servers, authentication profiles, and many other things.

The load-balancing capabilities have increased efficiency because servers can handle connection requests one at a time. There are no dropped connections, and the server health is always under the threshold.

Moreover, AI enhances LTM's performance in network management. It made it much more secure and efficient by understanding normal traffic patterns and learning the behavior of traffic within the environment. Any suspicious traffic is captured and flagged.

In the LTM solution, it would be beneficial to have more algorithms for traffic segmentation or the ability to create user-defined algorithms rather than being restricted to predefined ones.

I have experience with this product. I used it for years. 

I didn't face any issues with stability. 

It is a scalable product. In some environments that I worked on, it ranged from 1000 to 10,000 normal users. It was deployed across multiple locations with multiple deployments.

I managed LTM for scaling network resources during peak times. If I had multiple servers hosting the same servers, I could segment traffic across these servers during peak times. Rather than going to one server, the traffic can go to two or three servers to ensure fast delivery and keep the servers healthy, even during peak times.

I've used Citrix, but I didn't like it.

F5 was easier to manage and had better performance.

The initial setup was straightforward, with no trouble at all.

• Deployment process: The service I worked on followed best practices. It involved the initial configuration, management configuration, onboarding servers, creating authentication profiles, keep-alive connections, integrating with Active Directory, and applying rules.

• Deployment time: For a huge enterprise environment, it might take about a month to fully deploy it. 

Two to three resources can handle it for a large enterprise.

There is maintenance required. With appropriate training, it can be maintained and administered without any issues.

It's worth every penny. The return on investment is amazing.

It's more expensive than other load-balancing vendors.

Overall, I would rate the solution a nine out of ten.