Most engineers think…
Most people picture a DDoS appliance as 'a box you wire inline that drops floods'. That single mental model fails you in an interview and on a big network.
Radware DefensePro is one engine with three deployment models: inline (Transparent / L2 bridge) for instant in-path blocking, out-of-path (IP mode) where it learns from a copy and only diverts suspect traffic during an attack, and the scrubbing center that extends out-of-path to carrier scale with BGP route diversion and GRE clean-traffic return. Knowing which to place where — and the latency-vs-scale trade-off between them — is what lets you protect a single perimeter or a whole ISP backbone without melting the core or melting the SLA.
① Inline — the transparent L2 bridge that blocks in path
The first deployment model is inline, set as Transparent mode. DefensePro sits at the gateway as a bump-in-the-wire L2 bridge, so all production traffic passes through it. Because it is already in the live path, it can drop malicious packets immediately with no diversion step — this gives the lowest detection-to-mitigation time of any mode.
The price of that speed is that the device is in the critical path. It becomes a potential single point of failure and a capacity ceiling for the link, so HA pairs and fail-open / link-bypass are mandatory. Inline is the right call for an enterprise perimeter or DMZ where you control a single, mostly symmetric ingress and the link speeds fit one appliance.
In an interview, say inline = Transparent (L2 bridge) and out-of-path = IP mode, and add that both are set under Device > Global Operation Mode and changing the mode requires a device reset. Naming the exact console path shows you've actually operated the box, not just read the brochure.
Which device operation mode is used for inline deployment?
② Out-of-path — detect on a copy, divert on attack
The second model is out-of-path, set as IP mode, where DefensePro is a routed network entity with IP interfaces. In peacetime, production traffic does not pass through it — it only inspects a copy from a SPAN/mirror or tap port to learn baselines and detect anomalies. Destination servers keep receiving the live traffic directly.
Detect, then divert
When an anomaly is detected, DefensePro (often orchestrated by DefenseFlow) signals routers to redirect the suspect traffic to the device; the scrubbed clean traffic is injected back via GRE tunnels to avoid routing loops, with primary/secondary tunnel redundancy. The trade-off versus inline is a brief detect-then-divert delay before mitigation starts. Note that tap mode only sees a copy, so it can mis-report connections-per-second. Out-of-path is ideal for core networks and asymmetric/multi-homed links where you don't want every packet through the appliance.
Inline bridge deployment — DefensePro forwards at Layer 2 and blocks attack traffic in the live path. Lowest mitigation latency, but it is in the critical path.
Out-of-path routed deployment — peacetime traffic bypasses the device; it detects on a SPAN/tap copy and only diverted traffic is scrubbed during an attack.
Encapsulated return path that sends scrubbed clean traffic back to the customer without routing loops. Supports primary/secondary redundancy, up to 1000 tunnels.
BGP method that lengthens the normal route so the scrubbing-center advertisement is shorter and preferred, pulling traffic toward the scrubber.
Out-of-path detects on a copy and must divert traffic before it can scrub, so the first packets of an attack still take the normal path until the route change wins. Inline blocks in place with no diversion. Never claim equal mitigation speed — explain the detect-then-divert delay.
In out-of-path (IP) mode during peacetime, what does DefensePro inspect?
③ Scrubbing center — out-of-path at carrier scale with BGP
The third model is the scrubbing center: out-of-path extended across a carrier/ISP/MSSP backbone for very large volumetric defense. The customer's prefixes are diverted to the scrubbing center with BGP route diversion; DefensePro clusters scrub the traffic and return it clean over redundant GRE tunnels (supporting up to 1000 tunnels).
The BGP diversion methods
There are three ways to pull traffic in: smaller-prefix advertisement (announce two /24s instead of one /23 — automatic, longest-prefix wins), AS-path prepend so the scrubbing route is shorter and preferred, and manual advertisement withdrawal. A low-TTL DNS change to a VIP is an alternative for a handful of services. Because forward and return paths often differ here, DefensePro's support for asymmetric traffic is essential. The cost: you need a public ASN, /24–/23 prefixes and GRE plumbing, plus diversion latency at attack onset.
▶ Watch a volumetric flood get diverted and scrubbed out-of-path
How an attack is handled end-to-end in IP mode. Press Play for the healthy diversion path, then Break it to see the classic failure.
An upstream peer keeps preferring the normal route over your scrubbing-center advertisement. Which BGP lever makes the scrubbing route win?
④ Choosing a mode — latency vs blocking speed vs scale
There is no single best mode — there is a trade-off. Inline wins on speed (instant in-path blocking, minimal added latency) but adds an in-path failure point and a capacity ceiling. Out-of-path and scrubbing win on scale and add no peacetime latency, but pay a short detect-then-divert delay on the first packets of an attack.
A quick decision guide
Pick inline for an enterprise perimeter or DMZ with a single symmetric ingress that fits one appliance. Pick out-of-path for larger or core networks and asymmetric/multi-homed links where you can't push every packet through the box. Pick a scrubbing center for carrier/ISP/MSSP backbones, multi-tenant defense and massive volumetric attacks — accepting the ASN, prefix and GRE requirements and the diversion delay. Behavioral RT-Signature detection reacts in seconds in every mode; the difference is whether mitigation is instant (inline) or after diversion (out-of-path/scrubbing).
Vikram at a Bengaluru regional ISP/MSSP faces this
A hosting customer reports their site stays reachable but goes sluggish for about 90 seconds at the start of every volumetric flood, then recovers.
DefensePro is running out-of-path (IP mode) and detecting correctly on a SPAN copy, but mitigation only begins after diversion — and the BGP route change isn't being preferred fast enough, so attack packets keep taking the normal path during the gap.
Open the DefensePro console, confirm Device > Global Operation Mode is IP, then review the DefenseFlow diversion workflow logs: the smaller-prefix advertisement is correct, but the upstream peer is honouring AS-path and the diverted prefix isn't winning quickly.
Device ▸ Global Operation Mode + DefenseFlow ▸ Diversion workflow logs ▸ BGP advertisementAdd AS-path prepend on the normal route so the scrubbing-center advertisement is unambiguously preferred, and verify the GRE return tunnel has a configured secondary for redundancy.
On the next attack, traffic diverts within a few seconds; the customer's traffic flows clean through the scrubbing path and the 90-second sluggish window disappears, confirmed in the DefenseFlow diversion timestamps and the customer's latency graphs.
Never close a 'slow at attack onset' ticket on a hunch. The DefenseFlow diversion logs show the exact detect time, the BGP change and when clean traffic started returning over GRE. That timeline tells you whether the gap is detection, diversion or route preference — usually it's the route not winning fast enough.
A carrier must defend many customers against huge volumetric floods on multi-homed, asymmetric links. Which model fits best?
🤖 Ask the AI Tutor
Tap any question — instant, scoped to this lesson. No login, no waiting.
Pre-curated from vendor docs + community Q&A, scoped to this lesson. For a live prod issue, paste your export into chat.techclick.in.
📝 Wrap-up assessment — six more
You've answered 4 inline. Six left. 70% (7 of 10) marks the lesson complete on your profile. Tap Submit all answers at the end.
🧠 In your own words
Type one line: why does out-of-path mitigate slower than inline, even though both detect attacks in seconds? Then compare with the expert version.
🗣 Teach a friend
Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary.
📖 Glossary
- DefensePro
- Radware's behavioral DDoS detection and mitigation appliance (physical or virtual) that can run inline or out-of-path.
- DefenseFlow
- Radware's SDN/orchestration controller that automates attack detection and traffic diversion across the network.
- Transparent mode (inline)
- The L2-bridge operation mode where DefensePro sits in the live path and blocks attack traffic immediately.
- IP mode (out-of-path)
- The routed operation mode where peacetime traffic bypasses the device and only diverted traffic is scrubbed during attacks.
- Scrubbing center
- A facility where prefixes diverted by BGP are cleaned of attacks and clean traffic is returned to the customer.
- SPAN / Tap
- A mirrored copy of network traffic fed to DefensePro for baseline learning and anomaly detection in out-of-path mode.
- Route diversion
- Using BGP (smaller prefix, AS-path prepend, withdrawal) or DNS to pull traffic toward the mitigation device.
- GRE tunnel
- An encapsulated path that returns scrubbed clean traffic to the customer without routing loops; up to 1000 tunnels, with redundancy.
- RT-Signature
- Radware's real-time, auto-generated attack signature that enables fast behavioral mitigation without admin intervention.
📚 Sources
- Radware — Global Operation Mode (Device Operation Mode): Transparent vs IP. webhelp.radware.com
- Radware — DefensePro Out-of-Path Deployment. support.radware.com
- Radware — Choosing the Best Diversion For Your Needs. support.radware.com
- Radware — BGP Configuration for Routing-Based Diversion. support.radware.com
- Radware — How to Set Up GRE Tunnels for Clean-Traffic Return. support.radware.com
- Radware / Cisco — DefensePro and DefensePro Virtual Appliance Data Sheet. cisco.com
What's next?
Got the deployment modes? Next, go deep on DefensePro's behavioral detection engine — RT-Signatures, baselines and the BDoS/DNS/SYN protections — and how a real-time signature is auto-generated mid-attack.