Map RTBH containment failures before they become route leaks

Introduction to Remote Triggered Blackhole Design

Remote Triggered Blackhole (RTBH) injects a specially‑crafted route (usually a /32 host route or a more specific prefix) into the routing infrastructure so that matching packets are forwarded to a null0 or discard‑only next‑hop. The trigger is typically a BGP community, a static route, or a route‑map set by a detection system (DDoS scrubber, IDS/IPS) and propagated to edge or core routers.

RTBH is a containment primitive, not a policing mechanism. Its goal is to drop malicious traffic as close to the source as possible while ensuring the drop‑instruction does not leak beyond the intended trust boundary and affect legitimate traffic elsewhere.

Blackhole Intent and Containment Objectives

Failure of any boundary—most often a missing or mis‑configured outbound route filter—turns the local mitigation into an upstream leak, propagating the discard instruction to peers or transit providers and causing unintended denial‑of‑service for innocent destinations.

Understanding Blackhole Propagation

Network Topology Considerations

RTBH relies on the underlying routing topology to carry the trigger. Typical deployments fall into three patterns:

1. Edge‑only injection – Detection system injects a static blackhole route on the edge router; the route is redistributed into iBGP (or IS‑IS/OSPF) only within the AS.
2. BGP community‑based injection – Detection system sends a BGP UPDATE with a well‑known community (e.g., 65000:666) to a route‑reflector; routers with a matching inbound route‑map install the blackhole next‑hop.
3. Central controller model – An SDN controller pushes flow‑rules that install a discard action; the controller communicates via NETCONF/gNMI or gRPC to the forwarding plane.

The propagation path is the set of routers that receive the UPDATE (or redistribution) and install the blackhole. Containment requires that this set be exactly the intended enforcement domain.

Traffic Flow and Blackhole Triggering Mechanisms

If step 6 is missing or mis‑configured, the blackhole route leaks to external peers (transit, customers, or IXPs), turning a local containment into an upstream denial‑of‑service.

Containment Strategies and Policy Boundaries

Network Segmentation and Isolation Techniques

• VRF‑lite / VRF‑aware RTBH – Install the blackhole only in a dedicated VRF used for mitigation traffic; keep the global routing table clean.
• Separate routing instances for peers – Use distinct peer‑groups or confederations so that outbound filters can be applied per‑group without affecting others.
• Physical/logical separation – Place detection systems on an out‑of‑band management network; only inject routes into the data plane via a tightly‑controlled redistribution point.

Access Control Lists (ACLs) and Firewall Rules

ACLs provide defense‑in‑depth, catching packets that might escape the null0 due to mis‑ordered route‑maps or overlapping prefixes.

Cisco IOS‑XR – inbound ACL on the edge interface

ipv4 access-list BLACKHOLE-ACL
  10 deny ipv4 any 203.0.113.45/32
  20 permit ipv4 any any
!
interface GigabitEthernet0/0/0/0
  ipv4 access-group BLACKHOLE-ACL ingress

If the routing blackhole fails (e.g., route not installed), the ACL still enforces the drop. Conversely, an ACL that permits the blackhole prefix (mis‑ordered ACE) can become a leak path.

Route Filtering and Redistribution Policies

The core containment mechanism is outbound route filtering at the point where the blackhole route could leave the trusted domain.

• Prefix‑list based outbound filter – Explicitly deny the specific /32 (or aggregated) blackhole prefix.
• Community‑based outbound filter – Deny any route carrying the blackhole community.
• Outbound route‑filter (ORF) – Signal the peer to stop sending the blackhole route upstream (useful for BGP peers that support ORF).

Junos – outbound filter suppressing community 65000:666

policy-options {
    policy-statement BLACKHOLE-OUT {
        term deny-bh {
            from {
                community [ BLACKHOLE ];
            }
            then reject;
        }
        term accept-all {
            then accept;
        }
    }
}
community BLACKHOLE members [ 65000:666 ];
protocols {
    bgp {
        group internal {
            type internal;
            neighbor 10.0.0.2 {
                export [ BLACKHOLE-OUT ];
            }
        }
    }
}

If the export statement is omitted or mis‑typed, the blackhole route will be advertised to external peers.

Identifying and Mitigating Blackhole Leaks

Troubleshooting Methodologies and Tools

1. Verify local installation – show route <prefix> or show ip bgp <prefix> to confirm the null0/discard next‑hop.
2. Check outbound policy – show route advertising-protocol bgp <neighbor> (IOS) or show route receive-protocol bgp <neighbor> (Junos) to see what is being sent.
3. Capture BGP updates – Enable BMP or debug bgp updates on a route‑reflector to observe whether the blackhole community appears in updates sent to peers.
4. Flow analysis – NetFlow/IPFIX or sFlow to see if traffic destined for the blackhole prefix is still reaching upstream interfaces.
5. Packet capture – Mirror the interface facing the peer and confirm that packets are dropped locally versus forwarded.

Analyzing Network Logs and Traffic Patterns

• Syslog – Look for %BGP-5-ADJCHANGE or %RPKI-3-ROUTE_INVALID messages that may indicate a route flap coinciding with the blackhole event.
• RPKI/ROA logs – Ensure the blackhole prefix is not unintentionally validated as legitimate (which could suppress the discard).
• Interface counters – A sudden rise in outbound drops on the null0 interface (show interfaces null0) versus steady inbound traffic on the peer link suggests a leak.

Code Examples: Configuring ACLs and Route Filters

Cisco IOS‑XR – ACL + outbound route‑map

! 1. Define blackhole prefix
ipv4 prefix-list BLACKHOLE-PREFIX seq 5 permit 203.0.113.45/32

! 2. Route‑map to suppress advertisement
route-map BLACKHOLE-OUT deny 10
  match ip address prefix-list BLACKHOLE-PREFIX
!
route-map BLACKHOLE-OUT permit 20
  set community 65000:666 additive   ! optional: tag for internal tracking

! 3. Apply to eBGP neighbor (upstream transit)
router bgp 65000
  neighbor 203.0.113.1 remote-as 65001
  address-family ipv4 unicast
    send-community both
    neighbor 203.0.113.1 route-map BLACKHOLE-OUT out

Junos – ORF to suppress blackhole advertisement

policy-options {
    policy-statement ORF-BLACKHOLE {
        term reject-bh {
            from {
                community [ BLACKHOLE ];
            }
            then reject;
        }
        term accept {
            then accept;
        }
    }
}
community BLACKHOLE members [ 65000:666 ];
protocols {
    bgp {
        group transit {
            type external;
            neighbor 203.0.113.1 {
                peer-as 65001;
                orphan;
                import [ ORF-BLACKHOLE ];
            }
        }
    }
}

CLI Examples: Verifying Blackhole Containment

Verify local blackhole installation (IOS‑XR)

RP/0/RP0/CPU