Defense Fabric deployment guide

What the software does

Defense Fabric runs detection, packet filtering and policy control on your servers. Local capacity depends on those servers and their links. It does not supply the upstream capacity of Peeryx protected IP transit.

Flow Collector is a separate free observation and diversion tool. It does not replace the Defense Fabric filtering engine. Peeryx transit is the separately delivered network service that can filter traffic upstream.

Server and operating system

The current installer targets Debian 12 and the distributed filtering plugin is for x86-64. TPM 2.0 is required for machine-bound licensing. The installer pins VPP and its plugins to 25.10-release; do not substitute another VPP ABI during an operating system upgrade.

• Provide independent management access, working DNS, a correct system clock and outbound HTTPS for enrollment, licence checks and signed updates.
• Confirm CPU, memory population, NUMA placement, PCIe lane width, exact adapter part number, firmware, driver and optics together. A ConnectX family name alone is not a compatibility validation.
• Keep server management separate from traffic interfaces. Reserve enough CPU, memory and storage for the engine, flow collection and evidence retention.

Sizing and performance evidence

Use Gbit/s and Mpps together. Ethernet at 100 Gbit/s with 64-byte frames reaches about 148.81 Mpps when preamble and inter-frame gap are included. This is a line-rate calculation, not a filtering result. Two ports do not guarantee double the end-to-end capacity.

The published hardware configurations are qualification candidates. No reproducible performance report is published for these configurations. Test the actual machine with the intended rule count, packet sizes, concurrent legitimate traffic and mitigation enabled. Record loss, latency and recovery as well as throughput.

Licences, ports and servers

The base licence includes one 10G port. Purchased ports form a shared pool across the licence’s managed servers; installing a second server does not duplicate that pool. Allocate the required port speed and count to each server before paid operation. The management limit is 128 servers per licence.

The 14-day trial has no software quota on port count or declared speed. It does not remove physical limits, hardware qualification or network activation requirements. Adding a server does not restart the trial.

Licence validity, server identity and routing readiness are separate checks. After the trial, payment and valid entitlements are required to continue licensed operation. The customer area shows the applicable expiry and renewal status.

Installation and enrollment

Start from the Defense Fabric page in your customer account. Create or select the subscription, add the server and generate its short-lived, single-use enrollment token. Use the installation instructions associated with that server; keep its identity and token private.

The installer checks Debian 12, TPM availability and the required VPP version. An unrelated active dataplane is a migration task: prepare a maintenance plan instead of installing over it. Signed release verification and successful enrollment do not prove that customer traffic is protected.

• Record the installed release and inspect the installation result.
• Confirm the panel connection, filtering engine, allocated ports and interface counters independently.
• Keep the server in observation until the forwarding and return paths have been tested.

Interfaces and the clean return path

Identify the ingress receiving traffic to filter and the separate logical interface returning clean traffic. Confirm VLANs, addresses, gateways, MTU and next-hop reachability on both the router and the filtering server. Linux management counters must not be mistaken for filtering-port counters.

Ensure diverted traffic cannot loop back into the dirty ingress. Control-plane and clean-gateway addresses must stay outside the protected destination ranges. Measure actual customer traffic in both directions before confirming a path as ready.

Inline, BGP diversion or hybrid

Inline: traffic continuously crosses the local filtering path. Validate behaviour when the server, interface or power fails; software installation alone does not create a physical bypass.

BGP diversion: the router sends selected attacked destinations to the filtering next hop. Define explicit import/export filters and communities, then verify announcements, FIB installation, clean return and withdrawal. Export delays and convergence affect response time.

Hybrid: combine local filtering with Peeryx protected transit when upstream mitigation is required. The transit service needs its own activation, authorised prefixes and a tested delivery path. Do not assume a licence purchase has changed your upstream routing.

BGP, FlowSpec and RTBH

Set the router ID, local and peer addresses, ASNs, reachable filtering next hop and agreed diversion community. The panel’s routing switch authorises agent-managed sessions and announcements; saving a draft is not confirmation that the router installed the intended route.

FlowSpec exports selective upstream rules only when enabled, simulation is off and the relevant BGP family is established. Start in dry-run, inspect generated rules and test your router’s capabilities and limits. The panel bounds the simultaneous rule count at 50.

RTBH is a last resort that discards all traffic to the affected destination, including legitimate traffic. Treat its threshold, persistence delay and withdrawal lease as separate controls, and test recovery.

sFlow, NetFlow and IPFIX

Enable collection on an address reachable by your authorised exporters, preferably a private network or VPN. The default receiver port is UDP 6343; match the configured port on both sides and restrict the exporter allowlist. Do not expose an unrestricted collector to the Internet.

Check sampling and exporter timeouts before choosing detection thresholds. sFlow carries its sampling rate; the configured multiplier applies to NetFlow/IPFIX when the exporter does not supply it. The collection window is configurable from 5 to 60 seconds.

Compare estimated rates with interface counters and check freshness. Missing exports are not evidence that traffic or attacks have stopped. Packet captures and flow estimates describe different observations.

Prefixes, thresholds and recovery

Protection policies use registered IPv4 /24 blocks and /32 exceptions inside them. Review the normal traffic pattern before applying a profile. Protocol and destination detection thresholds in this release are expressed in PPS; Gbit/s settings in FlowSpec and RTBH describe their separate capacity decisions.

Monitor observes without attack diversion. Automatic diverts during detected attacks. Permanent keeps the validated filtering path active. Set the exit threshold below the entry threshold and use a hold period to avoid repeated route changes during a fluctuating attack.

A profile loads protocol thresholds. It is not an application allowlist, and a stricter profile is not automatically appropriate for a busier network.

Adaptive rules and TCP/UDP protection

Adaptive detection can evaluate signatures in observation mode or apply generated rules in active mode. Inspect the recorded signature and its effect on legitimate traffic before excluding it or changing the backend. Backend availability must match the installed release and qualified hardware.

SYN proxy validates connection setup and requires a tested symmetric path. SYN challenge is intended for the supported asymmetric case. The controls are not interchangeable: the panel prevents incompatible combinations. SYNACK-specific validation also requires the documented symmetric path.

Source quotas apply UDP or combined SYN/SYNACK packet limits per source IP on opted-in prefixes. Shared NAT, VPN or proxy users can share one source address; their normal combined traffic must be included when selecting a quota.

Exceptions and post-filter firewall rules

Use /32 exceptions for specific hosts inside a registered /24. Keep those exceptions narrow and documented. A firewall accept rule applies at the post-filter firewall stage; it does not undo earlier packet drops or guarantee that all other protection checks are bypassed.

The panel accepts up to 20 ordered firewall priorities per prefix. Verify protocol, source range, destination ports and rate units before applying. TCP/UDP port selectors are not meaningful for every IP protocol.

Panel, reports and API access

Read the panel connection, engine status, BGP state and traffic-protection readiness separately. A connected agent or a running process is not a successful forwarding test. Recent statistics are sampled; a stale sample should be investigated rather than treated as zero traffic.

Attack history, recorded mitigation rules and available PCAP, ZIP or PDF evidence help explain an incident. Retention and packet sampling limit what can be reconstructed; an export is not necessarily a complete capture of an attack.

Read the public OpenAPI reference for the available operations and scopes. Operations require authentication: limit tokens to the required account and permissions. Policy writes use revisions and return a pending-application state; check node status before considering the change applied. Do not build automation against private panel internals.

Multiple servers and ECMP

A shared licence and a second server do not create automatic state replication or high availability. Define failure detection, route preference, withdrawal and recovery for the complete network design, then test each failure separately.

The supported second-link design uses directly connected iBGP with the same ASN and separate dirty/clean VLANs. It requires Fabric 2.8.0 or later. Each session uses its own local next hop. ECMP distributes flows; one flow may remain on one link.

SYN proxy and SYNACK challenge are not qualified for this dual-path mode. Two 100G links do not establish a 200 Gbit/s filtering guarantee.

Updates and configuration recovery

Use the signed update workflow provided in the panel. Plan a maintenance window: updating can restart the filtering engine. Confirm the expected version and keep an independent access path before starting.

The updater verifies the release, preserves configuration and prepares recovery files. If installation fails, inspect diagnostics and the restored state; do not assume a rollback also proves that every network path has recovered.

Before changing policies, preserve the relevant configuration and compare the proposed changes. Keep backups and credentials private. Validate the restored policy against the running software before returning diverted traffic to it.

Production acceptance checklist

Agree the acceptance test and rollback conditions before redirecting live services. Use traffic you are authorised to generate and a controlled test destination.

• Baseline: compare normal traffic, counters, loss and application reachability with protection inactive and active.
• Detection: test a bounded event and verify the intended destination, rule and route only.
• Recovery: stop the event, wait for the configured hold and confirm rule withdrawal and restored forwarding.
• Failure: test exporter loss, BGP loss and filtering-node loss separately. Confirm the observed path and whether the design fails open or closed.
• Record the release, server, NIC, packet sizes, rule count, sampling, test duration, loss and latency. Retain evidence of both success and rollback.

Diagnose the layer that failed

No panel contact: check management connectivity, DNS, clock, HTTPS access, identity and licence status. Do not change production BGP merely to restore the management connection.

Engine running but no protected traffic: inspect filtering interfaces, VLANs, next hops and actual RX/TX counters. Check the router FIB and clean return independently of the BGP session state.

Unexpected mitigation: compare the measured normal rate, sampling, selected profile and recorded rule. Adjust a saved draft, inspect the change and apply it deliberately. Collect diagnostics before restarting processes or removing routes.

Known boundaries

This guide describes the distributed Debian 12/x86-64 release and IPv4 protection workflow. It does not certify other operating systems, arbitrary NICs, IPv6 policy parity, lossless failover or a given Mpps result.

Local filtering cannot recover bandwidth already saturated upstream. Peeryx transit is a separate way to move the filtering boundary upstream; Flow Collector can support a separately validated on-demand design.

SYN-related features, ECMP and automatic routing each have compatibility requirements. Treat an untested combination as a qualification task, not as an enabled service.