On this page
Key points
- Describe your servicePrefixes, protocols, normal peaks and operating constraints make a quotation comparable.
- Separate the capacity claimsTransport, packet processing and the connection delivered to you are different limits.
- Agree on acceptanceDefine the observations, failure scenarios and responsibility for recovery before activation.
Use one requirements sheet for every proposal
A useful request starts with what has to remain available. List the services, address families, protected prefixes or public endpoints, normal busy-hour traffic and where users connect from. State whether you control an ASN and prefixes, whether routing can change, and which organization operates the final server. A supplier can then distinguish network protection from a protocol-specific proxy or filtering software installed on your equipment.
Keep the first exchange short. For an initial review, provide the service type, approximate traffic, delivery constraints and a contact. Detailed routing policy, hardware inventory and incident evidence can follow through an agreed channel. Credentials, private keys and unredacted customer captures do not belong in a public enquiry form.
| Requirement | Useful information | Question for the supplier |
|---|---|---|
| Addressing and routing | ASN, authorized prefixes, IPv4/IPv6 and current providers. | What may you announce, and what is validated before delivery? |
| Traffic and applications | Normal Gbit/s, Mpps, connection behavior and required protocols. | Which functions apply to this workload, and which do not? |
| Delivery | Tunnel or physical handoff, location and return-path constraints. | What bandwidth, MTU and routing parameters apply to each path? |
| Operations | Who owns routers, servers, monitoring and on-call response. | Who changes policy, confirms recovery and rolls back a failed change? |
Put every capacity figure next to its boundary
A shared network absorption figure is not a reservation on your circuit. A server benchmark is not the capacity of every licensed configuration. A 100 Gbit/s interface is not proof that its host can process minimum-size packets with the proposed rules. Ask where a value was measured, in which direction, with which traffic and whether the limit is physical, licensed, shared or contractual.
If a bid gives a throughput figure, request the frame-size convention, packet rate, traffic distribution, active features, hardware and software version. A large-frame forwarding result cannot establish small-packet filtering capacity. The performance of one receive queue also cannot be inferred from average CPU utilization. These are questions about comparability, not reasons to reject hardware or software as a category.
Draw normal, protected and return traffic
The diagram should show where traffic is observed, where it is steered, where unwanted traffic is dropped and how the remainder reaches your service. Include the return direction. A feature that checks connection state may require both directions to reach the same state owner or a supported state-sharing arrangement. A route collector, diversion controller and inline filtering engine are not interchangeable components.
For redundant delivery, identify shared routers, physical links, power and upstream dependencies. Two tunnels can have different addresses and still terminate on one router. Ask what happens when a session fails, when an interface fails and when the device itself is lost. A backup design is qualified by its tested failure domain, not by the number of green BGP indicators.
Write an acceptance plan with the supplier
Choose measurable acceptance conditions for your application. A route being installed or an attack counter increasing is useful evidence, but neither proves that users can complete transactions. Record failed connections, response time and expected traffic alongside mitigation counters.
Do not run disruptive laboratory throughput benchmarks across a production network. RFC 6815 explains why RFC 2544 benchmarking assumptions do not fit a live shared network. Operational acceptance on a live service needs an agreed, bounded procedure; destructive load belongs in a separate environment.
Prove normal operation
Record application success, latency, route selection and counters before protection changes.
Exercise the delivered path
Check the agreed address families, small and large exchanges, MTU behavior and both traffic directions.
Validate filtering in isolation
Agree on authorized traffic, thresholds and expected legitimate behavior in an isolated test environment.
Exercise recovery
Verify withdrawal, backup forwarding, return to the preferred path and the owner of each rollback action.
Read the operating terms as carefully as the feature list
Ask what the monthly price includes, what starts an overage charge, which statistics are used and how the billing period is defined. Separate committed traffic, access speed, burst allowance, protected address count, software capacity and optional support. A percentile calculation, a sampled peak and a port speed describe different things.
An SLA must identify the covered service, measurement point, exclusions and remedy. A support response target is not automatically a restoration guarantee. Request the escalation route, approval rules for emergency filters, procedure for false positives and evidence available after an incident. These points belong in the actual proposal or contract; a marketing badge does not establish them.
Compare equivalent deployment models
Compare a managed network service with its delivery and operating scope; compare a software licence with the servers, interfaces, transport and staffing it needs. A component price can be entirely reasonable while covering only one part of the traffic path. Keep detection, orchestration, enforcement and network capacity in separate columns so that a missing layer remains visible.
For Peeryx, protected Transit IP, Defense Fabric and Flow Collector serve different roles. Defense Fabric licenses filtering on a compatible deployment; it does not include a dedicated allocation of the shared Peeryx network capacity. Flow Collector observes telemetry and can control authorized diversion; it is not an inline packet filter. Gaming delivery requires review for the supported application.
Record unknowns before approving the purchase
For each requirement, record the supplier’s answer, supporting document, acceptance test and unresolved condition. Mark a missing measurement as unknown rather than turning it into a performance estimate. This makes the remaining engineering work visible and gives both teams a useful handover after the sale.
A small approved pilot can answer a specific compatibility question. It does not prove unlimited capacity, every attack family or every recovery scenario. Carry untested conditions into the production acceptance record instead of silently treating a successful pilot as complete qualification.
Questions before signing
Is a larger advertised Tbit/s figure always better?
It may describe more shared network capacity, but it does not establish your delivered bandwidth, reserved resources, packet workload or application coverage. Compare those separately.
What is the smallest useful first enquiry?
State the service, normal traffic, addresses or routing model and the main delivery constraint. Add the detailed inventory after the initial scope is agreed.
Can a trial replace a technical acceptance plan?
No. A trial can validate defined conditions. The evidence, failure scenarios and remaining unknowns still need to be recorded.
