BGP DDoS Protection — Your Own IP Range over GRE

Who it is for

Hosting providers, game server operators, internet service providers and corporate infrastructures that own an IP range and an ASN. If you do not have your own range this service cannot be applied; in that case IP rental or hosting directly on Datafex infrastructure is a better fit.

Which attacks are stopped

Volumetric attacks stop before they reach your line: domestic traffic is scrubbed at distributed nodes inside Türkiye and international traffic at filters abroad, and reflection and amplification attacks such as DNS amplification, NTP amplification, TCP amplification and TCP reflection are cut on our DPDK + VPP router. The last layer, Fexwall, handles traffic with forged source addresses, botnet-driven request floods and the rules you define for your own project between L4 and L7. The layers work together.

What you need first: ASN, LOA, IRR and RPKI

BGP protection is a records exercise before it is a technical setup. Here is what you need, in order. You must have your own autonomous system number (ASN) and an IPv4 range of at least /24; prefixes longer than /24 are filtered by most operators in the global routing table, so announcing a /25 does not work in practice. A letter of authorisation (LOA) showing you may use the range is prepared. Then the route or route6 object in the IRR is updated to point at the ASN that will make the announcement. The last and most critical step is RPKI: if the origin ASN and maxLength in the ROA defined for your range do not match the new announcement, it is marked invalid and operators performing RPKI validation will not accept the traffic at all. Because these records take hours to propagate, they have to be completed before announcement day.

GRE tunnels, direct connections and the MTU problem

How cleaned traffic reaches you is solved one of two ways. If your servers are on the Datafex side, a direct connection is the simplest route. If you are in another location, traffic is carried over a GRE tunnel — and there is a detail that is often missed: GRE adds 24 bytes of header to every packet. On a tunnel running over a standard 1500-byte MTU, the usable payload drops to 1476 bytes. If you do not set the MTU accordingly at both tunnel ends and apply MSS clamping for TCP sessions, small packets pass while large ones vanish silently. Users usually describe this as the site loads but downloads never finish; it is hard to diagnose and fixed by a single line of configuration. Agreeing MTU and MSS values while building the tunnel is far cheaper than hunting that symptom afterwards.

Announcement day: propagation, monitoring and rollback

An announcement is not instantaneous. A new one usually becomes globally visible over minutes, while changes on the records side (IRR, RPKI) can spread over hours. That is why the transition is placed in a low-traffic window. Three things are watched during it: whether your range is visible from independent observers — RIPE RIS, looking glass services, public BGP monitoring tools — whether RPKI validation reads as valid, and whether real user traffic arrives over the expected path. The rollback plan is written in advance too: when you withdraw an announcement, traffic returning to the old path is subject to the same propagation delay, so we can revert instantly if needed is not a realistic sentence. Methods such as AS-path prepending can be used for a gradual cutover; which one fits depends on how you are connected to your existing providers.

How the process works

1. 1Share your ASN and prefix details; range size and the current announcement state are verified.
2. 2Prepare the letter of authorisation (LOA) for the range.
3. 3Update the IRR route object and the RPKI ROA to match the new announcement, then wait for them to propagate.
4. 4Build the path the traffic will take: a direct connection or a GRE tunnel — together with MTU and MSS settings.
5. 5Bring up the announcement in a low-traffic window and confirm visibility from independent observers.
6. 6Tune the filter rules for your project and put the monitoring and rollback plan in writing.

Common mistakes

• Announcing before updating RPKI. An announcement marked invalid means traffic is dropped entirely by validating operators.
• Leaving maxLength wider than necessary. It opens the door for someone else to announce more specific parts of your range.
• Skipping MSS clamping. Small packets cross the tunnel while large ones disappear; the symptom looks like the site loads but transfers never finish.
• Planning to announce a prefix longer than /24. It is filtered in the global routing table and the traffic never reaches you.
• Cutting over at peak hour. Propagation takes minutes and rollback is subject to the same delay.
• Trying to protect UDP-based game or voice traffic with an HTTP proxy. That layer never sees those packets; filtering has to happen at L3/L4.

Frequently Asked Questions

Can I use this without my own ASN?

No. BGP protection relies on announcing the range over BGP, which requires your own IP range and autonomous system number. If you do not have them, look at IP rental instead.

My servers are with another provider — can I still use it?

Yes. Because the protection works at the network layer, the physical location of your servers is not decisive; cleaned traffic is delivered to you over a GRE tunnel or a direct connection.

What is the smallest range that can be announced?

A /24 for IPv4. Because most operators filter prefixes longer than /24 in the global table, a /25 or smaller is effectively invisible. On the IPv6 side the commonly accepted limit is /48.

How long does propagation take, and will there be downtime?

An announcement usually becomes globally visible over minutes, while record changes (IRR, RPKI) can take hours. That is why the cutover happens in a low-traffic window with the records completed beforehand. The same timing applies to rolling back.

Who updates the RPKI and IRR records?

Those records are tied to your own RIPE account, so you make the updates; we tell you what the values should be — origin ASN, maxLength, the route object. The distinction matters: a wrong ROA causes the announcement to be rejected outright.

Can my IPv6 range be announced too?

Yes, the logic is the same. A route6 object is defined in the IRR and a separate RPKI ROA is created for the IPv6 prefix. The records for IPv4 and IPv6 announcements are independent of each other, and updating one while forgetting the other is a common mistake.