# Radware DefensePro Deployment Modes — Inline, Out-of-Path & Scrubbing Source: https://ai.techclick.in/blog_radware_ddos_deployment_modes Markdown: https://ai.techclick.in/blog_radware_ddos_deployment_modes.md Publisher: Techclick Infosec Pvt Ltd A clear, interactive guide to Radware DefensePro deployment modes (2026): inline Transparent (L2 bridge) for instant in-path blocking, out-of-path IP mode with SPAN/tap detection and GRE return, and the carrier-scale scrubbing center with BGP route diversion — plus exactly how to choose by latency, blocking speed and scale. Radware DefensePro Deployment Modes — Inline, Out-of-Path & Scrubbing student learning map A visual study map for Radware DefensePro Deployment Modes — Inline, Out-of-Path & Scrubbing showing learning path, evidence, traps, and practice sequence. TECHCLICK STUDY MAP Radware DefensePro Deployment Modes — Inline,... Radware · learn the flow, prove with evidence, avoid unsafe shortcuts 1. Start 🎯 By the end you will be able to 2. Understand Pick where you want to start 3. Prove ① Inline — the transparent L2... 4. Practice ② Out-of-path — detect on a copy,... How to use this page First build the mental model, then connect the concept to a realistic production decision. Finish by testing yourself. Techclick Infosec Pvt Ltd | ai.techclick.in | Training Contact: WhatsApp +91 92772 29456 Content-specific feature visual for this lesson: use it as the 60-second map before reading the full detail. 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 Global Operation Mode) where DefensePro forwards at Layer 2 as a bump-in-the-wire bridge. Changing the mode requires a device reset.'>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. Legend diagram title stage name stage detail traffic path & borders diagram canvas Figure 1 — Inline path — traffic flows through and is blocked in place In Transparent mode all production traffic passes through DefensePro, so attack packets are dropped in the live path with no diversion. - Inline path — traffic flows through and is blocked in place Internet inbound traffic DefensePro L2 bridge inspects Block drop attack in path Servers clean traffic only In Transparent mode all production traffic passes through DefensePro, so attack packets are dropped in the live path with no diversion. Name the mode, then the switch that sets it 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. Quick check · Q1 of 10 · Remember Which device operation mode is used for inline deployment? a) Transparent (L2 bridge) b) IP mode c) Tap mode d) DNS mode Correct: a. Inline = Transparent mode: DefensePro forwards at Layer 2 as a bump-in-the-wire bridge so all traffic passes through and attack packets are dropped in path. IP mode is out-of-path; tap/DNS are not operation modes. 👉 So far: Inline = Transparent (L2 bridge) mode: all traffic passes through DefensePro, so attack packets are dropped in path with the lowest mitigation latency — but it's a critical-path device needing HA and fail-open. ## ② 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. Figure 2 — Inline vs out-of-path at a glance The same engine, two operation modes — instant in-path blocking versus copy-based detect-then-divert. Inline vs out-of-path at a glance Inline (Transparent) L2 bridge in the live path All traffic passes through Instant in-path blocking Needs HA + fail-open Out-of-path (IP) Routed entity, off to the side Peacetime traffic bypasses it Detect on SPAN/tap copy Divert on attack, GRE return The same engine, two operation modes — instant in-path blocking versus copy-based detect-then-divert. Figure 3 — Out-of-path — detect on a copy, then divert Peacetime traffic flows direct; on attack, suspect traffic is diverted to DefensePro and returned clean over GRE. Out-of-path — detect on a copy, then divert Copy SPAN/tap to device Detect baseline anomaly Divert router / DefenseFlow Scrub drop attack traffic GRE return clean traffic back Peacetime traffic flows direct; on attack, suspect traffic is diverted to DefensePro and returned clean over GRE. 🌉 Transparent (L2) mode tap to flip 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. 🛰️ IP mode tap to flip 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. 🧪 GRE tunnel tap to flip Encapsulated return path that sends scrubbed clean traffic back to the customer without routing loops. Supports primary/secondary redundancy, up to 1000 tunnels. 📈 AS-path prepend tap to flip BGP method that lengthens the normal route so the scrubbing-center advertisement is shorter and preferred, pulling traffic toward the scrubber. 'Out-of-path blocks just as fast as inline' is wrong 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. Quick check · Q2 of 10 · Understand In out-of-path (IP) mode during peacetime, what does DefensePro inspect? a) Every live packet in the path b) Only device syslog c) A SPAN/mirror or tap copy of traffic d) Encrypted payloads only Correct: c. In IP mode production traffic does not pass through the device in peacetime; it learns baselines and detects anomalies from a mirrored SPAN/tap copy, then diverts the real suspect traffic only once an attack is detected. 👉 So far: Out-of-path = IP mode: peacetime traffic bypasses the device, which detects on a SPAN/tap copy, then diverts suspect traffic on attack (often via DefenseFlow) and returns clean traffic over GRE — at the cost of a detect-then-divert delay. ## ③ 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. Figure 4 — Scrubbing center — many diversion levers, one return path Customer prefixes are pulled to the scrubbing center by BGP; clean traffic returns over GRE, with asymmetric paths supported. Scrubbing center — many diversion levers, one return path Scrubbing center DefensePro cluster Smaller-prefix AS-path prepend Ad. withdrawal DNS to VIP GRE return Asymmetric OK Customer prefixes are pulled to the scrubbing center by BGP; clean traffic returns over GRE, with asymmetric paths supported. ### ▶ 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. ① Copy detect Peacetime traffic flows direct to the servers; DefensePro watches a SPAN/tap copy and learns the normal baseline. ▼ ② Anomaly A volumetric flood begins; the behavioral engine sees the baseline breach and DefenseFlow signals a diversion. ▼ ③ Divert (BGP) BGP route diversion pulls the customer's prefix to the scrubbing center, so suspect traffic now reaches DefensePro. ▼ ④ Scrub + GRE DefensePro drops the attack and returns clean traffic to the customer over a GRE tunnel, with no routing loop. Press Play to step through the healthy out-of-path diversion. Then press Break it . ▶ Play Next ▶ ⚠ Break it ↺ Reset Quick check · Q3 of 10 · Apply An upstream peer keeps preferring the normal route over your scrubbing-center advertisement. Which BGP lever makes the scrubbing route win? a) Enable a SPAN port b) AS-path prepend on the normal route c) Disable GRE d) Lower the server TTL Correct: b. AS-path prepend lengthens the normal route's AS path so the scrubbing-center advertisement is shorter and preferred. Smaller-prefix advertisement and manual withdrawal are the other BGP diversion methods; SPAN and GRE are detection and return, not diversion. 👉 So far: A scrubbing center is out-of-path at carrier scale: BGP diversion (smaller-prefix, AS-path prepend, withdrawal) pulls prefixes in, DefensePro scrubs, and clean traffic returns over up to 1000 GRE tunnels, with asymmetric paths supported. ## ④ 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). Figure 5 — Three models, rising scale From a single perimeter appliance to a carrier backbone — blocking speed falls and scale rises as you move down. Three models, rising scale Inline (Transparent) Perimeter/DMZ — instant blocking, in-path Out-of-path (IP) Core/asymmetric — detect on copy, divert Scrubbing center Carrier/MSSP — BGP diversion, multi-tenant From a single perimeter appliance to a carrier backbone — blocking speed falls and scale rises as you move down. 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. Likely cause 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. Diagnosis 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 advertisement Fix Add 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. Verify 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. Prove diversion timing, don't assume it 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. Quick check · Q4 of 10 · Analyze A carrier must defend many customers against huge volumetric floods on multi-homed, asymmetric links. Which model fits best? a) A single inline appliance at one site b) A host firewall on each server c) A scrubbing center with BGP diversion d) Tap mode with no mitigation Correct: c. Carrier/MSSP multi-tenant volumetric defense on asymmetric, multi-homed links is exactly the scrubbing-center case: BGP route diversion pulls prefixes in, DefensePro clusters scrub, and clean traffic returns over GRE — accepting a short diversion delay at attack onset. 👉 So far: Choose by trade-off: inline for a single symmetric perimeter (speed), out-of-path for core/asymmetric networks, and a scrubbing center for carrier/MSSP multi-tenant volumetric scale — speed falls and scale rises as you move down. ### 🤖 Ask the AI Tutor Tap any question — instant, scoped to this lesson. No login, no waiting. What is the difference between Transparent and IP operation modes? Why is inline faster to mitigate than out-of-path? How does DefensePro get traffic in out-of-path mode? How does clean traffic get back to the customer after scrubbing? What are the main BGP diversion methods? When would I pick a scrubbing center over inline? 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. Q5 · Remember Where do you set the DefensePro device operation mode? a) BGP > Routes b) Device > Global Operation Mode c) SPAN configuration d) DNS zone file Correct: b. Both Transparent (inline) and IP (out-of-path) are set under Device > Global Operation Mode, and changing it requires a device reset. BGP, SPAN and DNS are configured elsewhere. Q6 · Understand Which mode supports out-of-path deployment? a) Transparent mode b) Bridge mode c) IP mode d) Monitor mode Correct: c. IP mode makes DefensePro a routed network entity that stays off the path in peacetime and only handles diverted traffic during attacks. Transparent is the inline L2 bridge. Q7 · Apply How does cleaned traffic return from a scrubbing center to the customer? a) Over a SPAN port b) Through GRE tunnels c) Via the device's USB port d) By ICMP redirects Correct: b. Scrubbed clean traffic is encapsulated back to the protected network over GRE tunnels, which prevent routing loops and support primary/secondary redundancy. SPAN is a detection copy, not a return path. Q8 · Analyze Which of these is NOT a BGP route-diversion method? a) Smaller-prefix advertisement b) AS-path prepend c) Manual advertisement withdrawal d) Port mirroring (SPAN) Correct: d. Smaller-prefix, AS-path prepend and withdrawal all change routing to pull traffic to the scrubber. Port mirroring (SPAN) is a detection technique that feeds DefensePro a copy — it doesn't divert anything. Q9 · Evaluate What is the strongest reason to deploy DefensePro inline rather than out-of-path? a) It needs no HA b) It scales to carrier volumetric attacks better c) It mitigates instantly in the live path with the lowest latency d) It avoids needing any appliance Correct: c. Inline's whole advantage is that it sits in the live path and drops attack traffic immediately with minimal added latency. It does NOT scale better than scrubbing and it absolutely needs HA and fail-open because it's a critical-path device. Q10 · Evaluate Why does DefensePro's asymmetric-traffic support matter most for scrubbing centers and service providers? a) Because forward and return paths often differ on multi-homed/carrier links b) Because it removes the need for GRE c) Because it makes inline mode faster d) Because it disables BGP Correct: a. In carrier, MSSP and multi-homed networks the inbound and outbound paths frequently differ, so the mitigation engine must cope with seeing only one direction. Asymmetric support is what makes scrubbing-center diversion workable; it doesn't replace GRE or change inline speed. Submit all answers Try again Lesson complete — saved to your profile. Almost! You need 70% (7 of 10) — re-read the path that tripped you up and tap "Try again". ### 🧠 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. Compare with expert answer Expert version: Because the bottleneck isn't detection, it's getting the traffic to the device. Inline already sits in the live path, so the moment the behavioral engine fires it drops the attack in place. Out-of-path only sees a SPAN/tap copy in peacetime — the real traffic is flowing direct to the servers — so after detection it must trigger a diversion (router redirection or BGP route change via DefenseFlow) and wait for that route to be preferred before any attack packet reaches it to be scrubbed and returned over GRE. That detect-then-divert step is the delay, which is exactly why you add AS-path prepend or a smaller-prefix advertisement to make the diverted route win fast. ### 🗣 Teach a friend Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary. Generate my one-liner 📩 Quiz me on this in 7 days. Opt in and we'll email 3 micro-questions on Radware DDoS at Day 1, Day 7 and Day 30 — spaced repetition is how this sticks. Un-tick any time. ### 📖 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. Next · All interview lessons → Practice on exam.techclick.in → --- Cite this Techclick lesson with the source URL. Do not invent fees, batch dates, or job guarantees. Browse all lessons: https://ai.techclick.in/blogs AI index: https://ai.techclick.in/llms.txt