Mitigation, BGP, and Recovery

Detection works without a response connector. Configure mitigation only when the organisation has an authorised network design, an approval policy, an independent verification method, and a tested rollback owner.

Choose an approval mode

Configure and verify a connector

Open Response & BGP. Supported connector designs include RouterOS RTBH, RouterOS local exact-host blackhole, a contracted scrubbing provider, blocklist, external BGP neighbour, and webhook. New connectors remain Pending until their external route, session, endpoint, or device state is verified.

Configure the ISPbills RouterOS peer

1. Select a connected RouterOS 7 device and choose Configure ISPbills BGP peer.
2. Review the router record, management endpoint, local and remote ASNs, BGP endpoint, and multihop design.
3. Allow the real peer endpoint on TCP/179 through cloud security groups, host firewalls, and NAT.
4. Wait until both RouterOS and the ISPbills speaker report Established.
5. Confirm that the active announcement count is zero before the first incident response.

The one-click setup creates a dedicated router instance, inbound exact-host blackhole policy, outbound deny policy, and eBGP multihop session. Setup does not announce an incident target. An approved incident can announce only the detected IPv4 /32 with blackhole community 65535:666; wider prefixes are rejected and the route is withdrawn at expiry.

Protect critical addresses

Add peering, point-to-point, authoritative DNS, management, monitoring, collector, BGP, and other essential addresses to the Mitigation allowlist. Detection can continue, but manual and automatic action against an excluded address is rejected.

The automatic safety perimeter also checks tenant router, OLT, switch, and radio management addresses, gateways, connector endpoints, and the full suspended-user pool. It is re-evaluated during proposal, approval, sensor claim, and final execution.

Propose the narrowest response

1. Confirm the exact target and that it remains inside protected scope.
2. Verify the connector is Ready and review its actual external state.
3. Choose the narrowest supported target and shortest practical duration.
4. Record expected customer impact and the rollback method.
5. Submit the request through the configured approval workflow.
6. Watch the incident timeline for claim, execution, expiry, cancellation, or failure.

Verify and recover

1. Confirm route, provider, blocklist, or device state independently from ISPbills.
2. Check BPS, PPS, FPS, packet loss, latency, and the affected service.
3. Watch for traffic shifting to another protected target or address family.
4. Withdraw or roll back through the same connector that applied the change.
5. Confirm the route or rule is gone and the service remains stable.
6. Mark the incident Resolved, preserve evidence, and record policy or runbook improvements.

Response troubleshooting

• Pending connector: verify the actual external endpoint, peer, route, or device state.
• BGP not established: check endpoint reachability, TCP/179, ASNs, multihop, NAT, firewall, and both peer states.
• Proposal rejected: check protected scope, mitigation exclusions, entitlement, permissions, connector readiness, and lifecycle state.
• No observed improvement: confirm execution independently, re-check the target and vector, and escalate to the upstream or scrubber without broadening scope blindly.
• Withdrawal incomplete: use the connector’s rollback path, inspect active route/rule state, and keep the incident open until removal is confirmed.

During an event, use the printable DDoS Protection → Runbook alongside the attack investigation guide.