BGP Setup Guide

Remote Triggered Black Hole (RTBH) routing is the BGP-based method Spectops uses to drop malicious traffic at your network edge before it reaches protected resources. The service sends BGP route announcements for IP addresses/prefixes that should be suppressed, tagged with a well-known BGP community.

How It Works

1. The service aggregates threat intelligence from multiple sources
2. Malicious IPs are announced via BGP to your router
3. Your router installs these routes pointing to a null interface (blackhole)
4. Traffic to/from those IPs is dropped at the edge

• BGP-capable router - Cisco, Juniper, Nokia, MikroTik, VyOS, BIRD, etc.
• Public IP address - For BGP peering with the RTBH service
• ASN - Your Autonomous System Number (must be registered to you)
• Firewall access - TCP port 179 open to peering IP (203.0.113.1)
• Route filtering configured - Accept only blackhole-tagged routes

1. Log in and go to Sessions
2. Click "Create Session"
3. Fill in the configuration:

After creating the session, note the assigned peering IP.

Configure BGP peering on your router. Replace placeholder values:

• YOUR_ASN - Your ASN (e.g., 65000)
• PEERING_IP - 203.0.113.1 (or 2001:db8:100::1 for IPv6)
• PEERING_ASN - 49094
• YOUR_ROUTER_IP - Your router's BGP IP
• MD5_PASSWORD - Shared MD5 password (if configured)

Cisco IOS / IOS-XE

! Create null route interface for blackhole
ip route 192.0.2.1 255.255.255.255 Null0

! Route-map to set next-hop to null
route-map RTBH-IN permit 10
 match community BLACKHOLE
 set ip next-hop 192.0.2.1
 set local-preference 200

! Community list for blackhole
ip community-list standard BLACKHOLE permit 65535:666

! BGP configuration
router bgp YOUR_ASN
 neighbor 203.0.113.1 remote-as 49094
 neighbor 203.0.113.1 description RTBH Feed
 neighbor 203.0.113.1 password MD5_PASSWORD
 neighbor 203.0.113.1 soft-reconfiguration inbound
 !
 address-family ipv4 unicast
  neighbor 203.0.113.1 activate
  neighbor 203.0.113.1 route-map RTBH-IN in
  neighbor 203.0.113.1 prefix-list RTBH-PREFIXES in
 !
 address-family ipv6 unicast
  neighbor 2001:db8:100::1 activate
  neighbor 2001:db8:100::1 route-map RTBH-IN in

! Allow /32 routes only (host routes)
ip prefix-list RTBH-PREFIXES seq 10 permit 0.0.0.0/0 ge 32 le 32

Juniper JunOS

# Static discard route for blackhole next-hop
routing-options {
    static {
        route 192.0.2.1/32 discard;
    }
}

# Policy to accept blackhole routes
policy-options {
    community BLACKHOLE members 65535:666;
    
    policy-statement RTBH-IN {
        term accept-blackhole {
            from {
                community BLACKHOLE;
                route-filter 0.0.0.0/0 prefix-length-range /32-/32;
            }
            then {
                next-hop 192.0.2.1;
                local-preference 200;
                accept;
            }
        }
        term reject-all {
            then reject;
        }
    }
}

# BGP configuration
protocols {
    bgp {
        group rtbh-feed {
            type external;
            peer-as 49094;
            local-address YOUR_ROUTER_IP;
            import RTBH-IN;
            authentication-key "MD5_PASSWORD";
            neighbor 203.0.113.1 {
                description "RTBH Feed";
                family inet {
                    unicast;
                }
            }
            neighbor 2001:db8:100::1 {
                description "RTBH Feed IPv6";
                family inet6 {
                    unicast;
                }
            }
        }
    }
}

MikroTik RouterOS

# Create blackhole route
/ip route add dst-address=192.0.2.1/32 type=blackhole

# BGP peer configuration
/routing/bgp/connection add
  name=rtbh-feed
  remote.address=203.0.113.1
  remote.as=49094
  local.role=ebgp
  router-id=YOUR_ROUTER_IP
  routing-table=main
  address-families=ip
  as=YOUR_ASN
  tcp-md5-key=MD5_PASSWORD

# Filter to accept only /32 with blackhole community
/routing/filter/rule add
  chain=bgp-in-rtbh
  rule="if (bgp-communities includes 65535:666 && dst-len == 32) { 
    set gw 192.0.2.1; 
    accept; 
  } else { 
    reject; 
  }"

BIRD 2.x

# Define blackhole next-hop
protocol static blackhole_nh {
    ipv4;
    route 192.0.2.1/32 blackhole;
}

# Filter for RTBH routes
filter rtbh_import {
    # DOC-H1 FIX: Accept /24 through /32 — RTBH may announce larger prefixes, not just host routes.
    # Previous filter only accepted net.len = 32 (host routes), silently dropping valid /24-/31 routes.
    if (65535, 666) ~ bgp_community && net.len >= 24 && net.len <= 32 then {
        bgp_next_hop = 192.0.2.1;
        bgp_local_pref = 200;
        accept;
    }
    reject;
}

# BGP session for RTBH feed
protocol bgp rtbh_feed {
    local YOUR_ROUTER_IP as YOUR_ASN;
    neighbor 203.0.113.1 as 49094;
    password "MD5_PASSWORD";
    
    ipv4 {
        import filter rtbh_import;
        export none;
    };
    ipv6 {
        import filter rtbh_import;
        export none;
    };
}

In Dashboard

1. Log in and go to Sessions
2. Check the session state - should be "UP"
3. View the number of prefixes being advertised

On Your Router

Verify the session is established and routes are received:

Cisco:

show ip bgp summary
show ip bgp neighbor 203.0.113.1
show ip bgp neighbor 203.0.113.1 received-routes

Juniper:

show bgp summary
show bgp neighbor 203.0.113.1
show route receive-protocol bgp 203.0.113.1

MikroTik:

/routing/bgp/session print
/ip/route print where bgp

Session Won't Establish

• Verify IP connectivity: ping 203.0.113.1
• Check firewall allows TCP port 179 in both directions
• Verify ASN matches on both sides (peer AS: 49094)
• Confirm MD5 password is identical (if configured)
• Check router logs for BGP errors

Session Up But No Routes

• Ensure blocklist sources are bound to the session
• Verify import filter isn't rejecting all routes
• Check community matching is correct (65535:666)
• Look at received routes before filtering

Routes Not Being Installed

• Verify the blackhole next-hop (192.0.2.1) has a route to Null0/discard
• Check route-map is setting next-hop correctly
• Ensure prefix-list allows the received prefix lengths

Contact Support

If you're still having issues, contact support with:

• Session ID from the dashboard
• Router type and version
• BGP logs/debug output
• Current configuration (sanitized)

What is a Flap?

A flap is recorded each time a BGP session transitions from DOWN → UP. Frequent flaps indicate an unstable link or misconfiguration that can cause route oscillation and excessive BGP UPDATE traffic across your network.

Default Policy

• Threshold: 3 flaps within a 10-minute window triggers the "flapping" state.
• Cooldown: After triggering, re-entry alerts are suppressed for 30 minutes.
• Clear (no flaps): Flapping state clears after 30 minutes with zero new flaps.
• Clear (stable UP): Flapping state clears after 15 minutes of continuous ESTABLISHED state.

Automatic Mitigation

When a session enters flapping state, Spectops automatically:

1. Disables the session (admin-down) to stop route oscillation.
2. Withdraws all announced routes from the session.
3. Sends a CRITICAL notification to the session owner (email, in-app, and webhook based on your preferences).
4. Creates an admin alert visible to all platform administrators.

To restore the session, navigate to the session detail page and manually re-enable it after resolving the underlying issue.

Configuring the Policy

Platform administrators can tune all flap detection parameters in Admin → Platform Settings → Behavior:

• BGP_SESSION_FLAP_THRESHOLD_COUNT — Number of flaps to trigger (default: 3)
• BGP_SESSION_FLAP_WINDOW_SECONDS — Detection window (default: 600s / 10 min)
• BGP_SESSION_FLAP_COOLDOWN_SECONDS — Alert suppression after trigger (default: 1800s / 30 min)
• BGP_SESSION_FLAP_CLEAR_UP_SECONDS — Continuous UP to clear (default: 900s / 15 min)
• BGP_SESSION_FLAP_CLEAR_NO_FLAP_SECONDS — No-flap duration to clear (default: 1800s / 30 min)
• BGP_SESSION_FLAP_AUTO_DISABLE_ENABLED — Toggle auto-disable on/off (default: on)