Skip to content
AS213382 / PEERYX NETWORKUnder attack?Contact the network team
PEERYXNETWORK
Discuss this architecture

Deployment requirements

DDoS protection for datacenters and colocation

A datacenter design has to connect network protection to real interfaces, customer routing and shared failure domains. Port speed, local filter performance and upstream service capacity each need their own acceptance boundary.

Discuss this architecture Compare deployment options
An aisle between server racks in a data center.
Illustrative photograph · Brett Sayles / Pexels

Make the physical and operational boundaries explicit

A handoff includes more than a port speed
Interface type, optics, VLAN, addressing, MTU, route policy and location affect whether a delivery is usable. Physical availability and setup costs need review for the requested site; an online calculator does not confirm a cross-connect.
Redundancy can share a hidden dependency
Different tunnel addresses or server names may still rely on one router, switch, power feed or upstream. Document the failure domain the design must survive before counting a second path as independent capacity.
Several tenants share the protected edge
Colocation customers may control their own routers and announcements. Agree on prefix authorization, policy responsibility and the point where traffic is handed back. A mitigation counter on one device does not establish service availability in every rack.

Design the handoff and the remaining capacity together

Upstream protected delivery and local filtering can be combined where the deployment is compatible. Size the surviving path as carefully as the normal path, including ingress and egress ports and the operating reserve.

  1. Confirm the site and interface

    Review location, access options, physical parameters and who supplies the cross-connect or tunnel.

  2. Qualify the filtering path

    Measure the chosen hardware and policy with a stated packet workload; keep interface speed separate from that result.

  3. Hand traffic to the right tenant

    Validate permitted routes, return traffic and the tenant’s application at the agreed responsibility boundary.

Illustrative deployment sequence. The quotation and acceptance record define the delivered service.

Resolve these items in the delivery record

Which capacity remains after the required failure?
Account for paired interfaces, spare nodes, headroom and shared transport. A standby server is not additional active capacity when it must remain available for recovery.
Which MTU applies to each path?
Use the value delivered for that complete path. Extra encapsulation and different underlays can make primary and backup tunnels require different MTUs.
Who can change route and filter policy?
Document approvals, customer scope, rollback access and escalation ownership across the datacenter, protection operator and tenant. Those responsibilities should not be inferred from device ownership alone.

Accept the complete delivery, not just link-up

  • Check actual interfaces, VLANs, addressing and accepted routes against the delivery document.
  • Validate useful traffic in both directions with representative packet sizes and the intended protection mode.
  • Coordinate the agreed component failure, observe convergence and application recovery, and record untested limits.

Questions for this deployment

Does a 400-Gbit/s port prove 400-Gbit/s filtering?

No. The interface is one limit. Filtering must be qualified with the actual hardware, packet distribution and active features; no server result follows from the port label.

Can two tunnels on one router prove router redundancy?

No. They can provide different paths but share that device. Qualification must cover the failure domain the service is intended to survive.