On this page
Key points
- No single universal modelThe best design depends on your IP ownership, routing needs and production constraints.
- GRE is often the fastest startFor many customers, a simple tunnel is already enough to deploy cleanly.
- BGP adds controlIt becomes useful when you want to keep your own announcements or a more advanced routing policy.
- Protected IPs simplify onboardingThey let you test quickly without moving everything on day one.
The real decision: simplicity, control or deployment speed
The common mistake is to ask for the “most advanced” design before checking the real need. Many customers do not need BGP on day one. Others do benefit from keeping their own prefixes and routing logic from the beginning.
The right choice depends on three things: who owns the public IPs, how much routing control is needed and how fast the protection has to go live.
Why the delivery model matters so much
Your delivery model affects deployment time, maintenance effort, the number of required changes on the existing environment and how easily the design can evolve later.
A technically powerful solution that is too heavy to integrate can slow down the whole project. On the other hand, a very simple model can be perfect for one service but too limited for a larger multi-site or multi-prefix environment.
- Production impact
- The more complex the model, the more you need to validate routing, return traffic, MTU and monitoring.
- Timeline impact
- GRE or protected IP delivery often goes live faster than a full BGP integration.
- Scalability impact
- BGP becomes much more valuable when multiple services or multiple prefixes are involved.
- Commercial impact
- A simpler rollout usually reduces the time between first contact and go-live.
When to choose a simple GRE tunnel
GRE-only is often the right answer when a customer wants to protect an existing production service quickly and does not need to announce their own prefixes.
It fits dedicated servers, web services, APIs, gaming platforms and environments that want to add anti-DDoS protection without redesigning the public routing layer.
- Simpler deployment
- Fewer BGP-side dependencies on the customer environment
- Very good for fast latency and integration tests
- A strong option when keeping an existing OVH, Hetzner or similar dedicated server
When to add BGP to the GRE tunnel
BGP becomes relevant when you have your own IP space, your own ASN or an architecture where routing control is part of the requirement. It allows cleaner prefix handling and more flexibility as the environment grows.
It is not a mandatory prerequisite for protection. It is an architectural choice that adds control when that control has real operational value.
- Keep your own prefixes
- Your public addressing and announcements stay central to the design.
- Scale more cleanly later
- The model fits better when several services or blocks need to be managed.
- More initial work
- In exchange, integration is heavier than a very simple GRE-only setup.
When to use protected anti-DDoS IPs
Protected IPs are often the fastest way to start. Traffic hits an IP exposed on the mitigation side first, and clean traffic is then delivered to your server through a tunnel.
This is especially useful if you do not want to announce your own blocks, if you want to validate the service quickly or if you first want a simple production-ready model before moving to something more advanced.
The service is published on a protected IP
The public exposure point sits on the mitigation infrastructure.
Malicious traffic is filtered upstream
The goal is to stop the attack before delivery to your own environment.
Legitimate traffic is delivered to your infra
Delivery can happen through GRE or another method depending on the design.
You keep room to evolve later
If your needs change, the design can move towards more routing control later on.
How to decide between the three models quickly
If you want to move fast, protect a specific service and avoid complexity, start with GRE-only or protected IP delivery in most cases. If keeping your own public space is already important, GRE + BGP makes sense from day one.
The best design is usually the one that protects fast without locking you into unnecessary complexity. The goal is not to look impressive on paper, but to stay clean, stable and operable.
- You want speed
- Choose GRE-only or protected IPs.
- You want to keep your own IPs
- Choose GRE + BGP.
- You want to test before going further
- Choose protected IPs plus tunnel delivery.
- You manage multiple services and advanced routing
- BGP usually becomes more coherent.
Common mistakes to avoid
The most common mistake is picking a model that is too heavy for the real need, or too simple for an already advanced environment. It is also risky to ignore return traffic, MTU and the exact way the service will be exposed.
Is BGP mandatory to be protected?
No. Many services can be protected properly with GRE and, when helpful, protected IP delivery.
Is a tunnel alone enough for a dedicated server?
In many cases yes, especially when the main goal is to protect a service already running in production.
When are protected IPs most useful?
When you want to go live quickly, reduce complexity and avoid announcing your own blocks at the start.
Can we start simple and evolve later?
Yes. That is often the best path: validate the service first, then evolve the design if the architecture really requires it.
