A Gaming Company Nearly Fired Its Carrier. The DDoS Box Wasn't Enough.

A real incident about the difference between owning a mitigation appliance and operating a DDoS service.

‍

‍

A mobile-gaming company bought DDoS-protected IP Transit from a major incumbent carrier in Asia. The carrier had deployed a market-leading Traffic Mitigation System. The service was sold as protected, the mitigation equipment was in place, and everyone had reason to believe the risk was covered.

‍

Then more than 10 Gbps of attack traffic leaked through, saturated the gaming company's link, and interrupted its service. The customer threatened to terminate the carrier's protected-transit service.

‍

‍The carrier had DDoS protection. What it did not have, at the moment that mattered, was protection that worked.

‍

We sell DDoS protection, so read the rest with the appropriate suspicion. This is not a story about one vendor being incapable of mitigation and another being infallible. It is a story about a mistake our industry keeps making: treating a DDoS appliance as if it were a complete DDoS service.

‍

No serious engineer promises that nothing will ever go wrong

“100% uptime” looks good on a slide. Engineers who operate real networks know how fragile that promise becomes once it meets routing changes, software defects, configuration errors, previously unseen attack patterns, and ordinary human decisions made under pressure.

‍

DDoS protection has the same problem. It cannot honestly mean that every attack will always be blocked perfectly, that legitimate traffic will never be affected, or that the first mitigation policy will be right forever. Attacks change. Customer traffic changes. Sometimes the mitigation itself creates a problem.

‍

A more honest standard
Are you prepared to detect the attack, manage it, recover when something goes wrong, adapt the controls, and mitigate the next event more effectively?

‍

That is less comforting than a 100% promise. It is also closer to how reliable systems are actually built. This incident is a good example because neither side comes out looking magical.

‍

The customer bought an outcome, not a mitigation appliance

The carrier was one of a country's three incumbent telecom operators. Its downstream customer ran mobile-gaming services, where interruption is not an abstract SLA event. Players notice latency and disconnections immediately, and they do not care which vendor logo appears in the carrier's network diagram.

‍

The existing protected-transit service relied on a well-known, market-leading DDoS platform. According to the Nexusguard Pre-Sales engineer involved in the account, the deployment encountered three practical limits.

‍

‍

These were limitations encountered in this deployment, not a claim that every installation of the unnamed incumbent behaves identically. Blackholing can protect the rest of a network, but it “protects” the target by making it unreachable. That can be a valid emergency control. It is not the outcome a gaming company believes it purchased when it pays for protected transit.

‍

A strong product can still become a weak service when nobody owns the outcome.

‍

We did not get everything right on the first attempt either

Nexusguard proposed a two-week live production proof of concept. This was not a laboratory demonstration with generated traffic and a carefully staged success condition. Production traffic across five prefixes was swung to our Clean Pipe service with mitigation on.

‍

During an early mitigation test, a routing loop made one host unreachable. In a later 15 Gbps event, traffic policing produced an unacceptable result and required further tuning. These incidents occurred before the POC was handed to the SOC for full operational management.

‍

Why include our own difficulty?
Because the defensible claim is not that our first policy can never be wrong. It is that the service included people responsible for recognizing a bad outcome, correcting it, and watching what happened next.

‍

After the SOC handover, the team kept the initial baseline and preset configuration under review. It adjusted anti-spoofing, retransmission, protocol, and access-control measures against the attack traffic it was observing. Where policies risked dropping legitimate traffic, the team fine-tuned them. Where attack patterns passed through, it adapted the filtering. Rate limits remained a last resort rather than the entire strategy.

‍

‍

This is what production mitigation looks like. If a vendor's story leaves no room for that loop, it is probably describing a demo rather than an operating service.

‍

What changed after production traffic moved

The carrier moved five live production prefixes to Nexusguard. The Clean Pipe mitigation path remained on, so traffic was already passing through mitigation rather than waiting for an attack-time diversion. The SOC monitored events, tuned the profiles, and communicated with the carrier as attacks developed.

‍

Within one week, one particularly active prefix was hit by attacks of 60 Gbps and 80 Gbps. The gaming company's service was not affected. In some events, the platform detected and mitigated the attack before the customer realized one was underway.

‍

The customer did not terminate the carrier's DDoS-protected IP Transit service. Both the carrier and its gaming customer were pleased with the result, although there is no approved customer quotation - and I will not invent one for a cleaner ending.

‍

What turned a box into a service

‍

Visibility is not mitigation, and I am not claiming the gaming company used every portal screen. But once mitigation works, visibility is how a service provider proves its value and rebuilds trust.

‍

The 80 Gbps attack was not the real lesson

Eighty gigabits per second makes a good headline. It demonstrates that the production service handled a serious attack, but capacity alone was never the central problem.

‍

The earlier service failed when more than 10 Gbps reached and saturated the customer's link. A smaller attack that gets through can do more damage than a larger attack that is removed cleanly. Buyers who compare only advertised scrubbing capacity are measuring the size of the fire station, not whether water reaches their building.

‍

A DDoS box is an asset.
DDoS protection is an operating capability.

‍

A complete service needs four things working together: a mitigation path that stops malicious traffic before the protected link, policies fitted to real customer behavior, operators who monitor and retune, and evidence that explains the outcome.

‍

What to ask your carrier or DDoS provider

Do not ask only which vendor they use or how many terabits their platform can absorb. Ask questions that expose how the service behaves on your worst day.

‍

‍

If the answers are vague, the word “protected” in your transit contract may be doing more work than the protection itself.

‍

Protection is how you respond when protection is imperfect

The gaming company in this incident did not care whether the carrier owned a famous mitigation appliance. It cared that a service sold as protected still allowed attack traffic to saturate its link.

‍

Nexusguard did not restore confidence by promising that nothing would ever go wrong. We had our own early POC difficulty. Confidence returned because the production service was watched, corrected, tuned, and then tested again by real attacks peaking at 80 Gbps.

‍

That is the standard buyers should demand. Not protection against 100% of attacks. Not a fictional promise of permanent perfection. Readiness to manage, recover, adapt, and mitigate effectively when the attack - or the first response to it - does something you did not expect.

‍

For what it is worth, that is the standard you should apply to Nexusguard too. Ask us the same questions. Make us explain what our protection does, what it does not do, who operates it, and how we respond when the first answer is not good enough.

‍

The vendor worth trusting is not the one that promises nothing will go wrong. It is the one prepared to show you what happens when something does.

‍

FAQ

What is DDoS-protected IP Transit?

DDoS-protected IP Transit combines internet connectivity with detection and mitigation intended to stop malicious traffic before it overwhelms the customer's connection. The important questions are where filtering occurs, how traffic is diverted or kept in path, and what traffic can still reach the downstream link.

‍

Why can a DDoS-protected link still be saturated?

Enough malicious traffic may still reach the bottleneck because of detection thresholds, incomplete policy coverage, diversion behavior, rate limits, blackholing decisions, or attack leakage. The cause depends on the design and incident; the presence of a mitigation appliance alone does not prove that the protected link will remain usable.

‍

Is always-on mitigation better than on-demand mitigation?

Always-on mitigation removes the delay involved in diverting traffic after detection, but it introduces its own routing, latency, tuning, and cost considerations. On-demand designs can reduce the normal traffic-path impact but depend on timely detection and diversion. The right choice depends on the customer's network, risk, and operating model.

‍

What should a carrier provide beyond a DDoS appliance?

A complete service should include traffic baselining, continuous monitoring, live mitigation ownership, policy optimization, incident communication, post-event evidence, and people accountable for the outcome. The appliance is important, but it cannot perform the organizational work around it.