BGP Flowspec: RTBH’s Smarter, More Surgical Sibling

If you’ve read the previous post on BGP RTBH, you already know the core appeal of blackhole routing: it’s fast, it’s simple, and it puts the attack traffic on the floor before it ever consumes your upstream link. You also know the catch. The moment you blackhole a prefix, legitimate traffic toward that destination disappears right alongside the attack. You’ve stopped the flood, but the service is still down. For a lot of attack scenarios, that’s an acceptable tradeoff, and RTBH is the right tool. But there’s a large class of DDoS attacks where that tradeoff doesn’t hold up — and that’s where BGP Flowspec comes in.

Flowspec was built to answer a specific question: what if instead of just telling the network “drop everything going to this IP,” you could say “drop UDP traffic going to this IP on port 53 from these source ranges, but let everything else through”? That level of specificity turns a blunt instrument into something that can actually distinguish attack traffic from legitimate traffic at line rate, across the entire network, without touching a single router’s ACL configuration by hand.

What Flowspec actually does differently

The fundamental limitation of RTBH is that it only gives you one match criterion: destination prefix. If an IP is under attack, you blackhole the destination, and that’s it. There’s no concept of “only drop traffic that looks like this attack.” Flowspec, defined originally in RFC 5575 and substantially updated in RFC 8955 for modern deployments and IPv6 support, solves this by introducing an entirely new BGP address family — the Flow Specification NLRI — that carries multi-field traffic rules instead of simple destination prefixes.

Where a normal BGP update carries a prefix and some attributes describing how to reach it, a Flowspec update carries a set of match conditions and an action to perform on matching traffic. The match conditions can include destination prefix, source prefix, IP protocol, source port, destination port, TCP flags, packet length, DSCP value, and IP fragment type — up to twelve different components that can be combined in a single rule. The action is carried as a BGP extended community and can tell the receiving router to drop the traffic, rate-limit it to a specified bandwidth, redirect it to a different VRF (useful for steering it toward a scrubbing system), or remark the DSCP marking. That combination of granular matching with programmable actions is what makes Flowspec genuinely different from anything that came before it in the BGP toolbox.

The other thing that sets Flowspec apart is where the intelligence lives. In a traditional ACL-based response to a DDoS attack, you’re manually logging into routers, writing access lists, applying them to interfaces, and repeating that process across every device in the path. If the attack changes character — different source ports, different protocol, shifted to a new destination — you’re doing it all again. Flowspec takes that entire workflow and moves it into BGP. One update from a controller or detection system reaches every BGP peer simultaneously, rules propagate in seconds, and removing them is a BGP withdrawal, not a manual ACL cleanup across a dozen boxes.

How the rule propagation works in practice

On the wire, a Flowspec rule is encoded as a new NLRI type inside the L2VPN/Flow Specification address family in a BGP UPDATE message. Routers that have the Flowspec address family activated on their peering sessions receive these updates alongside their normal routing updates and install the rules directly into hardware — in TCAM, on platforms that support it — rather than into the routing table. The distinction matters because TCAM lookup happens at line rate in the forwarding ASIC, so a Flowspec rule that drops matching traffic costs the same in forwarding performance as not having the rule at all. There’s no software path hit, no CPU involvement on a per-packet basis.

Rules are applied with an implicit priority ordering based on specificity, with more specific rules taking precedence over broader ones. A rule matching both a specific destination prefix and a specific source port beats a rule matching just the destination prefix alone, so an operator can layer rules from broad to specific without worrying about ordering conflicts the way you would with a traditional ACL.

One important detail for operators coming from an RTBH background: Flowspec and RTBH are not mutually exclusive and they’re often used together in a layered response. A common operational pattern is to deploy Flowspec rules at your own edge to handle attacks that are below your link capacity, filtering specific attack flows while keeping the destination reachable for legitimate traffic. If the attack volume escalates beyond what your own infrastructure can absorb cleanly, you then escalate to RTBH toward your upstream transit providers to drop the volumetric traffic before it hits your link. Flowspec gives you the surgical option first; RTBH is the last resort when volume alone becomes the problem.

Enabling and verifying Flowspec on Arista EOS

Arista has supported BGP Flowspec since EOS 4.21.3F, and the feature is programmed into hardware TCAM on supported platforms including the DCS-7280R and DCS-7500R series. One prerequisite worth knowing up front: Flowspec on Arista requires the multi-agent routing model, which you may already have enabled if you’re running EVPN or other modern features.

The base configuration to enable the Flowspec address family on a BGP session looks like this:

service routing protocols model multi-agent
!
interface Ethernet1
   flow-spec ipv4
   flow-spec ipv6
!
router bgp 65000
   neighbor 192.0.2.1 remote-as 65001
   neighbor 192.0.2.1 send-community extended
   neighbor 192.0.2.1 maximum-routes 12000
   !
   address-family flow-spec ipv4
      neighbor 192.0.2.1 activate
   !
   address-family flow-spec ipv6
      neighbor 192.0.2.1 activate
!

The flow-spec ipv4 and flow-spec ipv6 statements on the interface are what tell EOS to apply received Flowspec rules to traffic arriving on that interface. Without those, the switch will accept and propagate Flowspec updates via BGP but won’t enforce them in the dataplane — a subtle point that trips people up in initial deployments.

On Arista, Flowspec rules themselves are typically injected by an external controller or detection system such as ExaBGP or a dedicated DDoS mitigation platform, which establishes an iBGP session with the switch and sends Flowspec BGP UPDATEs when an attack is detected. Once rules are installed, you can verify them with:

show bgp flow-spec ipv4 detail

Which will output something along these lines for an active rule dropping UDP port 53 traffic toward an attacked host:

BGP Flow Specification rules for VRF default
Router identifier 192.0.2.10, local AS number 65000

BGP Flow Specification Matching Rule for 203.0.113.50/32;*;IP:17;DP:53;
   Matching Rule:
      Destination Prefix: 203.0.113.50/32
      Source Prefix:      *
      IP Protocol:        17 (UDP)
      Destination Port:   53
   Paths: 1 available
      Actions: Drop

That rule is doing something RTBH fundamentally cannot: it is dropping only UDP port 53 traffic destined for that host. DNS queries from legitimate resolvers hitting a different port or protocol pass through untouched. The host stays reachable for everything except the exact traffic profile of the attack.

To verify that rules are actually installed in the dataplane and not just held in the BGP table, show flow-spec ipv4 will show you the hardware-programmed state. On Arista, you can also pull per-rule packet and byte counters from this command once EOS 4.23 or later is running, which is useful for confirming that rules are actually matching traffic and not just sitting there unused.

The real-world attack scenarios where this shines

DNS amplification and NTP reflection attacks are the classic use cases, and Flowspec was almost tailor-made for them. Both attack types have well-defined traffic signatures: UDP, specific source or destination ports, often with anomalous packet sizes. A Flowspec rule matching on UDP destination port 53 (or 123 for NTP) toward the victim, with a drop or rate-limit action, can surgically remove the amplified flood while leaving legitimate DNS or NTP traffic to that host completely intact. That’s simply not achievable with RTBH.

SYN flood attacks present a slightly different case. Because SYN packets are TCP with a specific flag pattern and no corresponding connection state, a Flowspec rule matching on TCP with the SYN flag set and no ACK can rate-limit the SYN traffic without touching established connections that are already passing the host’s normal TCP handshakes. The granularity here is the kind of thing that would have required a stateful firewall or purpose-built scrubbing appliance in the past — Flowspec pushes it into the network fabric itself, distributing the enforcement to every router that receives the BGP update rather than concentrating it at a single chokepoint.

Rate-limiting rather than dropping is worth calling out specifically. The redirect-to-VRF action, which steers matching traffic into a separate routing context rather than dropping it, is how operators deploy Flowspec in conjunction with inline scrubbing. Traffic matching the attack profile gets redirected into a “dirty” VRF where a scrubbing device inspects it and returns clean traffic to a separate “clean” VRF for delivery. The scrubber can do deep-packet inspection and strip the attack traffic, and only the clean portion reaches the destination. That architecture, Flowspec as the traffic steering mechanism with a scrubber doing the actual cleaning, is what purpose-built DDoS mitigation services largely implement at their core, even if they don’t always describe it in those terms.

What to know before deploying it

There are a few operational realities worth understanding before treating Flowspec as a production tool. The first is hardware support. Flowspec rules are programmed into TCAM, and TCAM is a finite resource shared with ACLs, QoS policies, and other forwarding table features. On Arista platforms, a simple IPv4 Flowspec rule typically consumes one TCAM entry, while IPv6 rules consume two. Rules with port ranges can expand significantly because the hardware expands ranges into individual entries. In a network under active attack where rules are being generated dynamically, it’s worth understanding your platform’s TCAM limits and monitoring headroom to avoid a situation where rule installation silently fails.

The second consideration is the controller. Unlike RTBH, where you can fire off a BGP route by hand from a router CLI in about thirty seconds, Flowspec is almost always driven by a detection system or controller that generates the rules programmatically. Getting that detection-to-mitigation pipeline built, tested, and validated before an attack is happening is important, because the value of Flowspec is speed of response. If the first time you’re figuring out how the controller works is during an active incident, you’ve lost the advantage the protocol was designed to give you.

The third is upstream provider support. Flowspec toward your transit provider, the equivalent of what RTBH offers with a blackhole community, requires that your provider’s PE routers support and accept Flowspec updates and have it enabled on their peering session with you. Adoption varies by provider and is generally less universal than RTBH support, which has been around long enough that most major transit providers offer it. It’s worth confirming with your transit contacts whether they support Flowspec peering and what their specific match and action capabilities are before depending on it as part of your upstream mitigation strategy.

RTBH and Flowspec together

The right mental model is to think of RTBH and Flowspec as complementary tools operating at different levels of precision and at different scales of response. Flowspec is the first line — granular, surgical, service-preserving. RTBH is the escalation path when volume alone is the threat and the link itself needs protecting. Understanding both and having both configured and tested before you need them is the point. DDoS mitigation is one of those areas where the time to learn how the tool works is very much not during the outage.