What Is BGP FlowSpec?

BGP FlowSpec is a BGP extension that carries packet filtering rules instead of routes. One BGP update describes a traffic flow by destination, source, protocol, ports, packet length, TCP flags, or fragment state, then tells every router that receives it what to do with that flow: discard it, rate limit it, redirect it, or remark it. Standardised in RFC 8955, it turns the routing control plane into a delivery system for firewall rules. This guide covers how a rule is encoded, how it propagates, which attacks it stops, where it quietly fails, and how to roll it out without filtering your own customers.

Key Takeaways

• BGP FlowSpec uses address family 1 with SAFI 133 for IPv4 and SAFI 134 for VPNv4, so rules travel on the same sessions and route reflectors as normal BGP routes.
• A rule combines up to 12 match components, and a packet has to match every component present before the action fires.
• Filtering actions ride in BGP extended communities, with traffic-rate-bytes set to zero acting as the discard action.
• FlowSpec is more precise than remotely triggered blackholing because it drops one flow rather than every packet destined for the victim.
• Received rules are validated against unicast routing, and a rule that fails validation is treated as unfeasible and never installed.
• Hardware capacity, not the protocol, sets the ceiling: filters consume TCAM, and vendors differ in which match types and actions they implement.
• FlowSpec matches on packet headers only, so application-layer floods and encrypted attack payloads need a different control.

What BGP FlowSpec Actually Does to a Packet

BGP FlowSpec installs a filter in the router’s forwarding path, in the same place an access control list would sit, and it gets there over a BGP session rather than through a configuration change. The router already knows how to classify, shape, police and drop packets. FlowSpec simply gives BGP a way to describe which packets and which treatment.

That distinction matters more than it sounds. A conventional BGP route answers one question: where does traffic for this prefix go next? A FlowSpec route answers a different one: what should happen to traffic that looks like this. The routing system stops being purely a map and starts carrying policy, which is why FlowSpec sits at the centre of most modern advanced DDoS mitigation designs at the network layer.

RFC 8955 is direct about the intent. The specification defines the extended communities and distribution mechanism to be used, in its own words, “to mitigate DoS and DDoS attacks”. Everything else in the document exists to make that safe.

Think of it as the difference between closing a motorway and closing one lane. Both relieve pressure. Only one of them lets everybody else keep driving. That single property is what makes operators reach for FlowSpec first when a customer prefix is under attack but still needs to serve real users.

The rule above is a working DNS amplification filter. Notice how narrow it is: only UDP, only source port 53, only packets larger than 512 bytes, only to one host. Everything else on that address keeps flowing. Understanding how those four lines get encoded and shipped is the next step.

How a FlowSpec Rule Is Built and Carried Over BGP

A FlowSpec rule has two halves that travel in different parts of the same BGP update. The match criteria are encoded as network layer reachability information and carried in the MP_REACH_NLRI attribute. The action is carried separately as a BGP extended community.

Which application a rule belongs to is decided by the address family pair. RFC 8955 assigns AFI 1 with SAFI 133 to IPv4 flow specifications and SAFI 134 to the VPNv4 variant, and RFC 8956 extends the same machinery to IPv6. Peers have to advertise the multiprotocol capability for that pair before either side will exchange anything, which gives you a clean on-and-off switch per session.

One encoding detail trips people up. When a FlowSpec route is advertised, the next hop length is set to zero, and the next hop field is ignored. There is no destination to resolve, because the rule is not telling the router where to send traffic.

The match components you can combine

Twelve component types are registered in the IANA Flow Spec Component Types registry. Components must appear in ascending numerical order inside the NLRI, each type may appear at most once, and a packet matches only when it satisfies every component present. That last rule is a logical AND, and it is the reason a badly built rule usually matches nothing rather than matching too much.

Numeric components such as protocol, ports, packet length, and DSCP use a comparison operator with less than, greater than, and equal bits that combine into the operators you would expect, including not equal. TCP flags and fragments use a bitmask operator instead, which is how you write a rule that catches SYN packets or non-initial fragments without touching anything else.

There is a trap worth knowing before you write your first port rule. RFC 8955 states plainly that a port component never matches when the protocol is not TCP or UDP, and never matches on a fragment that is not the first fragment. An attacker who fragments a flood can walk straight past a rule built on ports alone.

The filtering actions a rule can request

RFC 8955 standardises five actions, all encoded as transitive extended communities. Several can be attached to the same rule, and a router that cannot apply all of them treats them as interfering, which is an implementation decision rather than a protocol one.

The discard action is the one people expect and the one that is easiest to get wrong, because there is no discard community. You express a drop by setting traffic-rate-bytes to zero. Any non-zero value polices the flow instead, which is the same principle behind What Is Rate Limiting? at the application layer, applied here to raw packets on a forwarding chip.

traffic-rate-packets was added in RFC 8955 and did not exist in the original RFC 5575. It matters for attacks that are cheap in bandwidth and expensive in packet processing, where a bytes-per-second cap is the wrong instrument entirely.

Two rules, one host, very different blast radius. Which one you reach for depends on how confident your detection is, and that confidence comes from the pipeline that produced the rule.

How BGP FlowSpec Stops a DDoS Attack Step by Step

In production, almost nobody types FlowSpec rules by hand. A detection system watches sampled traffic, decides an attack is running, describes it as a match tuple, and hands that to a controller that speaks BGP. The whole loop is measured in seconds because it has to be.

1. Edge routers export sampled flow telemetry, usually sFlow or NetFlow, to a collector that maintains per host and per-prefix baselines.
2. The detector fires when packets per second, bits per second or a specific vector signature crosses a threshold for a protected prefix.
3. A controller translates the alert into a FlowSpec NLRI plus an action community, choosing discard for a clean signature and a rate limit where legitimate traffic shares the pattern.
4. The controller advertises the rule over its BGP sessions, and route reflectors carry it to every enforcing router exactly as they carry unicast routes.
5. Each receiving router validates the rule, orders it against existing rules, and programs it into hardware so matching packets are dropped at line rate.
6. When the attack stops, the controller withdraws the rule with MP_UNREACH_NLRI and the filter disappears from every router.

Speed is not a nice-to-have here. Cloudflare’s most recent half-year DDoS threat report found that 90.60 percent of network layer attacks finish in under ten minutes, and that it mitigated 935 attacks above one terabit per second across the period. A manual ticket workflow loses that race before it starts, which is exactly the argument made throughout our Volumetric DDoS Attack Guide.

You might be thinking that automation this aggressive is how outages happen. Fair objection. The answer is not to slow the pipeline down; it is to constrain what the pipeline is allowed to say, and the section below covers how.

Why FlowSpec Beats Blackholing for Most Attacks

Remotely triggered blackholing solves a DDoS attack by finishing it. You advertise the victim address with a community that points the next hop to a discard interface, and upstream routers drop everything aimed at that address. The link recovers. The service does not.

FlowSpec changes the unit of mitigation from an address to a flow. The flood is described precisely enough that customer sessions, API partners, and health checks on the same address keep working while the attack traffic is discarded on arrival.

Blackholing does not become obsolete, and treating it that way is a mistake. When an attack is saturating your transit links and the target genuinely has nothing to lose, RTBH is faster to trigger, simpler to reason about, and supported by almost every upstream. Many teams run both, using RTBH as the immediate containment step and FlowSpec as the precise follow-up once the attack is characterised. Our broader breakdown of DDoS Mitigation Techniques covers how those layers fit together.

The harder question is not which tool is better. It is which attacks FlowSpec can describe at all.

Which Attacks FlowSpec Filters Well, and Which Slip Through

FlowSpec reads packet headers. That single fact predicts almost everything about its coverage. Attacks with a distinctive header signature are easy to write rules for. Attacks that look like normal traffic until the payload is parsed are not.

Malformed packet attacks sit in an interesting middle ground. A classic Ping of Death Attack relies on oversized or overlapping fragments, and both the packet length and fragment components describe that shape directly, so a FlowSpec rule can drop it upstream long before a fragile host tries to reassemble anything.

Read the weak column twice, because that is where teams get hurt. A request flood arriving over TLS on port 443 has the same header profile as your best customer. No combination of the twelve component types separates them, and a rule broad enough to catch the flood will take the customer with it.

The Validation Rules That Decide If Your Rule Gets Installed

A FlowSpec route that arrives from a peer is not trusted on sight. RFC 8955 extends the concept of route feasibility so a flow specification is checked against unicast routing before it can be selected and installed.

The logic behind the three conditions is worth internalising because it explains most FlowSpec troubleshooting. The neighbour advertising the best unicast route for a destination is, by definition, the network that traffic is heading toward. If that neighbour asks you to drop some of that traffic, honouring the request costs nobody anything, since the packets were going to be dropped one hop later anyway.

This is also the most common reason a rule silently does nothing. The BGP table shows the FlowSpec prefix, the flowspec table is empty, and nothing in the logs looks broken. The route was received, failed validation, and was excluded as infeasible exactly as designed.

Validation is not static. Because the best matching unicast route can change independently of the rule, routers must revalidate flow specifications whenever unicast routing changes. A rule that was installed this morning can be withdrawn from hardware this afternoon without anyone touching the controller.

RFC 9117 addresses the operational pain this causes inside a single autonomous system. The original rules assume rules originate from a router in the forwarding path, which breaks the moment you want a central controller to originate them. The revised procedure relaxes that requirement for rules originated within your own AS, and also fixes validation for rules received through an internet exchange route server that does not prepend its AS.

How Overlapping Rules Are Ordered, and Why It Is Not an ACL

This is where FlowSpec surprises engineers who think in access control lists. An ACL is evaluated top to bottom in the order you wrote it. FlowSpec has no author-defined order at all.

When several rules could match the same packet, precedence is computed from the rules themselves. Comparison starts with the lowest component type present. A rule that carries a lower numbered component type wins over a rule that lacks it. For destination and source prefixes, the more specific prefix takes precedence. For every other component, the encoded bytes are compared directly.

What that buys you is consistency. Because ordering depends only on rule content, every router in the network reaches the same conclusion regardless of the sequence in which updates arrived. That is essential when a rule reaches one edge router through a route reflector and another through a direct session.

The cost is that you cannot express “permit this, then deny the rest” the way you would in a filter. The nearest equivalent is the terminal bit in the traffic-action community. Leave it unset and evaluation stops at the matching rule. Set it, and the router keeps evaluating later rules, collecting every action it finds, which is how a sample and log rule can coexist with a discard rule.

“Another issue is the hard limit on the number of BGP Flowspec rules.”

Where BGP FlowSpec Runs Out of Road

As a protocol, it is mature, and vendor support is broad. The constraints that bite in production are almost all about hardware and operations.

• Filter capacity is finite. Rules are programmed into TCAM or an equivalent resource, and that space is shared with other features. Complex rules with several value ranges consume more entries than simple ones, so the practical rule count is lower than any headline number suggests.
• Hitting the limit can cost you the session. When a receiving router exceeds the number of rules it will accept, the usual outcome is that the BGP session is torn down, which removes every rule at once rather than just the newest one.
• Visibility is thin. There is no standardised way to report how much traffic each rule dropped. Operators end up leaving rules installed longer than needed because nothing tells them a rule stopped being useful.
• Vendor behaviour varies. Support differs across platforms, line cards and software versions from the same vendor, so a rule that programs cleanly on one edge router can be rejected on another in the same network.
• Transit availability is limited. FlowSpec pays off most when your upstream applies the rules, and the flood never reaches your links, yet comparatively few transit providers offer FlowSpec peering to customers.
• The action set is coarse. Discard, police, redirect, remark, and sample cover a lot, but none of them can inspect a payload or challenge a client.

There is a contrarian reading of all this that is worth taking seriously. FlowSpec’s reputation for being risky comes mostly from deployments that treated it as a general-purpose firewall rather than a narrow, automated, short-lived DDoS control. Used the way the specification describes, with tight scoping and short rule lifetimes, it behaves predictably. Used as a place to park permanent policy, it becomes an unmanaged filter list nobody understands.

Deploying BGP FlowSpec Without Filtering Your Own Customers

Everyone fears the same failure here: a controller advertising a rule broad enough to drop legitimate traffic across the network. That risk is manageable, and it is managed with policy, not caution.

• Run FlowSpec as its own address family on dedicated sessions where you can, so enabling or disabling it never disturbs unicast routing.
• Filter inbound rules on NLRI content. Accept destination prefixes only from within address space you control, and reject anything covering more than a defined prefix length.
• Screen action communities at every border. Rate limiting actions are comparatively safe to accept from third parties. Redirect and remark actions can move traffic into another routing table, so map customer requests to your own communities rather than accepting their action communities directly.
• Cap the accepted rule count per session well below the hardware limit, and alert on the count long before it is reached.
• Give every automatically generated rule an expiry. If the detector has to keep reasserting a rule for it to survive, stale filters clean themselves up.
• Use the sample bit during rollout. Watching what a rule would have matched, before it discards anything, converts an argument into evidence.
• Test on the exact platform and software version you run in production, because match and action support varies by line card.

Choosing Between FlowSpec, Blackholing, and Scrubbing

No single control covers the full range of attacks, and the useful question is which layer should handle a given attack rather than which product wins.

For most organisations that are not carriers, the practical answer is to push absorption outward rather than to build FlowSpec infrastructure. A distributed Anycast Network spreads a flood across many points of presence instead of concentrating it on one link, and a transport layer control such as a layer 4 shield filters connection-level abuse before it reaches origin capacity. FlowSpec then handles the specific case it was designed for: telling other people’s routers what to drop.

If you operate your own AS and your own edge, the calculation flips. FlowSpec is the cheapest precise mitigation you can deploy, because the enforcement hardware is already sitting in your racks.

Final Thought on BGP FlowSpec

BGP FlowSpec earns its place by being precise where blackholing is blunt and fast where manual filtering is slow. A rule that describes a flood by protocol, port, and packet length can be running on every edge router in your network seconds after detection, and the service under attack keeps answering real users the entire time.

The discipline it demands is scoping. Validation, rule ordering and filter capacity are not obstacles to work around; they are the safety rails that let you automate mitigation without automating an outage. Decide which attack classes FlowSpec owns, constrain what your controller may advertise, expire rules automatically, and monitor rule counts as closely as you monitor traffic.

Get that framing right, and FlowSpec becomes a reliable part of the defence rather than a tool teams are afraid to switch on.

Common Questions About BGP FlowSpec