How to configure Voxility with
a custom BGP adapter on Flowtriq

Back to Blog

What Is Voxility?

Voxility is a DDoS protection and infrastructure provider headquartered in London, widely used by hosting companies, ISPs, and enterprises across Europe and beyond. They operate a global scrubbing network with over 1 Tbps of scrubbing capacity spread across multiple PoPs in Europe, North America, and Asia.

Their mitigation model is BGP-based: when an attack is detected, you announce your IP prefixes to Voxility via BGP. Voxility advertises those prefixes upstream, attracting all traffic through their scrubbing centers. Clean traffic is tunneled back to your origin via GRE or direct cross-connect. This is the same model used by other major scrubbing providers like Cloudflare Magic Transit and Akamai Prolexic, but Voxility is particularly popular in the European hosting market due to competitive pricing and flexible peering arrangements.

Why Pair Voxility with Flowtriq?

Voxility scrubs traffic. Flowtriq detects attacks. On their own, Voxility requires either manual intervention or their own detection (which may not align with your thresholds). By connecting Flowtriq to Voxility through a custom BGP adapter, you get a fully automated pipeline: Flowtriq detects an attack within 1-2 seconds, triggers a BGP announcement to Voxility, and scrubbing begins - all without a human touching anything.

This integration lets you keep Voxility in standby mode (not scrubbing) during normal traffic, and only swing traffic through their scrubbing centers when Flowtriq confirms a real attack. This avoids unnecessary latency during peacetime and reduces costs if your Voxility contract is usage-based.

Prerequisites

Before you begin, make sure you have the following:

• Voxility account with BGP peering: You need an active Voxility contract that includes BGP-based DDoS protection. Contact Voxility sales if you only have their proxy-based protection.
• IP prefix assignment: You must own or have a LOA (Letter of Authorization) for the IP prefixes you want Voxility to protect. Voxility needs to register these prefixes in their IRR records.
• BGP peering details from Voxility: ASN, peering IPs, MD5 password (if used), and the specific BGP community strings for triggering and releasing scrubbing.
• An edge router or VM capable of running ExaBGP or GoBGP: This is your BGP adapter - the software that announces and withdraws routes to Voxility on demand.
• A Flowtriq workspace: With at least one node deployed and monitoring the prefixes you want to protect.
• Network connectivity to Voxility's peering routers: Either via direct cross-connect, tunnel, or internet-routed BGP session (depending on your Voxility setup).

Step 1: Obtain Voxility BGP Details

Log in to the Voxility customer portal and navigate to your DDoS protection service. You need the following details:

Voxility BGP Peering Details (example)
──────────────────────────────────────────────
Voxility ASN:           AS 3223
Your ASN:               AS 65100 (your network)
Peering IPv4:           185.x.x.1 (Voxility side)
Your Peering IPv4:      185.x.x.2 (your side)
MD5 Password:           (provided by Voxility)

BGP Community Strings:
  Scrub traffic:        3223:666
  Release (stop scrub): withdraw the route
  Selective scrub:      3223:100 (scrub only, no blackhole)

Protected Prefixes:
  203.0.113.0/24
  198.51.100.0/24

Voxility also provides an API for some operations. The relevant endpoints:

# Voxility API (if enabled on your account)
# Base URL: https://api.voxility.com/v1

# Check protection status
GET /protection/status?prefix=203.0.113.0/24
Authorization: Bearer YOUR_VOXILITY_API_KEY

# View active scrubbing sessions
GET /protection/scrubbing
Authorization: Bearer YOUR_VOXILITY_API_KEY

The API is useful for monitoring but the actual mitigation triggering is done via BGP, not the API. The BGP adapter is the critical piece.

Step 2: Configure Your Edge Router with ExaBGP or GoBGP

The BGP adapter is a lightweight BGP speaker that runs on a server or VM in your network. It establishes a BGP session with Voxility and announces or withdraws routes on command. ExaBGP and GoBGP are the two most common choices.

Option A: ExaBGP Configuration

ExaBGP is a Python-based BGP implementation designed specifically for route injection and manipulation via external processes. It is ideal for this use case because it can be controlled by shell scripts, HTTP APIs, or any process that writes to stdin.

# /etc/exabgp/exabgp.conf

process announce-routes {
    run /etc/exabgp/handler.sh;
    encoder text;
}

neighbor 185.x.x.1 {
    description "Voxility scrubbing peer";
    router-id 185.x.x.2;
    local-address 185.x.x.2;
    local-as 65100;
    peer-as 3223;
    md5-password "your-md5-password";
    hold-time 90;

    family {
        ipv4 unicast;
    }

    api {
        processes [ announce-routes ];
    }
}

The handler script listens for commands and announces or withdraws routes:

#!/bin/bash
# /etc/exabgp/handler.sh
# This script is called by ExaBGP's process API.
# It reads commands from a named pipe to announce/withdraw routes.

PIPE="/var/run/exabgp/control.pipe"

mkfifo "$PIPE" 2>/dev/null

while true; do
    if read -r cmd < "$PIPE"; then
        case "$cmd" in
            announce:*)
                PREFIX="${cmd#announce:}"
                echo "announce route ${PREFIX} next-hop self community [3223:666]"
                ;;
            withdraw:*)
                PREFIX="${cmd#withdraw:}"
                echo "withdraw route ${PREFIX} next-hop self"
                ;;
        esac
    fi
done

To trigger scrubbing for a prefix, write to the named pipe:

# Trigger Voxility scrubbing for 203.0.113.0/24
echo "announce:203.0.113.0/24" > /var/run/exabgp/control.pipe

# Release scrubbing (withdraw the route)
echo "withdraw:203.0.113.0/24" > /var/run/exabgp/control.pipe

Option B: GoBGP Configuration

GoBGP is a Go-based BGP implementation that provides a gRPC API and CLI for route management. It is a good choice if you prefer a more structured API or need IPv6 support alongside IPv4.

# /etc/gobgp/gobgpd.conf (TOML format)

[global.config]
  as = 65100
  router-id = "185.x.x.2"

[[neighbors]]
  [neighbors.config]
    neighbor-address = "185.x.x.1"
    peer-as = 3223
    auth-password = "your-md5-password"

  [neighbors.timers.config]
    hold-time = 90
    keepalive-interval = 30

  [[neighbors.afi-safis]]
    [neighbors.afi-safis.config]
      afi-safi-name = "ipv4-unicast"

With GoBGP, you control route announcements via the CLI or gRPC API:

# Start GoBGP daemon
sudo gobgpd -f /etc/gobgp/gobgpd.conf &

# Announce a prefix to Voxility with scrubbing community
gobgp global rib add 203.0.113.0/24 \
  community 3223:666 \
  -a ipv4

# Verify the route is announced
gobgp global rib -a ipv4

# Check BGP session status
gobgp neighbor 185.x.x.1

# Withdraw the prefix (release scrubbing)
gobgp global rib del 203.0.113.0/24 -a ipv4

Step 3: Set Up the BGP Adapter in Flowtriq

Now that your BGP speaker is running and peered with Voxility, you need to connect it to Flowtriq so that attack detections automatically trigger route announcements.

In your Flowtriq dashboard, navigate to Mitigation and create a new auto-mitigation rule:

1. Click Add Rule and select BGP Announcement as the action type.
2. Set the adapter type to "Custom BGP (ExaBGP)" or "Custom BGP (GoBGP)" depending on your setup.
3. Configure the connection details:
   • ExaBGP: Set the control method to "Named Pipe" and specify the pipe path (/var/run/exabgp/control.pipe) or use the HTTP API if you have ExaBGP's built-in HTTP server enabled.
   • GoBGP: Set the control method to "gRPC" and provide the GoBGP server address (e.g., 127.0.0.1:50051).
4. Set the BGP community to 3223:666 (Voxility scrubbing community).
5. Define the protected prefixes - these should match the prefixes registered with Voxility.
6. Set the auto-withdraw timer to automatically release scrubbing after the attack subsides (recommended: 30-60 minutes after traffic normalizes).

If your Flowtriq node and BGP adapter run on different machines, use the webhook integration instead. Configure a webhook that calls a small HTTP API on the adapter machine, which then writes to the ExaBGP pipe or calls the GoBGP gRPC endpoint.

Step 4: Configure Escalation Thresholds

Not every spike in traffic warrants swinging all your traffic through Voxility's scrubbing centers. Configure your escalation thresholds carefully to avoid false triggers while still catching real attacks fast.

Recommended starting thresholds for Voxility BGP activation:

• PPS threshold: 500,000 packets per second sustained for 5+ seconds. Most legitimate traffic spikes do not sustain this level.
• BPS threshold: 2 Gbps sustained for 5+ seconds. Adjust based on your normal traffic baseline and link capacity.
• Attack classification: Trigger only on volumetric attack types (UDP flood, SYN flood, DNS amplification, NTP amplification, memcached amplification). Do not trigger Voxility for application-layer attacks like HTTP floods - those require L7 mitigation.
• Cooldown period: After withdrawing a route, wait at least 15 minutes before allowing a re-trigger. This prevents route flapping if the attack comes in waves.

In Flowtriq's mitigation settings, configure the escalation policy:

# Example escalation policy (configured in Flowtriq UI)
──────────────────────────────────────────────────────
Trigger Condition:
  ANY of:
    - PPS > 500,000 for 5 seconds
    - BPS > 2,000,000,000 for 5 seconds
  AND:
    - Attack type IN [udp_flood, syn_flood,
      dns_amplification, ntp_amplification,
      memcached_amplification, cldap_amplification]

Action:
  BGP Announce → Voxility (community 3223:666)
  Prefix: auto (match attacked prefix from node config)

Auto-Withdraw:
  When attack traffic < 10% of threshold for 30 minutes

Cooldown:
  15 minutes after withdraw before re-trigger allowed

Step 5: Test and Verify the Integration

Before relying on this integration in production, test every component of the chain.

Verify BGP Session

Confirm that your BGP adapter has an established session with Voxility:

# ExaBGP: check the log output
tail -f /var/log/exabgp/current | grep -i "state"
# Look for: "neighbor 185.x.x.1 up"

# GoBGP: check neighbor status
gobgp neighbor 185.x.x.1
# State should be "ESTABLISHED"
# Received routes and advertised routes should show counts

Test Route Announcement

Manually trigger a route announcement and verify it reaches Voxility:

# Announce a test prefix (use one of your registered prefixes)
# ExaBGP:
echo "announce:203.0.113.0/24" > /var/run/exabgp/control.pipe

# GoBGP:
gobgp global rib add 203.0.113.0/24 community 3223:666 -a ipv4

# Verify via Voxility portal or API
curl -s -H "Authorization: Bearer YOUR_API_KEY" \
  https://api.voxility.com/v1/protection/status?prefix=203.0.113.0/24

# Withdraw the test route immediately
# ExaBGP:
echo "withdraw:203.0.113.0/24" > /var/run/exabgp/control.pipe

# GoBGP:
gobgp global rib del 203.0.113.0/24 -a ipv4

End-to-End Test

Use Flowtriq's built-in test functionality (available in the Mitigation page) to simulate an attack detection and verify the full chain fires correctly: Flowtriq detects the simulated event, sends the trigger to the BGP adapter, the adapter announces the route to Voxility, and Voxility activates scrubbing. Then verify that the auto-withdraw works after the simulated event clears.

Monitor the following during testing:

• Flowtriq incident timeline: confirm the incident is created and the mitigation action is logged.
• BGP adapter logs: confirm the route was announced with the correct community.
• Voxility portal: confirm scrubbing activated for the correct prefix.
• Latency: measure round-trip latency to your protected IPs during scrubbing. Expect 5-20ms additional latency depending on your distance to the nearest Voxility scrubbing center.
• Auto-withdraw: confirm the route is withdrawn and scrubbing stops after the configured timer expires.

Voxility-Specific Notes

• Minimum prefix size: Voxility typically requires a /24 as the minimum prefix size for BGP announcements. You cannot announce a single /32 for scrubbing the way you would for a standard RTBH blackhole. Plan your IP allocation accordingly.
• GRE tunnel MTU: If Voxility returns clean traffic via GRE tunnel, your effective MTU drops to 1476 bytes (1500 minus 24 bytes of GRE overhead). Make sure your servers handle this with MSS clamping or path MTU discovery.
• Asymmetric routing: During scrubbing, inbound traffic routes through Voxility but outbound traffic goes directly to the internet via your normal upstream. This is expected and correct, but make sure your firewall rules do not drop return traffic due to asymmetric path enforcement (disable uRPF strict mode on the protected interface during scrubbing).
• Scrubbing profiles: Some Voxility contracts let you define scrubbing profiles (e.g., aggressive vs. conservative filtering). These are typically configured through the Voxility portal, not via BGP communities. Set your profiles before going live.
• Contract limits: Verify your Voxility contract's clean traffic allowance. Scrubbed traffic above your contracted clean bandwidth may be throttled or incur overage charges.

Troubleshooting

BGP Session Not Establishing

• Check connectivity: Ping or traceroute to the Voxility peering IP. If you are peering over a tunnel, verify the tunnel is up.
• Verify ASN and peering IPs: Double-check that your local-as, peer-as, local-address, and neighbor-address match exactly what Voxility provided.
• MD5 authentication: MD5 password mismatches silently drop BGP packets. Verify the password character-by-character. Look for trailing whitespace or encoding issues.
• Firewall rules: Ensure TCP port 179 is open in both directions between your BGP adapter and the Voxility peering IP.
• Hold timer mismatch: If Voxility's hold timer is significantly different from yours, the session may fail to negotiate. Use a hold-time of 90 seconds as a safe default.

Route Announced but Scrubbing Not Activating

• Community string: Verify you are sending the correct community. Use gobgp global rib -a ipv4 or check ExaBGP logs to confirm the community is attached to the announcement.
• Prefix not registered: Voxility will ignore announcements for prefixes not registered in their system. Confirm your prefixes are listed in the Voxility portal under your protection profile.
• IRR / RPKI issues: If Voxility validates routes against IRR or RPKI, make sure your ROA (Route Origin Authorization) records are correct and your prefix is registered in the appropriate IRR database (e.g., RIPE, ARIN).

Flowtriq Not Triggering the Adapter

• Threshold too high: Lower your thresholds temporarily and generate test traffic to confirm the detection-to-mitigation pipeline works.
• Connectivity: If using the webhook method, verify the Flowtriq node can reach the adapter's HTTP endpoint. Check firewall rules and test with curl from the node.
• Named pipe permissions: If using ExaBGP with a named pipe, ensure the Flowtriq process has write permission to the pipe file.
• Check Flowtriq audit log: The audit log in your dashboard shows all mitigation actions, including failures. Look for error messages related to the BGP adapter.

Route Flapping

• Increase cooldown: If the route is being announced and withdrawn repeatedly, increase the cooldown period and auto-withdraw timer.
• Hysteresis: Set the withdraw threshold significantly lower than the trigger threshold (e.g., trigger at 500K PPS, withdraw when below 50K PPS for 30 minutes). This prevents oscillation when attack traffic hovers near the threshold.

With everything configured and tested, your Flowtriq + Voxility integration provides automated, sub-10-second DDoS mitigation for volumetric attacks. Flowtriq handles the detection, classification, and decision-making; Voxility handles the scrubbing at scale.

Ready to set this up? Start your free 7-day Flowtriq trial and configure your first BGP adapter today.

Back to Blog

Related Articles