RTBH: Remote Triggered Blackhole Routing

February 24, 2026 · 7 min read

A massive DDoS attack is saturating your upstream link. Your entire network is affected because one target is receiving gigabits of attack traffic. You can’t filter it — there’s too much. You can’t absorb it — your link is overwhelmed.

RTBH (Remote Triggered Blackhole) tells your upstream provider: “Drop all traffic to this IP.” The attack traffic is discarded at the upstream, before it reaches your network. Your target is offline, but your network survives.

RTBH sacrifices the target to save the network.

How RTBH Works

Normal:
Attack ─→ [ISP] ─→ [Your Router] ─→ [Victim Server]
                   │ Link saturated
                   └─→ [Other Servers] (collateral damage)

With RTBH:
Attack ─→ [ISP] ─✕─ (traffic blackholed)

         [Your Router] ─→ [Victim Server] (unreachable, but attack stopped)
                      └─→ [Other Servers] (working normally)

RTBH Setup

Prerequisites

BGP session with upstream provider
Agreement on blackhole community (e.g., ISP_ASN:666)
Prefix you can announce (/32 or /24 depending on ISP)

Configure Blackhole Route

configure

# Create blackhole next-hop
set protocols static route 192.0.2.1/32 blackhole

# This creates a null route locally
# Packets to 192.0.2.1 are dropped

commit

Configure BGP to Announce Blackhole

configure

# Define blackhole community (check with your ISP)
set policy community-list ISP-BLACKHOLE rule 10 regex "65000:666"

# Route map for blackhole announcements
set policy route-map BLACKHOLE-OUT rule 10 action permit
set policy route-map BLACKHOLE-OUT rule 10 match ip address prefix-list BLACKHOLE-PREFIXES
set policy route-map BLACKHOLE-OUT rule 10 set community "65000:666"
set policy route-map BLACKHOLE-OUT rule 10 set origin igp

# Regular announcements
set policy route-map BLACKHOLE-OUT rule 20 action permit

# Apply to BGP neighbor
set protocols bgp neighbor 10.0.0.1 address-family ipv4-unicast route-map export BLACKHOLE-OUT

commit

Triggering RTBH

Manual Trigger

configure

# Add victim IP to blackhole prefix list
set policy prefix-list BLACKHOLE-PREFIXES rule 10 prefix 203.0.113.100/32
set policy prefix-list BLACKHOLE-PREFIXES rule 10 action permit

# Ensure route exists
set protocols static route 203.0.113.100/32 blackhole

commit

# ISP receives announcement with blackhole community
# ISP drops all traffic to 203.0.113.100

Remove Blackhole

configure

# Remove from prefix list
delete policy prefix-list BLACKHOLE-PREFIXES rule 10

# Remove blackhole route
delete protocols static route 203.0.113.100/32

commit

# ISP removes blackhole, traffic flows again

Trigger Router Architecture

Dedicated Trigger Router

                              ┌─────────────────┐
                              │ Trigger Router  │
                              │ (announces /32) │
                              └────────┬────────┘
                                       │ iBGP
┌────────────────────────────────────────────────────────────┐
│                    Your Network                            │
│  [Border1] ════════════════════════════════ [Border2]      │
│      │                                           │         │
│      └───────────────[ISP A]───────────────────┘           │
└────────────────────────────────────────────────────────────┘

Trigger router announces /32 with blackhole community
Border routers learn and propagate to ISP
ISP drops traffic to the /32

Trigger Router Configuration

configure

# Trigger router (separate from border routers)
set protocols bgp system-as 65001
set protocols bgp router-id 10.255.0.100

# iBGP to border routers
set protocols bgp neighbor 10.255.0.1 remote-as 65001
set protocols bgp neighbor 10.255.0.2 remote-as 65001

# Blackhole routes announced via iBGP
# Border routers then announce to ISP with community

commit

Destination-Based vs Source-Based RTBH

Destination-Based (Common)

# Drop traffic TO the victim
# Victim is unreachable but network saved

set protocols static route 203.0.113.100/32 blackhole
# Announce 203.0.113.100/32 with blackhole community

Source-Based (If ISP Supports)

# Drop traffic FROM attacker
# Victim remains reachable
# Requires ISP support for S-RTBH

# Much less common
# Check with your specific ISP

Automation

Trigger Script

#!/bin/bash
ACTION=$1
TARGET=$2

VYOS_API="https://localhost/api"
API_KEY="your-api-key"

case $ACTION in
    add)
        # Add blackhole route
        vtysh -c "configure terminal" \
              -c "ip route $TARGET/32 blackhole"

        # Add to prefix list
        # (requires API or direct config manipulation)
        echo "Blackhole triggered for $TARGET"
        ;;
    remove)
        vtysh -c "configure terminal" \
              -c "no ip route $TARGET/32 blackhole"
        echo "Blackhole removed for $TARGET"
        ;;
esac

Integration with Monitoring

#!/bin/bash
# Monitor traffic to critical IPs
# If threshold exceeded, trigger RTBH

THRESHOLD_PPS=1000000  # 1M pps

for ip in $(cat /config/protected-ips.txt); do
    PPS=$(get_pps_to_ip $ip)  # Your monitoring tool

    if [ $PPS -gt $THRESHOLD_PPS ]; then
        /config/scripts/trigger-rtbh.sh add $ip
        alert_team "RTBH triggered for $ip (${PPS} pps)"
    fi
done

ISP Community Reference

Common Blackhole Communities

# Format: ISP_ASN:666 (common convention)

# Check with your specific ISP
# Examples (verify before use):
# Level3:    3356:666 or 3356:9999
# NTT:       2914:666
# Cogent:    174:666
# Your ISP:  Check their BGP community documentation

Multiple Upstreams

configure

# Different community per upstream
set policy route-map BLACKHOLE-OUT-ISP1 rule 10 set community "65001:666"
set policy route-map BLACKHOLE-OUT-ISP2 rule 10 set community "65002:666"

# Apply to respective neighbors
set protocols bgp neighbor 10.0.0.1 address-family ipv4-unicast route-map export BLACKHOLE-OUT-ISP1
set protocols bgp neighbor 10.0.1.1 address-family ipv4-unicast route-map export BLACKHOLE-OUT-ISP2

commit

Verification

Check Local Blackhole

# Verify blackhole route installed
show ip route 203.0.113.100

# Should show:
# B>* 203.0.113.100/32 [20/0] unreachable (blackhole), 00:05:00

Check BGP Announcement

# Verify route is being announced
show bgp ipv4 unicast 203.0.113.100/32

# Check communities
show bgp ipv4 unicast 203.0.113.100/32 community

# Should show blackhole community attached

Check with ISP

# Look at ISP's looking glass
# Verify they received the announcement
# Verify they're applying blackhole

# Most ISPs have looking glass tools
# Check route presence and community

Risks and Considerations

Victim Becomes Unreachable

RTBH drops ALL traffic to victim:
- Attack traffic: dropped ✓
- Legitimate traffic: dropped ✓

Victim is completely offline during RTBH
Only use when alternative is worse (entire network down)

Prefix Length Requirements

# Many ISPs only accept /24 or shorter
# /32 announcements may be filtered

# Options:
# 1. ISP accepts /32 with blackhole community (best)
# 2. Announce covering /24 (affects more IPs)
# 3. Use ISP-specific RTBH mechanism

BGP Propagation Time

Trigger RTBH → BGP updates propagate → ISP applies blackhole

Typical: 30 seconds to few minutes
During this time, attack still reaches you

Best Practices

1. Document Procedure

# RTBH Trigger Procedure

## When to Use
- Attack saturating upstream link
- Collateral damage to other services
- Manual filtering impossible

## Steps
1. Confirm attack target IP
2. Notify team/management
3. Execute trigger script
4. Verify with ISP
5. Monitor network recovery
6. Remove blackhole when attack stops

## Contacts
- ISP NOC: +1-xxx-xxx-xxxx
- Internal: @security-team

2. Test Before You Need It

# Test with non-critical IP
# Verify ISP accepts and applies blackhole
# Measure propagation time
# Test removal procedure

3. Have Rollback Ready

# Keep removal procedure ready
# Time-limit blackholes (auto-remove)
# Monitor for attack cessation

4. Combine with Other Measures

RTBH: Nuclear option, saves network
Also use:
- Rate limiting (smaller attacks)
- Upstream scrubbing (sophisticated attacks)
- CDN/DDoS protection (application layer)

The Lesson

RTBH sacrifices the target to save the network.

When to use RTBH:

Attack larger than your link can handle
Collateral damage affecting entire network
No other option available

When NOT to use RTBH:

Attack is manageable with rate limiting
Upstream scrubbing is available
Target availability is critical

RTBH is the last resort. It works by making the victim unreachable to everyone — attackers and legitimate users alike. Use it when the alternative (entire network down) is worse.

Have it configured and tested before you need it. During an attack is not the time to learn RTBH.