Configure Telemetry and Protected Scope
Declare authorised networks, connect RouterOS or external flow telemetry, verify source health, and activate monitoring.
On this page
Reliable DDoS detection starts with an accurate network profile, authorised protected prefixes, and independently observed flow records. Complete these steps in DDoS Protection → Setup and Telemetry.
Complete the network profile
Enter the organisation name, monitored capacity, baseline learning window, and NOC notification email. Add the local ASN when BGP response or routing-context analysis is planned. The first observation of an attack creates an in-product owner alert and queues a summary to the NOC address.
Declare the protected scope
Add only public or private IPv4 or IPv6 space the organisation owns or is authorised to monitor. Enter a CIDR or one host; a host is stored as IPv4 /32 or IPv6 /128.
- Subscriber and service address space
- Infrastructure and management ranges
- Point-to-point, transit, and peering segments
- Private service networks that should be monitored
Protected scope defines where detection and an approved exact-host response are permitted. Adding an address does not announce, block, or scrub it, and protected scope is not the mitigation allowlist.
Add a telemetry source
Open Telemetry and define each source by type, name, site, exporter address, and listen port where applicable. Supported source types are:
- sFlow
- NetFlow v5 and NetFlow v9
- IPFIX
- SPAN or mirrored traffic observed by a managed sensor
- AWS VPC Flow Logs
- Google Cloud VPC Flow Logs
Configure a connected RouterOS device
- Open Telemetry and choose Configure Traffic Flow in one step.
- Select the connected router and NetFlow v5/v9 or IPFIX.
- Review the read-only managed collector address, reserved port, and six-character service ID.
- Apply the configuration through the saved RouterOS API connection.
- Wait for ISPbills to decode a real flow record before treating the source as healthy.
RouterOS API 8728 and API-SSL 8729 are supported. The managed collector keeps exporter templates and baseline state separate and refreshes NetFlow v9 templates for prompt recovery.
Connect a self-managed sensor
sFlow, SPAN, and cloud-log sources require a deployed sensor or adapter that normalises observations into the authenticated sensor contract. Reveal or rotate the optional sensor token only when a tenant-operated collector needs it, copy it directly into a secret manager, and remember that rotation invalidates the previous token immediately.
Read source health correctly
| State | Meaning and action |
|---|---|
| Pending | The definition is saved, but no decoded record has been verified. Check exporter settings, credentials, address, port, NAT, and firewall path. |
| Healthy | Decoded records are current. Confirm the displayed exporter, latest flow rate, and verification time match the intended source. |
| Stale | Records stopped arriving. Check the exporter, sensor process, templates, clocks, and network reachability. |
| Degraded profile | No reliable current source remains. Restore telemetry before relying on detections or an empty attack queue. |
A successful RouterOS API call or an arriving UDP packet alone is not healthy telemetry. ISPbills waits for a decoded flow record or a successful adapter report.
Activate monitoring
After protected scope, telemetry, and all required detection policies are ready, review the setup checklist and select Activate monitoring. Activation starts baseline learning and policy evaluation; it does not execute a response connector. During the learning window, detections can depend more heavily on absolute thresholds.
Telemetry checklist
- The displayed exporter and site match the intended device.
- The last verified record time is recent and continues to advance.
- BPS, PPS, and FPS values are plausible when compared with interface counters.
- IPv4 and IPv6 sources are represented where both address families are protected.
- Collector credentials and sensor tokens are stored outside tickets and chat.