Distributed Denial of Service (DDoS) attacks at layers 3 and 4 are blunt, fast, and disruptive. If you’re running networks at any scale, chances are you’ve already seen your fair share of UDP floods, TCP SYN storms, and other packet-level abuse.
Detection is step one. But what comes next, or how (how fast) you mitigate these attacks, is what really determines whether you’re back to normal in seconds or stuck firefighting for hours.
How to filter a DDoS attack at the routing layer?
When a DDoS attack hits, upstream bandwidth and router CPU are often your most limited resources. Two popular BGP-based approaches help you mitigate:
- Flow Spec, for fine-grained, rule-based filtering based on IP, ports, protocol, TCP flags, and more.
- RTBH, for quickly dropping all traffic to a target prefix, typically using a Null0 route.
Both approaches rely on injecting routes via BGP, which means they can scale across providers, peers, or transit depending on your setup. This guide walks through these two practical, well-tested methods for filtering DDoS traffic at scale using BGP. We’ll look at how they work, when to use them, configuration examples, and the trade-offs involved.
BGP Flow Spec: granular filtering in real-time
Flow Spec allows you to push specific traffic-matching rules directly into routers via BGP. It’s especially useful when you want to stop an attack without disrupting all traffic to the destination.
How Flow Spec works
- Flow monitoring tools (like NetFlow, sFlow, or IPFIX) identify a potential DDoS pattern.
- A filtering rule is generated i.e., to “block UDP traffic to port 53”.
- That rule is sent over BGP to supported routers, which apply it immediately.
- Traffic matching the rule is dropped, rate-limited, or redirected, depending on the action defined.
- See a ground-up explanation and visual diagrams on BGP flowspec here
Example: FastNetMon Flow Spec config
bash CopyEdit # Enable BGP and FlowSpec globally sudo fcli set main gobgp enable sudo fcli set main gobgp_flow_spec_announces enable sudo fcli set main gobgp_flow_spec_default_action discard # Optional: rate-limit instead of discard sudo fcli set main gobgp_flow_spec_rate_limit_value 1000000 # Enable on your BGP router session sudo fcli set bgp my_router ipv4_flowspec enable sudo fcli commit
Considerations
- Platform support: Flow Spec is widely supported on Juniper, Cisco, Arista, Huawei, and others, but with quirks. See what fields your platform supports (especially TCP flags and fragments).
- Rule validation: Some platforms ignore invalid combinations silently. Always test.
- Monitor live rules: Use tools to track what’s currently announced and how traffic is responding.
RTBH: The all-or-nothing approach
RTBH is the oldest trick in the book for DDoS mitigation, and it still works. Instead of matching on ports or flags, you simply drop all traffic to a prefix by advertising a route to a special next-hop (usually Null0). It’s simple, fast, and works even on routers without Flow Spec support.
When to use RTBH
- When you’re under a high-volume flood and need to cut traffic immediately
- If upstream providers don’t support Flow Spec
- As a fallback for attacks where packet-level filtering is too slow or doesn’t apply
How RTBH works
- A BGP route is announced with a predefined next-hop (e.g., 192.0.2.1)
- Routers apply the drop action to all traffic towards that prefix
- BGP communities are used to control the reach and scope of the announcement
- See a ground-up explanation and visual diagrams on BGP Blackhole here
Example: FastNetMon RTBH config (goBGP)
bash CopyEdit sudo fcli set bgp my_router ipv4_unicast enable # RTBH settings (example using goBGP or ExaBGP) # On attack detection: # exabgp_next_hop=192.0.2.1 # exabgp_community=65001:666 sudo fcli commit
Edge router example (Cisco IOS-XE)
bash CopyEdit router bgp 65000 neighbor 10.10.2.2 remote-as 65000 neighbor 10.10.2.2 send-community ip route 192.0.2.1 255.255.255.255 Null0 ip community-list expanded RTBH permit 65000:666 route-map RTBH permit 10 match community RTBH set ip next-hop 192.0.2.1 router bgp 65000 neighbor 10.10.2.2 route-map RTBH in
Flowspec vs RTBH: A quick comparison
| Feature | BGP Flowspec | RTBH (Null Routing) |
| Granularity | Packet-level (ports, flags) | Prefix-level (all-or-nothing) |
| Speed | Fast (2–5 sec detection + push) | Fast (similar detection + drop) |
| Network load | Low — just bad flows | High — all traffic dropped |
| Support quirks | Some vendor caveats (IPv6, flags) | Widely supported, simpler |
| Collateral impact | Minimal | High — legitimate traffic lost |
Real-world tips for safer, smarter mitigation
- If you can, start with Flow Spec, and escalate to RTBH if things get out of hand.
- Don’t assume all platforms behave the same. Lab-test Flow Spec if possible, and document any quirks in your network.
- Use timers or auto-unblock where possible to remove stale rules.
- Log everything – both what you’re announcing and what gets dropped.
DDoS attacks are noisy, stressful, and often cause disproportionate damage. The best thing you can do is prepare, test, and automate as much of the response as possible. Both BGP Flow Spec and RTBH are time-tested tools that give you control over what enters your network, and what gets stopped at the gate. If you’re running a NOC, peering network, or backbone and haven’t integrated these into your toolkit yet, now’s the time.
About FastNetMon
FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats.For more information, visit https://fastnetmon.com