Null routing explained: null route, RTBH and the difference from filtering

A null route is a route that discards packets instead of forwarding them. When the IP address of a server is null routed, that server disappears from the internet: the attack traffic no longer arrives, and neither does the traffic of your users. The server itself keeps running, the services keep listening, the database answers, the cron job starts on time. It is just that nobody reaches any of it any more. The common terms for the same procedure are null route, null routing and blackhole, and in operator slang it becomes "the address got blackholed".

This article explains the procedure in full: what a null route is on a Linux system and what the same route means on the router of a network operator, how Remotely Triggered Black Hole Filtering pushes such a route across entire networks through BGP within seconds, why network operators do it, what it means for the customer on the receiving end and how you can tell whether your own provider works this way. The most important section is the distinction from filtering, because that is where the difference that decides your availability actually sits.

Up front, the assessment that carries the whole text, in two sentences that are both true. Null routing is not a defense, it is a controlled surrender: the attack has reached its goal, the service is gone, just in an orderly way and without damage to the neighbors. And still, from the point of view of a network operator the decision is rational, and in certain situations the only responsible one. Anyone who knows only one of the two halves makes bad decisions: either they resent a measure that saved them, or they buy a "DDoS protection" that is in truth a shutdown mechanism.

What null routing is in technical terms

A null route is an entry in the routing table whose next hop is not an exit but nothing at all. Every other route answers the question "through which interface and to which next node does this packet go". A null route answers it with "it does not". The packet is discarded, the operation is complete, and no further work is created.

That is precisely where its appeal for the network operator lies. A firewall rule has to read a packet, compare it against a list and evaluate it. A routing entry is looked up for every packet anyway, that is the normal forwarding operation, and it runs in specialized hardware. Discarding by route therefore costs practically nothing and scales to full line rate, whereas every rule that evaluates packet content costs processing time multiplied by the packet rate.

Null route, blackhole and discard are the same thing

Three words, one procedure, different origins. Null route comes from the virtual interface Null0, which exists on the routers of one widespread vendor and swallows everything you hand to it. Blackhole is the term from the operator world and the one used in the relevant standards. Discard is the word another large router operating system uses in its configuration. Anyone talking to the support desk of their provider should know all three, because which one shows up in the ticket depends purely on which technology the person answering grew up with.

The null route on a Linux system

Linux has supported the procedure for a long time and distinguishes four behaviors. The difference is not whether the packet is discarded, but whether the sender is told about it:

The silent variant is the one this article is about. It is created, inspected and removed like this:

ip route add blackhole 203.0.113.42
ip route add blackhole 198.51.100.0/24
ip route show | grep blackhole
ip route del blackhole 203.0.113.42

Two things about this are important and are regularly misunderstood. First, such a route applies to the destination of a packet, not to its sender. On your own server it therefore works against the return path: the server still accepts the incoming packet but can no longer send anything back, the handshake never completes and the remote side runs into a timeout. That makes it a usable and very cheap block against a single known source. Second, a null route on your server does nothing about the fact that the packets have already occupied your uplink. Against a volumetric attack it helps just as little as any other setting on the server, and the reason is explained in detail in What is a DDoS attack.

The same route on the router of the provider

On the operator side the same entry only looks different in writing. On one widespread router operating system it reads:

ip route 203.0.113.42 255.255.255.255 Null0

On another large router operating system the action is called discard:

set routing-options static route 203.0.113.42/32 discard

The difference from the route on your server is not technical but spatial, and that difference is the entire point. The entry does not sit at the end of the uplink but at its beginning. Packets to your address are discarded before they occupy the line toward your server. The measure therefore works against any attack size, because it moves the point of discard to where more capacity is available. The price is that at that point nobody distinguishes any more who is actually arriving.

Remotely Triggered Black Hole Filtering: how a null route travels through an entire network

A single router is of little use when the attack traffic enters through twenty border routers at once. Remotely Triggered Black Hole Filtering, RTBH for short, solves exactly that: it is a procedure in which a single BGP announcement creates the same null route on every router of a network simultaneously. It is described in RFC 5635, "Remote Triggered Black Hole Filtering with Unicast Reverse Path Forwarding (uRPF)", an informational IETF document from August 2009 that builds on the older RFC 3882.

The procedure in four steps

The mechanism is less complicated than its name suggests and consists of a preparation and a trigger.

1. Preparation, done once: on every border router of the network, a static route for a discard address is configured that points into nothing. RFC 5635 recommends an address from the documentation range for this, typically 192.0.2.1, because that address never carries real traffic. Every router therefore holds ip route 192.0.2.1 255.255.255.255 Null0.
2. Trigger: a single router announces the attacked address inside internal BGP as a separate route, usually as a /32, and sets the discard address 192.0.2.1 as the next hop. The announcement carries an agreed community plus NO_EXPORT so that it does not leave the network.
3. Effect: every border router resolves the next hop, lands on its own static route into nothing and installs a forwarding entry that discards packets to that address. No configuration change is required, no process restart, no access list to compile.
4. Handing it upstream: if the traffic is not supposed to enter the operator network at all, the same route is passed on to the transit providers, tagged with the blackhole community. The transit provider then discards it at its own network edge.

In the history section of the procedure, RFC 5635 names the original requirement, and it describes the appeal better than any explanation: operators wanted to be able to push discard rules "out to over 60 routers within 60 seconds". That is exactly what a BGP announcement delivers, and it does so regardless of the size of the network.

The blackhole community 65535:666

So that a customer can trigger the null route at their transit provider without a separate agreement for every customer and provider pair, a uniform value has existed since October 2016. RFC 7999, "BLACKHOLE Community", defines the well-known BGP community 0xFFFF029A, in the usual notation 65535:666. The number 666 is no accident: the standard explicitly records that this value has long been associated with BGP blackholing among network operators.

Three provisions of that standard explain the behavior you observe as a customer. First, the announcement is as specific as possible: RFC 7999 states that the blackhole prefix length is typically /32 for IPv4 and /128 for IPv6, meaning exactly one address. Second, a router that accepts such a tagged announcement should add NO_ADVERTISE or NO_EXPORT to it so that it does not spread further across the internet. Third, that is why blackhole sessions must be tightly secured: a /32 announcement that escapes by mistake is the most specific route there is, therefore attracts the traffic for that address and destroys it.

In practice this means that many network operators actively offer this community to their customers. Whoever sets it on a BGP session takes their own address offline within seconds, with no ticket and no confirmation. It is the fastest self service that abuse handling has to offer, and at the same time the most final.

Destination based and source based

The case described above is the destination based variant: everything that wants to reach a particular address is discarded. RFC 5635 adds the source based variant on top of unicast reverse path forwarding. There, the address announced is not that of the victim but that of the attacker. The reverse path check finds the discard route for every incoming packet and throws it away, while the victim stays reachable for everybody else.

That sounds like the better solution and is still rare in practice. It requires the reverse path check to be active on all border routers, it does not work against spoofed source addresses, and in a distributed attack with tens of thousands of sources the list is simply too long. So the destination based variant remains the norm, and RFC 5635 describes its effect with remarkable candor: the impact of the attack on the target is "complete", because all packets toward that destination are dropped, attack traffic and legitimate traffic. The very standard that describes the procedure therefore states that it does not prevent the outage but produces it.

Why network operators null route, and why that is reasonable

This is where a change of perspective pays off, because from the outside the decision looks like indifference and from the inside it looks like arithmetic. A data center network does not consist of one uplink per customer but of a few large ones that many customers share. Everything else follows from that.

The arithmetic that leads to the decision

Take an uplink of 100 Gbps carrying a few hundred servers. An attack of 200 Gbps runs against a single address behind it. The uplink cannot carry 200 Gbps, so the queue in front of it fills up and overflows. An overflowing queue does not select, it discards whatever arrives. As a result every server behind that uplink loses packets, not only the one under attack. An attack against one customer thus becomes an outage for hundreds.

If the attacked address is null routed, and specifically upstream at the transit providers, the attack traffic ends where it enters. The 100 Gbps uplink is free again, all other services keep running, one customer is offline. The decision is therefore not "filter or null route" but, in that moment, "one outage or hundreds". Put that way the question answers itself, and anyone who has ever sat on the other side of such an incident would have decided the same.

The second calculation: capacity costs money, a route costs nothing

The second reason is economic and is rarely stated openly. Filtering requires holding more capacity than the attack brings along. That capacity consists of uplinks, of devices that evaluate packets at line rate, and of people who operate them. It is paid for permanently and sits unused most of the time, because attacks are rare and short.

A null route, by contrast, costs one line of configuration and no hardware. It also avoids costs that would otherwise arise: transit is usually billed on the 95th percentile, and attack traffic that is allowed into the network is billable traffic. Anyone implementing DDoS protection purely through null routing therefore has no capacity cost, no hardware cost and no traffic cost. That is why very cheap offerings are very often built exactly that way, and that is not an accusation but a consequence of pricing.

Let us record it without condemning anyone: null routing is a good measure for the network operator, because it protects the network, takes effect immediately, scales without limit and costs nothing. For the affected customer it is still not protection, because it does not achieve what they expect protection to achieve. The two sentences do not contradict each other, they simply describe different interests.

What null routing means for the customer on the receiving end

The server is running, only nobody reaches it

The confusing part of a null route is that everything looks fine on the server itself. There is no crash, no error message, no unusual load. Through the console in the customer panel you see a perfectly healthy server: the services are listening, systemctl reports everything as active, a request through 127.0.0.1 answers in milliseconds. From the outside the same server is dead.

To put it more plainly: an attack that reaches the server shows up as rising packet counters. With a null route those counters stand still. The network interface is unusually quiet, quieter than in normal operation. That silence is the actual identifying feature, and it is the most reliable single indication you can get.

The outbound direction is affected as well, with one qualification. If the null route exists only inside the provider network, your server may still be able to reach destinations outside it. If it has been announced upstream to the transit providers, every outbound connection fails too, because the response goes to your address and is discarded along the way. Package updates then run into timeouts, external interfaces stay silent, backups to a remote target break off. The server is therefore not only unreachable but frequently unable to act.

Typical duration and automatic withdrawal

A null route is almost never withdrawn by hand; it expires automatically after a fixed time window. In practice that window ranges from a few minutes up to 24 hours, often with the rule that a renewed attack restarts it. Some networks extend it automatically for as long as they keep seeing attack traffic toward the address.

From this follows the most unpleasant property of the procedure, and it is the core of the problem: the duration of the outage no longer has anything to do with the duration of the attack. An attack typically lasts seconds to a few minutes, and in the measurements of large operators very short attacks are the rule. A null route of two hours turns an attack of 40 seconds into an outage of two hours. The attacker has then not only won, they have leveraged the win by a factor of 180, and they did it with the help of the defense mechanism.

Why the attacker wanted exactly this

An attacker measures the result. They connect to your service, they see your entry in the server list, they read your status page. When your address is null routed, they see precisely what they paid for, and they see it with less effort than expected, because they did not even have to sustain the attack. The result is an invitation to repeat, and the invitation is accepted: recurring attacks every evening at the same time are the most common pattern among projects that were once taken offline this way.

The definition that follows is unromantic but sound. Denial of service is defined by its effect, not by its cause. A service that is unreachable for users has been denied, regardless of whether the packet was stopped by the attacker or by the border router of your own provider. Null routing produces the effect of a successful attack. It does so in a controlled way and for good reasons, but it does so.

Null routing and filtering: the difference that matters

This is the heart of the matter, and the difference fits into one sentence: filtering distinguishes between attack traffic and real users and lets the latter through, null routing does not distinguish at all. Everything else follows from that.

The following table measures both procedures against the same criteria. It is deliberately not one sided, because null routing wins several rows, and it wins them fairly:

A route knows one criterion, a filter knows twelve

The reason for the granularity row is not a matter of will but a property of the tool. A route makes its decision solely on the destination address, it knows no other attribute. It cannot know whether the packet wants the game port or the query port, whether it is 64 or 1,400 bytes long, and whether the same source is sending its tenth or its ten thousandth packet.

How much more a filter rule can do is written down in RFC 8955, "Dissemination of Flow Specification Rules" from December 2020, the standard that distributes filter rules through BGP. It defines twelve attributes by which a packet may be classified: destination prefix, source prefix, IP protocol, port, destination port, source port, ICMP type, ICMP code, TCP flags, packet length, DSCP field and fragment. On top of that comes an action that can do more than discard: a traffic rate of 0 means discard, any other value means pass up to that limit.

That makes the difference tangible. Against a query flood on port 27015 the filtering answer reads "at most ten queries per second per source address, the rest is discarded, the game port stays untouched". The null routing answer to the same question reads "this address no longer exists". Both answers end the attack. Only one of them ends it without taking the service along.

And even as an emergency measure, null routing works less well than assumed

There is one study that measured the procedure not in theory but against real events: "Down the Black Hole: Dismantling Operational Practices of BGP Blackholing at IXPs", published at the ACM Internet Measurement Conference 2019, pages 435 to 448. The authors correlated every RTBH event at one of the largest European internet exchange points with the traffic actually measured, over more than three months. Three results matter for anyone on the receiving end.

• Only 27 percent of all RTBH events showed any traffic in the preceding 72 hours together with a traffic anomaly in the last ten minutes before the event. For the majority, neither an anomaly nor any traffic at all was measurable. A considerable share of null routes is set without anything happening at that moment.
• The mean drop rate for /32 prefixes was 50 percent, even though those prefixes covered 99 percent of the traffic that should have been blackholed. On average the procedure therefore achieves only half of its own goal, because not every path into the network adopts the announcement.
• The authors also describe the phenomenon of "RTBH zombies": null routes that remain in the routing tables even though nothing in the data plane justifies them any more.

The conclusion is sober. Null routing is not only blunt, on average it is also less effective than the simplicity of the procedure suggests. As a last resort it still has its place. As the first answer to every attack it is the worst available choice that still works.

How to find out whether your provider null routes

The question can be answered, and in three ways: by measuring during an incident, by reading the contract terms and by asking the support desk a precise question. Taken together the three give an unambiguous picture.

The self test in four steps

The test assumes you have access to the server that does not depend on the network, meaning a console in the customer panel. With a null route in place SSH will not get you in, and that is not a fault but already the first result.

ip -br addr
ss -lntup
curl -o /dev/null -s -w '%{http_code} %{time_total}\n' http://127.0.0.1/
IF=$(ip -o route get 1.1.1.1 | awk '{print $5}')
A=$(cat /sys/class/net/$IF/statistics/rx_packets); sleep 5; B=$(cat /sys/class/net/$IF/statistics/rx_packets)
echo "$(( (B-A)/5 )) incoming packets per second on $IF"

The decisive value is the last one. In parallel, run a continuous ping toward your address from another connection and watch the incoming packet rate while doing so. If it does not rise, not a single one of those packets reaches you, and then they are being discarded in front of your server. If it rises sharply while the service stays silent, an attack is reaching the server, which is an entirely different diagnosis with entirely different measures, described in Detect a DDoS attack on your server.

From the outside, meaning from any other machine, three commands belong to the test:

ping -c 5 203.0.113.42
traceroute -n 203.0.113.42
mtr -rwzc 20 203.0.113.42

Read the path from the end. If the second to last node inside the provider network answers normally and the trace breaks off right after it with asterisks, the discard happens inside the provider network. If instead the trace runs all the way to the gateway directly in front of your server and only the server itself stays silent, the cause is on your side: your own firewall rule, a crashed service or a saturated uplink.

The symptoms and what they mean

What the contract terms say

The second way is reading, and it costs ten minutes. Search the terms and conditions, the service description and the acceptable use policy for these words: null routing, null route, blackhole, blackholing, blocking of the IP address, disconnection from the network, protection of the network infrastructure, mitigation measures. If you find a clause that allows the provider to "temporarily disconnect your address from the network in order to protect the network infrastructure", that is the contractual basis for null routing, even where the word itself never appears.

Two further formulations are telling. Where DDoS protection is advertised as "up to X Gbps", you should ask what happens above X, because that is exactly where the interesting answer lives. And where it says somewhere that costs for "excessive traffic" will be passed on, that describes a model in which attack traffic is let into the network and billed instead of ending before it.

The right question for the support desk

The third way is one single precise question, best asked before signing a contract and in this form:

What happens during an attack of more than 10 Gbps against my IP address: is the traffic filtered and the address stays reachable, or is the address null routed? If it is null routed: from which threshold onward, for how long, and is the route withdrawn automatically?

The question is a good one because it demands four pieces of information at once that cannot be packed into a marketing sentence: whether, from when, for how long and how it comes back. A clear answer is a good sign no matter how it turns out: even "we null route from 5 Gbps onward for 60 minutes" is an answer you can plan around. An evasive answer is an answer too, just a different one. Phrases such as "we take appropriate measures" or "our network is DDoS protected" answer none of the four questions.

What you can do while you are null routed

Briefly up front: you cannot withdraw the route yourself, it does not sit on your server. What you can do is still more than waiting, and the order matters.

1. Use the console in the customer panel, not SSH. The console runs independently of the network connection and is your only path onto the system in this situation.
2. Secure the findings. Incoming packet rate, a trace from outside with a timestamp and the time at which it went away. Those three values turn an assumption into evidence, and they are gone later.
3. Change nothing. Firewall rules, service restarts and kernel settings change nothing about a route outside your server. A reboot only erases your own counters.
4. Do not switch the IP address in a hurry. As long as the old address is in DNS you keep sending your users into the hole, and an attacker who can read the new address out of your own record within minutes simply follows. Switching the address makes sense after the incident, planned and together with the DNS records.
5. Open a ticket with numbers. Time with time zone, affected address, target port, measured packet rate, bandwidth, average packet size. Add the four questions from the previous section, above all: when will the route be withdrawn?
6. Rescue the dependencies that do not have to live on that address. A second name server in another network keeps the zone alive. A second MX with lower priority accepts mail instead of rejecting it. A status page outside your own network explains to your users what is going on.
7. No counter measures against the sources. Retaliation and stress tests through third party services are criminal offenses, in Austria under section 126b StGB and in Germany under section 303b StGB, and with amplification attacks they would hit uninvolved third parties anyway.
8. Afterwards, ask the right question. An incident that ends in a null route is not a configuration question but a contract question. The answer does not sit in your nftables file but in the filter capacity of whoever operates your uplink. The full procedure for a running, severe attack is described in What to do during a severe DDoS attack.

When null routing is the right choice after all

This section belongs here, because a text that only runs a procedure down would be dishonest. There are four situations in which a null route is the factually correct decision.

Above the filter capacity. Every network has a finite capacity, without exception. Once an attack exceeds the filtering capability that is held ready, the choice is no longer "filter or null route" but "one customer offline or all customers offline". Then the null route is right, and right immediately. The decisive difference between providers is therefore not whether such a threshold exists but where it sits, and whether it is the last resort or the first answer.

Against a manageable number of known sources. The source based variant from RFC 5635 discards by sender instead of by destination. The victim stays reachable, the attacker does not. It requires an active reverse path check and does not work against spoofed senders, but where both fit it is the better null route.

On your own server against a known individual nuisance. ip route add blackhole 203.0.113.42 is considerably cheaper than a long firewall chain, because the routing lookup happens for every packet anyway. For a handful of addresses that keep causing trouble it is a decent tool, as long as you know that it only affects the return path.

For an address that is not needed any more. A decommissioned service, a retired address, an abuse case: here there are no legitimate users to lose along the way, and therefore no objection.

What null routing must not be can be stated just as clearly. It must not be the default answer to every attack. The threshold must not be so low that an attack any decent filtering handles in passing takes the service offline. The time window must not be orders of magnitude longer than the attack. The customer has to learn that it happened and when it ends. And it must not be sold as "DDoS protection", because what is being protected is the network, not the service of the customer.

What KernelHost does instead

Two stage filtering instead of shutdown

At KernelHost, null routing is not the answer to an attack. The attacked traffic is filtered, the IP address stays on the network, and only the malicious packets are discarded. The protection is built in two stages and permanently active, without you having to order, enable or configure anything:

• Stage 1: 17 Tbps of mitigation capacity in the global scrubbing network. Volumetric attacks are cleaned close to their source before they reach the data center. That capacity is what decides where the threshold described above actually sits.
• Stage 2: Arbor real-time filtering with 3.2 Tbps in Frankfurt am Main. Directly in front of the server, protocol specific patterns are recognized and discarded packet by packet, while the traffic of your users keeps flowing.

Two properties are decisive when it counts. The protection runs permanently and is active from the provisioning of the server onward, so it does not have to detect an attack first in order to work. And it is included with every server package at no surcharge, from the KVM root server to the dedicated server. Which services and protocols have their own filter profiles is listed in Game server DDoS protection in real time, and the overview for gaming projects is in Specialized game DDoS protection.

Advanced DDoS Protection for projects under constant fire

Some projects are not hit occasionally but deliberately and over weeks, every evening at the same time and with changing patterns. Those are exactly the projects that get null routed first elsewhere. For them there is Advanced DDoS Protection from €50.00 per month, PrePaid, with no minimum term and no setup fee. The difference lies not in more capacity but in control:

• A dedicated protected IP from the Frankfurt core, to which your server is switched inside our own network. No rebuilding is required on your side.
• Self managed protection rules per port and protocol in the customer panel, without a ticket: the service port gets different rules than the query port, and that distinction is exactly what a route can never make.
• Changes take effect in real time, so you can adjust in the middle of a running attack instead of waiting for a maintenance window.
• A protection profile matching the service, including modified and self written applications on any TCP or UDP port.

Advanced DDoS Protection is aimed at KernelHost customers and requires a server at KernelHost. If your project currently runs elsewhere and is regularly taken offline there, moving it here is the way forward, not remote care of your existing address. What you can secure on the server itself regardless is covered in How to protect your server from DDoS attacks.

The two stages compared

Common misconceptions about null routing

"Null routing protects my server": it protects the network your server sits in, which is something else. For your service the result is indistinguishable from a successful attack.

"When the address is null routed, the attack is over": usually the other way around. The attack ends after seconds to minutes, the route stays in place for the entire agreed time window. The larger part of the outage happens after the attack.

"A new IP address solves the problem": only until the new address is public, and on a game server that is the moment the first player connects. Switching addresses buys time, it is not a solution.

"Null routing is the same as a firewall rule": both discard packets, but at opposite ends. The firewall decides per packet at the end of the uplink and knows ports, protocols and rates. The null route decides per address at the beginning of the uplink and knows only the address.

"I would have noticed if my provider null routed me": a null route of 20 minutes at four in the morning looks like a brief outage in your monitoring. Without measuring the incoming packet rate it cannot be told apart from a crashed service.

"My provider does it out of convenience": usually not. They weigh one outage against many, and in that moment the answer is unambiguous. The legitimate question is not whether they may do it but from which attack size they are forced to, and that is a question of the filter capacity they hold ready.

Summary

• Null routing is a route to discard or null0: packets to that destination address are discarded instead of forwarded. On Linux the command is ip route add blackhole 203.0.113.42, on routers the same instruction reads Null0 or discard.
• Remotely Triggered Black Hole Filtering per RFC 5635 distributes that route through an entire network via BGP and, with the community 65535:666 from RFC 7999, all the way to the transit providers. It takes effect within seconds because a single announcement is enough.
• Network operators use it because an attack on one customer saturates the shared uplink and takes everybody else with it. Null routing sacrifices one to save hundreds. That decision is rational and, in its situation, correct.
• For the customer on the receiving end it means the server keeps running but is unreachable from the internet, frequently in the outbound direction as well. Typical time windows range from minutes to 24 hours with automatic withdrawal.
• RFC 5635 itself states that the impact on the target is "complete", because attack traffic and legitimate traffic are discarded alike. Null routing does not prevent the outage, it produces it.
• Filtering distinguishes between attack traffic and real users, null routing does not. A route knows exactly one attribute, the destination address. A filter rule per RFC 8955 knows twelve, among them protocol, port, packet length and rate.
• The study "Down the Black Hole" (ACM IMC 2019) found at a large European internet exchange point that only 27 percent of RTBH events came with a measurable traffic anomaly, and that /32 announcements on average discarded only 50 percent of the traffic concerned.
• You can tell whether your provider null routes from three things: the service answers locally, nothing arrives from outside, and the incoming packet rate stays near zero. Add a trace from outside that ends inside the provider network, and a question to the support desk about threshold, duration and automatic withdrawal.
• Null routing remains correct as a last resort once the attack size exceeds the filter capacity. The difference between providers is therefore not whether a threshold exists but where it sits.
• At KernelHost null routing is not the answer to an attack: the IP address stays on the network and only the malicious packets are discarded. The two stage always-on protection with 17 Tbps of mitigation capacity in the global scrubbing network and Arbor real-time filtering with 3.2 Tbps in Frankfurt am Main is included with every server package at no surcharge and active from provisioning. Advanced DDoS Protection adds a dedicated protected IP and self managed rules per port from €50.00 per month.

If your project already runs at KernelHost, the filtering is active without you having to do anything. If you still see an outage in which the server answers perfectly on the local interface, open a support ticket with the time, the address, the target port and the measured packet rate so that the filter rules for your IP address can be adjusted. During a running attack you can also reach us through the WhatsApp emergency chat at +43 650 8209883.