Architecture guide
Choose where your protection should run.
Describe the service and the part of the network you want to control. The guide identifies a starting architecture, explains the selection and lists what still needs to be checked.
Your choices have changed. Select “Compare architectures” to update the result.
Suggested starting point
Protected IP Transit
An orientation based on your answers; it is not a quote, routing authorization or a qualified performance result.
Why this selection
You want traffic filtered on the Peeryx network and delivered to your infrastructure. Protected IP Transit supplies that network service under its own terms.
Indicative traffic path
- Internet
- Peeryx protected network
- Your network and services
This is a design outline, not a configuration applied to your network. Link capacity, return routing and failure behaviour need separate validation.
Before deployment 3
- Confirm the integration with the technical team. This guide does not approve a deployment or change live traffic.
- Qualify the delivery endpoint, encapsulation, MTU, return route and failover before moving production traffic.
- Clarify which public addresses must remain reachable and who can authorize their announcements before choosing the routing model.
Inputs used for this result
- What needs protection?
- A network or IP prefixes
- What do you want to operate?
- Protection on the Peeryx network
- Do you have an ASN?
- Not sure
- Do you control your own public IP prefixes?
- Not sure
- When should Peeryx carry the protected traffic?
- Continuously
Explore the components
How the selection works
The rules choose a component by its role. They do not score vendors, approve prefixes or turn a port speed into a software benchmark.
| Requirement | Starting point |
|---|---|
| FiveM or Minecraft Java | The corresponding specialized game product, subject to origin and protocol checks. |
| Another game | Technical review; no unsupported application-filtering claim. |
| Network + local filtering | Defense Fabric; your server, NICs and links must be qualified. |
| Network + remote protection | Protected IP Transit; addressing and delivery determine the routing model. |
| Network + hybrid filtering | Defense Fabric plus protected IP Transit, with separate software and network conditions. |
| Remote/hybrid + on demand + declared ASN and prefixes | Add Flow Collector as a candidate for an authorized IPv4 /24 diversion workflow. Otherwise review routing first. |
| Observation and detection | Free Flow Collector outside the forwarding path. |
| Virtual routing endpoint | Router VM, within its documented resources and traffic limits. |
Questions about the guide
Does a 100G port qualify a filtering server?
No. It identifies the physical link rate. NICs, PCIe, memory, packet sizes, rules and failure conditions determine the measured processing limit.
Can local software protect an already saturated access circuit?
Filtering downstream of the bottleneck cannot restore packets that never arrived. Check upstream mitigation and ingress capacity as part of the design.
Does free Flow Collector include free protected Transit?
No. The collector software is free. A Peeryx network service used for protection remains subject to its own commercial and routing conditions.
Does this result authorize my BGP announcements?
No. Answers about ASN and prefixes are declarations. Ownership, origin, announcement policy and the delivery/return paths still require validation.