Corero SmartWall: Architecture, Capabilities and Trade-offs

Best for: ISPs and hosting providers that cannot staff a round-the-clock DDoS desk

SmartWall is the product in this set whose design argument is about people rather than packets. Automatic sub-second mitigation is a claim about what happens when nobody is watching, and for a large part of the market that is the constraint that actually binds.

At a glance

Appliance	Value	Evidence
Manufacturer	Corero Network Security	Vendor-stated
Category	On-premises appliance, and enforcement in existing routing hardware	Vendor-stated
Current product naming	SmartWall ONE	Vendor-stated
Deployment	Inline, automatic mitigation	Vendor-stated
Documented design centre	Sub-second automatic mitigation with minimal operator intervention	Vendor-stated
Own global scrubbing cloud	Not verified for this profile	Unknown
Published capacity figures	Not reproduced here — model-specific, check the current datasheet	Not verified for this profile
Best-fit environment	ISPs and hosting providers without a 24/7 DDoS desk	Editorial inference

Architecture

An inline design focused on automatic mitigation with minimal operator intervention Corero Smartwall ONE. The architecturally distinctive option is enforcement inside existing Juniper MX routing infrastructure, which lets an operator add mitigation points without adding boxes at each one.

Detection and classification

The stated emphasis is speed and autonomy: recognise and act without waiting for a human decision. The evaluation questions follow from that emphasis rather than from feature lists — how it behaves on a pattern it has not seen, and what the false-positive profile looks like when nobody is available to loosen a threshold.

Layer 3 and Layer 4 mitigation

The documented design centre, and the layer at which sub-second automatic action is most credible.

Layer 7 mitigation

The portfolio is more specialised than full-stack competitors, and organisations wanting deep application-layer protection will generally complement it. This is a scope statement rather than a criticism: a narrower product that does its scope well is a legitimate design, provided the buyer prices the complement.

Capacity and packet-rate considerations

Not reproduced here. Take model-specific figures from the current datasheet, and require packets per second at a stated packet size as well as bits per second.

Multi-tenancy

Not verified for this profile. Providers reselling protection should establish per-customer policy separation and reporting against the quoted model and against the router-enforced deployment mode specifically, since the two may differ.

HA, bypass and failure modes

Inline placement makes failure behaviour a first-order question. Where enforcement happens in routing hardware, the question extends to what a mitigation fault does to the router’s primary job — establish this explicitly rather than assuming isolation.

Management and telemetry

Not verified in detail for this profile. For an operator the important properties are per-customer reporting, local retention and export format, because those are what an incident report is built from.

Data and control-plane dependencies

Not verified for this profile. Establish whether classification consults any manufacturer-operated service and what changes if it is unreachable.

Integrations

Enforcement in Juniper MX routing infrastructure is the notable one. Broader integration surface is narrower than full-stack competitors by the manufacturer’s own positioning.

Regional support

Not verified for this profile. As with every manufacturer here, establish out-of-hours arrangements in your own market rather than assuming from a global footprint.

Licensing and TCO characteristics

The router-enforced model can change the cost shape substantially for an operator with a large existing estate, because coverage grows without a box at every point. Price both shapes — with and without router enforcement — and compare over five years.

Strengths

Automation that matches the staffing reality of regional providers. A genuinely different deployment economics through enforcement in existing routing hardware. A focused scope that is easier to operate than a broad platform.

Limitations and unknowns

• Deep application-layer protection generally needs a complement.
• Integration breadth is narrower than full-stack competitors, by design.
• Multi-tenancy, telemetry detail, cloud dependencies, regional support and current model capacities were not verified for this profile.
• Automation reduces the nuance available for manual intervention on the day you want it.

Best fit

ISPs and hosting providers whose binding constraint is staffing rather than budget, and operators with a Juniper MX estate where router-enforced mitigation changes the economics.

Poor fit

Organisations whose primary requirement is application-layer depth, and teams that want fine-grained manual control during an incident.

POC questions

1. Run an attack outside business hours with nobody intervening, and measure what the automatic path actually achieved.
2. Measure the false-positive rate on replayed legitimate traffic during automatic mitigation.
3. If using router enforcement: test what a mitigation fault does to the router’s primary forwarding role.
4. Test a Layer 7 attack and establish precisely what the complement would need to cover.
5. Test at small packet sizes and record where behaviour changes.
6. Price both deployment shapes over five years, including the application-layer complement.

Sources