A carrier is rarely the intended target of the flood that hurts it most.
The packets are addressed to one customer: a gaming server in a data centre you serve, a small business on a leased line, a subscriber who annoyed someone in a chat. They arrive over transit and peering ports that carry traffic for everyone else as well.
So the question a telecom operator faces is unusual. It is not "do we stay up?" but "when one customer is attacked, how many of the others notice, and who decides which of them loses?"
What DDoS testing means for a telecom operator
DDoS testing for telecom operators and ISPs is an authorised test of how a carrier network behaves when traffic aimed at its customers, or at its own shared services, exceeds what some part of the network can carry. It measures the damage to customers who were not the target, the time to engage each upstream and in-network control, and the services every subscriber depends on: resolvers, carrier-grade NAT and the routing control plane.
If you need the general shape of a test engagement first, start with the complete guide to DDoS testing. This post assumes it and spends its length on the operator's side of the wire.
| Question | Why a carrier is different | What the test should report |
|---|---|---|
| Who is hurt? | the target is one customer, the links are shared | loss and latency for customers who were not attacked |
| Where does it enter? | transit, private peering and IXP ports each have their own headroom | utilisation per ingress port, not an aggregate |
| Will detection fire? | thresholds are keyed per destination; floods can be spread across a prefix | whether a prefix-wide spread is seen at all |
| Who pulls the lever? | you run blackholing and filtering on behalf of customers | signal-to-drop time at every border, and what you refuse |
| What does every subscriber need? | resolvers, CGNAT pools and BGP sessions are shared by everyone | behaviour of each under load, with the customer impact |
| What leaves your network? | your subscribers' devices are also attack sources | spoofed and flooding traffic stopped at your own edge |
One customer is attacked, the rest take the damage
An enterprise sees a flood as traffic against its own addresses. A carrier sees the same flood as load on links it sells to thousands of other people.
The flood rides shared links all the way in
Traffic for a single customer enters through your border routers, crosses your core and lands on an aggregation link or a broadband network gateway before it reaches that customer's port. Every one of those hops is shared.
If the flood is larger than the free capacity on any of them, the drops are not polite. Queues on that link fill, and packets for every customer behind it are discarded in roughly the proportion they occupy the link.
The arithmetic of a shared link
Take an aggregation link of 100 Gbps running at 60 Gbps on a normal evening. A 30 Gbps attack on one customer fits, and the neighbours notice nothing beyond a little more queueing.
A 60 Gbps attack does not fit. 120 Gbps is offered to a 100 Gbps link, so about one packet in six is dropped. That loss lands on the gaming server under attack and on every household and business that shares the link with it.
Real queues do not share loss perfectly evenly, and latency-sensitive traffic suffers first. The point of the model is the shape: below the link's free capacity the attack is one customer's problem, above it it is everyone's.
Every mitigation picks who loses
Blackholing the target's address protects the link and completes the attack against that one customer. Filtering by port or protocol keeps the target reachable for some traffic and costs router resources. Diverting through a scrubbing service keeps the target up and adds a detour for everyone in the diverted prefix.
The on-premise post treats the blackhole from the customer's chair, as a decision about which host to sacrifice. A carrier carries it out, often for a customer who has not yet noticed the attack.
What to test
Measure the people who were not attacked. During a test against a customer address you own (or a test customer set up for the purpose), record packet loss, latency and jitter for monitoring probes on other ports behind the same aggregation link, the same gateway and the same border.
A report that says "the target was protected in four minutes" without saying what the neighbours saw for those four minutes has left out the carrier's half of the result.
Ingress is several doors, each with its own headroom
Aggregate capacity is the number on the sales deck. The number that matters during a flood is the free capacity on whichever port the flood happens to use.
You do not choose where attack traffic enters
Attack traffic follows the internet's routing to your network, not your traffic engineering. A botnet concentrated in one region may arrive almost entirely over one transit provider, or over a single IXP port where a large access network peers with you.
An IXP port is often smaller than a transit port and runs hotter, because peering is cheaper and you fill it. It can be the first thing to saturate even when total ingress capacity looks ample.
Aggregates hide the port that failed
A dashboard that shows 300 Gbps of ingress capacity and 180 Gbps in use looks healthy. If 60 Gbps of attack arrives on a 100 Gbps IXP port already at 70 Gbps, that port is dropping traffic while the total is still well short of 300.
The fix is boring and often missing: per-port alerting on every external interface, with a threshold set on that port's own headroom.
What to test
Coordinate with an upstream or a peer to have test traffic arrive over a specific ingress, one at a time, and confirm that per-port alerting fires on the port in question. Then check what your traffic engineering can do about it in minutes: depreferencing a route to that peer, or moving inbound traffic with AS-path prepending or communities, which takes effect only as fast as other networks converge.
Spread across a prefix, a flood can slip past detection
Most carrier detection compares flow data against thresholds per destination address. That works when one address takes the whole flood. It works badly when the flood is spread thinly.
The carpet-bombing arithmetic
In a carpet-bombing attack the traffic is aimed across a whole range: every address in a /24, or every address in a block of residential subscribers. Each address receives a modest amount.
Take 40 Gbps spread across a /22, which is 1,024 addresses. That is about 39 Mbps per address. If the per-destination threshold is a few hundred megabits, nothing alerts, while the aggregation link carrying that /22 is full.
Why the usual levers fail here
Blackholing one address does nothing, because no address carries the flood. Blackholing the whole /22 takes a thousand customers offline. The useful controls work on what the traffic has in common rather than where it is going: source port for reflection, packet size, protocol, and an aggregate threshold per prefix that diverts the range to scrubbing.
Residential ranges make this worse. Many subscribers' addresses change, so a per-address baseline is noisy, and the prefix total is the only stable number you have.
What to test
Run a spread test across a range of test addresses and confirm three things: that prefix-level detection fires, how long it takes compared with a single-address flood of the same total size, and which mitigation the playbook actually applies to a range.
Customer-signalled blackholing is a service you run for others
Many carriers let customers request a blackhole themselves, by announcing the attacked address over BGP with a community the carrier recognises. It is fast, and it moves a dangerous lever into a customer's hands.
How the signal works
RTBH signalling usually uses the well-known BLACKHOLE community defined in RFC 7999, 65535:666, or a carrier-specific equivalent. The customer announces a /32 (or /128) for the address under attack, and the carrier's edge sets the next hop to a discard route.
Normal inbound prefix filters reject anything longer than a /24 or /48, so accepting these needs a separate policy. That policy is where the risk lives.
Accept it only for space the customer holds
The edge must check that the announced /32 sits inside address space the customer is authorised for, using the same prefix lists, IRR objects or RPKI data that govern their normal routes. Without that check, one customer can blackhole another, or a mistyped address can take down a third party.
Operators commonly attach NO_EXPORT or an equivalent, so the blackhole stays inside their own network unless it is deliberately passed upstream.
Upstream and IXP blackholing
A blackhole at your border protects your core but not the transit or IXP port the flood arrives on. To protect the port, the drop has to happen in the upstream network, which means passing the signal on to transit providers that accept it, and to IXP route servers where the exchange offers blackholing.
Each of those has its own acceptance rules and its own delay. Find out what they are before an incident, not during one.
Flowspec from the operator's side
BGP Flowspec gives a finer tool: drop or rate-limit by port, protocol or packet length rather than discarding everything. The standard's validation rule (RFC 8955) ties a filter to the network that originates the best unicast route for its destination, which is one reason few carriers accept Flowspec directly from customers.
There is also a hardware limit. Flowspec rules become entries in router filter hardware, which holds a finite number of them, and a large set of rules pushed in an emergency can exceed it. Know the number for each router model in your border, and test what happens when it is reached.
What to test
Time the full path with a test customer: announcement to discard at each border router, at each upstream that accepts the signal and at each IXP. Then try to blackhole an address outside the test customer's space and confirm it is rejected and logged. Withdraw the route and time the restore, since a blackhole that outlives the attack is an outage of its own.
The services every subscriber depends on
Some of a carrier's own infrastructure is shared by the whole customer base. When it fails, the helpdesk hears "the internet is down" from people who were never near the attack.
Recursive resolvers
Subscribers reach almost everything by name, through your resolvers. A flood that saturates them, or a burst of random-subdomain queries that ties them up waiting on slow authoritative servers, takes out browsing for everyone while the links themselves are idle.
Resolvers should answer only your own subscriber ranges, so they cannot be used as an open resolver for reflection. The authoritative side, where you host zones for customers, is covered in the DNS DDoS testing post.
Carrier-grade NAT pools
Behind CGNAT, many subscribers share each public address, and each gets a block of ports and a share of the translation table. RFC 6888 requires a CGN to be able to limit the external ports per subscriber, precisely so that one subscriber cannot consume the pool.
Two failure modes are worth testing. An infected subscriber opening sessions at a high rate should hit their own limit and nobody else's. A flood aimed at one public pool address hurts every subscriber mapped to it, and blackholing that address cuts off all of them. Why per-IP limits misfire on the far side of CGNAT is covered in the mobile backend post.
The routing control plane
Your border routers forward floods in hardware, but their BGP sessions, management and routing protocols run on a route processor that can be overwhelmed. Control-plane policing, infrastructure ACLs that keep external traffic off router addresses, and the TTL security check of RFC 5082 (GTSM) on external BGP sessions are the usual protections.
If they fail, BGP sessions drop when hold timers expire, commonly after 90 or 180 seconds, and reconvergence follows. The routing outage can outlast the flood that caused it.
Customer equipment and its management
In November 2016, a Mirai variant scanning for a management interface on port 7547 caused around 900,000 Deutsche Telekom customer routers to fail and drop offline. It was not a flood against the network, but it shows how the carrier's own customer equipment, managed at scale, can become the outage. Management servers and the protocols that reach customer routers belong in the inventory of shared things to test.
What to test
Load each shared service in a test environment or a controlled slice of production: resolvers with random-subdomain query patterns, a CGNAT pool with one high-rate subscriber and with a flood on one pool address, and a lab router of the border model with traffic aimed at its own addresses. Record what a subscriber would have experienced, not only whether the service stayed up.
Your subscribers are also the sources
A carrier's access network is full of devices that can be recruited into botnets: home routers, cameras, set-top boxes. The traffic they send is your outbound load, and your upstreams and peers see it as coming from you.
Outbound floods fill your own links
A large share of your subscribers' upstream capacity, recruited at once, is an outbound flood across your transit and peering ports. It competes with legitimate traffic on the same ports, and if it is reflection traffic with spoofed sources, it is aimed at someone else using your network.
Source address validation at the subscriber edge, as described in BCP 38 and enforced with uRPF or equivalent, stops the spoofed part. It does nothing about a compromised device flooding from its real address, which needs outbound detection and a process for contacting or isolating the subscriber.
Documented attacks that used subscriber devices
In 2016 a Mirai-based botnet was used for repeated attacks on the Liberian mobile operator Lonestar Cell MTC, and the attacks were reported to have degraded wider internet access in the country. A British man was sentenced in the UK in 2019 for carrying them out. The tools that took down an operator were built from other networks' subscriber devices.
What to test
From a test subscriber line, send traffic with spoofed source addresses and confirm your edge drops it. Then run a high-rate outbound burst from a test line and check whether outbound detection alerts, who receives the alert and what they do with it.
Telecom regulators treat availability as a security duty
In the UK, the Telecommunications (Security) Act 2021 added security duties for public network and service providers to the Communications Act 2003. The Electronic Communications (Security Measures) Regulations 2022 and the Telecommunications Security Code of Practice set out what that means in practice, with Ofcom monitoring compliance.
In the EU, NIS2 lists providers of public electronic communications networks and services among its digital infrastructure entities. In the US, the FCC's network outage reporting rules (47 CFR Part 4) require reporting of outages above set thresholds, whatever the cause.
None of these is a DDoS testing mandate in so many words. Test results that show bystander impact, signal-to-drop times and what failed first are useful evidence for all of them; the UK DDoS testing post covers the wider UK landscape. Treat this section as orientation and confirm your obligations with your own regulatory and legal teams.
Coordinating a test across other people's networks
Testing a carrier means sending traffic that crosses networks you do not own. Every one of them needs to know.
| Party | Why they need to know |
|---|---|
| Transit providers | their own detection may blackhole your prefix mid-test |
| Peers and IXPs | test traffic over a peering port is load on their side too |
| Scrubbing provider | a diversion during a test should be deliberate and logged |
| Your NOC and customer support | test-driven alerts and tickets must not trigger real escalations |
| Test customers | lines and addresses used as targets must be yours or agreed in writing |
Some systems stay out of scope entirely: emergency call routing, lawful intercept, signalling interconnects with other operators, other operators' networks and live subscriber lines. Ceilings, abort criteria and live monitoring follow the post on testing without disrupting production.
A telecom test plan in one table
| Area | Test | Pass looks like |
|---|---|---|
| Bystanders | flood a test customer, probe neighbours on the same link and gateway | neighbours' loss and latency reported for the whole attack window |
| Ingress | test traffic over each transit and IXP port in turn | per-port alerting fires on the port's own headroom |
| Carpet bombing | the same total spread across a range | prefix-level detection fires, and the range playbook is known |
| Blackhole signal | /32 with the community from a test customer | discard at every border, upstream and IXP, each timed |
| Blackhole abuse | /32 outside the test customer's space | rejected and logged |
| Flowspec | push a large rule set to a lab border router | behaviour at the hardware rule limit is known |
| Resolvers | random-subdomain query load | subscriber lookups keep answering |
| CGNAT | one high-rate subscriber; flood on one pool address | the subscriber hits their own limit; the shared-address impact is counted |
| Control plane | traffic at a lab router's own addresses | BGP sessions stay up |
| Outbound | spoofed and high-rate traffic from a test line | spoofed packets dropped; the burst raises an alert someone acts on |
FAQ
Will a transit provider blackhole us during a test?
It can. Many transit providers run their own detection and may null-route a destination receiving unusual volume, which turns a test into a real outage for that address. Tell each upstream in advance, agree the test window and addresses, and ask what their automatic thresholds are.
Is carpet bombing a new attack?
No, but it has become a common way to get under per-destination thresholds. Spreading a flood across a whole prefix keeps each address below its alert level while filling the link that serves the range. Detection keyed on prefix totals, not only on single addresses, is what catches it.
Should a carrier accept Flowspec announcements from customers?
Many do not, or only through a managed portal that validates every rule before it reaches a router. A Flowspec rule acts on traffic in your network, and router filter hardware is finite. Customer-signalled blackholing, checked against the customer's own address space, is the more common self-service lever.
Who is harmed when an ISP null-routes a customer address?
The customer whose address is nulled loses all traffic to it, which completes the attack against them. Everyone else on the shared links gets their capacity back. If the nulled address is a CGNAT pool address or a shared server, many people lose access at once.
Does the Telecommunications (Security) Act require DDoS testing?
Not in those words. The Act and the regulations and code of practice under it set security duties for UK public network and service providers, and evidence of how the network behaves under attack supports them. Ask your regulatory team how test results fit your own compliance work.
A carrier's DDoS posture is a policy for sharing loss
Most organisations test whether they can survive an attack. A carrier is testing something closer to a rule of allocation: when there is not enough capacity for everyone, whose traffic is dropped first, and who chose.
Every mitigation in the network embodies an answer. A blackhole gives the target's share to the neighbours. An unfiltered flood gives the neighbours' share to the attacker. A scrubbing diversion spreads the cost across a prefix as added latency.
A test that measures only the target never sees those choices. The customers who were not attacked are where a carrier's result is found, and they are usually the ones nobody put a probe on.