A10 Thunder TPS Reviews

Currently, I have a test setup. A10 Thunder TPS works in a chain with a Check Point firewall and a Juniper MX router. Recently, we had a presentation from a vendor, but we do not have practical experience with Check Point and DDoS protection. We use A10 Networks solutions and sometimes Arbor.

There is an interesting Management Console called A Galaxy. The vendor indicated that Thunder would not be supported, but I was able to add Thunder to the central console management.

I had issues with the user interface because, when putting settings up, the system asked me for strange things like virtual local networks that I didn't create. For example, I set an NTP server, and after some clicks, a message appeared stating 'setup is incorrect'. It asked for a VLAN even though no VLANs were created. We had to find workarounds for issues like A10 blocking necessary traffic, sometimes leading to decreased security, because it was the simplest way to deal with them. This was a real issue. A more flexible policy for demo licenses would also be helpful.

A10 Thunder TPS is scalable, and modern solutions are scalable. However, some vendors may require several steps before dealing with scalability. Without accessible documentation, setting up can be time-consuming.

Previously, I submitted requests to show user interface bugs. The technical support was quick and accepted my requests. They asked me to upgrade the firmware of the hardware, and I received an appropriate fix. I had a rather positive experience with A10 Networks Support Service.

Neutral

I have not seen specific prices, like $10,000 or $20,000. A frustrating aspect is the lack of demo versions. The vendor insists on commercial licenses despite requests for demo licenses. The global price list is not accessible, making it difficult to work.

We use A10 Networks solutions and sometimes Arbor.

There is no personal reason for setting bad marks, so I would rate A10 Thunder TPS a 10 out of 10. I have no specific advice for additional features since anti-DDoS functionality is narrow. If talking about the interface, it is human-friendly, but the integration between vendors could be problematic, especially with false positives.

On-premises

The most valuable feature of the solution is protecting customers and supporting them against attacks in Brazil.

In the tool, we use a lot of its DDoS protection features to protect the resources in a link. It also helps mitigate attacks so that users don't face problems because of it.

One problem for me with A10 Thunder TPS is that the box comes from another country in Brazil. In the tool, there is no one key to block it. For example, in F5 Networks, we have a key. If you try to buy another box from Huawei or from F5 and try to enable them in A10 Thunder TPS, you need a key to do it. The problem here is when you buy another box from A10, they want to put Thunder TPS to run, and it works okay, after which we cannot block it for another solution to be used, which is a problem for me where improvements are needed.

I have been using A10 Thunder TPS for years.

Stability-wise, I rate the solution an eight out of ten.

It is a scalable solution. Scalability-wise, I rate the solution an eight out of ten.

The solution's technical support takes more than a week to reply to a query from our company's end. I rate the technical support a six out of ten.

Neutral

The difference between A10 Thunder TPS and other DDoS solutions is that, with the formerly mentioned product, our customers use the box already there in their environment, allowing me to sell more than just one solution for security. I have used Huawei's DDoS tool. Huawei only runs DDoS services, so there are not many more features available.

The product's initial setup phase is very simple. I rate the product's initial setup phase an eight out of ten. The setup phase is a little bit more complex than A10 Thunder ADC because with A10 Thunder TPS, you have to have to know what you are doing, or else you will end up buying some application with some other features for your customers.

The solution can be deployed with help from the experts associated with the security side since they have skills related to ADC and TPS.

With the tool, I have just one opportunity to try to add one more feature for the customer, so I feel my company does not experience a very good return from the tool.

The tool is expensive. If one is low price and ten is expensive, I rate the tool's price as a ten.

A10 Thunder TPS has very good features for ISPs. For me, right now, the tool is too expensive. I am also an ISP trying to get another solution from another player because A10 Thunder TPS is still very expensive.

I never configured the tool in a way that allows me to use the multi-vector attack protection feature. It also varies depending on the performance of the tool on the customer's end.

I have had no problems with the maintenance of the product because the hardware part is good. Even during the trial, I saw that it was a good tool.

I recommend the tool to others.

In my company, we don't use any AI with the product, but I know that some of our customers use a little bit of AI.

I rate the tool an eight out of ten.

We have our own data center, and we perform load balancing for a lot of internal and external services using A10 Thunder TPS. For some users, we use A10 Thunder TPS for HTTP protocol. We perform load balancing for HTTPS on A10 Thunder TPS and others with too much workload we have to do on the servers. We cannot do the load balancing using HTTPS.

There is a limitation for SSL communication, but we had a problem with our application that started to hang. So, we had to change the SSL certificate to this server.

The most valuable feature of A10 Thunder TPS is load balancing.

The solution is a little expensive.

I have been using A10 Thunder TPS for seven years.

I rate A10 Thunder TPS ten out of ten for stability.

We have 20,000 active connections simultaneously for A10 Thunder TPS.

We contacted the solution's technical support to maintain and exchange the power supply. A few versions ago, we had some CPU and memory problems. We just started the appliance, and it was already on 70% of CPU usage.

We first contacted our reseller in Brazil and then escalated the issue to A10 Thunder TPS support. The reseller in Brazil was a little slow, but the A10 Thunder TPS support was fast.

Positive

We did a price survey, and compared to other solutions, A10 Thunder TPS wasn't cheap.

A10 Thunder TPS is a good product, and I have recommended it to a manager from another company in the past.

Overall, I rate A10 Thunder TPS a nine out of ten.

Thunder TPS protects your network from DDoS attacks. 

Our company experienced some DDoS attacks that temporarily took down parts of the network. The manual process we had in place took some time to execute, and Thunder TPS offered better mitigation methods so we could block malicious IP addresses at the edge of the network.

Thunder TPS has automated mitigation and fully managed support in case the device cannot handle the attack. They have engineers available to respond.

We were in the early stages of using Thunder TPS when I left the company, so I only used it for a few days.

I rate Thunder TPS seven out of 10 for scalability. 

We used A10 support during the deployment. They were helpful.

We had a script built in-house. We decided to replace some of our own programming with a proper appliance.

Setting up Thunder TPS isn't complex, and A10 provided excellent support. My team received pre-provisioned devices and sent them to our offices in Chicago and Toronto. We deployed it with their base configuration and brought the appliances online using their technical support. The whole process took about a month.

Thunder TPS costs about the same as most other DDoS protection, but it isn't a cheap solution. We had a 100-gig production license on each appliance and two devices. You pay annually for a license and support.

I rate A10 Thunder TPS eight out of 10. A10 is well-known in the networking world. The product is good, and it met the company's requirements.

I use the solution to check the tickets and reports of the configuration site.

The solution is easy to use.

The solution’s documentation could be better.

I have been using the solution for one year.

It is a stable solution.

It is a scalable solution. Around 50% of our staff use it.

The solution's initial setup process is straightforward.

I recommend the solution to others and rate it a nine out of ten.

We use it for DDoS mitigation. First of all, we decided that outsourcing it or putting it out into the cloud was just too expensive, so we decided to build our own scrubbing center rather than outsource it to somebody else. We use it to protect against DDoS attacks.

It's on-prem.

Availability is absolutely critical to our business. We get attacked two and three times a day at times. Without it we'd be hamstrung, bandwidth-wise.

Although the attacks happen every day, they're not a big deal anymore because the mitigation takes care of it. But in the past, before we had the solution in place — there are other components to it beyond just the A10; the A10 is just the mitigation piece of our DDoS protection scheme. But before this whole solution was in place, it used to take two or three engineers half an hour to figure out how to mitigate an attack. Now, it's pretty much zero. We get an attack, we get an e-mail saying, "Hey, there's an attack underway." The systems that are in place redirect it to the A10, the A10 scrubs the traffic and it's not such a big deal anymore.

In terms of how much it has increased availability, being that we get attacked two or three times a day, with some of them we probably we wouldn't really know they were happening. But some of them would take us to our knees. We've never really measured it. We're a service provider in the Northeast region, so we've got lots and lots of bandwidth. It has helped a lot, but I couldn't put a number on it because we're always up.

In terms of small attacks we were getting but missing prior to having Thunder TPS, we're over 200 Gig in the backbone now, but we never saw a lot of those little, what I call "squirt-in-the-eye" attacks before. We had a 50-Meg customer out there that was getting DDoS'ed at a 100 Meg. We would've never seen that before. We would have never mitigated it. The customer would have called and said, "Hey, my circuit's down," and we would have looked at it and spent time trying to figure out what's up with the circuit. Then somebody would have looked at their bandwidth charge and said, "Oh, you're maxed," and the customer wouldn't understand why they were maxed. Now, the DDoS solution we put in place sees those small attacks, mitigates them, and the customer never calls.

It has absolutely made a big difference for our customers. DDoSes are happening every moment of the day. We just never know who we're protecting from a given attack or why, but it just happens automatically and we don't really worry that much about it any longer.

All it does is mitigation. It mitigates and scrubs bad traffic. We send the bad traffic to it, it determines the good traffic and allows the good traffic to come through. That's the only feature we use on it, the DDoS mitigation.

Given its 1RU form factor, the performance has been excellent for us so far. What they said was that it is about 38.5 Gig of throughput. We've not really hit that yet, we haven't tested the extremes, but so far it's doing well and we haven't had any performance issues.

The response time to an attack is instant. We've used some outsourced solutions in the past, out in the cloud, that weren't so quick. But it's all within our control now. We control how fast it mitigates.

We've been using it for about a year-and-a-half.

We have 100 percent uptime.

We haven't found that it's helped us to scale defenses because we have pigeonholed it to do one thing and that's DDoS. So it hasn't helped us scale but it's helped us retain customers who otherwise probably would have been angry and left us, thinking it was our fault that they got DDoS'ed. But defense scale-wise, no. Although we're still scaling up like crazy, it's not due to this DDoS product whatsoever.

We haven't experienced any issues with performance. But again, we haven't put that much traffic on it yet. I'm sure it's coming. I'm sure, some day, we'll get a DDoS attack that's more than 40 Gig and then we'll have an answer for how it scales.

Their tech support has been excellent. Every time we've had to call them they have been very responsive and always fixed our problem within minutes. It's been excellent so far. 

I believe the last issue we had to contact them about was just a question of a false-positive. The A10 system wasn't supposed to decide what is a false-positive. So if we send it good traffic, it's supposed to just pass that good traffic through. But we opened this last ticket because the A10 did block some of the good traffic. Their support had to tweak it a little bit, but it wasn't anything that took a long time. It was pretty much just minutes. They understood what the issue was. They tweaked something and fixed it.

What we signed off on when we signed the contract with them was very specifically DDoS mitigation. We went over all the specs of what we intended the system to do. They met all the specs better than the other vendors as far as the throughput, the footprint, and cost went. So we went with them.

The main reason we switched was cost. The cloud solutions were very expensive and, as we sent more traffic, of course, the prices went up. And it was a huge variable. We couldn't budget saying, "We're going to spend X amount of dollars per month on DDoS," because it all depended upon how much traffic we sent to those mitigation servers. If we got attacked one month a couple of hundred times, our expense there could have been tens of thousands of dollars a month. We were not willing to play that game and have that much variability in our expense. By putting this system in, it's our system, so we use it as much as we need to, and we don't pay a monthly expense. We pay A10 for support and that's it.

There was also a difference in response time between A10 and the cloud solutions because now we completely control the solution. Whereas, when we were outsourcing it, we didn't control any of it. So we would send traffic and hope that their mitigation system wasn't overtaxed. Their detection system, sometimes, could also be a little overtaxed and delayed, because there was the internet. We were sending traffic, sending our stats, across the net to their detection system. Their detection system would analyze that traffic, send a response back, and then mitigate if it had to. We had to send that traffic back out onto the public internet. So there was a lot of delay and a lot of variability in the response times. Now it's completely on our network and we control everything about it. So we get much faster response time in mitigation and detection.

The initial setup was very simple. Again, we only use one feature, so the complexities of the setup were pretty much nil. They asked us how much traffic we intend to send to this thing. We spec'ed out the box. They said, "Well, this is the box you want." We did some 15 or 20 minutes configuration of the box and that was it. It was up and live. Everything was done in an afternoon.

A10 did the initial config while it was all at our site. They did it remotely. It went flawlessly. It took about an hour or two hours and it was done. We've not had to change the configuration or anything about the box itself since we installed it.

There were three people involved in the deployment. Two others and me. I didn't do any of the configuration. I was just overseeing the whole project.

ROI is a tough one on this solution because it doesn't make us money, but it potentially saves us from losing some customers. I don't know how many customers would have left us if they got DDoS'ed or if our network didn't perform. So ROI on something that doesn't create revenue is a big, black hole. We don't know what would've been. 

We don't charge for this, so there's no revenue associated with it. I'm sure it's saving us some revenue but, day one, it also saved expense. It actually cost us less to put this box in. For the expense that we were paying out to the cloud providers before, it was probably just a couple of months before it broke even with that expense that disappeared.

It was so variable, based on traffic. Some months we would spend $30,000 with that cloud provider and other months we'd spend $5,000. It was all based on the number of attacks that we would get. If we had a bad month of attacks, or even one bad day where somebody attacked us for 20 or 24 hours straight, we could be looking at spending $30,000 or $40,000 with that cloud provider. Today, it's nothing. There's no expense.

Pricing is very reasonable.

In the past, we've used other cloud-based solutions.

Don't even think twice about doing it. It's a given in this day and age; you just need to do it. You need to have some form of DDoS mitigation in place. And if you don't, God be with you. It's not a matter of if you will be attacked. A lot of ISPs think, "Oh, I'm too small," and even some enterprise customers think that way: "I'm too small. Nobody's going to attack me." These botnets don't care. They don't even know who you are. They just start sweeping IPs and, if they find some vulnerability or somebody decides that they'd like to attack even a customer of ours, it's going to happen. It's happening whether you know it or not, already.

The big thing was to get a lot more visibility into the types of DDoS attacks that we were getting, because now we had full access to the gears. One of the biggest lessons we learned — because we all assumed that non-volumetric attacks were not a problem for the provider — is that they were a problem. We just weren't seeing the problem. Some of our customers may have seen the problem, like a small DDoS attack against their DNS servers. DNS response time might've been delayed by just a fraction of a millisecond per query because of that DDoS attack, but in the grand scheme of things, with thousands of customers hitting that, it ended up being multiple milliseconds. That was something that we learned right off that was a "wow." When we looked at the response times of some of our servers that we never mitigated these attacks on before, it was big, overall.

The only automation features we use are the DDoS. We have other systems in place for the detection piece of it. That's the only feature we use. When it gets traffic, it mitigates it and that's pretty much it. We want to keep it extremely simple.

We haven't thought about where it has room for improvement because it is working so well right now. Again, we only use it for one very specific feature and that's the DDoS mitigation. It's doing what it's supposed to be doing right now. I don't have any enhancements I'd like to see on the product yet because we've not really used it for many of the features it's capable of.

In terms of maintenance, our company has a group that just updates software. That's all they do. They look at different systems in the network, Linux boxes, Windows boxes, appliances like this. They may spend half-an-hour a month if there are any updates to it. All they do is go to the web site and see if there are any updates. If there is an update, they look at what should be applied and they check with the different groups to see if they absolutely should apply it and then they download it.

We don't have plans to use any other features, but we do have plans to implement another system that our customer-support folks are looking at, to be able to do DDoS mitigation per customer. Right now my group, the engineering group, uses this system to protect the network as a whole, but we don't look at specific customers and say, "Well, that customer's getting a very small DDoS attack on their SQL server." We won't mitigate that because it doesn't affect the inner network. We would mitigate something that was a couple of hundred meg that we saw was malicious to the entire network, and that customer might benefit from it. Now, we're looking at selling this to customers. So if a customer calls and says, "Can you mitigate this attack against my SQL server?" the new system would be sensitive enough for even a tiny, little attack. Whereas, the system that we have now wouldn't. We'll probably do that in the next six months.

I'd give A10 a ten out of ten. I have no reason to subtract any points from it at all.

Availability is very critical for us. We use it to mitigate DDoS attacks for rural North Dakota. We really don't use it to identify attacks, we use third-party software, a Kentik solution, to identify anomalies within the IP stack. Then, we turn around and send mitigation profiles to the A10 based on an API call, and the A10 initializes a BGP session to our core routers to offload that traffic and mitigate it.

We provide hosted solutions so our deployment of A10 is private cloud.

Our setup is something of a hybrid solution. We're using the third-party software, the Kentik solution, but we also have some clients that are directly connected to TPS. There is a 30-second delay in time to mitigation for clients that are not direct. By the time that third-party solution identifies something and sends it, via API, to the TPS, there's about a 30-second delay. When we have customers that are directly connected, they have just about instantaneous mitigations with TPS.

We use that inline setup as a premium service. If customers can tolerate a small spike in traffic flow until the mitigation happens then we'll just leave them on the Kentik solution. If they want it instantaneously then we'll put them inline and connect them directly to the TPS for that. Customers who opt for the premium service include financials, utilities - anything which needs that instant mitigation and understands the threat of DDoS. Some entities can tolerate it if they're down for a minute or two minutes and it's not crucial that they pay the extra dollars.

Overall, DDoS attacks affect small-town North Dakota in a fairly large fashion, meaning that they could affect infrastructure from schools to county courthouses to libraries, etc. Those places aren't directly associated with the target of the attack but the appliance itself and the solution in general allow for the protection of those services in those communities. It has been very successful.

The solution has reduced the amount of manual intervention required during an attack. We have the inline solution and when it comes to the customers that we have on it, it has saved us some troubleshooting time. If we can see that there is an active zone, we know that their traffic is being mitigated. If a customer calls and says, "Hey, I have internet problems", one of the first things we check is if there's a DDoS attack happening.

Anytime you filter, you set up thresholds, you can identify your traffic patterns a lot better.
It has helped in that aspect as well. We did miss attacks previously.

We're just using a portion of it, the mitigation aspect.

If there's one aspect of A10 that needs improvement it would be the training. All of their training is done online, at least in what we've been exposed to. I would like to have a classroom environment for training. I would like to say, "Okay, if we have three or four people who need to get trained up, we want to send them to a classroom." That way they're detached from their home office and have the lab facilities. They can have a classroom environment or experience instead of a virtual classroom. It would give them a chance to provision it. There's a better experience in a classroom than in a virtual classroom.

It's not a terrible issue, but the training was the biggest thing that we faced. We're two years into this and we haven't done all the training probably needed to fully support it, because our deployment is very limited. But when we did want to pursue training, I believe that the training was all virtual.

We've been using this solution for about two years.

It's been rock solid. We haven't had any issues with power supplies or software anomalies. It's been a pretty good platform.

For our deployment, we're probably not even using ten percent of its capacity as far as throughput port space. For us, the scalability is very high. For us, it's like investing future-forward.

The usage potential increases daily, exponentially, based on the internet curve. But we're just using a small percentage of the features and a small percentage of its capacity.

We have about 200 customers that have access to the solution with 100,000 users on their side. We carry something like 80 Gig of internet traffic into the state. Because we're using that third-party for the majority, TPS doesn't see all that 80 Gig of traffic. It only sees the traffic that has been identified by the third-party software. The TPS isn't necessarily handling packet, packet, packet, packet; it's handling only packets that are being sent to it by the third-party. In that scope of scalability, it's almost exponential because we're only identifying the traffic flows and patterns that need to be mitigated.

We have opened a few tickets with TAC and they've been good, along with their sales engineering team. We may have a customer that will have an atypical type of deployment. In that case, we'll bring in the sales engineering team or TAC and they'll get us in contact with an expert in that field. Their tech support has been very good.

We did not have a previous solution.

The initial setup was pretty straightforward. You set up your routing tables, your interfaces. There was no magic there.

We have two and we had them both up and running within three or four days, meshed with our network. The process was to get it connected to our core internet routers and have it start talking to a third-party software and, after that, start the mitigation processes.

We mostly did it ourselves. From the A10 side, we had our sales engineer and we had a few calls with their support staff. Based on that, we developed a roadmap and then we self-installed and deployed it.

Our situation is unique because we're owned by the 14 independent broadband providers in North Dakota. So we may not directly see an ROI because the bandwidth of the DDoS traffic basically gets to us. However, we save that extra bandwidth to our owner companies from downstream services. We're saving our members money with the solution.

We did a proof of concept and had a bake-off between Arbor and A10 and Kentik. Because of the reports that we wanted and how we wanted to handle things, the third-party and the A10 solution were technically the best, and scalable.

The flexibility of solutions was important to us. We have the ability to either go inline, to connect directly to the TPS, or to bring it through the third-party. That in itself was a major selling point because we're not stuck with one solution. If we decide that we want to change third-party vendors, we're not married to it. We can shop around and if there's something better that comes out, we can still interface the TPS system with that new software. It meant we weren't just saddled to one vendor for a DDoS solution.

Do your research to understand your solution options. Then, have a PoC bake-off and task the system. Identify ad-hoc anomalies in your test-bed and look at the time to mitigation. Look at different types of situations to see, if an anomaly comes along, how long it would take you to deploy an ad-hoc solution or redirect the traffic. Research and proof of concept is our biggest thing. We never do anything without doing them thoroughly.

The biggest thing I have learned is how many attacks there are and how many different ways the attacks happen, throughout an attack. You can have a DNS attack, you can have an ICMP attack. You can have all these different flavors of attacks. That was probably the biggest eye-opener for me. When you hear the word "DDoS," everything gets put into a container. It's not until you look into the container that you see all the different types of attacks that are summed up by that word.

The solution has been rock solid for us. We haven't had any issues. We've had numerous attacks and it's worked perfectly.

I don't know that it has an increased network availability notably but it has added to it. Instead of having four-nines of availability, we've got five-nines. It's a solution and a package, so it's not our only tool in our toolbox.

We only use the TPS side of it and we're not 100 percent trained up on it, even though we've had two years of deployment on it. We don't know the whole, full-meal deal on what it can do. There's a possibility we'll go to the load balancing and some of those features. Even though we have hosted solutions, we don't have enough because we're a small company. There are other features but we'll explore those as we need.

We have just two people who have access for configuration of the solution and its operations, in our engineering operations.

I would have to rate A10 TPs as a nine out of ten. We've been very happy with the product. Of course, we don't want to give tens because then get people get cocky about it. 

We use it for DDoS mitigation. Availability is extremely critical to our business. We provide online services for two, large video game titles, so there's a requirement to keep our game online and for our players to be able to play the game.

We use it on-prem.

Due to the availability and power of these devices, we've been able to ramp off our upstream cloud-scrubbing provider and handle all attacks on our own. Right now 100 percent of our attacks are handled on-prem with these devices. In 2019 - we're nine months into the year - we've had 1,500-plus attacks and less than five of those attacks have had impact on us.

Our current setup is two 6435 TPS devices at each location. Each of those boxes is rated for 155 Gigs of traffic. We currently are sending 100 Gigs of traffic to each box, that's the bandwidth of the line that we have coming in, and we successfully mitigated a 163-Gig attack. That one was successfully mitigated within the last month by those devices.

In terms of increased availability, I would say it's at about 99.999 percent, overall. We haven't had any major impact, anything more than five minutes, in about two or three years now, due to DDoS.

The automation in TPS makes my team more productive. There is less manual work for my team in dealing with attacks, and with other functions as well, because that automation is built-in: An incident is created, the attack is mitigated, and a report is created. There's really zero touch at this point in time for attacks. It has very much reduced the amount of manual intervention required during an attack.

That is especially true with the newest upgrades that just came out where it does automated pcaps. Everything that we need at this point in time is automated. The device automatically goes into mitigation. It gets the pcaps for us and, a large percentage of the time, it just blocks the traffic that we're looking for. Having those pcaps also helps out because in the future, when we're looking at attacks where we may not have either signature or a proper remediation, we can actually build that in based on the data that we're receiving from those pcaps.

Using TPS we have detected a lot more small attacks and attacks that we had been missing previously, but that's not only because of TPS. We do gather flow information from the TPS devices as well as from our border routers that we recently upgraded. We're using FlowTraq. With that combination, we are seeing a large increase in the number of DDoS attacks that we're detecting compared to what we were using previously, which was a third-party cloud provider. On average, we're detecting anywhere from 25 to 50 more attacks per week than we did previously.

The most valuable feature is the DDoS mitigation availability, the ability to be able to block different types of attacks, and large attacks. That's the main function of the device that we use today. They're able to block attacks that we see against us, to prevent attacks as we see them, to prevent further outage to the environment.

Also, based on previous equipment that we had, it's amazing that this device can do what it can do in a 1U form factor. The devices that we have right now have never gone over capacity and we've actually mitigated some pretty large attacks with these devices.

The solution's response time to an attack is pretty good. Normally, it's a matter of milliseconds and most of the time, within one minute, we have a response and we have mitigation in place. That limits the impact to our environment when we do have an attack.

We use the solution's programmable automated defense using RESTful API quite a lot. We don't use it for configuring the device, but we do use it for things such as grabbing stats and data as well as doing automated blacklisting of IPs and using class lists within devices. It works fairly well. For the most part, we only use the RESTful API for certain tasks. A10's aGalaxy uses API to configure the devices as well and we rely on that for all basic configuration such as IP addresses and port configuration.

We currently do not use the solution's machine-learning-powered Zero-day Automated Protection because of an issue with it. We have a ticket open with the team to try to resolve that problem. That is one of the problems that we have today, something that is not working.

We also use the aGalaxy platform, which is a management platform for the TPS devices. The issue is that some TPS features were added at the TPS level but weren't carried over to aGalaxy, and we manage all of our devices through aGalaxy. So we can't actually use some of the new features that are available on the TPS because that functionality doesn't exist in aGalaxy. That is one of my biggest complaints.

We're somewhat the guinea pig for using both aGalaxy and TPS. There are some features that we would love to use, but unfortunately, because we're on aGalaxy, we don't have the ability to use them due to limitations of the devices. The A10 team just needs to work on making sure they have a release cadence so that the TPS and aGalaxy are in line with each other.

A lot of the issues that we had previously with the devices were because a given functionality didn't exist and it took a while for the team to actually create that for us. But since they were implemented and the kinks were worked out, everything has been working pretty well.

We have been using A10 TPS for about a year-and-a-half.

Overall, today, the stability is great. We have very few issues with the devices in terms of their performance or their availability. 

We did have some issues previously which were resolved. We had some crashing issues on the devices but, with the last upgrade that we received about a month or two ago, those issues were resolved. We haven't had any major issues with our devices since we moved to the new code version.

It enables us to scale defenses. We can go up to eight boxes at each location, with the current configuration that we have.

As time goes on, we are looking into possibly going with the newer devices which just came out and which have increased capacity. We're also potentially looking to move out to more pop locations in the future: Having an internet connection and an A10 TPS at a remote location, and then we would back-haul traffic to us. We are looking to potentially expand our footprint in the future.

Overall, scalability is just a limitation of our own network. But having ECMP and BGP available to us, we can scale out as horizontal as we need to, relying on whatever size of pipe we have coming in. It's really our own limitation at this point in time. Each of our data centers do 100-Gig pipes, which the devices have plenty of support for. But if we did need to roll out to either four devices or six devices, we would have the availability to do that.

We used A10's support team, not for the initial setup but when we ran into issues. We would definitely use their support team for bringing issues to their attention and getting information to them saying, "Hey, this is what we're trying to do, this is what we need for the device to do," and they would actually build it out for us. That included their dev team as well. They were very open with their dev team for what we needed.

Overall, they're really great. For the most part, they understand what our needs are and they understand what problems we run into. Their support team is really good when we speak with them, as far as resolving our issues goes. 

It does take some time, at times, to get issues resolved, but that is the nature of having them build out products or fixes for us. They have worked on a number of issues with us where something is not scheduled to be released but they either give us a hot-fix or they fix it in code and give us that version ahead of time, before it's actually released to the public. That is a great asset for us.

We were previously using the Arbor APS platform. Some of the reasons we switched were that the TMS platform we were looking at didn't have the functionality to do ECMP and BGP the way we wanted to be able to do them. The second major factor was pricing. Pricing was much higher with Arbor for the same type of solution.

I'd break the initial setup into two parts. I did not do the network part of the setup, although I know our network team had some issues with the initial setup because of the limitations of the devices at that point in time.

For the network part of the setup, one of the limitations the device used to have, and no longer have, was with BGP. The way we run our environment is that the TPS device is actually a BGP device within our network and it peers with other devices. That's not a common setup that A10 is usually used for. It's normally used in an environment where there are routers to the north and south of the device, so that there's usually another device that you reroute traffic to when there's an attack. But because we wanted to be in an always-on, asymmetric situation, we didn't have that ability. So they had to build it for us.

They also had to build what's called ECMP, which is equal-cost multi-path. It's basically load balancing on the network side. They had to build that in for us as well because that was a requirement for how we were going to build the environment. So there were some growing pains when we first brought it online just to make sure that everything was working. They built it into the product for us and it is now working perfectly fine. It is a standard feature now in the newer versions. They've added the ability to have BGP route-on and route-off as an option. Some teams do use that functionality where they have the two routers and they route on only when there's an attack. In our case, we are always on so we have the ability to turn that functionality off because we don't need it.

From the perspective of defenses through aGalaxy, that's gotten better over time. They've made a lot of enhancements to the product that we've requested to make our lives easier. We are currently running approximately 163 zones in our aGalaxy. Managing that number of zones and IPs can be kind of a daunting task, but they've added a bunch of features in the new versions of aGalaxy to be able to easily do that and onboard new IP addresses in an easier manner.

It took us about six-plus months to deploy. We had our existing solution in place and the new solution was hanging off of that for testing purposes. It was a good six to eight months before we were fully migrated over and we had our devices inline.

Previously we were using a different vendor for our mitigation, which was basically two 10-Gig connections that were shared across a switch stack, with all the devices being inline. That was very susceptible to failure because the traffic was always inline. Part of the new implementation requirements from the network team was that we have the ability to set up BGP, which is how it's set up today. So if for some reason there is an issue with a device, like a TPS, we can always pull the BGP route to that device and route traffic around it. Previously we didn't have that ability, so if there ever was an issue on our hardware stack, it would affect all services.

We have definitely seen return on our investment by going with A10. We have been able to scale back our cloud services due to the deployment of the A10s. Our future goal is to actually discontinue use of cloud services for DDoS mitigation.

We are doing multiyear licensing. We signed up for three years to get a discount. We're doing that for most of our vendors at this point in time.

As far as I'm aware, there aren't any additional costs to the standard licensing fees. For aGalaxy there is a limitation on how many zones and how many devices we can deploy, but that's the only limitation there is. Currently, we're at 500 zones and about 50 devices. Everything else is not on a gigabyte or a license model where you can only have so much traffic through these devices. There are no such limitations. It's a software license for being able to upgrade to newer versions.

We are always looking to do multi-year deals, especially with devices that we plan on keeping. Being able to do multi-year is a pretty standard thing now. It just works for us and it gives us the ability to grow as we need.

We looked at products such as Radware and another product but I don't remember the name of it. Ultimately, based on some information and data from other gaming companies that we spoke with, it was suggested that we look at A10.

It's so long since we actually looked at Radware, but Radware was being used by our cloud provider for their DDoS mitigation. One of the things that we looked at was that their capacity per box was much lower. At the time, those boxes only were able to handle about 10-Gigs of traffic each, which was way below our needs, especially since we were moving to a multi-hundred-Gig solution.

The type of configuration and the type of network you're planning on running really matters. A10 does a good job of letting you know what's available and what works for the company, depending on those needs. For our use, we needed to be full, 100 percent on. Some companies don't require that and they can afford some type of downtime for BGP cut-over and such. My advice would be to really work with the A10 engineering team on what your needs are and what you're looking for in a product, to make sure that is a viable option. We spoke a lot with other gaming companies that were using the solution and asked, "What is your setup? What kind of issues have you had?" We're using it in a different fashion than some of the other gaming companies are using it today, but it works for us and we think it does a great job.

The biggest lesson I have learned from using this solution is that it does take time to implement. There always are going to be some software issues that need to be worked through. Having a more versatile environment and versatile network makes it a lot easier, so that if you do have issues you can certainly work around them. That's especially true in a production environment. We really don't have a test environment that we are able to set up to test these in and this was basically done by hanging off our production environment with minimal downtime.

In our organization, there are two major teams that use the tools. There are three folks on the networking team and they handle all networking aspects, including BGP, routing, and configuration of the device from a networking perspective. And my team is the SOC team. I currently have nine folks. We work about 95 percent off of the aGalaxy system. We're responsible for responding to alerts, responding to attacks, gathering pcap data, gathering data about zone alerts, etc. Those 12 people are the ones responsible for the A10 devices.

That same group of people is responsible for deployment and maintenance of the solution. I'm mainly responsible, on the security side, for any types of updates that get pushed to the devices. That would be any type of software updates or any type of work being done. Whereas on the networking side, it usually just requires one person if we're doing any type of work. It doesn't require the whole team, for the most part. All three people in the network team have knowledge of the system, but it's usually two people required for that work if we do any types of updates.

I would rate it at nine out of ten. It does have its issues that are being worked through, but overall it's great.

We work like an MSSP. We provide massive capacity and other network capacity to customers. We have customers connect anywhere on back burn. It can be in Europe. It can be in the US or in Asia. We plug the attack anywhere on the back burn, trying plug the attack closest to the source of the attack. So, we don't work like all the other guys who do scrubbing centers. We try to build a scrubbing network. That is why we need to buy more TPS in order to be distributive.

When we start to work with the customer, we don't know what they have. The goal for them is to be able to block any type of massive volume metric attack. The reason is why we have about a two terabytes capacity and are building to afford three to four terabytes of capacity. Therefore, anytime the customer needs to block something, we can configure for them any type of custom role.

We are using them for a mitigation offer that we have globally. We have a bunch of A10s and will deploy more in a few weeks.

We use both the hardware and software.

We started with them and built our network based on this solution. We started with them directly from scratch.

The automation makes our team more efficient and productive. We are distributed and don't use the A10 Portal. It's easy for us to deploy. E.g., they have an aGalaxy product. Instead of connecting to all the boxes, so we will have the A10 box. We don't want to send a code to all the A10 boxes. We will just send the information to one box: the A10 aGalaxy. This one box will proxy it and send the information all the other boxes. This is exactly what we are doing today. It has improved the way that we are working.

We use all the features, but our customers have started asking for key features around SIP. We are also using some proxy features.

The solution’s response time to an attack is fast. When it is configured in line, it is automatically done. When we have to stop the attack, it takes 10 to 15 seconds.

We selected the solution because of its programmable automated defense using RESTful API. We didn't want to connect to the box. We wanted to be able to do some automation. We wanted to have our own portal because we wanted to connect our customers to our own UI using the A10 API. It has been good and exactly what we need. 

The TPS has reduced the amount of manual intervention required during an attack. When we have an attack, and we need to block some stuff everywhere, we just click on a button and push the rules. Then, it's deployed in Asia, Europe, and US. We don't have to do anything more. 

The aGalaxy is a control plane for the product. It controls the entire TPS so you don't have to connect to the box. You just have to connect to this control plane.

The solution’s machine-learning-powered Zero-day Automated Protection (ZAP) works for enterprise customers, but for MSSPs, we have too much traffic and analytics. Therefore, it is unusable and A10 is working on a new feature that we requested. It should be ready in two weeks.

We have to be able to do some automatic rules proposals based on what is detected. We use this product internally and this feature hasn't been ready for the last eighteen months. So, this was done on the side. We would prefer them to develop this feature and pay for it rather than having us do it.

We need more 100 gig ports. Right now, there are a lot of 10 gig ports and we don't need them all. We really need are more ports between 10 gig and 100 gig, which isn't possible.

The upgrade process for the boxes is not efficient. We have to go through the A10 aGalaxy where we have issues, like timeouts. They told me it was fixed in the latest version, but I tried to do it on the Portal and it is not working all the time.

A10 needs to be more distributed across all their customers. This would allow them to have the ability to act quickly during an attack across their entire customer base. At the moment, there isn't a way to provide information (anonymously). This is something A10 will hopefully release Q1 next year.

The documentation with the A10 really needs some improvement. They need to work on this, as it's hard to find all the information that you want.

The Customer Portal is sometimes really buggy.

I have been using it for eighteen months.

We don't have issues with the stability. However, we did have an issue when we had the new box. We needed to have some optic support, which was not working. This was fixed in two weeks when they created a specific code for us. Compared to the industry, this is very fast.

The TPS gives us increased availability because we are using it to protect our customers.

It is not complicated to maintain. It takes one person to maintain it.

We have deployed it globally in Europe and the US. We will be deploying in Singapore and Japan in a few weeks. We are increasing our deployment for customers.

Today, we are serving 30 customers.

While we have the biggest unit, we haven't had the chance to use the box's full capacity. As we are distributed, every time we have an attack, we are not able to reach the capacity of the box. One TPS can block 200 gigs, as well 100 and 150 gigs. So, we never been in the position that we are using the full capacity of the box, at least not today. We are not getting enough 100 gig from this box, which we have already spoken to the design team about.

With the smaller boxes, they are okay, but we are not able to evaluate the box's fullest capacity because we bought two of them.

The goal is not to use it at maximum capacity because we want to have good quality for our customers. We want to add more boxes in order to have a lot of distribution for DDoS attacks across all the TPS boxes. Today, we have four boxes in position. We are going to order four more boxes (minimum) in order to distribute the traffic as much as we can. The goal is to be able to not use more than 60 percent capacity of the box.

We are doing stuff today to have the traffic not go through the box every time. It triggers going through the box for IOPS maybe two or three percent of the time.

Tech support is good. We have access directly to engineering where we can speak to someone to debug. All our tickets go to engineering.

We had some internal stuff previously. For solutions that we purchased, this was the first.

We have had the solution since the beginning. We have used it as our own mitigation and detection.

The box was deployed really easily. When we had to do the distributed mitigation, it took some time because we had to work with the aGalaxy and aGalaxy was pretty new for A10. We had to work directly with the engineering. Initial setup was done within a week because it was easy.

If you're just starting to work in a sample environment, what we did the first time, the process can be done really quickly. But, when you want to do something, like engineering or custom configurations, this can take sometimes months.

We did the setup ourselves since we have access to engineering. It only took one person to implement. It was pretty easy.

All the B2B configuration have to be done manually. As a network operator, this is easy for us. However, if you take an enterprise person who needs to do this, they may have some issues. They may spend a lot of time trying to understand how to configure it, as there is a lack of templates available. This is something which needs to be improved for the enterprise market.

We had a customer who was down for six hours and the loss of revenue for him was three times the price he was paying for us per year. The customer just said, "I don't care about paying you because on only one attack I saved money. It's three times better than losing money."

When customers start to get attacked, they need to be protected and we protect them. It's like insurance. When you buy your car, you don't use it. You say, "I pay for nothing." But the day someone crashes your car, and you are paying for insurance, you are happy that you are insured. This solution is exactly the same for customers.

We are waiting for our subscription model on our next four boxes.

We also looked at Radware and Fortinet.

Radware had good reporting. A10 does not have good reporting.

A10 had a good B2B code and the TPS box has good capacity. The key thing for us was the direct access to engineering. However, A10 is more complex then the other solutions. You have to spend time with it to become efficient at using it. You cannot just buy it and get started on it.

We use Juniper a lot. Their support would take months to fix the same issue that A10's engineering tech support team can fix in a couple of weeks.

The solution is not for newbies. You need to know some security stuff. The box is very flexible and capable with a lot of possibilities. 

We are using A10, not just as a mitigation box. We provide the TPS box and all its mitigation backbone to our customer as a tool. At some point, we are obliged to do some training and do some testing in our lab for them.

DDoS attacks are evolving every day. Attackers are getting smarter. You have to continue to learn and experiment.

As a cloud infrastructure and hosting company, we provide public and private cloud services. We use the A10 technology to protect our customers against DDoS attacks against their hosting instances. The latter could be dedicated servers or virtual servers or data storage platforms.

We have technology in place to detect attacks at the border routers of our networks in all 20 data centers worldwide where we operate. If we detect an attack, we reroute the traffic of the IP addresses that are being attacked to the A10 Thunder systems. They drop the malicious attack traffic and they pass through the legitimate traffic to the servers or the virtual servers that our customers use.

We deploy different types, different sizes of equipment. We use these solutions on-premises.

When we started deploying this and we measured the impact on the number of customer complaints, we saw a significant reduction in the overall number of customer tickets. If customers have an issue with one of our servers, they open a ticket; that could be any outage or a DDoS attack. We saw an overall reduction of 11 percent in support tickets.

But we also saw that we were typically able to mitigate over 98 percent of all the attacks that we detect. That has a two-fold benefit. First of all, customers are happier because their service stays alive even in a situation where they are being attacked. And for us, it has a positive impact on our support team because it has 11 percent fewer tickets it needs to handle. That's especially true since "attack tickets" are not nice tickets to have to handle. It also helped us a little bit in the engagement and the motivation of our support team.

A10 has also definitely reduced the amount of manual intervention required during an attack. Before we had these systems in place, if an IP address or server was attacked above a certain level, we would manually no-route or "black-hole" the traffic, and basically remove that IP address from the internet. That was all manual work, while customers were complaining, and their customers were complaining. People were opening tickets. With this solution in place, all that manual work no longer has to happen. After detection of an attack, the scrubbing is initiated automatically. In the case of a huge attack, we will still null-route the traffic which is going to the IP address under attack, but that process is fully automated. So deploying these systems has reduced a lot of the manual work.

Using this solution we have also, to some extent, detected more small attacks, attacks that we had been missing previously. Before we deployed A10, we did not have any technology in place to detect an attack. Only if a customer opened a ticket did we know there was an attack. But when we started deploying the detection technology and the A10 scrubbing technology, we suddenly saw that we actually have a lot of smaller attacks as well, which were invisible to us previously. That means, most likely, that there were a lot of unhappy customers - or unhappy end-users of our customers' systems - that we were never aware of. That was suddenly fixed by deploying these systems. In all of 2018, we identified about 400 attacks each day, anywhere in our 20 data centers around the world. Many of these attacks were invisible to us before 2016 when we did not have this solution in place.

When it comes to the solution's performance given its form factors, for us, any equipment that takes up space and power is using scarce resources in a data center. The fact that these boxes do have a small form-factor, as only 1RU or 2RU devices, and that the power consumption is relatively low, is very beneficial for us.

We don't deliberately use the solution's machine-learning powered Zero-day Automated Protection (ZAP) but the systems require very little effort to keep them alive and manage them. The automation and the updates that A10 built in result in there being very little work for us to do to keep these systems up to date and efficient in the way they scrub attack traffic. So it's not functionality that we deliberately use, but it's a benefit of these systems, which helps us maintain a low cost of operations and an effective system.

The solution's automation also has the effect that the systems are very low-maintenance. That means that we can free up our people to do other work.

The primary benefit that we see from their systems is that their filtering technology has the ability to detect and drop the malicious traffic from the legitimate traffic with a high success rate. That, in combination with the very small effort needed to manage their systems, are the two most important benefits to us. On the one hand, it's the quality of scrubbing, and on the other hand, it's the low total cost of operations for us to keep these systems alive and working efficiently.

The quality of the scrubbing is, of course, what the system is supposed to do. It's the key functionality of the system. That's what we bought the equipment for. And the small effort to manage the systems and keep them alive, of course, immediately translates into a benefit that we have a low cost of managing those systems. That means we can allocate the time of our network engineers to other activities.

If you look at the total response time that we see in our solution, which means the time between the start of an attack and the time that the scrubbing really starts, we typically see two to three minutes. But the majority of that time is actually used by our detection technology, not so much the A10 network scrubbing technology. And then it takes a bit of time to reroute the traffic to the A10 equipment. Once it has been rerouted, the scrubbing starts very fast, so the start of the scrubbing is only a small part of the two to three minutes. In general, we're very happy with the response times and the scrubbing quality of the A10 equipment.

We started deploying A10 TPS at the beginning of 2016.

I've heard no complaints, so my perception is that the systems run very stable.

The solution enables us to scale defenses. We use different types or sizes of equipment. Typically, we start in some smaller locations with the smaller equipment type. When we see that location growing, we typically replace that device with a larger one and we move the smaller device to a new location where it's needed. We move the technology around quite a bit, which is our way of scaling up. The fact that there are different sizes of equipment, all with the same technology and the same processes for managing them, is very helpful for us. If you look at our smallest data center worldwide, it's a location which generates around ten gigabits per second of outbound traffic. That typically means about one or two gigabits of inbound traffic. Our larger data centers generate around 1.7 terabits per second of traffic. That's a lot more. And with one family of products, we can still protect both the smaller data centers as well as our larger locations.

So far, the systems do what we expect them to do and they scale as we expect them to scale.

Overall, our experience with technical support has been positive. We've had very few requirements for technical support. I know there's a 24/7 SOC team available to help us with large incidents or attacks which we can't resolve ourselves. But so far, we've never had a need to use that team. It's easy for us because the A10 team lives just a couple of blocks away from us. That makes it a bit easier to communicate.

The initial setup was pretty straightforward but we also had very good support from the local A10 team here in the Netherlands. Our headquarters are based in Amsterdam. The A10 Dutch office is just a couple of streets away from us, which also made it easier to work on this together. But having said that, the systems themselves are pretty easy to deploy.

Our initial deployment, back in 2016, happened in what were our six main data centers at the time. The easiest one for us was here in Amsterdam because it's almost next door to our office. The deployment itself, the physical installation and activation of the system, is not really the critical activity. Most of our time was spent integrating the systems with our own administration systems, so that we could deploy automatically. And there was the whole setting of profiles for IP addresses to understand how the detection should work and how the scrubbing should work. That was a bit of a software development effort which took about three months in total. But once that was done and we had all the integration tested, the actual deployment was basically determined by delivery time of the boxes, and that is true now for the deployment to new sites. Once a box is delivered, it's typically up and running in a couple of days.

Our implementation strategy was to make the solution part of our standard architecture for all data center networks. As of now, we have deployed the technology in 20 data centers around the world. Whenever we start a new site, we immediately put in this technology as well to make sure that we protect our customers on that site. And we try to automate the installation as much as possible so that deployment can be done remotely, from the configuration perspective. That way we don't need to send specialists onsite to a remote data center to get it up and running.

We did the first installation together with the A10 team here in Amsterdam. But all other installations, we've done ourselves, typically with remote hands that have very little knowledge about the specific systems in the data center itself.

The solution is then managed by our team of specialists in our NOC here in Amsterdam. The team that manages it consists of three network engineers who also do other things, of course. They are a part of our network operations team. These three people have developed into specialists for these systems and are, on the one hand, responsible for maintaining them and managing them. But on the other hand, they sometimes get involved when there are specific, large attacks where manual intervention is required to mitigate the attack.

Our experience with the A10 team was very positive, both during the evaluation of the various vendors back in 2015 - A10 was very supportive - as well as during the initial deployments here in Amsterdam where we worked together. They were knowledgeable, responsive, enthusiastic.

We have definitely seen return on our investment. If you look at some of the things we can measure, like an 11 percent reduction in support tickets, that can easily be turned into cost savings. Other things, like improved customer satisfaction, are a bit harder to monetize. But for us, we were convinced that within a year, we'd definitely earn back the investment, both in the A10 equipment, as well as developing the end-to-end solution, including the integration with our administration systems.

The financials are always a challenge with this type of technology. That's not really a product-functionality thing but it's the area where we were pushing A10 the most. But compared to the alternatives that we evaluated in 2015, the price-performance of the A10 solution was definitely superior to the other solutions which we evaluated at the time.

The way we did the deal was a combination of the equipment, the license, and a five-year support contract, for all sites. At the time it was a pretty good deal. 

We did a lot of analysis in the second half of 2015. We evaluated different technologies and we ended up using A10. We went with it based on the price-performance. We had four systems on the shortlist. We physically tested two of those providers and, at the end of the day, the two came out pretty even from a functionality and performance perspective. But the total cost of ownership of the A10 solution was superior to the other vendor, so we decided to go with A10.

One of the four providers did not want to support a proof of concept test, so we dropped that one right away. We dropped another one after looking at functional specifications which, at the time, were not as good as A10 and the other vendor. We were left with the two that we tested. At the end of the day, the total cost of ownership made the difference.

From our perspective, the technology works well, and it has a low cost to maintain and manage.

One of the biggest lessons for me, in using this solution, was that there are so many smaller attacks going on that we were not aware of and which must have had an impact on the satisfaction of our customers, as well as the satisfaction of their customers. Everybody always talks about the huge attacks, the one- or two-terabit attacks that get into the news. But the fact there is such a huge volume of smaller attacks going, script kiddies, etc., to make other people's lives miserable was, to me, a bit of an eye-opener. That was resolved by deploying the A10 solution.

Availability is very critical to the success of our business. If you look at the customers that we primarily and proactively target, they are customers in the online gaming market, in the advertising-technology/marketing-technology markets, in the Software-as-a-Service and in the managed service providers market. All these companies are borne on the internet and their internet presence is critical to their success, to their existence. So for us, it's of primary importance that we keep their services up and running at all times, even when they are being attacked by cyber-criminals.

As Leaseweb, we have around 18,000 customers using our hosting services. All these customers' services with us are protected by the A10 technology.

In terms of increasing our usage of the solution, whenever we deploy new data center locations, we put A10 in right away. We do have some new locations that will be opening up in the next six months, so we will definitely be using more of these systems and protecting more customers.

I would rate A10 at eight out of ten. What would take it to a ten is the scalability, the ease of scaling up without replacing a box.